Henry,
I've moved this to the sip-implementors list because that is the
appropriate place for such questions.
Are you absolutely certain that the 400 is being returned because the
request contained Max-Forwards:1 and not Max-Forwards:70?
I've seen a lot of brain-dead behavior, but this one would be a new
record, and would demonstrate such a complete lack of understanding of
sip that its unlikely that anything else would work either.
Even if every request started out with M-F:70, that value gets reduced
at each hop, so that the value observed by a UAS will vary based on the
number of hops actually traversed in reaching it. So if the UAS somehow
felt it should enforce the setting of Max-Forwards it would need to
adjust the value it observed by the number of hops traversed. (E.g. by
adding the count of via header fields.) That could give some
approximation to the value in the original request. But then 3261 does
not require any particular value - it recommends (non-normatively) an
initial value of 70.
Just tell them they are profoundly wrong, and tell them to ask anyone
with a working sip implementation that has visited SipIt.
But I expect that really there is some other problem - which could be at
your end or the other end.
Regarding the sort of response you can expect from OPTIONS: while I
acknowledge that the language is there in 3261 indicating that you
should get 200 if an INVITE would be accepted, and an error if an INVITE
would not be accepted, its been widely understood for a long time that
this behavior is overly simplistic. For instance, there are UASs that
will *never* accept an INVITE, because they are event servers that
handle PUBLISH/SUBSCRIBE. Those are going to respond 200 even though
they don't support INVITE.
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.
>
> 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 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
>
> Henry Peter | Dialogic Inc. | [email protected]
> <mailto:[email protected]>
> 209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2
>
>
>
> _______________________________________________
> dispatch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
