Frankly Chris, this seems to be becoming a too academic discussion. What matters is interoperability and running code. To achieve that, robustness is a primary requirement and all BUTs are quite secondary. (I'm now speaking more as an integrator rather than as a SIP spell-checker.) As a matter of fact, you will not be able to deploy a working SIP network with many frequently used SIP devices if you insist on empty lr today.
The only action item which can be drawn from this discussion is an appeal for more robustness on all sides. Unfortunately, the incoveniently unforgiving stacks come from frequently deployed products of large vendors with looooong code-fixing cycles. A check-list for robust stacks would be: - does a UAS return Record-Routes in replies as received in requests? - does a UA build Routes with URIs as in Record-Routes? - is a UAS liberal and process all kinds of lr? We are now launching an interop testing effort in SIP Forum, whose purpose will be to provide tools for assessment of SIP-compliance. That might help some vendors. -jiri At 05:35 PM 10/6/2003, Chris Boulton wrote: >I am all for robustness BUT a line has to be drawn in the ground at some >point. The BNF clearly states that if you want to use the lr-param then >it must be of the form > >lr-param = "lr" > >Anything, that falls outside of this must be consider an other-param. >It is not reasonable for this to be interpreted as having the same >meaning as the explicit expression in the BNF. Yes, it could mean >something internally to your server BUT should not be expected to be >interpreted correctly outside of this. > >My server interprets lr=foo - I expect this to be treated the same as >just 'lr', this just doesn't make sense to me. > >Chris. > > >>-----Original Message----- >>From: Jiri Kuthan [mailto:[EMAIL PROTECTED] >>Sent: 06 October 2003 16:00 >>To: Samir Srivastava; Salman Abdul Baset; Jan Janak >>Cc: [EMAIL PROTECTED] >>Subject: RE: [Sip-implementors] Is "lr=on" a correct syntax for the lr- >>param? >> >>What is indeed clear is the robustness principle, stated in RFC0761: >>"be conservative in what you do, be liberal in what you accept from >> others". That's an immensly important practice which takes precedence >>over whatsoever. >> >>As a matter of fact, there is a variety of UAs today failing to >implement >>the principle. There are some prefering empty lr, some prefering >>lr=something. >>Particularly, a very popular softclient insists on non-empty lr's and >>discards >>empty lr's with 400. Also, a very popular PSTN gateway strips non-empty >lr >>uri-parameters away, which is a clear spec violation. >> >>We are liberal receivers with the server in question. As for the "what >you >>do" >>part -- we delegated the choice of empty versus non-empty lr to the >>operator as a config option. Alternatively, you can pick from a variety >>of hacks such as using a B2BUA which avoids forming record-routes by >>keeping session state. >> >>Again, the root of problem is in stacks which violate the robustness >>priniciple. >> >>-Jiri >> >>At 02:23 AM 10/4/2003, Samir Srivastava wrote: >>>Hi, >>> >>>If you see the BNF, it states clearly >>> >>>lr-param = "lr" >>> >>>So exactly "lr =On | Off" is incorrect syntax. You should not have >>>looked into >>>the defintion of other-param. >>> >>>Also in the examples of RecordRoutes it states ";lr" only in section >>>16.12.1.1 >>> >>>Thx >>>Samir >>> >>> >>>-----Original Message----- >>>From: Salman Abdul Baset [mailto:[EMAIL PROTECTED] >>>Sent: Friday, October 03, 2003 3:51 PM >>>To: Jan Janak >>>Cc: [EMAIL PROTECTED] >>>Subject: Re: [Sip-implementors] Is "lr=on" a correct syntax for the >>>lr-param? >>> >>> >>>See page 222 of rfc 3261 for definition of lr. >>> >>>Only lr is required. This is correct since according to BNF it is not >>>necessary to have a r-value >>> >>>uri-parameters = *( ";" uri-parameter) >>>uri-parameter = transport-param / user-param / method-param >>> / ttl-param / maddr-param / lr-param / >other-param >>> >>>other-param = pname [ "=" pvalue ] >>> >>>Salman >>> >>>On Sat, 4 Oct 2003, Jan Janak wrote: >>> >>>> I disagree. This ";lr=on" thing has been implemented in the server >>>because >>>> of other implementations that do not implement loose routing >>>correctly. >>>> So it is not about older implementations, it is about new >>>> implementations. >>>> >>>> Suprisingly many implementations cut off ;lr parameter (i.e. >parameter >>>> without any value). >>>> >>>> The specification says: >>>> >>>> "If the route set is not empty, and the first URI in the route set >>>contains >>>> the lr parameter" >>>> >>>> It doesn't say anything about the value of the parameter, you just >>>need >>>> to see if there is the lr parameter or not. And ;lr=on certainly is >>>the >>>> lr parameter as well as ;lr >>>> >>>> Some people complained that examples in the section contain ;lr >only, >>>> but examples are just examples... >>>> >>>> Jan. >>>> >>>> On 02-10 13:47, Rob Phillips wrote: >>>> > No, it's not. The correct BNF position per 3261 is "lr", although >>>some older implementations have been known to use variations. >>>> > >>>> > - rob >>>> > >>>> > -----Original Message----- >>>> > From: Franz Edler [mailto:[EMAIL PROTECTED] >>>> > Sent: Thursday, October 02, 2003 1:45 PM >>>> > To: [EMAIL PROTECTED] >>>> > Subject: [Sip-implementors] Is "lr=on" a correct syntax for the >>>> > lr-param? >>>> > >>>> > >>>> > Hi all, >>>> > >>>> > I need the help of experts in identifying which side is correct >and >>>which >>>> > side has a bug: >>>> > Microsoft Messenger 5.0 or Free World Dialup Server (0.8.11rc3) >>>> > >>>> > The problem is the interpretation of the lr-param in the route >set. >>>> > >>>> > This is the fact: >>>> > When I connect with MS Messenger to [EMAIL PROTECTED] I get the >>>following >>>> > 200 OK response: >>>> > >>>> > SIP/2.0 200 OK >>>> > Via: SIP/2.0/UDP 212.152.201.190:15448 >>>> > Record-Route: >>>> > >>><sip:[EMAIL PROTECTED];ftag=acd8235d6b18416093ab224b18257dc7;lr=on> >>>> > From: "[EMAIL PROTECTED]" >>>> > >>><sip:[EMAIL PROTECTED]>;tag=acd8235d6b18416093ab224b18257dc7;epid= >5b >>>bb18 >>>> > e48e >>>> > To: <sip:[EMAIL PROTECTED]>;tag=as75f23980 >>>> > Call-ID: [EMAIL PROTECTED] >>>> > CSeq: 2 INVITE >>>> > User-Agent: Asterisk PBX >>>> > Contact: <sip:[EMAIL PROTECTED]:5028> >>>> > Content-Type: application/sdp >>>> > Content-Length: 187 >>>> > >>>> > v=0 >>>> > o=root 7610 7610 IN IP4 65.39.205.112 >>>> > s=session >>>> > c=IN IP4 65.39.205.112 >>>> > t=0 0 >>>> > m=audio 5438 RTP/AVP 3 101 >>>> > a=rtpmap:3 GSM/8000 >>>> > a=rtpmap:101 telephone-event/8000 >>>> > a=fmtp:101 0-16 >>>> > >>>> > >>>> > If you look at the Record-Route Header you can see "lr=on", which >I >>>assume >>>> > should mean the lr-param. But this is obviously not recognized as >>>the >>>> > lr-param by MS messenger, because it does not place the remote >>>target URI >>>> > into the request URI of ACK. Instead it pushes the remote target >URI >>>into >>>> > the Route header and uses the top URI from the route set as the >>>request URI, >>>> > because it supposes the next proxy is a strict router: >>>> > >>>> > >>>> > ACK >>>sip:[EMAIL PROTECTED];ftag=acd8235d6b18416093ab224b18257dc7;lr=on >>>> > SIP/2.0 >>>> > Via: SIP/2.0/UDP 212.152.201.190:15448 >>>> > Max-Forwards: 70 >>>> > From: "[EMAIL PROTECTED]" >>>> > >>><sip:[EMAIL PROTECTED]>;tag=acd8235d6b18416093ab224b18257dc7;epid= >5b >>>bb18 >>>> > e48e >>>> > To: <sip:[EMAIL PROTECTED]>;tag=as75f23980 >>>> > Call-ID: [EMAIL PROTECTED] >>>> > CSeq: 2 ACK >>>> > Route: <sip:[EMAIL PROTECTED]:5028> >>>> > User-Agent: RTC/1.2 >>>> > Content-Length: 0 >>>> > >>>> > I am not an expert in BNF, but the question is: >>>> > Is "lr=on" a correct syntax for the lr-param? >>>> > >>>> > >>>> > Any help is appreciated. >>>> > >>>> > Franz >>>> > >>>> > >>>> > _______________________________________________ >>>> > Sip-implementors mailing list >>>> > [EMAIL PROTECTED] >>>> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> > >>>> > _______________________________________________ >>>> > Sip-implementors mailing list >>>> > [EMAIL PROTECTED] >>>> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> [EMAIL PROTECTED] >>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> >>>_______________________________________________ >>>Sip-implementors mailing list >>>[EMAIL PROTECTED] >>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >>>_______________________________________________ >>>Sip-implementors mailing list >>>[EMAIL PROTECTED] >>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >>_______________________________________________ >>Sip-implementors mailing list >>[EMAIL PROTECTED] >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >_______________________________________________ >Sip-implementors mailing list >[EMAIL PROTECTED] >http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
