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 the original header doesn't match what's in the existing dialog. WARNING:dialog:dlg_onroute: tight matching failed for ACK with callid=' [email protected]'/60, ftag='3832136123-1536789624'/21, ttag='2e31e1179f3440fca8aed29db28c4314'/32 and direction=0 WARNING:dialog:dlg_onroute: dialog identification elements are callid='DLGCH_e0JXVmd7Y2NiQ11dYXhjZX5CVkNhfWlneUlRXWIJIzEsXRAFfiV9NS4CVVkxZyU4YQMBBz1nMidhHgAa'/86, caller tag='3832136123-1536789624'/21, callee tag='2e31e1179f3440fca8aed29db28c4314'/32 But according to sngrep the ACK arrives with the correct Call-ID header: Call-ID: DLGCH_e0JXVmd7Y2NiQ11dYXhjZX5CVkNhfWlneUlRXWIJIzEsXRAFfiV9NS4CVVkxZyU4YQMBBz1nMidhHgAa So I don't know which to believe at this point. Mark. On Tue, 8 Jun 2021 at 13:58, John Quick <[email protected]> wrote: > 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 hiding puts a unique hash code into the Contact > header. Is that getting altered by a downstream server? > > Compare the "200 OK" elements with the equivalent ACK elements. Hope this > helps. > > John Quick > Smartvox Limited > > > -- Mark Farmer [email protected]
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
