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

<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><div><img src="https://www.x-on.co.uk/email/footer/General-Practice-Awards-winners.jpg"></div><div><br></div><div><div><div><font size="4"><b>^{<font face="Verdana">0333 332 0000  |  <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a>  |  </font>}</b></font><font size="4"><b>_{^{<font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a>  <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a>  <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font>}} </b></font><br><p><span style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span> and delete the<br>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. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>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<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>





<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p></div></div></div>