Re: [Sip-implementors] Is "lr=on" a correct syntax for the lr-param?

Mon, 06 Oct 2003 12:09:10 -0700

When I see something using "lr=on", I am inclined to think that I may also see "lr=off" in some other context.

Its easy to treat "lr=X" the same as "lr" regardless of X. Its less easy to distinguish one unspecified set of values that mean TRUE from another unspecified set of values that mean FALSE.

Does anything known *ever* use "lr=X" for some value of X other than "on"?
        Paul

Jiri Kuthan wrote:
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


_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to