<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Răzvan,</div><div>I'm using Opensips 3.4.14 and this bug still exists. locally generated indialog INVITE (Reinvite) are handled in a different way:</div><div><div>/* Received RE-INVITE where we mangle the CSEQ due to existing pings sent</div><div> *</div><div> * Set the FL_USE_UAC_CSEQ flag so that the TM build_local knows to get the</div><div> * CSEQ from the INVITE when generating the ACK */</div><div>req->msg_flags |= FL_USE_UAC_CSEQ;</div></div><div><br></div><div>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].</div><div><br></div><div>Also, I have applied this patch and it has been working without a problem.</div><div><br></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Nov 11, 2025 at 12:18 PM Răzvan Crainea <<a href="mailto:razvan@opensips.org">razvan@opensips.org</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">Hello!<br>
<br>
What version of OpenSIPS are you hitting this bug on?<br>
TBH, I don't think your patch is complete, as I don't think it accounts <br>
for locally generated indialog messages (OPTIONS, re-INVITES). Might <br>
work for your case though, but does not seem generic enough.<br>
But I somehow have the feeling this was sorted out before, that's why <br>
I'm wondering the opensips version you're using.<br>
<br>
Best regards,<br>
<br>
Răzvan Crainea<br>
OpenSIPS Core Developer / SIPhub CTO<br>
<a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">http://www.opensips-solutions.com</a> / <a href="https://www.siphub.com" rel="noreferrer" target="_blank">https://www.siphub.com</a><br>
<br>
On 10/18/25 2:01 PM, M S wrote:<br>
> Found the problem. below is the proposed patch:<br>
> <br>
> --- dlg_handlers.c.280925       2025-09-28 16:55:18.390945830 +0330<br>
> +++ dlg_handlers.c      2025-10-18 14:25:45.967860324 +0330<br>
> @@ -2282,9 +2282,9 @@<br>
>                          src_leg = other_leg(dlg, dst_leg);<br>
> <br>
>                          if (dlg->legs[dst_leg].last_gen_cseq ||<br>
> -                       dlg->legs[src_leg].cseq_maps) {<br>
> -                               LM_DBG("dlg_leg_get_cseq(dlg, [%d],<br>
> req)\n", src_leg);<br>
> -                               update_val = dlg_leg_get_cseq(dlg, src_leg,<br>
> req);<br>
> +                       dlg->legs[DLG_CALLER_LEG].cseq_maps) {<br>
> +                               LM_DBG("dlg_leg_get_cseq(dlg, [%d],<br>
> req)\n", DLG_CALLER_LEG);<br>
> +                               update_val = dlg_leg_get_cseq(dlg,<br>
> DLG_CALLER_LEG, req);<br>
>                                  if (update_val == 0) {<br>
>                                          if<br>
> (dlg->legs[dst_leg].last_gen_cseq) {<br>
> <br>
> LM_DBG("dlg->legs[%d].last_gen_cseq=[%d]\n",<br>
> <br>
> I will apply it today and test under load to see how it works. Note to<br>
> developers: cseq_maps is created for DLG_CALLER_LEG (defined 0) and not per<br>
> src/dst<br>
> <br>
> 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>
> <br>
>> Dear Opensips developers,<br>
>> I have noticed a bug with CSeq handling. When handling ACK, Opensips<br>
>> uses dlg->legs[x].last_gen_cseq when forwarding it. This causes problems in<br>
>> the valid case that there is another transaction happening between 200 OK<br>
>> and ACK (i.e. INFO/OK). In this case, ACK uses CSeq from INFO, which is<br>
>> incorrect.<br>
>> I thought of using inv_cseq but inv_cseq always points to the CSeq from<br>
>> the first invite, so if this happens during reinvite (my case) we cannot<br>
>> use it.<br>
>> I have 3 solutions and I wonder which one doesn't cause further issues:<br>
>> 1. I update inv_cseq with re-invites (and use it later for ACK)<br>
>> 2. Add a new field (reinv_cseq) to dlg_leg to keep cseq for reinvites and<br>
>> use it later<br>
>> 3. figure out if I can fix this using cseq_maps (have to look into it)<br>
>><br>
>> Ideas are appreciated!<br>
>><br>
>><br>
>> Found the problem. below is the proposed patch:<br>
>><br>
>> --- dlg_handlers.c.280925       2025-09-28 16:55:18.390945830 +0330<br>
>> +++ dlg_handlers.c      2025-10-18 14:25:45.967860324 +0330<br>
>> @@ -2282,9 +2282,9 @@<br>
>>                         src_leg = other_leg(dlg, dst_leg);<br>
>>                         if (dlg->legs[dst_leg].last_gen_cseq ||<br>
>> -                       dlg->legs[src_leg].cseq_maps) {<br>
>> -                               LM_DBG("dlg_leg_get_cseq(dlg, [%d], <br>
>> req)\n", src_leg);<br>
>> -                               update_val = dlg_leg_get_cseq(dlg, <br>
>> src_leg, req);<br>
>> +                       dlg->legs[DLG_CALLER_LEG].cseq_maps) {<br>
>> +                               LM_DBG("dlg_leg_get_cseq(dlg, [%d], <br>
>> req)\n", DLG_CALLER_LEG);<br>
>> +                               update_val = dlg_leg_get_cseq(dlg, <br>
>> DLG_CALLER_LEG, req);<br>
>>                                 if (update_val == 0) {<br>
>>                                         if (dlg- <br>
>> >legs[dst_leg].last_gen_cseq) {<br>
>>                                                 LM_DBG("dlg- <br>
>> >legs[%d].last_gen_cseq=[%d]\n",<br>
>><br>
>> I will apply it today and test under load to see how it works. Note to <br>
>> developers: cseq_maps is created for DLG_CALLER_LEG (defined 0) and <br>
>> not per src/dst<br>
>><br>
>> On Sat, Oct 18, 2025 at 1:57 AM M S <<a href="mailto:medeanwz@gmail.com" target="_blank">medeanwz@gmail.com</a> <br>
>> <mailto:<a href="mailto:medeanwz@gmail.com" target="_blank">medeanwz@gmail.com</a>>> wrote:<br>
>><br>
>>     Dear Opensips developers,<br>
>>     I have noticed a bug with CSeq handling. When handling ACK,<br>
>>     Opensips uses dlg->legs[x].last_gen_cseq when forwarding it. This<br>
>>     causes problems in the valid case that there is another<br>
>>     transaction happening between 200 OK and ACK (i.e. INFO/OK). In<br>
>>     this case, ACK uses CSeq from INFO, which is incorrect.<br>
>>     I thought of using inv_cseq but inv_cseq always points to the CSeq<br>
>>     from the first invite, so if this happens during reinvite (my<br>
>>     case) we cannot use it.<br>
>>     I have 3 solutions and I wonder which one doesn't cause further<br>
>>     issues:<br>
>>     1. I update inv_cseq with re-invites (and use it later for ACK)<br>
>>     2. Add a new field (reinv_cseq) to dlg_leg to keep cseq for<br>
>>     reinvites and use it later<br>
>>     3. figure out if I can fix this using cseq_maps (have to look into it)<br>
>><br>
>>     Ideas are appreciated!<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>