3 Feb
2010
3 Feb
'10
5:36 p.m.
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/…)
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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users