[asterisk-users] How to check if a SIP phone isforwardedwithout ringing 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 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.