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
