[OpenSIPS-Users] NAT for in-dialog requests

[Callum Guy]

Hi Bogdan,

Apologies for the late reply, I've been away on paternity leave but your
response is very much appreciated as I resume work on the project.

Thank you for the clarification, I didn't expect a one size fits all
approach to NAT but wanted to confirm that I wasn't missing a trick.

Callum

On Tue, 7 Jan 2020 at 12:41, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

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

-- 





*0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> *


X-on
is a trading name of Storacall 
Technology Ltd a limited company registered in
England and Wales.


Registered Office : Avaland House, 110 London Road, Apsley, Hemel 
Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.

The 
information in this e-mail is confidential and for use by the addressee(s)

only. If you are not the intended recipient, please notify X-on immediately 
on +44(0)333 332 0000 and delete the
message from your computer. If you are 
not a named addressee you must not use,
disclose, disseminate, distribute, 
copy, print or reply to this email. Views
or opinions expressed by an 
individual
within this email may not necessarily
reflect the views of X-on 
or its associated companies. Although X-on routinely
screens for viruses, 
addressees should scan this email and any attachments
for
viruses. X-on 
makes no representation or warranty as to the absence of viruses
in this 
email or any attachments.










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200116/5888d2d0/attachment.html>