Thanks Dale. Inline are comments.
Best Regards, Henry Peter Henry Peter | Dialogic Inc. | [email protected] 209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2 -----Original Message----- From: Worley, Dale R (Dale) [mailto:[email protected]] Sent: Wednesday, May 23, 2012 8:53 AM To: Henry Peter Cc: [email protected] Subject: RE: [Sip-implementors] [dispatch] Need a resolution on the usage of SIP OPTIONS -b4- > 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. [Henry Peter] If it were standardized so I would not have the situation I am facing where I am hearing from a vendor that 70 is expected in an OPTION no matter where the req-uri points to (in fact it does precisely to the IP and Port and hence no forwarding expected and even if one does that is a different matter of initiating a new OPTION; from the sender point of view, the OPTION is strictly to the next hop and expects a response or not. Worse yet the reference for 70 is being given to RFC 3261! The Max-Forwards cannot stand by itself...it needs a context such as the OPTIONS and where the req-uri points to ...these are not clearly stated... Only reason that we may not hear much problems about SIP OPTIONS is because probably everywhere 70 is used...but does it make it right? ) 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). [Henry Peter] Dale, you can see that you had to make so many statements to clarify and this is precisely expected in an RFC for standard-practice or related. Why is it not that the draft that already exists on this moving towards an RFC? Thanks. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
