[asterisk-users] How to check if a SIP phone isforwardedwithoutringing it ?

[Olivier]

2008/1/9, Steve Langstaff <steve.langstaff at citel.com>:
>
> > -----Original Message-----
> > From: asterisk-users-bounces at lists.digium.com
> > [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of
> > Johansson Olle E
> > Sent: 09 January 2008 14:11
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: Re: [asterisk-users] How to check if a SIP phone
> > isforwardedwithoutringing it ?
> >
> >
> > 9 jan 2008 kl. 10.46 skrev Steve Langstaff:
> >
> > >> -----Original Message-----
> > >> From: asterisk-users-bounces at lists.digium.com
> > >> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of
> > >> Johansson Olle E
> > >> Sent: 09 January 2008 06:50
> > >> To: Asterisk Users Mailing List - Non-Commercial Discussion
> > >> Subject: Re: [asterisk-users] How to check if a SIP phone
> > >> isforwardedwithout ringing it ?
> > >>
> > >>
> > >> 9 jan 2008 kl. 02.48 skrev Raj Jain:
> > >>
> > >>> This issue of phone vendors not supporting OPTIONS
> > according to RFC
> > >>> 3261
> > >>> often comes up on this list. Like Kevin Fleming said, an OPTIONS
> > >>> request is supposed to be responded in the same way as an INVITE.
> > >>> Almost all SIP phone vendors have construed OPTIONS as some
> > >> kind of a
> > >>> keep-alive request, which is wrong.
> > >> Which we do too, by the way. In worst case, maybe Asterisk has set
> > >> this industry standard.
> > >>
> > >> OPTIONS is far to heavy in processing on the server side
> > to be used
> > >> for keep-alives. I'm  starting to see devices that use it for
> > >> checking capabilities - the proper way. To do this
> > properly, we will
> > >> have to authenticate the OPTIONs request and match it with
> > the proper
> > >> peer/ user to get the proper codec settings, ACLs and such.
> > >>
> > >> Since all versions of Asterisk use OPTIONs for
> > NAT-keepalives, I'm a
> > >> bit hesitant to fix this. It's a catch 22. I want to do it
> > properly,
> > >> but then the amount of processing for each OPTIONs request that we
> > >> receive is going to be a bit too much. Maybe one could ask
> > vendors to
> > >> add a header to the  OPTIONs packet saying "this is just a
> > >> keep-alive.
> > >> Give me a 200 OK without any parsing and be happy, because I don't
> > >> care about the reply."
> > >
> > > It looks like there are two issues rolled into one here...
> > >
> > > I hope I'm not "teaching my grandmother to suck eggs" when
> > telling you
> > > this, Olle, but as I understand it, Asterisk sending OPTIONS to
> > > devices as a NAT keepalive is a separate issue from devices sending
> > > OPTIONS to asterisk as a capabilities check...
> > >
> > > Received OPTIONS messages should/must be handled as-per the
> > RFCs (so
> > > authentication, matching etc should be done).
> > >
> > > If Asterisk wants to send an OPTIONS message just to keep a NAT
> > > binding open then I don't think that it has any obligation
> > to include
> > > authentication headers if it receives a 401/407 response -  it has
> > > received *some* response, and that's enough.
> > >
> > > If Asterisk wants to send an OPTIONS message to discover peer state
> > > (e.g.
> > > call forward enabled) then obviously it will have to complete any
> > > 401/407
> > > handling.
> > >
> > > So instead of needing
> > >    "a header to the OPTIONs packet saying "this is just a
> > keep-alive""
> > > I think that maybe Asterisk needs to control how it uses OPTIONS,
> > > depending on purpose.
> >
> > The issue here is that it requires a lot of extra processing
> > when RECEIVING the OPTION message if we want to do it right.
> > Sending is not an issue.
> >
> > If we want to handle OPTIONs correctly we need to match with
> > the peer/ user list and then set up a complete dialog with
> > all the options from the peer/user and then reply...
>
> Right.
>
> I agree that RECEIVING an OPTION message on the Asterisk server may
> require a lot of extra processing.
>
> I agree that sending an OPTION message from the Asterisk server could
> well have a low processing load.
>
> The original poster wanted to use OPTIONS sent FROM the Asterisk server
> to query the phone state, so I don't think your concerns about receive
> processing come into the picture.


Yes, obviously,  there are 2 different issues  :
1. how to query phone status
2. how to keep NAT alives

A. For phone status queries, a list of phone vendors (at least one)
supporting this usage or future SIPit tests would help to motivate other
vendors to implement desired SIP OPTIONS behaviour along today's one.
Maybe an email sent by Digium to a list of SIP phone vendors and asking for
guidance would be a practical mean to get replies.

B. As keeping NAT alive is a basic need, maybe we should ask SIP PING method
authors or sponsors for advice on this (contact address in enclosed in
http://www.cornfed.com/ping.html ) ?
Either SIP PING (or something equivalent) should be ratified or SIP OPTIONS
should be "clarified".


_______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080109/803c862d/attachment.htm