[asterisk-dev] [Code Review] SIP: authenticate OPTIONS requests just like we would an INVITE

[Olle E. Johansson]

31 aug 2010 kl. 09.53 skrev Klaus Darilion:

> 
> 
> On 27.08.2010 21:09, Olle E. Johansson wrote:
>> 
>> 27 aug 2010 kl. 21.24 skrev David Vossel:
>> 
>>> OPTIONS requests should be treated the same as an INVITE... which includes authentication.  This patch adds the ability for incoming out of dialog OPTION requests to be authenticated before providing a response indicating whether an extension is available or not.  The authentication routine works the exact same way as it does for incoming INVITEs. This means that if a peer has 'insecure=invite' in their peer definition, the same will be true for the processing of the OPTIONS request.
>>> 
>> 
>> We should also add an SDP if possible... There are applications out there who "poke" the other end to find out codec support with OPTIONS.
> 
> Which codecs SDP should be presented in the SDP? The one's configured of 
> the peer sending the OPTIONS request?
It's normal device matching that goes on here, so the same as if the device would 
send an INVITE. Which is useful.
> 
> btw: I guess if allowguests=yes, then sending the OPTIONS request would 
> still work.
Like today, yes.
> 
> Further, if (with current behavior) there is no SDP in 200 OK response, 
> there is actually no difference in receiving a 200 OK and receiving a 
> 401/407. The sender just knows that there is another SIP client on the 
> other side.
I think David pointed that out in an earlier mail.
THis way, we not only know that there's a device out there, but can also adopt and check whether or not we can communicate and parse some headers to get some more specific information - will session timers work? Is MESSAGE allowed?

Question for you: Will Kamailio dispatcher accept a 401 message to OPTIONs as "being alive" or will it be an error?

/O