> From: Henry Peter wrote: > > 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.
The practice is fairly well standardized, but not exactly as described (or at least implied) by RFC 3261. In regard to Max-Forwards, the rigid rule is that if an element forwards a request, it must decrement Max-Forwards, and so an element may not forward a request that it received with "Max-Forwards: 0". If an element would be required to forward the request but the request arrived with "Max-Forwards: 0", if the request is OPTIONS, it MAY respond to it as if the request was addressed to it; otherwise, it MUST respond 483. If the element is the UAS for the request (is not required to forward the request), it MUST process the request as normal, even if Max-Forwards is 0. In regard to responding to OPTIONS, there is a considerable amount of flexibility. The UAS is expected to reveal its capabilities as much as the SIP response format makes possible. According to the text of RFC 3261, it should be an error response if the UA cannot accept an INVITE, but that is not adhered to. More likely, the UAS will generate a 200 response in any circumstance; if the element cannot accept an INVITE, "INVITE" will be missing from the Allow header in the response. (Of course, any situation which only temporarily prevents INVITE from being accepted may change at any moment, so there isn't much value in reporting the momentary inability to accept INVITE.) In your situation, OPTIONS is a good method for checking liveness and SIP responsiveness of the target. In principle, you should use "Max-Forwards: 0", since you know the requests will never need to be forwarded, but on the other hand, since the request-URI contains an absolute address:port, it will never be forwarded anyway. (Although if the element at x.y.z.w:p implements SIP by forwarding requests, you would need to have a higher Max-Forwards to determine if the element was capable of effectively responding to INVITEs.) You certainly can't use the response to OPTIONS to ensure that the destination is capable of accepting INVITE at that moment, unless the response does not contain "Allow: INVITE", in which case the destination does not implement INVITE at all. A SIP element should not respond 400 to a request *only* because Max-Forwards was 0 or any other number which is in range (0 to 255). Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
