> From: Henry Peter [[email protected]] > > > From: Worley, Dale R (Dale) [mailto:[email protected]] > > > > 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...
The reference is not relevant because: (1) As Paul pointed out, 3261 says SHOULD not MUST, so UACs are allowed to use different values, and (2) After a request has passed through one or more proxies, Max-Forwards will have been decremented before it reaches the UAS, so RFC 3261-conforming devices must accept requests with Max-Forwards values smaller than 70. > 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? ) Actually, the value 20 is commonly used. Many vendors decided early on that 70 was much higher than was needed for practical implementations. > [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? Because (1) The deviations from RFC 3261 are small (i.e., a UA can respond 200 to an OPTIONS even if it cannot accept an incoming INVITE), and (2) Nobody has volunteered to write this draft. (Are you volunteering to do so?) Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
