Hi Callum, I would say you are on the right tracks.
For detecting different NAT situation, there is no other way than to play with the flags of the `nat_uac_test()`.....
For the in-dialog NAT handling, during the initial request you need to learn the NAT status of the parties involved (for the caller, based on the nat_uac_test(), for the callee, based on the data from lookup()). Once you learned the caller/callee 's NAT status, you should preserve this information across the whole dialog, so, when handling in-dialog requests, you already know the NAT status of each party.
And yes, when you receive traffic (requests or replies) for a party behind the NAT, you need to do the Contact fixing (and SDP if the case), in order to get rid of the private IPs.
Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/13/19 2:12 PM, Callum Guy wrote:
Hi All, I am operating a registrar which proxies calls to an internal network of media servers. Most of my subscribers are operating using RFC1918 addresses behind NAT. We detect this configuration through nat_uac_test() and patch the SIP using fix_nated_contact(). By rewriting the requests the media servers will send in-dialog requests with request URI set to the NAT address. This works fine for the majority of my use cases however I am now dealing with a UAC which has chosen to use public addresses on the handsets but continues to run behind NAT. The effect here is that my choice of flags for nat_uac_test() do not match the scenario and the rewrites are not happening. I can resolve this issue with some additional flags and logic however I wonder if there is a "more correct" way to do this. In an ideal world I would lookup the registration during INVITE processing, notice that there is a different received address and use this for all future communications for the rest of the dialog. For example the initial requests out to these handsets are performing a lookup() operation which will retrieve the original contact for use as request URI and received address for use as destination URI allowing the request to be properly formed and forwarded. The issue arises when the dialog is started, the UAC responds to the well formed INVITE with 200 OK and unless I patch the contact with the received IP the subsequent ACK will end up routing back to the UAC contact rather than the NAT device. What I am hoping is that there may be a correct way for me to track the received IP against the dialog such that it can be used in subsequent in-dialog requests, allowing the request URI to correctly represent the UAC contact whilst still delivering requests to the NAT address. I can probably achieve this by recording the information using dialog variables however I imagine this is a common scenario so I wouldn't want to add this logic in manually if there was a proper way to do this natively in OpenSIPs. Hopefully this isn't one of those questions that gets asked too regularly however if it is please point me in the direction of an article that might help, I've re-read the nathelper, nat_trasveral, registrar and usrloc documentation today and haven't found what I'm looking for. Any pointers would be appreciated before I embark on a homegrown solution. Thanks, Callum
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
