(Sorry for cross-posting from Sip-Implementors; however, upon some reflection this is really more of a Kamailio mechanics question.)
Greetings,
I have a scenario where endpoint A is calling endpoint B through proxy P. Endpoints A and B are on different networks that are not directly reachable--A is on the public Internet, to which proxy P is connected, but NAT'd, and B is on a private RFC1918 network on which the proxy P has an interface as well.
The purpose of proxy P is to make calling A <-> B possible, while providing the appropriate far-end NAT traversal functionality for A and so on and so on. It does this by inserting the correct Record-Route headers into the INVITE from A, and otherwise by staying in the signaling path; both A and B can reach the proxy, so all requests and replies go through it.
The problem I'm having is prior to full dialog establishment. Upon receipt of INVITE from A by way of proxy P, B replies with 183 + SDP and also:
Require: 100rel
In the 183 it provides a Contact on its private network that A obviously cannot reach:
Contact: sip:xxxxx@192.168.0.10:5060
As a result, A attempts to send PRACKs to sip:xxxxx@192.168.0.10, which are obviously not going to go anywhere. After not receiving a few of these expected PRACKs, B replies to the call with a final negative failure.
The question is, is there anything I can twiddle on the proxy to make this work? The problem with PRACKs is that although they are sequential requests, they arise (in this case) prior to the point at which RR can be used to guide them through the proxy.
The most obvious answer is, "Make B not Require: 100rel", of course. However, that is not an option here.
Thanks!
Hello,
On 6/18/11 11:05 PM, Alex Balashov wrote:
(Sorry for cross-posting from Sip-Implementors; however, upon some reflection this is really more of a Kamailio mechanics question.)
Greetings,
I have a scenario where endpoint A is calling endpoint B through proxy P. Endpoints A and B are on different networks that are not directly reachable--A is on the public Internet, to which proxy P is connected, but NAT'd, and B is on a private RFC1918 network on which the proxy P has an interface as well.
The purpose of proxy P is to make calling A <-> B possible, while providing the appropriate far-end NAT traversal functionality for A and so on and so on. It does this by inserting the correct Record-Route headers into the INVITE from A, and otherwise by staying in the signaling path; both A and B can reach the proxy, so all requests and replies go through it.
The problem I'm having is prior to full dialog establishment. Upon receipt of INVITE from A by way of proxy P, B replies with 183 + SDP and also:
Require: 100rel
In the 183 it provides a Contact on its private network that A obviously cannot reach:
Contact: sip:xxxxx@192.168.0.10:5060
As a result, A attempts to send PRACKs to sip:xxxxx@192.168.0.10, which are obviously not going to go anywhere. After not receiving a few of these expected PRACKs, B replies to the call with a final negative failure.
The question is, is there anything I can twiddle on the proxy to make this work? The problem with PRACKs is that although they are sequential requests, they arise (in this case) prior to the point at which RR can be used to guide them through the proxy.
The most obvious answer is, "Make B not Require: 100rel", of course. However, that is not an option here.
iirc, the PRACK should follow the record-routing as part of its early dialog state. At least, from my experience the PRACKs I saw so far were sent to the proxy address due to record routing, not directly to contact address in 183. Without following the record routing, I see no way to go even for cases with NAT. For me looks like A is buggy, but I haven't checked actually the specs at this time.
Cheers, Daniel
On Jun 18, 2011, at 5:35 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
iirc, the PRACK should follow the record-routing as part of its early dialog state. At least, from my experience the PRACKs I saw so far were sent to the proxy address due to record routing, not directly to contact address in 183. Without following the record routing, I see no way to go even for cases with NAT. For me looks like A is buggy, but I haven't checked actually the specs at this time.
Daniel,
Sorry, perhaps I was not clear. A is a softphone initiating a call through Kamailio. Kamailio forwards the call to UAS B with Record-Route header added, and UAS B sends 183s back to A through Kamailio, with 100rel Require'd. There are no RR headers seen by A, and so it does not know to send PRACK to something but the Contact in the 183.
My understanding is that the deficiency in the standard here is that B is not required to copy RR headers into provisional responses, only final ones.
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Jun 18, 2011, at 5:59 PM, Alex Balashov abalashov@evaristesys.com wrote:
On Jun 18, 2011, at 5:35 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
iirc, the PRACK should follow the record-routing as part of its early dialog state. At least, from my experience the PRACKs I saw so far were sent to the proxy address due to record routing, not directly to contact address in 183. Without following the record routing, I see no way to go even for cases with NAT. For me looks like A is buggy, but I haven't checked actually the specs at this time.
Daniel,
Sorry, perhaps I was not clear. A is a softphone initiating a call through Kamailio. Kamailio forwards the call to UAS B with Record-Route header added, and UAS B sends 183s back to A through Kamailio, with 100rel Require'd. There are no RR headers seen by A, and so it does not know to send PRACK to something but the Contact in the 183. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 6/19/11 12:03 AM, Alex Balashov wrote:
My understanding is that the deficiency in the standard here is that B is not required to copy RR headers into provisional responses, only final ones.
indeed, if 183 does not copy record-route headers is not much to do in A side -- I expected that any 1xx reply apart of 100, and especially 183 to mirror record-route headers. I searched a bit and in several cases I could spot, the 183 had the R-R headers.
So the fault would be now in B, but if there is no _MUST_ for 183 to mirror R-R, then it is in IETF WG :-) ...
Maybe you can fix it via Kamailio configuration file: - if there is no R-R header in 183 and you know it is going to be a bridged call (via some flag set or a special onreply route), then insert the headers manually with append_hf(R-R: sip:ip1;lr\r\nR-R: sip:ip2;lr\r\n");
Then see if A is following the R-R.
Cheers, Daniel
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Jun 18, 2011, at 5:59 PM, Alex Balashovabalashov@evaristesys.com wrote:
On Jun 18, 2011, at 5:35 PM, Daniel-Constantin Mierlamiconda@gmail.com wrote:
iirc, the PRACK should follow the record-routing as part of its early dialog state. At least, from my experience the PRACKs I saw so far were sent to the proxy address due to record routing, not directly to contact address in 183. Without following the record routing, I see no way to go even for cases with NAT. For me looks like A is buggy, but I haven't checked actually the specs at this time.
Daniel,
Sorry, perhaps I was not clear. A is a softphone initiating a call through Kamailio. Kamailio forwards the call to UAS B with Record-Route header added, and UAS B sends 183s back to A through Kamailio, with 100rel Require'd. There are no RR headers seen by A, and so it does not know to send PRACK to something but the Contact in the 183. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 06/18/2011 06:17 PM, Daniel-Constantin Mierla wrote:
indeed, if 183 does not copy record-route headers is not much to do in A side -- I expected that any 1xx reply apart of 100, and especially 183 to mirror record-route headers. I searched a bit and in several cases I could spot, the 183 had the R-R headers.
So the fault would be now in B, but if there is no _MUST_ for 183 to mirror R-R, then it is in IETF WG :-) ...
Well, here's what 3261 12.1.1 ("UAS Behavior") says on the subject:
When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values.
Since a 183 does not establish a dialog, I suppose that means there's no need for the UAS to copy the RR headers.
On the other hand, take a look at page 7 of RFC 3262:
http://www.ietf.org/rfc/rfc3262.txt
It seems to say that Record-Route goes into "2xx,18x", although offers no elaboration on this point. Whether this constitutes an amendment to the 3261 view I do not know.
- if there is no R-R header in 183 and you know it is going to be a
bridged call (via some flag set or a special onreply route), then insert the headers manually with append_hf(R-R: sip:ip1;lr\r\nR-R: sip:ip2;lr\r\n");
Yeah, that was going to be my next step, I just figured I'd try to avoid something so ugly. :-)
Thanks for your help!
2011/6/19 Alex Balashov abalashov@evaristesys.com:
Well, here's what 3261 12.1.1 ("UAS Behavior") says on the subject:
When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values.
Since a 183 does not establish a dialog, I suppose that means there's no need for the UAS to copy the RR headers.
Wrong, 183 *does* establish a dialog. An early-dialog in fact, but that doesn't matter. As said above, 1XX response with require 100rel is a reliable response so it requires Contact header and mirroring Record-Route headers.
On the other hand, take a look at page 7 of RFC 3262:
http://www.ietf.org/rfc/rfc3262.txt
It seems to say that Record-Route goes into "2xx,18x", although offers no elaboration on this point. Whether this constitutes an amendment to the 3261 view I do not know.
It says:
Header field where PRACK __________________________________________ Record-Route R o Record-Route 2xx,18x o
Of course Record-Route is optional in request (INVITE) and 18X or 2XX responses, as the proxy could decide not to do record-routing.
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo