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

Raj Jain rj2807 at gmail.com
Wed Jan 2 08:58:14 CST 2008


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?


       | SLA Trunks
     |
     |
 ------------         -------------
 | Asterisk |---SIP---| Broadsoft |
 ------------  peers  -------------
     |                      |
     |                      |
  Asterisk              Broadsoft
SLA Stations          SLA Stations


  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/d939f4a3/attachment.htm 


More information about the asterisk-dev mailing list