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
