[OpenSIPS-Users] nat_traversal fails on loose_route ACK

[Jeff Pyle]

Robert,

I'll have to dig into that and take a look.  Unfortunately, though, Asterisk
in this case is 1.2.26 and I don't have any ability to update it.  We're
ultimately phasing it out in favor of an Opensips+Freeswitch soltuion.
Because it works well enough to satisfy all the operational criteria of its
time, we're not touching it.  As distasteful as it is we need to get all the
"new" components operating as successfully as possible with it while it's
still around.

It seems to work well enough with a client_nat_test("1")+fix_contact() in
the reply_route.  And that's good enough for me.  :/


- Jeff
 


On 7/11/09 12:39 AM, "Robert Dyck" <robert.dyck at shaw.ca> wrote:

> Maybe before fiddling with the contact make sure you are not being hit by a
> bug in some versions of asterisk. The re-invite arrived OK but not the ACK.
> Was the route set present in the ACK. In-dialog messages should not alter the
> route set. The UAS is not required to send a route header in the reply while
> in-dialog. The UAC should not interpret this as a null route set and must use
> the route set already established. Private addresses can be reached this way.
> 
> On Friday 10 July 2009, Jeff Pyle wrote:
>> ¡Easy indeed!  I didn't have any NAT intelligence in the reply route.
>> 
>> Here's what I tried first:
>> 
>> onreply_route[1] {
>>         if (client_nat_test("3")) {
>>                 xlog("L_INFO", "NAT Reply\n");
>>                 fix_contact();
>>         } else {
>>                 xlog("L_INFO", "Reply\n");
>>         }
>> }
>> 
>> This appeared to work a bit "too" well.  The client_nat_test returned true
>> even for non-NAT'd hosts.  I changed the test from "3" to "1" and it seems
>> to be behaving as expected.
>> 
>> None of the examples seem to use the number 4 "private IP address in the
>> top Via field" test.  Is there any particular reason for that?  In my
>> searches I haven't come across a discussion on the pros and cons of the
>> various tests.
>> 
>> 
>> - Jeff
>> 
>> On 7/10/09 5:03 PM, "Iñaki Baz Castillo" <ibc at aliax.net> wrote:
>>> Easy: you must ensure that the proxy performs NAT detection for reply
>>> routes (onreply_route) for in-dialog requests, and fix the Contact
>>> (fix_contact()) in onreply_route.
>>> 
>>> This is:
>>> 
>>> - The UA sends INVITE behind NAT.
>>> - OpenSIPS fixed Contact and routes it to Asterisk.
>>> - Asterisk replies 200 => proxy => UA.
>>> - UA sends ACK => proxy => Asterisk.
>>> - Now Asterisk sends re-INVITE (in-dialog request) to the proxy.
>>> - The proxy routes it to UA.
>>> - UA replies 200.
>>> - Proxy *fixes Contact* for the 200 and routes to Asterisk.
>>> - Asterisk now will send ACK to proxy with RURI containing the fixed
>>> Contact address (UA's public IP:port).