I have seen _many_ correct implementations of route handling using the ;lr parameter at the last two SIPits. The vast majority of proxies and endpoints participating in the multiparty tests were getting this right.
Values for ;lr currently have _no standard meaning_ and should simply be ignored. The following are equivalent and mean that the element providing the URI supports loose routing: ;lr ;lr=true ;lr=false ;lr=arbitrarybits It is the presence of the parameter that makes the difference. Its value is irrelevant. Yes, the ;lr=false case is counter-intuitive. ;lr=true will not be added to the specification. Those who introduced it into our milieu are fixing the errors that generated it. I will be working hard (and I hope the rest of you will be working with me) to make it go away as soon as we can. I plan to publish a draft soon documenting how to best deal with encountering ;lr=true and the issues that led to it in hopes of making weeding it out easier. RjS On Mon, 2002-11-18 at 18:50, Jasson Casey wrote: > It seems that little to no devices our there support the lr tag as it applies to >record-route and route. What I have seen are two things: lack of proper parsing >support of a single value token in the record-route/route headers, and lack of >support of lr as a function. I'm not that concerned w/ little to no support for lr >just yet, proxies/ua(s) don't have to understand lr, just parse it properly. However, >I have seen many bugs w/ just proper parsing. It also seems that a syntax of lr=true >has been implemented to get around these problems. Should this parameter string >(lr=true) be recognized as needing lr route handling? Will this parameter string get >added to the sip spec? > > I would like to follow the general convention, but I cannot find much information on >the matter. > > Thanks, > > -jasson > > _______________________________________________ > 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
