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 when routed to 2nd OpenSIPS it is sent with the original Call-ID created by provider instead of than the one generated by topology_hiding(UC) for the original INVITE which results in: WARNING:dialog:dlg_onroute: tight matching failed for ACK with callid='54303148.....etc' I doubt this is a bug, more likely something I'm doing wrong. Does anyone have any ideas please? Many thanks! Mark. On Tue, 8 Jun 2021 at 16:56, Mark Farmer <[email protected]> wrote: > 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] > -- Mark Farmer [email protected]
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
