[OpenSIPS-Users] NAT Traversal Module and Proxying Presence

Nathan Baker bakern at gmail.com
Tue Dec 12 12:01:29 EST 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171212/77a6479c/attachment.html>


More information about the Users mailing list