Summary:	ASTERISK-08333: [patch] implement basic "Shared Lines" functionality
Reporter:	Damien Wedhorn (wedhorn)	Labels:
Date Opened:	2006-12-11 14:25:08.000-0600	Date Closed:	2011-06-07 14:02:51
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_skinny
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) shared.patch
Description:	Patch attached introducing basic shared line functionality into skinny. With this patch, if two devices register to the same line, it becomes a shared line (eg Line1@Device1 and Line1@Device2 means that Line1 is shared). Shared lines status is indicated on devices registering that line (that is, they indicated line in use, not in use, hold etc). Lines can be held on one device and unheld on another without the need to transfer. As part of the development a couple of other features snuck into this code. First, added a CLI command 'skinny show status' which provides a couple of tables of the status of lines and devices, should be fairly self explanatory and is handy for debugging shared lines stuff. Second, the wife got sick of the phones ringing at 6am (that's the only time I have for this stuff) so I implemented a dial option 'silent' for silent rings. Basic format in extensions.conf is 'Dial(SKINNY/Line/silent)'. Only silent implemented but other options should be easy to add. Code has been tested on VIP30/SP12 phones and generally works, but work on locking needed. I doubt the soft keys work correctly (nothing to test them with). Call waiting needs work and is probably broken (did it work previously?), how should we handle call waiting on shared lines, it could be very messy (eg, a single line with subchannels on different devices is asking for trouble). ****** ADDITIONAL INFORMATION ****** Basic funtionality of shared lines. Dial(SKINNY/Line1) - all devices registering Line1 will ring, first to pick up gets the call. Dial(SKINNY/Line1@Device2) - only Device2 will ring, others registered to Line1 will still indicate the line is ringing. Device2 will act normally (pick up the handset to answer), other devices will not answer the call unless that line button is pressed. Hold - A call can be put on hold and only unheld from that device unless the device hangs up. Once the device has been hung up (or another line chosen -> hangup of original line) any other device can pick up the line by pressing the appropriate line button.
Comments:	By: Jason Parker (jparker) 2006-12-11 14:29:12.000-0600 I don't have time right this minute to look at this patch, but you mentioned 30VIP and 12SP...  Completely unrelated to this bug - I have one of each at home, and haven't really looked into how to power them.  Can you provide some insight into that? By: Damien Wedhorn (wedhorn) 2006-12-11 14:50:05.000-0600 They just use 48v dc power supplies. There shouldn't be any issues with the 30VIP, but I have noticed that the 12SP's can have issues and you have to fiddle between connecting the network and connecting the power (something to do with the way POE is implemented I think). While I'm not certain, I believe that the Cisco 79xx power supplies should work (although the plugs may be different). By: Serge Vecher (serge-v) 2007-02-28 13:51:12.000-0600 Russell has recently put in the rewritten SLA code into 1.4 (http://lists.digium.com/pipermail/svn-commits/2007-February/021990.html). Did you have a chance to glance it over? By: Russell Bryant (russell) 2007-03-02 11:13:32.000-0600 This functionality sounds very cool.  However, it really just doesn't fit into the Asterisk philosophy.  We generally try not to add new functionality that is not written in a generic way so that it can be used across different channel types, unless it is not possible or does not make sense to do so. With that said, I would encourage you to take a look at my generic SLA implementation that I recently added to 1.4 and trunk.  Right now, the trunk side works with any channel type.  However, the station side only works for chan_sip.  This is only because no other channel drivers implement the required features to make it work. As far as I know, the only thing that needs to be added to chan_skinny to work is support for extension state subscriptions.  Qwell has told me that he has this part implemented for trunk, but it has not yet been merged. I really want to work with both you and Qwell to make sure that chan_skinny can be used in an SLA environment with Asterisk.  To do that, let's get the extension state subscription code merged and go from there.  We can figure out what else needs to be added to chan_skinny, or what needs to be added to the generic SLA implementation to support features that exist in skinny. By: Jason Parker (jparker) 2007-06-04 18:15:29 I'm going to go ahead and close this for now, per the comments from Russell on 03/02.  If his suggestions don't work, please feel free to reopen this bug so we can get everything worked out. By: Russell Bryant (russell) 2007-06-18 10:19:55 I have been thinking about this type of functionality a lot more lately and I'd like to keep this patch open so I don't forget that it is here.  I'll post more info on my thoughts as I get time to work on it ... By: Russell Bryant (russell) 2007-07-30 15:22:06 I am changing this so that it is not explicitly assigned to me.   I will be keeping it in my list of issues that I am monitoring, though.  I just don't want to prevent anyone else from looking at this and expressing their thoughts, as well. By: Olle Johansson (oej) 2007-12-16 03:15:13.000-0600 Suspending this report. Nothing has happened for a long time and I personally agree that channels shouldn't really implement this concept.