Hi Nathan,
1) both nathelper and nat_traversal module are fine for the moment, as
time as they serve your needs.
2) short answer : the routing of SUBSCRIBE based dialogs do not require
location data, as all the SIP dialog routing data is stored in the SIP
messages themselves - see the Route Set concept (
http://www.opensips.org/Documentation/Webinars#toc12, chapter 5.5,
Routing in SIP).
On P0 you need to do fix_contact() (so the private contact is replaced)
and nat_keepalive() (for pinging purposes). The Notify will be routed
back from P1 via Route hdrs (P0) and received Contact (fixed to point to
a public IP).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 12/12/2017 07:01 PM, Nathan Baker wrote:
Hello Everyone,
After reading the documentation for the NAT traversal module I have a
couple questions about it, some specific to my purpose of proxying
presence messages:
1) I came across this old page
(https://www.opensips.org/Development/Nattraversal) on the OpenSIPS
website seeming to indicate that the nathelper module was going to go
away at some point. I'm guessing that work is not being done anymore,
but wondering if one module is better than the other, or are both
fine? It seems like NAT traversal has more flexibility for keepalives
outside of just for registrations.
2) In the NAT traversal documentation, section 1.8.3 Subscription in
multi-proxy environments, it says:
We have a user agent UA1 for which subscriptions are handled by
the proxy P1. However UA1 sends the SUBSCRIBE to P0 which in turn
forwards it to P1 like this: UA1 --> P0 --> P1. In this case P0
calls nat_keepalive(), then calls record_route() to stay in the
path and forwards the request to P1 using t_relay().Further
SUBSCRIBE and NOTIFY requests will follow the record route and use
P0 as a NAT entry point to have access to UA1.
Basically I'm wondering how P0 would keep track of the received/NAT
address of UA1 for routing the NOTIFY it gets, without relying on UA1
to be registered and stored in the location table? P1 will route the
NOTIFY to P0 because of Record Routing, but the Contact in the message
will either have a domain name or private IP address. Is this
recommendation assuming that fix_contact() should be called before
relaying the subscribe message?
I can probably just add the received address info in parameters on the
record-route (I tested this does work), or on the Contact, in the
original SUBSCRIBE, but this doesn't seem like a clean solution. Am I
missing a better or easier way to accomplish this? I didn't have good
luck with the topology_hiding module or dialog module with presence,
so my last resort would be to store subscriptions in a new location table.
Sorry for the long post, any help would be greatly appreciated!
Thanks,
Nate
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
