[BUG]B2b - Incorrect Rseq on provisional response 183 with SDP in dialog.

[devoxy1]

I'm testing redirects with b2b on opensips setup. I have A calling to opensips, opensips sends call to B, B responds with 183 with SDP for media which is sent back to A, then B sends 302 Redirect(with Contact C) to opensips, opensips accepts it and sends INVITE to C, C sends 183 with new SDP(new IP), opensips sends it back to A, then C replies with 200 OK.

The scenario is:
A -INVITE--> Opensips -INVITE--> B
A <-183(SDP Cseq1) -- Opensips <-183(SDP) -- B
------ Opensips <-302-- B
------ Opensips --BYE-> B
------ Opensips --INVITE-> C
A <-183(SDP Cseq1) -- Opensips <-183(SDP) -- C
------ Opensips <-200OK-- C

OpenSIPS version you are running

version: opensips 3.4.9 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 448fdf959
main.c compiled on 12:37:50 No
v 19 2024 with gcc 11

Describe the bug
The problem is that opensips doesn't change Rseq number on second 183 with new SDP, which makes A to discard this message and not update new connection address from SDP.

To Reproduce

1. Call from A to B via opensips
2. B sends 183 with SDP to opensips
3. opensips sends 183 to A
4. B sends 302 to redirect the call to C
5. opensips accepts 302 and send new INVITE to C
6. C sends 183 with new SDP to opensips
7. opensips send 183 with new SDP to A Incorrect Rseq
8. C sends 200OK to opensips
9. opensips send 200OK to A

Expected behavior
Based on RFC3262

The provisional response to be sent reliably is constructed by the
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing the
option tag 100rel, and MUST include an RSeq header field. The value
of the header field for the first reliable provisional response in a
transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that
it be chosen uniformly in this range. The RSeq numbering space is
within a single transaction. This means that provisional responses
for different requests MAY use the same values for the RSeq number.

Second 183 goes to A within single transaction and it is not a retransmit, therefore it should have Rseq 2 for A to accept it and change ip for media respectively.

Relevant System Logs

OS/environment information

• Operating System: Ubuntu 22.04.1 LTS
• OpenSIPS installation: git
• other relevant information:

Additional context

[github-actions]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[devoxy1]

Up

[github-actions]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.