[OpenSIPS-Users] CSeq and Reinvite

[M S]

Found the problem. below is the proposed patch:

--- dlg_handlers.c.280925       2025-09-28 16:55:18.390945830 +0330
+++ dlg_handlers.c      2025-10-18 14:25:45.967860324 +0330
@@ -2282,9 +2282,9 @@
                        src_leg = other_leg(dlg, dst_leg);

                        if (dlg->legs[dst_leg].last_gen_cseq ||
-                       dlg->legs[src_leg].cseq_maps) {
-                               LM_DBG("dlg_leg_get_cseq(dlg, [%d],
req)\n", src_leg);
-                               update_val = dlg_leg_get_cseq(dlg, src_leg,
req);
+                       dlg->legs[DLG_CALLER_LEG].cseq_maps) {
+                               LM_DBG("dlg_leg_get_cseq(dlg, [%d],
req)\n", DLG_CALLER_LEG);
+                               update_val = dlg_leg_get_cseq(dlg,
DLG_CALLER_LEG, req);
                                if (update_val == 0) {
                                        if
(dlg->legs[dst_leg].last_gen_cseq) {

LM_DBG("dlg->legs[%d].last_gen_cseq=[%d]\n",

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

On Sat, Oct 18, 2025 at 1:57 AM M S <medeanwz at gmail.com> wrote:

> Dear Opensips developers,
> 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.
> 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.
> I have 3 solutions and I wonder which one doesn't cause further issues:
> 1. I update inv_cseq with re-invites (and use it later for ACK)
> 2. Add a new field (reinv_cseq) to dlg_leg to keep cseq for reinvites and
> use it later
> 3. figure out if I can fix this using cseq_maps (have to look into it)
>
> Ideas are appreciated!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20251018/68cd99d7/attachment.html>