[OpenSIPS-Users] NAT Traversal Module and Proxying Presence

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Dec 13 05:08:27 EST 2017

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).


Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer

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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171213/2a39cc44/attachment-0001.html>

More information about the Users mailing list