Dale, >> and (2) Nobody has volunteered to write this draft. (Are you >> volunteering to do so?)
There is a draft http://tools.ietf.org/html/draft-jones-sip-options-ping-02 which has more specifics and would have been nice if this were an RFC. Perhaps it can undergo certain reviews before it can become an RFC but at least we have a good start already. Do you think you can help get this moving towards an RFC? I know you have been involved with the IETF for quite a long time and have good influence. Let me know how I can be of help in any regard related to this. Thanks Dale. 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 12:56 PM To: Henry Peter Cc: [email protected] Subject: RE: [Sip-implementors] [dispatch] Need a resolution on the usage of SIP OPTIONS -b4- > 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
