<div dir="ltr">Hi John, many thanks for this!!<div><br></div><div>I have actually removed all instances of fix_nated_contact() from OpenSIPS2 and my problem is solved :)</div><div><br></div><div>Anyone setting up OpenSIPS as a Teams SBC - do not use fix_nated_contact() (even with NAT in place) as it will break your ACK's!</div><div><br></div><div>Mark.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Jun 2021 at 20:42, John Quick <<a href="mailto:john.quick@smartvox.co.uk">john.quick@smartvox.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Mark,<br>
<br>
I think I know what is going on here.<br>
By a lucky coincidence I was testing two OpenSIPS servers back to back in a<br>
very similar setup to yours.<br>
Today I converted one of them to use Topology Hiding, (partly to try to help<br>
you but it was something I wanted anyway).<br>
After converting it to use Topology Hiding, I got an error that looks very<br>
similar to yours and I think the solution to my problem is quite likely to<br>
be the solution for you too.<br>
<br>
Background: See my article below about Contact header fixing and look for<br>
the section "When is it wrong to fix a Contact header?"<br>
<a href="https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/" rel="noreferrer" target="_blank">https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/</a><br>
It specifically refers to the case of two SIP proxies back-to-back.<br>
<br>
What I found today is that Topology Hiding makes this problem much harder to<br>
spot because the fixed Contact header will never appear in a SIP trace such<br>
as you get in sngrep.<br>
Instead, what you see in the sip trace is the usual hashed id substituted by<br>
the TH module. It makes debugging very confusing.<br>
<br>
When the 200 OK arrives at your 2nd OpenSIPS Proxy from your 1st OpenSIPS<br>
Proxy, are you calling fix_nated_contact() in onreply_route?<br>
If you are, I'd wager that's your problem. You must not fix the Contact<br>
header because you are receiving the 200 OK from another proxy.<br>
<br>
You could design a fix based on checking the source address of the reply,<br>
but alternatively it may also be possible to insert a more generalised<br>
solution in onreply_route.<br>
On your 2nd OpenSIPS Proxy (the one using Topology Hiding), I think some<br>
code like this might work:<br>
  if (is_present_hf("Record-Route"))<br>
      xlog("Found a Record-Route header.   Not going to fix Contact\n");<br>
  else {<br>
      if (nat_uac_test(65)) {<br>
          fix_nated_contact();<br>
          xlog("Fixing Contact\n);<br>
      } else<br>
          xlog("No need to fix Contact header.  Its alright anyway\n");<br>
  }<br>
<br>
John Quick<br>
Smartvox Limited<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Mark Farmer<br><a href="mailto:farmorg@gmail.com" target="_blank">farmorg@gmail.com</a></div>