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 <i...@aliax.net>
Date: Wed, 3 Feb 2010 21:17:47
To: <users@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:u...@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:u...@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 <i...@aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
