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

Martin Klisch martin at campus-merseburg.de
Mon Jul 16 07:59:17 CEST 2007


Hello,

here the final statement by cisco: this problem doesnt appear in relase 9.7.3


> 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
>>>>
>>>
>>>
>>
>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>






More information about the Users mailing list