[Home]

Summary:ASTERISK-11159: [patch] Allow Sipura handsets (SPA942) to use Asterisk SLA via implementation of Broadsoft Sip extensions
Reporter:eugene grossi (grossi)Labels:
Date Opened:2008-01-05 10:58:21.000-0600Date Closed:2011-12-29 08:54:02.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13_23_spacfg.xml
( 1) Asterisk-trunk-bugid11688.patch_6_2_11
( 2) asterisk-trunk-bugid11688.patch#2
( 3) asterisk-trunk-bugid11688.patch#3
( 4) extensions_custom.conf
( 5) extensions_customjuly09.conf
( 6) partial_sip_additional.conf
( 7) Patch_doc_for_Broadcom_Ext_compatability_july09.rtf
( 8) sip_additional.conf
( 9) sip_additionaljuly09.conf
(10) SLA_setup_for_sipura_and_asterisk.rtf
(11) sla.conf
(12) slajuly09.conf
(13) spa_16_26_spacfg.xml
(14) zapata-auto.conf
Description:Modifications in chan_sip.c and pbx.h to accommidate rudimentary implementation of Broadsoft SIP Access side extensions with the short term goal of achieving SLA functionality for Sipura phones (tested on SPA942's) .

Currently I have full SLA compatability with SPA942's working as well as integration with other (AASTRA 53i) SLA compatible phones on asterisk.



****** ADDITIONAL INFORMATION ******

In pbx.h:  AST_EXTENSION_REQLINESEIZE was added to ast_extension_states. A Broadsoft shared extension can request a line seize.

In chan_sip.c:
Added subscriptiontype of CALL_INFO.  The Call-Info header is specified in RFC 3261.

Added to the sip_user configuration and sip_pvt declarations "notify_exten" as discussed earlier in the fall on hte developers list. Originally this was going to be used due to lack of a subscription setup on the Sipura phones; Current firmware does generate a subscription to the peer exten automatically now.  I am using this variable to specifically direct the incoming call when a SLA is already active, otherwise the INVITE generated by the broadsoft generates an "incomplete address" from Asterisk.  Should this field be renamed to "sla_connect" ?

Transmit_state_notify subroutine was added and modified to handle CALL_INFO .  Also added state "LINE_SEIZE" used by Broadsoft and  AST_EXTENSION_REQLINESEIZE handler was added.  When a Broadsoft Shared extension requests a line seize, it is automatically granted. When other Broadsoft Shared extensions are sent a notification, there are told the the call is on "hold" (not private). This allows them to join into the SLA if their line key is hit.

Handle_request_invite subroutine was modified. When a Broadsoft Shared extension attempts to INVITE into an active shared call, the address was incomplete. This is checked for and the address is "completed" using the information from the "notify_exten" variable.

Handle_request_subscribe subroutine was modified. Deal with subscription for Line-Seize event and for Call-info subscriptions. Uses Call-info as the subscription type for Linksys user agents.
Comments:By: eugene grossi (grossi) 2008-01-06 09:54:52.000-0600

forgot to state the SPA942 using lastest firmware (5.2.2.(a))
By: Olle Johansson (oej) 2008-01-22 10:00:44.000-0600

You need to remove the tags "grossi patch" all over the code. Thanks.
By: Olle Johansson (oej) 2008-01-22 10:02:59.000-0600

This patch also disables overlap dialing, which it shouldn't.
By: Olle Johansson (oej) 2008-01-22 10:04:39.000-0600

...and, finally, all patches need to apply to svn trunk, not 1.4. Thanks.
By: eugene grossi (grossi) 2008-01-23 17:56:28.000-0600

will resolve all the above noted issues and repost an appropriate patch. thx.
By: eugene grossi (grossi) 2008-02-13 11:53:49.000-0600

Am on hold with this patch for SVN and/ or 1.6 due to the encountered issue I reported yesterday:
0011978: SLA failing in 1.6rcbeta2 with repeated restarting of the meetme conference
This issue in both SVN and 1.6rc has prevented me in the last few weeks from thoroughly testing out the patch. After this is resolved, I will reimplement and fully test out the patch.
By: Olle Johansson (oej) 2008-02-16 04:57:33.000-0600

Ok, I'll wait until you come back then.
By: eugene grossi (grossi) 2008-03-30 17:06:39

I have uploaded pbx.h.tpatch and chan_sip.c.tpatch.

These patches now correct the previously noted deficiencies:
developed on SVN-trunk-r111909M,
corrected the interference with overlap dialing,
and removed unnecessary tags.

Sorry for the delay - when upgrading to the trunk version I also upgraded zaptel to 1.4.8.1 - this caused issues with my Digium TDM400P which I didn't understand. Finally I found a reference to this (http://pbxinaflash.com/forum/showthread.php?t=1025) and rolled zaptel back to 1.4.7 and those problems dissappeared.
By: snuffy (snuffy) 2008-03-30 22:53:55

Minor things I noticed about patch.
Should use 'else if' instead of the consecutive comparisions to statestring
missing some indentation


By: eugene grossi (grossi) 2008-06-07 15:41:05

have cleaned code style as requested; upload patches for trunk version SVN-trunk-r121079M
By: Michiel van Baak (mvanbaak) 2008-06-07 15:59:00

+ if ((p->subscribed == CALL_INFO) | (state == AST_EXTENSION_REQLINESEIZE)) {
+ }
+ else {

that looks wrong to me.
If you dont do anything when those parts are set you should use the negative check
something like:
if (foo != bar & baz != zoo) {
By: Raj Jain (rjain) 2008-06-07 16:06:40

I think what may be intended is conditional || and && not arithmetic | and &.

+ if ((p->subscribed == CALL_INFO) | (state == AST_EXTENSION_REQLINESEIZE)) {
+ }
+ else {

if (foo != bar & baz != zoo) {
By: Mark Brooker (mbit) 2008-08-23 09:28:01

I have an issue trying to patch the chan_sip.c with this patch. Here is my output. The asterisk version I am trying to patch is 1.4.19.

[root@localhost channels]# patch chan_sip.c < /usr/src/chan_sip.c.tpatch
patching file chan_sip.c
Hunk #1 succeeded at 291 (offset -19 lines).
Hunk #2 succeeded at 326 (offset -5 lines).
Hunk #3 succeeded at 928 (offset -252 lines).
Hunk #4 succeeded at 1304 (offset -80 lines).
Hunk ASTERISK-1 succeeded at 1167 (offset -272 lines).
Hunk ASTERISK-2 FAILED at 8561.
Hunk ASTERISK-3 succeeded at 7540 (offset -1393 lines).
Hunk ASTERISK-4 succeeded at 8679 (offset -272 lines).
Hunk ASTERISK-5 succeeded at 7612 with fuzz 2 (offset -1395 lines).
Hunk ASTERISK-6 FAILED at 9923.
Hunk ASTERISK-7 succeeded at 15376 (offset -1102 lines).
Hunk ASTERISK-8 FAILED at 16570.
Hunk ASTERISK-9 succeeded at 16120 (offset -1576 lines).
Hunk ASTERISK-10 succeeded at 18018 with fuzz 2 (offset -1595 lines).
Hunk ASTERISK-11 succeeded at 18266 (offset -1652 lines).
3 out of 15 hunks FAILED -- saving rejects to file chan_sip.c.rej
By: eugene grossi (grossi) 2008-09-20 16:12:31

I have rewritten patches for trunk since removal of struct sip_user {....} from chan_sip.c.
also included are older patches for 1.4.21 since they were requested above.

ACtually hold on this - i found a bug and need to upload fresh patches.


By: eugene grossi (grossi) 2008-09-24 08:35:12

The corrected trunk patches are uploaded today.
Changes reguired included that "picking up" a "call on hold" now requires find_peer() to lookup the appropriate notify_exten in addition to dealing with removal of struct sip_user{}.
I also have a working patch set for 1.4.21 that I have emailed offline to a user for testing. If requested, I will post here.
By: eugene grossi (grossi) 2008-10-14 10:24:41

Sipura released updated firmware which allows for "asterisk" style "blf" for their spa94x sets.
I will proceed and examine/test this firmware change and see if it obviates some of the feature changes I have created.
By: Leif Madsen (lmadsen) 2008-10-14 10:58:32

I'm changing this to confirmed since there is work going on here. What patches need to still be here? (and I will remove the rest.) Also please confirm these are for trunk, and if so, I will update the bug information to reflect that (since it currently says 1.4.16)

Thanks!
By: Leif Madsen (lmadsen) 2008-10-14 10:59:30

Realized this should probably be set to feedback as the original reporter is checking to see if this patch is still needed as a new feature has been implemented in the most recent firmware for the phones involved.
By: Andreas van dem Helge (joak0) 2008-11-20 00:42:54.000-0600

The patch is still needed. As stated by the reporter this also applies to Aastra phones, and it seems Polycom also implements SLA in this manner only. Per the Polycom documentation:

Shared Call Appearance Signaling
                  A shared line is an address of record managed by a call server. The server
                  allows multiple end points to register locations against the address of record.
                  The phone supports shared call appearances (SCA) using the
                  SUBSCRIBE-NOTIFY method in the “SIP Specific Event Notification”
                  framework (RFC 3265). The events used are:
                  •   “call-info” for call appearance state notification
                  •   “line-seize for the phone to ask to seize the line

From    Administrator’s Guide for the Polycom® SoundPoint® IP/SoundStation® IP Family SIP 3.1, page B-10.


By: Leif Madsen (lmadsen) 2009-02-02 15:46:08.000-0600

Ping?

Wondering if there is any work going to be done to move this forward?
By: Per Jessen (pjessen) 2009-02-16 06:07:04.000-0600

The Sipura (Linksys/Cisco) firmware updates mentioned earlier only seem to apply to the SPA9x2 series - I had a look around at www.cisco.com/go/smallbiz for firmware updates for the SPA941, no luck.
By: eugene grossi (grossi) 2009-04-18 19:07:19

have updated the patches for the current trunk - this continues to be a viable solution for the sipura subscriptions. Soory I have been offline for a few months.
By: eugene grossi (grossi) 2009-04-18 19:09:56

this patch works with the latest SPA942 firmware.
By: Leif Madsen (lmadsen) 2009-06-10 12:51:48

Changed status to Ready for Review to see if this code is ready for merge.
By: David Vossel (dvossel) 2009-07-13 16:56:18

Thanks for the patch, I honestly don't have a great understanding of what is actually going on, but I have a few comments on the code alone.

1. In transmit_state_notify() within the extension state switch case
case AST_EXTENSION_REQLINESEIZE:
add_header(&req, "Event" , "Line-Seize");
add_header(&req, "Subscription-State", "active, 14");
Why is the Event header added here rather than in the CALL_INFO subscribed switchcase below like all the others?

2. This may have been caused by later changes to the code, but in transmit_state_notify() I see that tmp->string is added in the CALL_INFO: switch case, add_header(&req, "Call-Info", tmp->str), and once again after the switch case a few lines below, add_line(&req, tmp->str).  I don't really understand why that should happen.

3. There are still some coding guideline issues. http://www.asterisk.org/developers/coding-guidelines.

Avoid unnecessary whitespace at the end of lines.

if and else statements should look like this.
  if (blah) {
      stuff
  } else {
      stuff
  }

Make sure spacing is correct.
  if (blah){     should be     if (blah) {

Those are just a few examples.  Look over the guidelines, I'm sure there are more I may have missed.

Thanks again for the contribution!
By: eugene grossi (grossi) 2009-07-26 16:23:19

Thank you for the comments. I have gone thru cleaning up stylystic issues and white space.

with regards to:
1. In transmit_state_notify() within the extension state switch case
   case AST_EXTENSION_REQLINESEIZE:
       add_header(&req, "Event" , "Line-Seize");
       add_header(&req, "Subscription-State", "active, 14");
Why is the Event header added here rather than in the CALL_INFO subscribed switchcase below like all the others?

in the first section we are only going to send out the Line seize event -basically ignoring it.
in the second switch, CALL_INFO (only if it is not a Line seize event) are we going to send out the appearance state.

with regards to:
2. This may have been caused by later changes to the code, but in transmit_state_notify() I see that tmp->string is added in the CALL_INFO: switch case, add_header(&req, "Call-Info", tmp->str),
and once again after the switch case a few lines below, add_line(&req, tmp->str). I don't really  understand why that should happen.

add_header requires both the "Call-Info" and  tmp->str arguments in addition to the request pointer. When we are out of the switch context, add_line(&req, tmp->str) cannot appropriately add the "Call-Info" header.
so I have to do it in side the switch context.

thanks again for your sugesstions.
By: eugene grossi (grossi) 2009-07-26 16:24:59

oops forgot to mention that the cleaned up patches (for the current trunk version)was uploaded today, as well as a text file giving the rationale for each
patch section.
By: nenadr (nenadr) 2009-07-27 12:45:59

@grossi: Did you managed to get this working with the latest Cisco-Linksys SPA9x2 firmware generation (6.1.5), and if you did, could you be so kind to post necesery steps of phone configuration ?

I have tried but failed - phone's shared line key only starts to fast-blink red (indicating error in subscription process).
By: eugene grossi (grossi) 2009-07-28 19:07:28

yes working with current sipura firmware. i have upload my sla.conf, sip.additional.conf, xml phone configs, and extensions.custom.conf.
let me know if this doesnt resolve any questions.
By: David Vossel (dvossel) 2009-08-03 12:26:37

thanks for the new patch and documentation grossi!  I've been very busy lately, but I'll try and review it shortly.
By: Mark Michelson (mmichelson) 2009-08-11 18:13:31

dvossel asked me to take a look at this patch to give a review. I have a few concerns about it. Note that I am not very familiar with the Broadsoft SLA implementation, so if I say anything that is just plain wrong, I apologize.

1. I think this has the potential to break overlap dialing. Specifically, in handle_request_invite, if a Call-Info header is present, and an extension was not matched in the dialplan, then a channel is allocated so that a pbx may be started on the peer's notify_exten. The problem is that gotdest will be equal to 1 if using overlap dialling. In such a case, we should not make the assumption that the SLA capabilities are being used.

2. I find it troubling that the presence of a Call-Info header in an incoming INVITE is enough to trigger the SLA behavior. RFC 3261 specifies that the Call-Info header can have lots of information about the caller, and of course RFC 3261 knows nothing of any SLA implementation. I unfortunately don't know much about the Broadsoft SLA extensions, but I would expect that the Call-Info header would have some specific value in it to look for.

3. In handle_request_subscribe, you seem to have mixed presence and call-info behavior. For instance, I don't know if this is possible, but what if a Sipura were to send a SUBSCRIBE for event "presence?" The way the patch is coded, just because the phone is a Sipura, it will be subscribed to the call-info event instead. I think the handling of the call-info event needs to be in a different if statement from the "presence" and "dialog" handling.

4. There are some very minor coding guidelines violations, such as not always placing a space after a comma and putting parentheses around the 0 in return (0); Since these are so minor, don't go out of your way to correct them, but keep them in mind for the next time you submit a patch.
By: David Vossel (dvossel) 2009-08-24 16:18:43

grossi,  Can I get an update on the progress of this issue?  Is there anything I can do to help move it along?
By: Leif Madsen (lmadsen) 2009-09-22 08:28:08

Pinging this issue again to see if the reporter still has interest in moving this issue forward. Thanks!
By: eugene grossi (grossi) 2009-10-04 15:10:42

have uploaded new patches to trunk - this only adds sip_cfg.default_notify_exten to sip channel, similar to sip_cfg.default_subscribecontext
By: Leif Madsen (lmadsen) 2009-10-05 12:03:13

Setting to Confirmed now that we have some new patches, yay!

Let me know if this can be moved to Ready for Testing.

Additionally, can someone mention which files can be deleted (or which ones can be kept) so I can clean this up a bit? Thanks again!
By: eugene grossi (grossi) 2010-03-09 15:56:47.000-0600

uploading upted patches for trunk - basically accommidating for the some code being moved into sip.h
By: eugene grossi (grossi) 2010-03-09 16:00:59.000-0600

additionally, patches prior to 3/10 can be deleted.
By: Philip Prindeville (pprindeville) 2010-06-24 22:23:08

Wondering if anything else is holding up this fix, and if it can be committed into 1.6.2 and trunk as well.
By: Paul Belanger (pabelanger) 2010-06-25 07:00:43

Bumping to 'Ready for Testing'.  Round up some more testers and we can move this along.
By: eugene grossi (grossi) 2010-06-29 06:02:38

updated 3 patch files to current SVN trunk as of 6/28/10.
please delete older versions of patches. thx.
By: Paul Belanger (pabelanger) 2010-06-29 06:54:07

Done.  At this point, there is no need to create 3 patch files. Simply checkout subverion, make your changes and export the patch.

$svn diff > my.patch
By: Philip Prindeville (pprindeville) 2010-07-10 16:24:36

I took the last 3 patches and combined them together, but this won't patch against trunk.

Please update and repost.
By: eugene grossi (grossi) 2010-07-14 10:23:21

there were some changes in chan.sip.c that required a little work to patch.
attached is the latest patch.


By: Leif Madsen (lmadsen) 2010-07-14 13:31:18

What can I delete from this issue? There is a lot of "junk" sitting around in the uploads and it'd be ideal to remove anything that isn't necessary here.
By: Philip Prindeville (pprindeville) 2010-07-15 16:04:24

Taking a wild guess, the line:

+                               *callinfo = get_header(req, "Call-Info");

should probably be:

+                               callinfo = get_header(req, "Call-Info");

as I'm getting the warning:

chan_sip.c: In function 'handle_request_invite':
chan_sip.c:21089: warning: assignment makes integer from pointer without a cast
chan_sip.c:21089: warning: 'callinfo' is used uninitialized in this function
chan_sip.c:20647: note: 'callinfo' was declared here

when compiling.
By: Philip Prindeville (pprindeville) 2010-07-15 16:18:14

Fixed above issue, plus the warning about discarding 'const' type.
By: Philip Prindeville (pprindeville) 2010-07-15 16:30:45

lmadsen: all of the patches except the very last can be deprecated.
By: Paul Belanger (pabelanger) 2010-07-15 20:45:48

patches deleted.
By: Philip Prindeville (pprindeville) 2010-07-19 17:46:45

Grossi: please contact me.  You can find my email on asterisk-dev mailing list or on the #asterisk-dev IRC channel (philipp64).

I wanted to ask about (a) updating the configs you've attached, and (b) accompanying this fix with an update to the doc/tex/SLA.tex document as well.

Thanks.
By: Philip Prindeville (pprindeville) 2010-07-21 14:06:05

Would be nice to get this vetted and into 1.8, but my understanding is that's just days away, so that likelihood diminishes daily.
By: Olle Johansson (oej) 2010-07-22 03:52:01

So please tell me what you gain from this that is not supported by using dialog-info instead? Thanks for your help in explaining this.
By: Philip Prindeville (pprindeville) 2010-07-22 14:40:06

Olle: for those of us not as up on the arcania of SIP, and the latest extensions, how likely is it that all devices support this functionality?

For the SPA-94x, it hasn't had a firmware update in 3 years, and as far as I know it's EOE (end-of-engineering).

Having more than one way to implement SLA and BLF might not be a bad thing when dealing with legacy devices.
By: Olle Johansson (oej) 2010-07-23 01:50:54

We still would have to support it, for a very small number of units. Have you checked these phones. I would be surprised if they do not support dialog-info subscriptions. When this patch was created, Asterisk did not support call pickup in dialog-info, so it made sense. As we do that now, I see very little benefits of adding a protocol that is already legacy, and having to support it.
By: eugene grossi (grossi) 2010-07-23 02:37:21

last firmware update was SPA942_6.1.5a on 11/Feb/2009. It still do not believe that subscription via dialog-info but rather via the Broassoft "call-info". I shall however further research the issue.
By: Leif Madsen (lmadsen) 2010-07-26 13:53:06

I'm tending to agree with oej on this one. If this is a legacy implementation for something that Asterisk already supports, and which is only implemented on a device which is already EOL, I don't quite see the point of placing this into 1.8.
By: Philip Prindeville (pprindeville) 2010-07-26 14:32:13

At $150 a pop (or worse) per handset, people are likely to hold onto EOL'd handsets until the blue smoke leaks out.  That's a simple reality.

Besides, while there are some pretty flimsy handsets out there, Sipura's aren't amongst them.  I wouldn't be surprised to see my SPA-942's still in service 5 or 10 years from now.
By: eugene grossi (grossi) 2010-07-26 16:08:10

Just to be clear this patch is to support the Broadsoft sip extensions which are currently used by the SPAs and polycomms as well as Broadsoft compatible devices
By: Olle Johansson (oej) 2010-07-27 02:54:11

A simple google search tells me that SPA 942 does support dialog-info subscriptions. Here's a message from http://www.mail-archive.com/users@lists.opensips.org/msg09676.html

----
SUBSCRIBE sip:2...@sipb.provider.com SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.44:5060;branch=z9hG4bK-30bde5c3;rport.
From: "4590" <sip:4...@sipb.provider.com>;tag=352777379609d209.
To: <sip:2...@sipb.provider.com>.
Call-ID: 461aa94f-dd768...@192.168.0.44.
CSeq: 25000 SUBSCRIBE.
Max-Forwards: 70.
Contact: "4590" <sip:4...@192.168.0.44:5060>.
Accept: application/dialog-info+xml.
Expires: 1800.
Event: dialog.
User-Agent: Linksys/SPA942-6.1.5(a).
Content-Length: 0.
----

Notice the Accept: and the User-Agent: headers :-)
By: Olle Johansson (oej) 2010-07-27 02:55:06

Yes, I know that a lot of old phones support this, but most of them actually supports the new, and standardized, format as well.
By: Leif Madsen (lmadsen) 2010-07-27 08:27:02

If the SPA942's support the standard method, then I'm even more convinced this is unnecessary.
By: Leif Madsen (lmadsen) 2010-07-27 09:56:47

So I spoke with Russell about this today in order to try and figure out where we should go with this.

If the SPA942 truly supports the dialog-info subscription method, then someone needs to setup a few of these phones and do some testing to verify whether this method will work.

Russell doesn't want to close this issue due to "word of mouth" about some feature the phones may support. We need to verify if the phones truly can support the same functionality using Asterisks already built in support.

I agree with Russell that we need to test that functionality before we can truly decide how to move this issue forward. That is currently the blocker.
By: Andreas van dem Helge (joak0) 2010-07-27 10:36:24

The current and old Polycom phones only support SLA via these methods.
SPIP 3.2.2 Admin Guide Page B-10

Shared Call Appearance Signaling
A shared line is an address of record managed by a call server. The server
allows multiple end points to register locations against the address of record.
The phone supports shared call appearances (SCA) using the
SUBSCRIBE-NOTIFY method in the “SIP Specific Event Notification”
framework (RFC 3265). The events used are:
• “call-info” for call appearance state notification
• “line-seize for the phone to ask to seize the line

SPIP 3.2.2 Admin Guide Page B-4

Header Support The following SIP request headers are supported:

Dialog-info *not* listed,


But also I see in the patch that you are detecting based on useragent. There could be a better way to detect? Either way there should be a configuration option.
By: eugene grossi (grossi) 2010-07-27 20:09:20

I verified that with the latest sipura firmware, the SUBSCRIBE with dialog-info+xml is not used with SLA implementation.

SUBSCRIBE sip:33@192.168.100.30 SIP/2.0
...
Event: call-info
User-Agent: Linksys/SPA942-6.1.5(a)

is still used as per Broadsoft SIP Extensions.
By: Olle Johansson (oej) 2010-07-28 14:36:34

Of course, if you configure SLA you will get SLA. The question here is if you configure line subscriptions, using dialog-info like the manual describes, and use the SLA implementation in Asterisk - won't you get the same functionality? Even better, since you then have true line sharing, line pickup and line seize, which you can't get through the sip channel patch.
By: Olle Johansson (oej) 2010-07-28 14:36:37

Of course, if you configure SLA you will get SLA. The question here is if you configure line subscriptions, using dialog-info like the manual describes, and use the SLA implementation in Asterisk - won't you get the same functionality? Even better, since you then have true line sharing, line pickup and line seize, which you can't get through the sip channel patch.
By: eugene grossi (grossi) 2010-07-29 13:22:40

I have read all the firmware release notes and there is no description of a SLA configuration which uses dialog-info. The Sip transcript quoted above is not for SLA  but for programming an "idle line (key) with blf (fnc=blf;sub=2...@$proxy;nme=2036)"

Enabling the Shared line feature for a Line on these phones results call-info (Broadsoft extensions) being used.

Additionally, I believe that there is some confusion - with the current patch we do get true line sharing, line pickup and line seize.
By: Olle Johansson (oej) 2010-07-29 14:14:16

This patch doesn't give the same feature set as the SLA implementation in asterisk today. And assuming that all LInksys subscriptions is Call-Info is just wrong.

I told you that there's no SLA in Linksys phones that use anything else than Call-Info, but there is another subscription method which combined with the SLA in Asterisk gives you the same functionality, and even better. Please try it.
By: eugene grossi (grossi) 2010-07-29 14:28:27

I do not mean to be dense; I shall try again without using the "Shared Line" feature and just program an idle line key to subscribe via dialog-info.
By: eugene grossi (grossi) 2011-06-02 18:25:06

Upload valid patch for current trunk version as of 6/2/11.
Of Note current Cisco SPA series phones use the Broadsoft SLA protocol.
This patch does add functionality to asterisk; while an unused line key can be programmed to subscribe and emulate a 'shared line', the Broadsoft implementation gives the full functionality of a shared extension.
By: Philip Prindeville (pprindeville) 2011-09-06 11:00:44.254-0500

Can we get some movement on this? From what I can tell, the patch author has made all the changes that were requested of him...

By: Paul Belanger (pabelanger) 2011-10-18 12:27:10.441-0500

If that is the case, then uploading the patches to reviewboard is the next step.
By: Matt Jordan (mjordan) 2011-12-27 08:12:13.327-0600

Eugene - are you able to post your patch to Review Board?
By: Matt Jordan (mjordan) 2011-12-29 08:53:54.711-0600

There are licensing issues with Broadsoft that prevent the inclusion of this patch into Asterisk.  At this time, to prevent any further confusion regarding this work, I'll be closing this issue as suspended.  If those licensing issues are resolved this issue can be reopened.
By: Philip Prindeville (pprindeville) 2011-12-29 11:37:28.281-0600

Wait... what? I have Sipura phones and need this functionality also.

Can we trim away the Broadsoft-specific parts and run with it?