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

[Johansson Olle E]

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


Where's my eggs?

/O