sunil.bha...@wipro.com wrote:
> Hi,
>
> Say, UAS doesn't have any endpoint configured and will not be able to handle
> calls. In this case, should the UAS send a 4xx response, say 408 timeout,
> when it receives OPTIONS request, or is it better to ignore the incoming
> OPTIONS request and not send any response to it?
Returning no response at all is an *exceedingly* bad choice. It will
result in the requester retrying and so take a long time to fail. Almost
anything else would be better, but 408 is nearly as bad.
You say it is a UAS, but can't handle calls. Do you mean it can't handle
calls *now*? (E.g. it is a "pbx" implemented as a B2BUA that may at a
later time be able to handle calls when it has some extensions
connected.) Or do you mean it will *never* be able to handle calls, suas
would be the case for an event server that only handles SUBSCRIBE and
NOTIFY??
IMO OPTIONS was specified poorly when it called for returning the same
response that an INVITE would, because it doesn't recognize all these
kinds of cases. I believe many devices will respond with 200 to OPTIONS
regardless of what they would do for an INVITE.
So you might consider doing that - returning 200. If you can *never*
support INVITE, just omit it from the Allow header. If you really want
to return an error, 480 might suit this situation - that is typically
what a proxy would return to an invite if there were currently no
registrations.
Thanks,
Paul
> Regards,
> Sunil
>
> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:i...@aliax.net]
> Sent: Thursday, November 12, 2009 8:03 PM
> To: Sunil Bhagat (WT01 - Telecom Equipment)
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Query related to OPTIONS
>
> 2009/11/12 <sunil.bha...@wipro.com>:
>> Hi,
>>
>> I have a small query regarding OPTIONS method in SIP.
>> As per RFC 3261, OPTIONS is used to query a user agent or server about
>> its capabilities and discover its current availability.
>>
>> Say, I have a SIP server which controls several endpoints, but none of
>> them is up. Now I receive an OPTIONS message from the NETWORK.
>> So, what should the reply from my server be? Should the SIP server send
>> 200 OK response with its capabilities and availability? Or should it
>> send some 4XX or 6XX response indicating that endpoints are down?
>
> I would suggest you to forget the theoretical usage of OPTIONS as it's
> not a robust "feature" (imagine there is parallel forking so you just
> receive the response from one of the branches).
>
> However the behavior you mean is more designed to work with endpoints.
> This is, I send an OPTIONS to a phone and it replies me 200 if it's
> available to receive an INVITE, 486 if it has all its lines in use,
> 480 if it has set DND and so...
>
> But I don't expect the same behaviour in a server/b2bua/gateway as the
> server/b2bua/gateway cannot know which response it will receive when
> forwarding a call.
>
> IMHO nowadays OPTIONS is just used to mantain the NAT keepalive and to
> check if a server/endpoint is alive (regardless of the response it
> replies for that OPTIONS).
>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
