<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Found the problem. below is the proposed patch:</div><div><br></div><div><div>--- dlg_handlers.c.280925       2025-09-28 16:55:18.390945830 +0330</div><div>+++ dlg_handlers.c      2025-10-18 14:25:45.967860324 +0330</div><div>@@ -2282,9 +2282,9 @@</div><div>                        src_leg = other_leg(dlg, dst_leg);</div><div> </div><div>                        if (dlg->legs[dst_leg].last_gen_cseq ||</div><div>-                       dlg->legs[src_leg].cseq_maps) {</div><div>-                               LM_DBG("dlg_leg_get_cseq(dlg, [%d], req)\n", src_leg);</div><div>-                               update_val = dlg_leg_get_cseq(dlg, src_leg, req);</div><div>+                       dlg->legs[DLG_CALLER_LEG].cseq_maps) {</div><div>+                               LM_DBG("dlg_leg_get_cseq(dlg, [%d], req)\n", DLG_CALLER_LEG);</div><div>+                               update_val = dlg_leg_get_cseq(dlg, DLG_CALLER_LEG, req);</div><div>                                if (update_val == 0) {</div><div>                                        if (dlg->legs[dst_leg].last_gen_cseq) {</div><div>                                                LM_DBG("dlg->legs[%d].last_gen_cseq=[%d]\n",</div></div><div><br></div><div>I will apply it today and test under load to see how it works. Note to developers: cseq_maps is created for DLG_CALLER_LEG (defined 0) and not per src/dst</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 18, 2025 at 1:57 AM M S <<a href="mailto:medeanwz@gmail.com" target="_blank">medeanwz@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">Dear Opensips developers,<div>I have noticed a bug with CSeq handling. When handling ACK, Opensips uses dlg->legs[x].last_gen_cseq when forwarding it. This causes problems in the valid case that there is another transaction happening between 200 OK and ACK (i.e. INFO/OK). In this case, ACK uses CSeq from INFO, which is incorrect.</div><div>I thought of using inv_cseq but inv_cseq always points to the CSeq from the first invite, so if this happens during reinvite (my case) we cannot use it.</div><div>I have 3 solutions and I wonder which one doesn't cause further issues:</div><div>1. I update inv_cseq with re-invites (and use it later for ACK)</div><div>2. Add a new field (reinv_cseq) to dlg_leg to keep cseq for reinvites and use it later</div><div>3. figure out if I can fix this using cseq_maps (have to look into it)</div><div><br></div><div>Ideas are appreciated!</div></div></div>
</blockquote></div>
</div></div>