[asterisk-dev] BLF/SLA on SPA942 via "notifyexten"

[Raj Jain]

Unsolicited NOTIFYs are generally a bad idea, but people use them
anyway. If they can solve your problem then that's fine. You'll
probably want to configure a list of SIP peers per BLA extension in
the "notifyexten" tag.

Do you know for sure that the SIP phone in question supports
dialog-package (RFC 4235) and that it will render line states based on
unsolicited dialog-package NOTIFYs?

-- Raj


On 10/9/07, Eugene Grossi <grossi at cv.med.nyu.edu> wrote:
> I am placing this previous private email (from the summer) onto this list to
> get comments from developers. The issue (as summed up by Russell below) is
> that:
> some phones doesn't support sending a SUBSCRIBE, so there is no way to
> receive the NOTIFY. We would create an option called something like
> "notifyexten" that indicates that state changes for that extension should be
> sent to this peer, regardless of whether there is a subscription for it or
> not.
>
> In particular this would enable the BLF/SLA for the SPA94x family.
>
> Our previous email:
> > I have modified chan_sip to deal with the issue of "non" subscription
> > of Sipura phones (working with SPA942's).
> >
> > Specifically, the issue is that if a spa942 is programmed to "share" a
> > line, it sends a NOTIFY without prior creation of a subscription. My
> > current modifications allow acceptance of the NOTIFY and control the
> > "lamp state" by a "sip notify xxx xxx" to the given peer from the command
> line interface.
> >
> > I now am going to create a "subscription" such that SLA will work for
> > these phones. This issue is which way to go. Since I want to be able
> > to submit this code to the developer community I need your input.
> > Should Asterisk take an inappropriate NOTIFY from the SIPURA and at
> > that point in time create the subscription or should a "SUBSCRIPTION"
> > field variable be added to the sip.conf entry for a peer, such that
> > when a peer registers, the SUBSCRIPTON is created using the
> > configuration value of the "SUBSCRIPTION" variable.
> > I believe that the ASTERISK community would get great value out of
> > having BLF/SLA working on these phones, however I would like to
> > minimize the amount of "hack" since basically the reason it doesn't
> > work in the first place is a nonstandard approach by the Sipura software.
>
> I apologize for the extreme delay in getting back to you.  The message got
> lost in the depths of my inbox ...
>
> I'm not sure that I really understand the problem.  Asterisk has no support
> currently for *receiving* a NOTIFY message, as you may have already
> discovered.
>  So, the phone should not be sending any NOTIFY messages to Asterisk.
>
> The SLA feature in Asterisk is not quite like other similar implementations
> out there, which in my opinion, are really more like shared extensions.
> (I'm referring to the SIP-B drafts).  Asterisk uses NOTIFY messages to
> control the lamp on the phone to indicate the state of the shared line.
>
> Now, if your problem is that the phone doesn't support sending a SUBSCRIBE,
> so there is no way to receive the NOTIFY, then I think the sip.conf option
> is a good idea.  I would create an option called something like
> "notifyexten" that indicates that state changes for that extension should be
> sent to this peer, regardless of whether there is a subscription for it or
> not.
>
> The tricky part here is that the code to do this in trunk is going to be
> much different than 1.4.  However, we only merge new features into trunk,
> and you likely need this for 1.4.
>
> I would be happy to further discuss the details of what changes are
> necessary to code this, but I'd like to move the discussion to the
> asterisk-dev mailing list so that others may benefit from the discussion.
> See lists.digium.com for the mailing list information.
>
> Thanks,
>
> --
> Russell Bryant
> Software Engineer
> Digium, Inc.
> -------------------------------
> 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
>