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 <[email protected]> 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.
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
