[SR-Users] 100rel without direct reachability

[Daniel-Constantin Mierla]

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 at 192.168.0.10:5060>
>
> As a result, A attempts to send PRACKs to sip:xxxxx at 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