<div>Now it makes sense. I agree that you do need to extend SIP one way or another to acheive the correct key telephone system functionality, because RFC 4235 support alone is not sufficient for many use cases.</div>
<div> </div>
<div>I personally think this is very valuable work as far as supporting SLA with Linksys SPA942s go. But, there are quite a few proprietary SIP extensions involved in this and I'm not sure if these extensions are protected under some kind of intellectual property right.
</div>
<div> </div>
<div>--</div>
<div>Raj</div>
<div> </div>
<div><br><br> </div>
<div class="gmail_quote">On Jan 2, 2008 12:03 PM, Eugene Grossi <<a href="mailto:grossi@cv.med.nyu.edu">grossi@cv.med.nyu.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I apologize for not being clearer. There is no Broadsoft application server<br>in my configuration.<br><br>
My model is simply:<br><br> | SLA Trunks<br> |<br> |<br>------------<br>| Asterisk |<br>------------ <br> | <br> | <br> Asterisk <br>SLA Stations<br><br>However some of my client phones (the Linksys SPA942s)are functioning as SLA
<br>stations using Subscribe/Notify according to Broadsoft Sip Access<br>Extensions. The Specifications Are In "Broadworks Sip Access Side Extensions<br>Interface Specifications -Release 13.0. I have attached it.<br>
<br>My modifications to Asterisk allow theses Linksys stations to Subscribe and<br>Notify using the Broadsoft dialect and work in the Asterisk SLA Station<br>model with full functionality.<br>
<div class="Ih2E3d"><br>gene<br>-------------------------------<br>Eugene A. Grossi, M.D.<br>Professor of Cardiothoracic Surgery<br>New York University School of Medicine<br>Suite 9-V; 530 First Avenue<br>New York, NY 10016
<br>ph (212) 263-7452<br>fax(212) 263-5534<br><a href="mailto:grossi@cv.med.nyu.edu">grossi@cv.med.nyu.edu</a><br>________________________________________<br></div>From: Raj Jain [mailto:<a href="mailto:rj2807@gmail.com">
rj2807@gmail.com</a>]<br>Sent: Wednesday, January 02, 2008 9:58 AM<br>
<div class="Ih2E3d">To: <a href="mailto:grossi@cv.med.nyu.edu">grossi@cv.med.nyu.edu</a>; Asterisk Developers Mailing List<br>Subject: Re: [asterisk-dev] Implementation of Broadsoft Sip Access in<br>Asterisk to enable SLA for Sipura/Linksys
<br><br></div>
<div class="Ih2E3d">Gene,<br><br>I'm trying to better understand what you've developed. It seems that you're<br>trying to share Asterisk SLA trunks w/ a different system (Broadsoft). Is<br>the following a correct representation of your architecture?
<br><br><br></div>
<div>
<div></div>
<div class="Wj3C7c">You speak about something called as CALL_INFO event-package and then<br>reference it to Call-Info: header in RFC 3261. An event-package (RFC 3265)<br>and header are two separate things. There is no standard CALL_INFO event
<br>package in SIP. Likewise, there is no standard Line-Seize event-package in<br>SIP. It seems that these are Broadsoft proprietary SIP event-packages.<br><br>It seems that you've developed these proprietary SIP event-packages in
<br>Asterisk. Why couldn't this be done using the standard dialog-package (RFC<br>4235)?<br><br>The "line sieze" issue that you're trying to solve is an interesting one.<br>Line seize can be accomplished using RFC 4235 (although it is not very
<br>straightforward to do so). Basically, I think the issue you're trying to<br>solve is to show a line busy on other SLA phones while one of the SLA phones<br>has seized the line and is dialing the destination number. I've seen
<br>different commercial PBX vendors handle it in their own proprietary way. So,<br>I can somewhat understand why you've resorted to proprietary SIP<br>event-package for solving the "line seize" problem. But what does the
<br>call-info event-package buy you?<br><br>--<br>Raj<br><br><br>On Jan 1, 2008 12:09 PM, Eugene Grossi <<a href="mailto:grossi@cv.med.nyu.edu">grossi@cv.med.nyu.edu</a>> wrote:<br>> I started out this summer implementing Asterisk SLA for the Sipura/Linksys
<br><br>> handsets. My strategy was to make Asterisk compatible with the Broadworks<br>> sip access side extensions; this would allow the Sipura shared extensions<br>to<br>> be compatible Asterisk SLA.<br>><br>
> Currently I have full SLA compatability with SPA942's working as well as<br>> integration with other (AASTRA 53i) SLA compatible phones. I have<br>described<br>> my implementation strategy below for developer comments, before I post the
<br><br>> code as a potential feature patch.<br>><br>> ****************<br>> Listed below are modifications of Asterisk in chan_sip.c and pbx.h to<br>> accommidate rudimentary implementation of Broadsoft Extensions. The
<br>> specifications in "BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE<br>> SPECIFICATIONS -RELEASE 13.0" were used, with the short term goal of<br>> achieving SLA functionality for Sipura phones (tested on SPA942's).
<br>><br>> To Asterisk:<br>><br>> In pbx.h:<br>> AST_EXTENSION_REQLINESEIZE was added to ast_extension_states. A Broadsoft<br>> shared extension can request a line seize.<br>><br>> In chan_sip.c:<br>
><br>> Added subscriptiontype of CALL_INFO. The Call-Info header is specified in<br><br>> RFC 3261.<br>><br>> Added to the sip_user configuration and sip_pvt declarations<br>"notify_exten"<br>> as discussed earlier in the fall on the developers list. Originally this
<br>was<br>> going to be used due to lack of a subscription setup on the Sipura phones;<br><br>> Current firmware does generate a subscription to the peer exten<br>> automatically now for "shared" extensions. I am using this variable to
<br>> specifically direct the incoming call when a SLA is already active,<br>> otherwise the INVITE generated by the broadsoft generates an "incomplete<br>> address" from Asterisk. Should this field be renamed to "sla_connect" ?
<br>><br>> Transmit_state_notify subroutine was added and modified to handle<br>CALL_INFO<br>> . Also added state "LINE_SEIZE" used by Broadsoft and<br>> AST_EXTENSION_REQLINESEIZE handler was added. When a Broadsoft Shared
<br>> extension requests a line seize, it is automatically granted. When other<br>> Broadsoft Shared extensions are sent a notification, there are told that<br>the<br>> call is on "hold" (not private). This allows them to join into the SLA (by
<br><br>> generating an INVITE) if their line key is hit.<br>><br>> Handle_request_invite subroutine was modified. When a Broadsoft Shared<br>> extension attempts to INVITE into an active shared call, the address was
<br>> incomplete. This is checked for and the address is "completed" using the<br>> information from the "notify_exten" variable.<br>><br>> Handle_request_subscribe subroutine was modified. Deal with subscription
<br>for<br>> Line-Seize event and for Call-info subscriptions. Uses Call-info as the<br>> subscription type for Linksys user agents.<br>><br>> I would appreciate any feedback.<br>> gene<br>><br>><br>> -------------------------------
<br>> Eugene A. Grossi, M.D.<br>> Professor of Cardiothoracic Surgery<br>> New York University School of Medicine<br>> Suite 9-V; 530 First Avenue<br>> New York, NY 10016<br>> ph (212) 263-7452<br>> fax(212) 263-5534
<br>> <a href="mailto:grossi@cv.med.nyu.edu">grossi@cv.med.nyu.edu</a><br>><br>> _______________________________________________<br>> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--/" target="_blank">
http://www.api-digital.com--</a><br>><br>> asterisk-dev mailing list<br>> To UNSUBSCRIBE or update options visit:<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev
</a><br>><br></div></div></blockquote></div><br>