Hi John, many thanks for this!!
I have actually removed all instances of fix_nated_contact() from OpenSIPS2
and my problem is solved :)
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!
Mark.
On Thu, 10 Jun 2021 at
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 To
I have confirmed that the Call-ID header is in fact incorrect regardless of
what sngrep tells me by logging the message buffer for ACK's.
The call flows like this:
Provider -> 1st OpenSIPS -> 2nd OpenSIPS -> Teams
What seems to be happening is that the ACK comes from provider to 1st
OpenSIPS and
Thanks for the reply John!
Checking things over, the tags look fine.
According to the logs the ACK is being forwarded with the original Call-ID
header.
It seems to arrive at the next hop as having been encrypted by
topology_hiding() but in the log of that next hop I get a match failure
because th
Mark,
I wasn't using topology hiding, but had a problem similar to this which
baffled me for a long time until I noticed that the To-tag value wasn't
matching the value in the "200 OK". Looking at the DBG logs, it appears that
the dialog matching uses To-tag and From-tag.
Another idea - topology
Hi all!
I'm seeing a really weird issue where topology_hiding_match() fails to
match because of an incorrect Call-ID header but in a trace the header
looks correct.
I did think that it might be because of a missing fix_nated_contact() when
if (has_totag) is true so I added that but no change.
Is
