Handle the request and the reply with far-end NAT traversal detection
routines in the same way you would handle a non-sequential INVITE.
On 02/03/2010 03:05 PM, Brandon Armstead wrote:
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!
Sincerely,
Brandon
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web :
http://www.evaristesys.com/