[OpenSER-Users] Strange ACK format gives OpenSER error?

[Martin Klisch]

Hi,

our cisco service partner asked the TAC to create a offical cisco bug. we
are still waiting for it. as i said, the first response by cisco was:
"it's your proxy, which is broken, not our pgw."

the answer by cisco was:
=================

The root cause is customer's sip proxy doesn't follow the RFC3261, when
generating Record-Route headers for loose routing.

One example of the invalid Record-Route is "Record-Route:
<sip:xxx;lr=on;ftag=1749303520>".

According to RFC 3261, "=on" is unwanted for loosing routing, which cause
the problem:
25.1 Basic Rules
     lr-param          =  "lr"
=================

i tried to argument, that the rfc doesnt say, that a parameter after lr is
not allowed. but the rfc says clearly a "MUST NOT" to < > in R-URI.

bye.


> Hi,
>
> yep, you're right, it's a pgw. We upgraded it to the latest patch level,
> but ended up going back to the older one just because of this.
>
> Thanks again.
>
> Br,
> /Tobias
>
> Martin Klisch said the following on 2007-07-06 15:19:
>> Hi,
>>
>> the bug is on the side of you providers gateway (i bet it is a cisco
>> pgw).
>> with lr=on the cisco PGW creates the R-URI from the from-uri with <>.
>> without the "=on" it creates the correct R-URI. we had the same problem
>> after upgrading the IOS of the cisco PGW.
>>
>> there are two workarounds:
>> 1. disable full lr
>> 2. modify the R-URI in the config file: the $ruri variable is empty
>> (<null>) when openser gets a SIP Message with < > in the R-URI. use the
>> to-uri and write it into the $ruri. you'll still have error messages in
>> the logs, but it does work for your clients. (yeah, it is a bad
>> workaround, but it is working...)
>>
>> 1. is the better way.
>>
>>> Hi Martin,
>>>
>>> thanks for quick answer.
>>>
>>> Exactly how does disabling full lr solve this? I mean, how does it
>>> change the way "<>" is handled?
>>>
>>> Br,
>>> /Tobias
>>>
>>> Martin Klisch said the following on 2007-07-06 12:59:
>>>>> Hi all,
>>>>>
>>>>> after a patch from one of our providers ACKs started to come with
>>>>> R-URI
>>>>> looking like:
>>>>> ACK <sip:192.168.0.1;lr=on;ftag=507454020> SIP/2.0
>>>>> instead of:
>>>>> ACK sip:192.168.0.1;lr=on;ftag=507454020 SIP/2.0
>>>>> like it did before the patch.
>>>>>
>>>>> The new ACK format gives an error in OpenSER:
>>>>> Jul  6 11:35:55 ser1 /sbin/openser[9634]: ERROR: parse_uri: bad uri,
>>>>> state 0 parsed: <<sip> (4) / <<sip:192.168.0.1;lr=on;ftag=507454020>>
>>>>> (38)
>>>>> Jul  6 11:35:55 ser1 /sbin/openser[9634]: ERROR: parse_sip_msg_uri:
>>>>> bad
>>>>> uri <<sip:192.168.0.1;lr=on;ftag=507454020>>
>>>>> Jul  6 11:35:55 ser1 /sbin/openser[9634]: loose_route: Error while
>>>>> parsing Request URI
>>>>>
>>>>> Are the new format of the ACKs valid? With the "<>"? If they are
>>>>> valid,
>>>>> the problem lies in OpenSER?
>>>>
>>>> It is not valid. it is a bug on cisco PGW after upgrading to another
>>>> ios.
>>>> you have to disable full lr: modparam("rr", "enable_full_lr", 0).
>>>>
>>>> the cisco gateway takes the whole from-uri (with <>) for the r-uri.
>>>> cisco
>>>> people said "the =on behind the lr is wrong. it is not in the rfc." -
>>>> but
>>>> the rfc doesnt say, that there must only be a lr without params. but
>>>> the
>>>> rfc shows a "must not" about <> in R-URI.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>