[OpenSIPS-Users] CSeq and Reinvite
M S
medeanwz at gmail.com
Tue Nov 11 11:40:08 UTC 2025
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 <razvan at opensips.org> 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 <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!
> >>
> >>
> >> 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
> >> <mailto: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!
> >>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20251111/b55d7bcd/attachment-0001.html>
More information about the Users
mailing list