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
--
Daniel-Constantin Mierla --
http://www.asipto.com
http://linkedin.com/in/miconda --
http://twitter.com/miconda