[1.x] `a=extmap` Identifier Instability During SDP Renegotiation

[SERDUN]

The main problem is that Janus creates incorrect SDP when updating an active call (specifically, an active SIP plugin handle managing the call leg) like during a transfer.

Specifically, the Janus SIP Plugin fails to keep the numeric ID numbers for a=extmap features consistent for that specific ongoing call (within the context of that plugin handle's session state). These IDs are like temporary nicknames agreed upon at the start of the call (when the handle negotiated the initial SDP) for things like audio level or media line identification. When Janus sends an updated SDP Offer (updating_call/re-INVITE) related to this handle, it incorrectly changes these agreed-upon ID numbers, violating WebRTC rules (RFC 8829) and causing client-side setRemoteDescription errors.

Instead of reusing the IDs originally negotiated for the current call session (e.g., Android B’s active session), the server appears to:

• Reuse IDs from a different session (e.g., Firefox’s), or
• Generate new IDs arbitrarily during the transfer/renegotiation.

This violates RFC 8285 which mandate that the mapping between an RTP header extension URI and its numeric ID A session update MAY add or remove extension(s). Identifier values in the valid range MUST NOT be altered (remapped)..

---

Observed Behavior

1. Initial Negotiation (Android A → Android B – Call ID: e0kHeN...)

Simplified Answer (Agreed Mapping):

m=audio 9 UDP/TLS/RTP/SAVPF ... 111 102 9 0 8 101
...
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
...

State:
Session e0kHeN... expects sdes:mid → ID 4.
All RTP packets will encode the MID using this ID.

---

2. Faulty updating_call SDP (Server → Android B – During Transfer to Firefox)

m=audio 9 UDP/TLS/RTP/SAVPF 9 0 8 96 3 7 18 101
...
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
...

Problem:
The SDP correctly limits the extmaps to the minimal set supported by Firefox (ssrc-audio-level, sdes:mid)
—but it incorrectly changes the ID for sdes:mid from 4 → 3.

This violates:

• RFC 8285 §4.3:

  “Identifier values... MUST NOT be altered (remapped) during a session update.”

• RFC 8285 §5:

  “The same identifier MUST be used for the same offered extension in the answer.”

---

Expected Behavior

When sending the updating_call SDP to Android B for the attended transfer to Firefox,
the server must generate an SDP that:

1. Includes only the extmap URIs supported by the new peer (Firefox):

   • urn:ietf:params:rtp-hdrext:ssrc-audio-level
   • urn:ietf:params:rtp-hdrext:sdes:mid

2. Reuses the IDs originally negotiated for those URIs in the current active session (e0kHeN...).

---

Correct Updating SDP (Expected Server Behavior)

m=audio 9 UDP/TLS/RTP/SAVPF 9 0 8 101
...
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
...

This version:

• Removes unsupported extensions (abs-send-time, transport-cc)
• Preserves the correct numeric mapping (ID 4) for sdes:mid
• Keeps session state consistent across renegotiation

---

Impact

• Negotiation Failure:
  WebRTC clients (Chrome, Firefox, Safari, Pion) will reject the non-compliant SDP with:

  Error: Answer changed id for extmap attribute (urn:ietf:params:rtp-hdrext:sdes:mid) from 4 to 3
  

  → RTCPeerConnection.setRemoteDescription() rejects.
  → The renegotiation fails completely.

• Media Loss or Corruption:
  Since sdes:mid defines how bundled media are demultiplexed,
  any remapping causes the client to misroute or drop RTP packets, leading to total media failure.

---

Standards References

Topic	RFC	Section	Quote
Identifier Stability	RFC 8285	§4.3	“Identifier values... MUST NOT be altered (remapped) during a session update.”
Answerer Behavior	RFC 8285	§5	“The same identifier MUST be used for the same offered extension in the answer.”

---

Related References

• RFC 8285 – A General Mechanism for RTP Header Extensions

---

Conclusion

This issue represents a critical standards violation.
By altering extmap IDs mid-session, the server:

• Breaks Offer/Answer consistency (RFC 8285)
• Causes setRemoteDescription() rejection in all major WebRTC clients

Required Fix

Janus must preserve the extmap ID mapping per session context:

Once a mapping between URI → ID is negotiated for a session,
it must remain stable for all subsequent Offers/Answers within that same session (including attended transfers and re-INVITEs).

---

Severity: Critical — causes total renegotiation failure and media loss in multiparty / attended transfer scenarios.
Affected Components: Janus SIP Plugin / SDP generation during updating_call or re-INVITE handling.

[lminiero]

Not sure I understand the issue: if you're talking call transfers, in Janus (as I think it is in SIP) this is done using different calls, that are associated with each other using custom SIP headers for correlation purposes ("this is the call that replaces call XYX)". Different calls means different PeerConnections, which is why we don't impose any constraint on extension IDs: those are enforced only for updates on an existing PeerConnection.

I don't know if the RFC forces these extension IDs to stay the same in the new call as they ware in the old call too: if so, then we're definitely not doing it at the moment. If this needs to be changed, it will need to wait, as I'll attend the IETF meeting in a few days, so I'll be busy on other things for a couple of weeks. As usual, pull requests are welcome in case you want to try and tackle this yourself first.

[digiboridev]

Not sure I understand the issue: if you're talking call transfers, in Janus (as I think it is in SIP) this is done using different calls, that are associated with each other using custom SIP headers for correlation purposes ("this is the call that replaces call XYX)". Different calls means different PeerConnections, which is why we don't impose any constraint on extension IDs: those are enforced only for updates on an existing PeerConnection.

I don't know if the RFC forces these extension IDs to stay the same in the new call as they ware in the old call too: if so, then we're definitely not doing it at the moment. If this needs to be changed, it will need to wait, as I'll attend the IETF meeting in a few days, so I'll be busy on other things for a couple of weeks. As usual, pull requests are welcome in case you want to try and tackle this yourself first.

Hello, thanks for the response, hope this case will be covered sometime, we also not sure is that should be made on Janus side, currently we fix it via mungle re-invite extmap ids on transport layer before it reach client, but looks like its better to do it on Janus side.

There are some details and log to reproduce the case that might be useful.

Janus log

Log description:

We have 3 client, client A(firefox), client B(android/ios/chrome) and client C(android/ios/chrome).
Whats matter is that firefox has different extmap ids from android/ios/chrome clients.
Provided log shows client C only for simplicity.

Whats happened:
1 - A calls B, they are in call and thy peer connection established using this extmaps.
  a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
  a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
2 - B puts A on hold, and make call to C. they are in call now, peer connection established using these extmaps:
  a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
  a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
  a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
  a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
    this sdps you can find in log:
       invite line 149 at 2025-10-29 18:32:03.140
       answer line 523 at 2025-10-29 18:32:07.691
3 - B made attended transfer from A to C, now C received re-invite with sdp containing extmaps from step 1.
  a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
  a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
    this sdps you can find in log:
      re-invite line 1050 at 2025-10-29 18:32:11.306
4 C set this sdp and webrtc crashes with error of mismatch extmaps ids.

[lminiero]

B made attended transfer from A to C, now C received re-invite with sdp containing extmaps from step 1.

I think that's your problem. That is a separate call, so you shouldn't re-INVITE with a new SDP coming from another call. You can refer to this presentation I made at OpenSIPS a few years ago (video here) to see how call transfers are supposed to work in the Janus SIP plugin.

[lminiero]

This is exemplified in how the RFC describes attended transfers too:

https://www.rfc-editor.org/rfc/rfc5589#section-7.3

As you can see in Figure 7, that's three separate calls. You're trying to only use two, where one is re-invited, but that's not how that's supposed to work to my knowledge.

[digiboridev]

This is exemplified in how the RFC describes attended transfers too:

https://www.rfc-editor.org/rfc/rfc5589#section-7.3

As you can see in Figure 7, that's three separate calls. You're trying to only use two, where one is re-invited, but that's not how that's supposed to work to my knowledge.

Its not the only option, our pbx(PortaSwitch, also tested with 3CX and Asterisk) handles REFER request and join calls on its own and then sends re-invites in existing dialogs, so transferee never receives REFER or "transfer" event from Janus perspective, and dont need to send INVITE(with replaces tag) manually. And its just works 💁‍♂️, but have this little bug with Firefox extmaps.

[lminiero]

The SIP plugin doesn't support that mode, it only does it the way the RFC describes it.