[OpenSIPS-Users] CSeq and Reinvite

[Răzvan Crainea]

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