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.
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
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:
- disable full lr
- 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...)
- 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
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:
- disable full lr
- 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...)
- 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
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:
- disable full lr
- 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...)
- 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
-
Martin Klisch -
Tobias Lindgren