Codec stripped from final 200(SDP) when codec changes after UPDATE negotiation with a new to-tag

[pyysa]

rtpengine version the issue has been seen with

13.5.1.16+0~mr13.5.1.16

Used distribution and its version

Debian 12

Linux kernel version used

6.1.0-37-amd64

CPU architecture issue was seen on (see uname -m)

x86_64

Expected behaviour you didn't see

A -> B: INVITE (EVS, AMR-WB)
B -> A: 183 Session Progress (EVS)
A -> B: UPDATE (EVS)
B -> A: 200 OK UPDATE (EVS)
B -> A: 200 OK INVITE (AMR-WB)

Comunication establishes correctly

Unexpected behaviour you saw

A -> B: INVITE (EVS, AMR-WB)
B -> A: 183 Session Progress (EVS)
A -> B: UPDATE (EVS)
B -> A: 200 OK UPDATE (EVS)
B -> A: 200 OK INVITE (AMR-WB) -> Not adding stray answer codec AMR-WB

Call fails

Steps to reproduce the problem

No response

Additional program output to the terminal or logs illustrating the issue

debug log available: https://gist.github.com/pyysa/bf42c415c3541c4ce8c8838918ac9580

Anything else?

I tried previusly already report this at #2073
And i can confirm that without that UPDATE there in the middle the AMR-WB at 200ok works as expected based on the fix done on that issue.

rtpengine_manage("replace-session-connection replace-origin trust-address replace-force-increment-sdp-ver")

For readability and privacy, I have anonymized the IP addresses in the logs.
I also collapsed all callers/callee-side IPs into the same placeholder (2.2.2.2/3.3.3.3), even though in the original trace signalling and media used different addresses.

RTPengine has the ip 1.1.1.1
The caller has the ip 2.2.2.2
The callee has the ip 3.3.3.3
The kamailio instance has the ip 4.4.4.4

[rfuchs]

The debug log you posted is missing the content of the SDPs

[pyysa]

My mistake, sdps included https://gist.github.com/pyysa/bf42c415c3541c4ce8c8838918ac9580

[rfuchs]

Not really sure how you expect this to work. The subsequent offer (I guess it's the one from the UPDATE) only lists EVS, so from this moment on, "A" is understood to only support/want EVS. The following answer with AMR is therefore not valid.

[pyysa]

Ah, sry, again misleading while reporting, the update is coming from A->B (fixed in original post). In SIP-wise the update is part of the early-dialog and its to-tag is same as the one in 183, so i would assume its only narrowing the possible options which are given in 183, (yes, there isnt actually any options on 183, but i guess could be). B confirms that with 200ok but still i think it should be related only towards the early-dialog. When the 200ok for invite arrives it contains different to-tag which i would assume should be recognized as new party. The scenario is first phone ringing and then eventually voicemail answering with the final 200OK.

[rfuchs]

No I understood, but with the UPDATE from "A" only advertising EVS, to me this says that "A" now only supports EVS. So I'm not sure that an answer to a previously sent offer with a different codec is even valid. In your case I guess it works, but I'm not sure if that can be reliably expected. A client sending an UPDATE (or a re-INVITE for that matter) with just one codec may well have abandoned support for all other previously offered codecs. So I don't think this can be considered a bug.

[pyysa]

I agree that a regular UPDATE within an existing early-dialog should replace the previous offer for that dialog.

However, in my trace the final 200 OK contains a different To-tag than the UPDATE(and 183) transaction. Since the dialog identifier is Call-ID + From-tag + To-tag, a changed To-tag appears to create a different dialog leg rather than confirming the dialog that carried the UPDATE.

From that perspective, the UPDATE belongs to the earlier dialog, while the newly established dialog has only seen the original INVITE offer. Therefore I would expect RTPengine to match the SDP in the 200 OK against the original INVITE offer, not against the UPDATE that was sent on the other dialog leg.

[rfuchs]

From that perspective, the UPDATE belongs to the earlier dialog, while the newly established dialog has only seen the original INVITE offer. Therefore I would expect RTPengine to match the SDP in the 200 OK against the original INVITE offer, not against the UPDATE that was sent on the other dialog leg.

It doesn't work like that. Rtpengine associates codec support with call parties, not with dialogues. A call party offering only EVS is understood to mean that the call party only supports EVS, regardless of what was offered before. We'd have to introduce a whole new set of logic to change that.

[pyysa]

Roger, and in a way that makes sense cause A is not changing in the dialog. Ill close this one and try to figure out other options how to solve my issue. Thanks for the replies.