[asterisk-dev] Implementation of Broadsoft Sip Access in Asterisk to enable SLA for Sipura/Linksys

Wed Jan 2 12:57:48 CST 2008

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.

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.

--
Raj

On Jan 2, 2008 12:03 PM, Eugene Grossi <grossi at cv.med.nyu.edu> wrote:

> I apologize for not being clearer. There is no Broadsoft application
> server
> in my configuration.
>
> My model is simply:
>
>   | SLA Trunks
>   |
>   |
> ------------
> | Asterisk |
> ------------
>   |
>   |
>  Asterisk
> SLA Stations
>
> However some of my client phones (the Linksys SPA942s)are functioning as
> SLA
> stations using Subscribe/Notify according to Broadsoft Sip Access
> Extensions. The Specifications Are In "Broadworks Sip Access Side
> Extensions
> Interface  Specifications -Release 13.0. I have attached it.
>
> My modifications to Asterisk allow theses Linksys stations to Subscribe
> and
> Notify using the Broadsoft dialect and work in the Asterisk SLA Station
> model with full functionality.
>
> gene
> -------------------------------
> Eugene A. Grossi, M.D.
> Professor of Cardiothoracic Surgery
> New York University School of Medicine
> Suite 9-V; 530 First Avenue
> New York, NY 10016
> ph (212) 263-7452
> fax(212) 263-5534
> grossi at cv.med.nyu.edu
> ________________________________________
> From: Raj Jain [mailto:rj2807 at gmail.com]
> Sent: Wednesday, January 02, 2008 9:58 AM
> To: grossi at cv.med.nyu.edu; Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] Implementation of Broadsoft Sip Access in
> Asterisk to enable SLA for Sipura/Linksys
>
> Gene,
>
> I'm trying to better understand what you've developed. It seems that
> you're
> trying to share Asterisk SLA trunks w/ a different system (Broadsoft). Is
> the following a correct representation of your architecture?
>
>
>  You speak about something called as CALL_INFO event-package and then
> reference it to Call-Info: header in RFC 3261. An event-package (RFC 3265)
> and header are two separate things. There is no standard CALL_INFO event
> package in SIP. Likewise, there is no standard Line-Seize event-package in
> SIP. It seems that these are Broadsoft proprietary SIP event-packages.
>
> It seems that you've developed these proprietary SIP event-packages in
> Asterisk. Why couldn't this be done using the standard dialog-package (RFC
> 4235)?
>
> The "line sieze" issue that you're trying to solve is an interesting one.
> Line seize can be accomplished using RFC 4235 (although it is not very
> straightforward to do so). Basically, I think the issue you're trying to
> solve is to show a line busy on other SLA phones while one of the SLA
> phones
> has seized the line and is dialing the destination number. I've seen
> different commercial PBX vendors handle it in their own proprietary way.
> So,
> I can somewhat understand why you've resorted to proprietary SIP
> event-package for solving the "line seize" problem. But what does the
> call-info event-package buy you?
>
> --
> Raj
>
>
> On Jan 1, 2008 12:09 PM, Eugene Grossi <grossi at cv.med.nyu.edu> wrote:
> > I started out this summer implementing Asterisk SLA for the
> Sipura/Linksys
>
> > handsets. My strategy was to make Asterisk compatible with the
> Broadworks
> > sip access side extensions; this would allow the Sipura shared
> extensions
> to
> > be compatible Asterisk SLA.
> >
> > Currently I have full SLA compatability with SPA942's working as well as
> > integration with other (AASTRA 53i) SLA compatible phones. I have
> described
> > my implementation strategy below for developer comments, before I post
> the
>
> > code as a potential feature patch.
> >
> > ****************
> > Listed below are modifications of Asterisk in chan_sip.c and pbx.h to
> > accommidate rudimentary implementation of Broadsoft Extensions. The
> > specifications in "BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE
> > SPECIFICATIONS -RELEASE 13.0" were used, with the short term goal of
> > achieving SLA functionality for Sipura phones (tested on SPA942's).
> >
> > To Asterisk:
> >
> > 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 the 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 for "shared" extensions. 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 that
> the
> > call is on "hold" (not private). This allows them to join into the SLA
> (by
>
> > generating an INVITE) 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.
> >
> > I would appreciate any feedback.
> > gene
> >
> >
> > -------------------------------
> > Eugene A. Grossi, M.D.
> > Professor of Cardiothoracic Surgery
> > New York University School of Medicine
> > Suite 9-V; 530 First Avenue
> > New York, NY 10016
> > ph (212) 263-7452
> > fax(212) 263-5534
> > grossi at cv.med.nyu.edu
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080102/ff14fda9/attachment.htm 