Hi all,
I've a Cisco PGW interconnecting with an OpenSER server. The INVITE is sent to OpenSER, which does some record-routing via some different hops and then sends back the 180 from the called party. If the calling party now cancels the call, the PGW tries to loose-route the CANCEL by adding the Route header to the CANCEL and altering the R-URI, which is rejected by my OpenSER since I don't allow initial loose-routing.
So the question is: is it valid for a CANCEL to carry a Route header which wasn't available in the INVITE? §9.1 of RFC3261 says it MUST contain the Route header if it was present in the request being cancelled. What about the other way around? I heavily suspect it's violating the RFC since CANCEL should be more or less a 1:1 copy of the INVITE, but can anyone confirm this?
If it violates the RFC, anyone with some Cisco knowledge who knows how to disable this behavior, or is it a known bug?
Cheers, Andreas
Andreas Granig schrieb:
Hi all,
I've a Cisco PGW interconnecting with an OpenSER server. The INVITE is sent to OpenSER, which does some record-routing via some different hops and then sends back the 180 from the called party. If the calling party now cancels the call, the PGW tries to loose-route the CANCEL by adding the Route header to the CANCEL and altering the R-URI, which is rejected by my OpenSER since I don't allow initial loose-routing.
So the question is: is it valid for a CANCEL to carry a Route header which wasn't available in the INVITE? §9.1 of RFC3261 says it MUST contain the Route header if it was present in the request being cancelled. What about the other way around? I heavily suspect it's violating the RFC since CANCEL should be more or less a 1:1 copy of the INVITE, but can anyone confirm this?
I think it is a bug in the Cisco.
klaus
If it violates the RFC, anyone with some Cisco knowledge who knows how to disable this behavior, or is it a known bug?
Cheers, Andreas
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Andreas Granig writes:
If it violates the RFC, anyone with some Cisco knowledge who knows how to disable this behavior, or is it a known bug?
i remember hearing that this has been fixed in latest version of pgw, which is also (finally) supposed to conform to rfc3261 in all aspects.
-- juha
El Wednesday 05 March 2008 17:28:26 Andreas Granig escribió:
Hi all,
I've a Cisco PGW interconnecting with an OpenSER server. The INVITE is sent to OpenSER, which does some record-routing via some different hops and then sends back the 180 from the called party. If the calling party now cancels the call, the PGW tries to loose-route the CANCEL by adding the Route header to the CANCEL and altering the R-URI, which is rejected by my OpenSER since I don't allow initial loose-routing.
RFC 3261:
9.1 Client Behavior [...] The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. [...] If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values.
This is needed so that stateless proxies are able to route CANCEL requests properly.
So the question is: is it valid for a CANCEL to carry a Route header which wasn't available in the INVITE? §9.1 of RFC3261 says it MUST contain the Route header if it was present in the request being cancelled. What about the other way around?
Yes, not sure about the reverse case (INVITE with no "Route" header but CANCEL containing it). Anyway, in your case the RURI is modified my Cisco PGW so it violates the CANCEL.
Regards.