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 tohandling 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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users