Hi Brandon!
This is my pragmatic approach:
During dialog-creating transaction (INVITE, SUBSCRIBE) I decide if a clients gets NAT-traversal* or not. Thus result will be stored in a record-route cookie (add_rr_param()).Therefore, when dooing loose_route I will check the content of this parameter and therefor apply same strategy to in-dialog requests.
* perform NAT traversal always, unless I know for sure that the client does not support symmetric SIP. For doing NAT traversal you can either use fix_nated_contact() - which is not standard conform but works - or use the new add_contact_alias/handle_ruri_alias (kamailio 3.0: http://sip-router.org/docbook/sip-router/branch/master/modules_k/nathelper/n...)
regards klaus
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users