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

[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 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.