Thanks Paul. Inline are my comments.
Message: 1 Date: Wed, 23 May 2012 10:46:25 -0400 From: Paul Kyzivat <[email protected]<mailto:[email protected]>> Subject: Re: [Sip-implementors] [dispatch] Need a resolution on the usage of SIP OPTIONS -b4- To: [email protected]<mailto:[email protected]> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Message-ID: <[email protected]<mailto:[email protected]>> Content-Type: text/plain; charset=windows-1252; format=flowed 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? >>>> Yes, very certain and interestingly it was a 400 bad request as opposed to >>>> a 483! Sounds like either a stack or an alg function which blindly checks >>>> on MF! We are requested to change because we are not compliant with RFC >>>> 3261! :) It is quite clear that the OPTION is specifically going to a >>>> specific IP and Port and there is no forwarding necessary by the >>>> requesting party.....In fact MF could have been 0 as per RFC 3261.....but >>>> in the end when there is no clear spec (RFC and not draft) what happens is >>>> that the not so clear statements in RFC 3261 is being pointed out and most >>>> of all when we do something right we get caught for it and in the end we >>>> had to change MF to 70 for a point to point OPTIONS! That is why I was >>>> wondering why not standardize the already written draft on the sip >>>> options.... I've seen a lot of brain-dead behavior, but this one would be a new record, >>>> that's funny. and would demonstrate such a complete lack of understanding of sip that its unlikely that anything else would work either. >>>> worse, when we stick to common behavior like blindly putting 70, all are >>>> happy but when you do something with some thought put to it then you end >>>> up getting penalized! :( 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. >>>>> In a setting with customer relationship we can only point to why we did >>>>> it but in the end one of the party ends up making the change. The only >>>>> authority can be an RFC from compliancy point of view. Of course this RFC >>>>> has to say it updates the RFC 3261. 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. >>>>> Actually using OPTIONS is only a first step or one of the mechanisms >>>>> used. One could think of various others including usage of INVITE >>>>> responses. Thanks much. Thanks, Paul Best Regards, Henry Peter Henry Peter | Dialogic Inc. | [email protected] 209 207 8446 M | 209 836 0737 W1 | 408 750 9428 W2 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
