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