Subject: [dispatch] Need a resolution on the usage of SIP OPTIONS -b4-

From: Henry Peter <[email-masked]>
Date: Wed, 23 May 2012 01:29:14 -0400

Folks,

I have encountered a scenario regarding the usage of SIP OPTIONS and need a resolution.  I went thru some of the discussions of the past on the usage of SIP OPTIONS as a ping mechanism and it looks like I am not getting a concrete answer to what I am looking for.

>From RFC 3261 the primary intention of SIP OPTION being to query the capabilities of a SIP UA.

This is evident from Section 4, "Additional operations in SIP, such as querying for the capabilities
   of a SIP server or client using OPTIONS, or canceling a pending
   request using CANCEL, will be introduced in later sections.
"

The same is mentioned in section 7.1, 8.1.1, and finally 11.

Also from Section 11 it is clear that OPTIONS should not have to be generated only with Max-Forwards of 70.  In fact a value of 0 makes perfect sense for some scenarios.

The target of the OPTIONS request is identified by the Request-URI,

   which could identify another UA or a SIP server.  If the OPTIONS is

   addressed to a proxy server, the Request-URI is set without a user

   part, similar to the way a Request-URI is set for a REGISTER request.

Alternatively, a server receiving an OPTIONS request with a Max-

   Forwards header field value of 0 MAY respond to the request

   regardless of the Request-URI.

      This behavior is common with HTTP/1.1.  This behavior can be used

      as a "traceroute" functionality to check the capabilities of

      individual hop servers by sending a series of OPTIONS requests

      with incremented Max-Forwards values.

Now in Section 11.2, it gets interesting.  I can only derive that the UAS conveying its readiness to accept a call, that is an INVITE, is part of its capability, in order to maintain the previous emphasis of the reasoning behind the inception of OPTIONS.

11.2<http://tools.ietf.org/html/rfc3261#section-11.2> Processing of OPTIONS Request

   The response to an OPTIONS is constructed using the standard rules

   for a SIP response as discussed in Section 8.2.6<http://tools.ietf.org/html/rfc3261#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.

Now I will get to the problem I am facing.  A UA has identified a specific remote server of IP and Port to be used in sending INVITEs to establish sessions.  It wants to find out if that remote server is ready to accept INVITE, for any reasons; it need not necessarily be an overload but can even be an administrative "lock", a license capacity issue,, etc.,

So the UA initiates a SIP OPTION and since it is a specific remote server it creates a Max-Forwards (MF) of 1.  The Req-Uri specifically has IP and Port.  One can argue the MF can even be 0.  However the remote server is actually sending a 400 Bad Request because it does not like the "1" in MF and in fact expects "70".  It seems (from other vendor's/implementations point of view) that is what RFC 3261 is requiring although I don't see how.

How to clarify this situation?  It would have been nice if the RFC 3261 was very explicit about the role of MF in the SIP OPTIONS although it does hint with traceroute example.

When trying to set the MF in SIP OPTIONS (as a 70 did not fit the scenario), in our search for a follow-up after RFC 3261 on the usage of SIP OPTIONS we could only find the draft (http://tools.ietf.org/html/draft-jones-sip-options-ping-02 ) which recommended using a value of "1" that was much better off than 70.

Is there a plan to standardize certain of these mechanisms as a best-practice?  Any suggestion or comments are appreciated.  Thanks.
Best Regards,
Henry Peter
Henry Peter | Dialogic Inc. | [email-masked]<mailto:[email-masked]>
209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 May 2012 10:45:50 -0400

Henry,

Questions such as this belong on the sip-implementors list, not the 
dispatch list. I will respond to you there.

	Thanks,
	Paul

On 5/23/12 1:29 AM, Henry Peter wrote:
> Folks,
>
> I have encountered a scenario regarding the usage of SIP OPTIONS and
> need a resolution. I went thru some of the discussions of the past on
> the usage of SIP OPTIONS as a ping mechanism and it looks like I am not
> getting a concrete answer to what I am looking for.
>
> This is evident from Section 4,*/“Additional operations in SIP, such as querying for the capabilities/*
>
> */of a SIP server or client using OPTIONS, or canceling a pending/*
>
> */request using CANCEL, will be introduced in later sections./*
>
> */“/**//*
>
> Also from Section 11 it is clear that OPTIONS should not have to be
> generated only with Max-Forwards of 70. In fact a value of 0 makes
> perfect sense for some scenarios.
>
> */The target of the OPTIONS request is identified by the Request-URI,/*
>
> */      which could identify another UA or a SIP server.    If the OPTIONS is/*
>
> */      addressed to a proxy server, the Request-URI is set without a user/*
>
> */      part, similar to the way a Request-URI is set for a REGISTER request./*
>
> *//*
>
> *//*
>
> */Alternatively, a server receiving an OPTIONS request with a Max-/*
>
> */      Forwards header field value of 0 MAY respond to the request/*
>
> */      regardless of the Request-URI./*
>
> */  /*
>
> */            This behavior is common with HTTP/1.1.    This behavior can be used/*
>
> */            as a"traceroute"  functionality to check the capabilities of/*
>
> */            individual hop servers by sending a series of OPTIONS requests/*
>
> */            with incremented Max-Forwards values./*
>
> Now in Section 11.2, it gets interesting. I can only derive that the UAS
> conveying its readiness to accept a call, that is an INVITE, is part of
> its capability, in order to maintain the previous emphasis of the
> reasoning behind the inception of OPTIONS.
>
>
>
>
>       11.2 <http://tools.ietf.org/html/rfc3261#section-11.2>/Processing
>       of OPTIONS Request/
>
> /  /
>
> /  /
>
> /      The response to an OPTIONS is constructed using the standard rules/
>
> /      for a SIP response as discussed inSection 8.2.6  <http://tools.ietf.org/html/rfc3261#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./
>
> Now I will get to the problem I am facing. A UA has identified a
> specific remote server of IP and Port to be used in sending INVITEs to
> establish sessions. It wants to find out if that remote server is ready
> to accept INVITE, for any reasons; it need not necessarily be an
> overload but can even be an administrative “lock”, a license capacity
> issue,, etc.,
>
> So the UA initiates a SIP OPTION and since it is a specific remote
> server it creates a Max-Forwards (MF) of 1. The Req-Uri specifically has
> IP and Port. One can argue the MF can even be 0. However the remote
> server is actually sending a 400 Bad Request because it does not like
> the “1” in MF and in fact expects “70”. It seems (from other
> vendor’s/implementations point of view) that is what RFC 3261 is
> requiring although I don’t see how.
>
> How to clarify this situation? It would have been nice if the RFC 3261
> was very explicit about the role of MF in the SIP OPTIONS although it
> does hint with traceroute example.
>
> When trying to set the MF in SIP OPTIONS (as a 70 did not fit the
> scenario), in our search for a follow-up after RFC 3261 on the usage of
> SIP OPTIONS we could only find the draft
> (http://tools.ietf.org/html/draft-jones-sip-options-ping-02 ) which
> recommended using a value of “1” that was much better off than 70.
>
> Is there a plan to standardize certain of these mechanisms as a
> best-practice? Any suggestion or comments are appreciated. Thanks.
>
> /Best Regards/,
>
> Henry Peter
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch