[OpenSIPS-Users] Incorrect callid in ACK

[John Quick]

Mark,

I think I know what is going on here.
By a lucky coincidence I was testing two OpenSIPS servers back to back in a
very similar setup to yours.
Today I converted one of them to use Topology Hiding, (partly to try to help
you but it was something I wanted anyway).
After converting it to use Topology Hiding, I got an error that looks very
similar to yours and I think the solution to my problem is quite likely to
be the solution for you too.

Background: See my article below about Contact header fixing and look for
the section "When is it wrong to fix a Contact header?"
https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/
It specifically refers to the case of two SIP proxies back-to-back.

What I found today is that Topology Hiding makes this problem much harder to
spot because the fixed Contact header will never appear in a SIP trace such
as you get in sngrep.
Instead, what you see in the sip trace is the usual hashed id substituted by
the TH module. It makes debugging very confusing.

When the 200 OK arrives at your 2nd OpenSIPS Proxy from your 1st OpenSIPS
Proxy, are you calling fix_nated_contact() in onreply_route?
If you are, I'd wager that's your problem. You must not fix the Contact
header because you are receiving the 200 OK from another proxy.

You could design a fix based on checking the source address of the reply,
but alternatively it may also be possible to insert a more generalised
solution in onreply_route.
On your 2nd OpenSIPS Proxy (the one using Topology Hiding), I think some
code like this might work:
  if (is_present_hf("Record-Route"))
      xlog("Found a Record-Route header.   Not going to fix Contact\n");
  else {
      if (nat_uac_test(65)) {
          fix_nated_contact();
          xlog("Fixing Contact\n);
      } else
          xlog("No need to fix Contact header.  Its alright anyway\n");
  }

John Quick
Smartvox Limited