<div dir="ltr"><div><div><span style="font-family:verdana,sans-serif">One little clarification that the impact of the match mode, the non-default mode is forced with dlg_manage, meaning everyone will use it in this case.<br></span></div><span style="font-family:verdana,sans-serif"></span></div><div><span style="font-family:verdana,sans-serif"><br></span></div><span style="font-family:verdana,sans-serif"></span><div><br><div><span style="font-family:monospace"></span><span style="font-family:monospace"></span><div><span style="font-family:monospace"><br>int dlg_manage(sip_msg_t *msg)<br>...<br>                backup_mode = seq_match_mode;<br>                seq_match_mode = SEQ_MATCH_NO_ID;<br>                dlg_onroute(msg, NULL, NULL);                                                                                                                                                               <br>                seq_match_mode = backup_mode;<br>...<br></span><br><br>I just create a MR with the intent of preventing any mismatch caused by empty to-tag.<br><a href="https://github.com/kamailio/kamailio/pull/2484">https://github.com/kamailio/kamailio/pull/2484</a></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 11:58 PM Henning Westerholt <<a href="mailto:hw@skalatan.de">hw@skalatan.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div style="color:rgb(33,33,33);background-color:rgb(255,255,255);text-align:left" dir="auto">
Thank you Julien for digging into it. If its affects not the default match mode - this sounds indeed like the reason that it was not found earlier.</div>
<div style="color:rgb(33,33,33);background-color:rgb(255,255,255);text-align:left" dir="auto">
<br>
</div>
<div style="color:rgb(33,33,33);background-color:rgb(255,255,255);text-align:left" dir="auto">
Cheers,</div>
<div style="color:rgb(33,33,33);background-color:rgb(255,255,255);text-align:left" dir="auto">
<br>
</div>
<div style="color:rgb(33,33,33);background-color:rgb(255,255,255);text-align:left" dir="auto">
Henning</div>
<div id="gmail-m_2462028451074523634ms-outlook-mobile-signature">
<div><br>
</div>
<br>
-- <br>
Henning Westerholt - <a href="https://skalatan.de/blog/" target="_blank">https://skalatan.de/blog/</a><br>
Kamailio services - <a href="https://skalatan.de/services" target="_blank">https://skalatan.de/services</a></div>
<div id="gmail-m_2462028451074523634id-91bf6dd5-080f-40d2-9284-f2e1dff6ac40">
<div style="font-family:sans-serif;font-size:12pt;color:rgb(0,0,0)"><br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_2462028451074523634divRplyFwdMsg"><strong>Von:</strong> sr-users <<a href="mailto:sr-users-bounces@lists.kamailio.org" target="_blank">sr-users-bounces@lists.kamailio.org</a>> im Auftrag von Julien Chavanton <<a href="mailto:jchavanton@gmail.com" target="_blank">jchavanton@gmail.com</a>><br>
<strong>Gesendet:</strong> Samstag, 26. September 2020, 04:17<br>
<strong>An:</strong> Daniel-Constantin Mierla<br>
<strong>Cc:</strong> Kamailio (SER) - Users Mailing List<br>
<strong>Betreff:</strong> Re: [SR-Users] Dialog - timeout for dlg with CallID<br>
</div>
<br>

<div dir="ltr">
<div>It seems I found the problem and I have a fix. <br>
</div>
<div><br>
</div>
<div>The root cause is probably that the locally generated 408 is not updating the dialog to-tag.<br>
</div>
<br>
<div>However, always checking for a to-tag match, before a non to-tag match will fix any such issue.<br>
<br>
I will prepare a merge request on Monday to start discussing the option always matching to-tag first.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 11:27 AM Julien Chavanton <<a href="mailto:jchavanton@gmail.com" target="_blank">jchavanton@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr"><span style="font-family:monospace"><span style="font-family:verdana,sans-serif">I did catch the logs, and after looking at the trace, it seems like dialog mismatch with a serial forking scenario :</span><br>
</span>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:verdana,sans-serif">- log line 3 is telling us that a NO-ACK disconnection should be triggered<br>
</span></div>
<div><span style="font-family:monospace"><span style="font-family:verdana,sans-serif">- log line 1-2 is telling us what happened when the ACK was received in dlg_onroute()</span>,
<span style="font-family:verdana,sans-serif">oddly enough state 5 was old and new, could it be a mismatch/confusio with the previous dialog, looking in this direction ...</span><br>
</span></div>
<div><span style="font-family:monospace"><br>
1: 2020-09-25T16:30:16.896: dialog [dlg_handlers.c:1273]: extra_ack_debug_info(): [ACK][1] state not changed >>> call-id[562419_125824138_2072238224] to-tag[<<a href="mailto:sip%3A%2B14019991904@anon.com" target="_blank">sip:+14019991904@anon.com</a>>;tag=gK02b68836]<br>
2: 2020-09-25T16:30:16.896: dialog [dlg_handlers.c:1440]: dlg_onroute(): [ACK] state not changed old[5]new[5]
<br>
...<br>
3: 2020-09-25T16:32:22.674: dialog [dlg_hash.c:247]: dlg_clean_run(): dialog disconnection no-ACK call-id[562419_125824138_2072238224][1601051416]<[1601051542 - 60]<br>
<br>
<br>
<span style="font-family:verdana,sans-serif">After looking at the pcap trace, call-id 562419_125824138_2072238224 was involved in serial forking :</span><br>
<br>
call attempt #1<br>
<br>
X >> INVITE >> Y   // no to-tag  <br>
X << 100<br>
...<br>
X << 408           // to-tag=594d50c3218065a60bb91fd47a70fbc1-59edef02 (locally generated)<br>
X >> ACK           // to-tag=594d50c3218065a60bb91fd47a70fbc1-59edef02<br>
<br>
call attempt #2<br>
<br>
X >> INVITE >> Z   // no to-tag<br>
X << 100<br>
X << 200    << Z   // to-tag=gK02b68836<br>
X >> ACK    >> Z   // to-tag=gK02b68836 (Should be state old[3]new[4], I wonder how it could possibly be state old[5]new[5])<br>
<br>
<br>
</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace">I did look at several occurrences and there is always a locally generated 408/to-tag before, seems like I have a good lead to investigate further.</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace"></span><br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>

</blockquote></div>