[OpenSIPS-Users] NAT for in-dialog requests

[Bogdan-Andrei Iancu]

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
>