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

Tobias Lindgren tobias.lindgren at ip-only.se
Fri Jul 6 13:38:04 CEST 2007


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.
> 
> 
> 
> 
> 
> 




More information about the Users mailing list