Hi Răzvan, I'm using Opensips 3.4.14 and this bug still exists. locally generated indialog INVITE (Reinvite) are handled in a different way: /* Received RE-INVITE where we mangle the CSEQ due to existing pings sent * * Set the FL_USE_UAC_CSEQ flag so that the TM build_local knows to get the * CSEQ from the INVITE when generating the ACK */ req->msg_flags |= FL_USE_UAC_CSEQ;
Main point of the patch is: dlg->legs[src_leg].cseq_maps should be dlg->legs[DLG_CALLER_LEG].cseq_maps because cseq_maps was originally created using dlg->legs[DLG_CALLER_LEG]. Also, I have applied this patch and it has been working without a problem. On Tue, Nov 11, 2025 at 12:18 PM Răzvan Crainea <[email protected]> wrote: > Hello! > > What version of OpenSIPS are you hitting this bug on? > TBH, I don't think your patch is complete, as I don't think it accounts > for locally generated indialog messages (OPTIONS, re-INVITES). Might > work for your case though, but does not seem generic enough. > But I somehow have the feeling this was sorted out before, that's why > I'm wondering the opensips version you're using. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer / SIPhub CTO > http://www.opensips-solutions.com / https://www.siphub.com > > On 10/18/25 2:01 PM, M S wrote: > > 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 <[email protected]> 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! > >> > >> > >> 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 <[email protected] > >> <mailto:[email protected]>> 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! > >> > >> > >> _______________________________________________ > >> Users mailing list > >> [email protected] > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
