[Kamailio-Users] Loose Route / Re-Invite

[brandon at cryy.com]

Hello,

    I do see all the behavior as referenced, however the actual problem is upon receipt of the invite to the UAC, in which it responds with 200 OK and Contact of RFC1918 address, in which is not being fix natted contact because at this point kamailio is not aware of the UAC being behind nat due to the reinvite passing the nat uac test because we can not tell with the invite coming downstream from PSTN, however can only tell upon receipt of 200 ok back from client.

Let me know if this all makes sense and if there is something I am still missing.

Thanks again for all of the help! 
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Iñaki Baz Castillo <ibc at aliax.net>
Date: Wed, 3 Feb 2010 21:17:47 
To: <users at lists.kamailio.org>
Subject: Re: [Kamailio-Users] Loose Route / Re-Invite

El Miércoles, 3 de Febrero de 2010, Brandon Armstead escribió:
> Hello everyone,
> 
>    I'm just curious as to see what some of you guys do in regards to
> handling a Re-Invite that comes back downstream to a NATTED UAC.
> 
> For example, call scenario:
> 
> UAC -> Kamailio (Fix Nated Contact) -> PSTN
> 
> Re-Invite Occurs:
> 
> PSTN -> Kamailio -> UAC
> 
> UAC (200 OK w/ NAT RFC1918 contact) -> Kamailio (branch flags at this point
> are not notifying of NAT, due to the downstream direction of the INVITE, so
> RFC1918 address exists, but does not fix_nated_contact) -> PSTN
> 
> PSTN does not appropriately ACK.
> 
> 
> So, what are your guys solutions for solving this problem?
> 
> Is the best way to add an attribute onto the contact header sent in
>  original INVITE?  Are there other ways of handling?  What is the best,
>  cleanest method.  Possible to handle with AVP's?
> 
> Thanks in advanced for all of your input!


This is IMHO the most common approach:

- UA1 -> Kamailio (fix natted Contact and do loose routing) -> PSTN.

At this point, the dialog info of PSTN endpoint is:
- target_uri: "Contact" URI fixed by Kamailio (so a public address).
- route set: the IP of Kamailio (which added it in Record-Route).

So when the PSTN endpoint sends the re-INVITE it would look at follows:

  INVITE sip:ua1 at PUBLIC_ADDRESS_OF_UA1 SIP/2.0
  Route: <sip:PROXY_IP>

Such INVITE is sent to the proxy (due to the presence of a Route header 
mirrored from the Record-Rooute in the dialog creation).

The proxy does loose routing by removing the Route header and routes the 
INVITE to the SIP URI present in the request line:

 sip:ua1 at PUBLIC_ADDRESS_OF_UA1

So the INVITE will reach ua1 as it will use the open mapping in the NAT 
router.


However this is not a perfect solution as the domain/host part of the original 
Contact URI is modified by the proxy, so such INVITE could be rejected by UA1 
(it doesn't match the SIP URI it set in the original "Contact" header).

But the fact is that this "hack" works in the real world.




-- 
Iñaki Baz Castillo <ibc at aliax.net>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users