[asterisk-dev] Qualify OPTIONS messages

[Evan Borgström]

	Actually, it is for determining if the UAC is willing to accept an
INVITE. RFC 3262 Section 11.2

   The response to an OPTIONS is constructed using the standard rules
   for a SIP response as discussed in Section 8.2.6.  The response code
   chosen MUST be the same that would have been chosen had the request
   been an INVITE.  That is, a 200 (OK) would be returned if the UAS is
   ready to accept a call, a 486 (Busy Here) would be returned if the
   UAS is busy, etc.  This allows an OPTIONS request to be used to
   determine the basic state of a UAS, which can be an indication of
   whether the UAS will accept an INVITE request.

-Evan

Joshua Colp wrote:
> ----- Jon Schøpzinsky <jos at detele.dk> wrote:
>> Hello
>>  
>> Ive been playing around with clustering using DUNDi, and found a
>> problem with the way chan_sip handles the response to its qualify
>> OPTION messages.
>> If a negative response is received, such as 403, it still markes the
>> sip peer as being alive, which is quite a problem when using
>> ChanIsAvail.
> 
> OPTIONS is not for determining whether the device is capable of accepting a call on that level, it is to determine whether the device is actually there and capable of receiving SIP packets. Due to the fact that it received a 403 back, the device is indeed there and capable of receiving/processing SIP packets. If we turned this into the way you want, we might even hurt things as depending on the SIP stack they can respond with different things.
>   
>>  
>> Med venlig hilsen
>>
> 
> Joshua Colp
> Digium
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev