VP8/H264 simulcast producer causes "RTP extension ID reassignment not supported" in Chrome 148+

[panov-va]

NOTE

Looks like a regression in libwebrtc. See https://issues.webrtc.org/issues/503013383.

Bug

Starting with Chrome 148, producing a video simulcast track and then producing (or replacing) an audio track on the same send transport throws at setLocalDescription and permanently breaks the PeerConnection:

Failed to set local offer sdp: RTP extension ID reassignment not supported (video-layers-allocation00 → ssrc-audio-level)

VP8 hits a slightly different variant, typically when the mic is swapped after video is already published:

RTP extension ID reassignment not supported (dependency-descriptor → ssrc-audio-level)

Once either one fires, the send transport is toast — no further producers can be created on it.

Steps to reproduce

NOTE: See also these STR that are easier to test.

1. Create a send transport and produce a video simulcast track (VP8 or H264).
2. Produce an audio track on the same transport.
3. Close the audio producer and produce again with a different deviceId.

Step 3 throws the reassignment error.

Reproducible in mediasoup-demo with a small tweak: split the combined enable/disable flow into separate per-device buttons for webcam, mic, and mic selection.

Expected behaviour

Renegotiation goes through regardless of the order in which audio and video producers are created or replaced.

Environment

• mediasoup-client: 3.18.8
• Browser: Chrome 148+ (confirmed on 148.0.7778.5 Beta; Chrome 147 stable is fine)
• Codec: VP8 and H264 simulcast
• OS: any

Root cause

Chrome 148 picked up libwebrtc commit 5788235 ("Consolidate RTP header extension validation in BaseChannel"), which adds a historical_rtp_header_extensions_ map on BaseChannel. Every extmap ID seen in a local offer is recorded there permanently, and any later setLocalDescription that binds the same ID to a different URI gets rejected.

AnswerMediaSection builds the synthetic answer only from extensions the server confirmed (answerRtpParameters.headerExtensions). Extensions Chrome offered but the server doesn't support — video-layers-allocation00 for simulcast, dependency-descriptor for VP8/VP9 — are dropped from the answer. Chrome still records their IDs in its history but treats them as "unconfirmed", so when a later m-section comes along it may hand those IDs to other extensions (e.g. ssrc-audio-level). The new strict check then rejects the whole renegotiation.

Fix

#367

[pnts-se-whereby]

Thank you!

producing a video simulcast track and then producing (or replacing) an audio track on the same send transport

Are you sure it happens when we're replacing a track in an audio producer? It's easy to reproduce when closing the audio producer and creating a new one, but so far I can't reproduce it while replacing the track in an audio producer.

[ibc]

Can someone please expose STR to reproduce using the mediasoup demo?

Also, why would I need to create a new audio producer with a different deviceId? How is that related at all?

And last question before I review the issue and PR in detail (hopefully tomorrow): Is this a bug in Chrome and this PR "mitigates/hides" it? If I understood the issue properly it happens when the remote SDP answer doesn't include the extension IDs that were in the local offer but the remote doesn't support them. Is it? And the fix is basically copy&pasting ALL extensions of the offer into the answer despite mediasoup may not support them all. Is that right? If so I don't like that solution because we really want to disable those unsupported extensions. At least we should include them into the answer either direction "disabled" if that thing exists. But if my understanding is correct this is a wrong behaviour of Chrome rather than a spec based thing.

[pnts-se-whereby]

I interpret the intention of the libwebrtc change to be a refactor. Not a change.
Currently, I'm leaning towards it maybe being a bug.

From libwebrtc PR review comments:

RTP header extensions are supposed to be constant across the session (once assigned they can never change), so registering the URI twice should have no effect - it should always get the same number.

(RFC 8285 section 7, paragraph 7)

To me, it looks like this is in line with RFC 8285 section 7.

From RTC 8285 section 7:

An answerer that has no desire to, or is unable to, send the extension SHOULD remove it from the SDP answer.
[...]
An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP answer.

And that is what we currently do in mediasoup-client right? We're dropping unsupported extensions from the answer if the router does not support them.

[pnts-se-whereby]

At least we should include them into the answer either direction "disabled" if that thing exists. But if my understanding is correct this is a wrong behaviour of Chrome rather than a spec based thing.

According to the spec you can set direction to "inactive" if you may decide to receive/send sometime in the future.

From RFC 8285:

An answerer MAY want to respond that he supports the extension and does not want to receive it at the moment, but he may indicate a desire to receive it in a future offer and will mark the extension as "inactive".

I'm not sure, but that seems like a hack/workaround in our case when we know the router does not support an extension.

[ibc]

I interpret the intention of the libwebrtc change to be a refactor. Not a change. Currently, I'm leaning towards it maybe being a bug.

From libwebrtc PR review comments:

RTP header extensions are supposed to be constant across the session (once assigned they can never change), so registering the URI twice should have no effect - it should always get the same number.
(RFC 8285 section 7, paragraph 7)

To me, it looks like this is in line with RFC 8285 section 7.

From RTC 8285 section 7:

An answerer that has no desire to, or is unable to, send the extension SHOULD remove it from the SDP answer.
[...]
An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP answer.

And that is what we currently do in mediasoup-client right? We're dropping unsupported extensions from the answer if the router does not support them.

Yes, that's what mediasoup-client does and for sure that's correct. We do need to disable unsupported extensions by not including them in the remote SDP answer.

At least we should include them into the answer either direction "disabled" if that thing exists. But if my understanding is correct this is a wrong behaviour of Chrome rather than a spec based thing.

According to the spec you can set direction to "inactive" if you may decide to receive/send sometime in the future.

From RFC 8285:

An answerer MAY want to respond that he supports the extension and does not want to receive it at the moment, but he may indicate a desire to receive it in a future offer and will mark the extension as "inactive".

I'm not sure, but that seems like a hack/workaround in our case when we know the router does not support an extension.

Ok, so let's assume we do need to include unsupported extensions in the remote SDP answer (more about this in next comment I will write soon). In that case we must add inactive to them. It would have the same effect as removing them from the SDP answer.

[ibc]

In Chrome111 and other handlers, in send() method we do this (among many other things):

const transceiver = this._pc.addTransceiver(track, {
	direction: 'sendonly',
	streams: [this._sendStream],
	sendEncodings: encodings,
});

// [...]

let offer = await this._pc.createOffer();
let localSdpObject = sdpTransform.parse(offer.sdp!);

// [...]

const extraHeaderExtensions: {
	uri: RtpHeaderExtensionUri;
	kind: MediaKind;
	direction: RtpHeaderExtensionDirection;
}[] = [];

extraHeaderExtensions.push({
	uri: 'http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time',
	kind: track.kind as MediaKind,
	direction: 'sendonly',
});

// [...]

if (headerExtensionOptions?.absCaptureTime) {
	const offerMediaObject = localSdpObject.media[mediaSectionIdx.idx]!;

	sdpCommonUtils.addHeaderExtension({
		offerMediaObject,
		headerExtensionUri:
			'http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time',
		headerExtensionId: sendingRemoteRtpParameters.headerExtensions!.find(
			headerExtension =>
				headerExtension.uri ===
				'http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time'
		)!.id,
	});

	offer = {
		type: 'offer',
		sdp: sdpTransform.write(localSdpObject),
	};
}

await this._pc.setLocalDescription(offer);

So here, if headerExtensionOptions.absCaptureTime is set to true, we are mangling the SDP offer generated by the browser by adding a new extension "abs-capture-time" with an id that is chosen by mediasoup-client (and not by Chrome).

But AFAIU there is nothing risky here, right? This is perfectly legal. Also notice that the chosen id for "abs-capture-time" extension is constant (it doesn't change) when new Producers are created later (or I think so, I'm 99% sure I enforced this when I wrote this complex code in the past).

Then in RemoteSdp class in send() method we may remove "dependency-descriptor-rtp-header-extension" extension from the generated remote SDP answer to ensure that we don't enable Dependency-Descriptor stuff for certain problematic codecs. Again, here we are just NOT including in the SDP answer some extensions that mediasoup doesn't support (or that don't work correctly for certain video codecs). I fail to see how this can be a problem.

---

So my point is: where exactly is mediasoup-client (I mean v3 main branch) doing something risky or problematic? Do I miss something? Otherwise it looks to me that there is a real bug (a regression) in libwebrtc/Chrome.

Could I know please how exactly to reproduce the issue using the mediasoup-demo app?

[ibc]

Ok, I found a way to reproduce the problem in Chrome (Canary 149) using the mediasoup-demo app:

STR 1

1. Join a room with webcam producer and without mic producer: https://local.dev:5555/?roomId=xxxx&info=true&mic=false&webcam=true&datachannel=false
2. In Console run CC.enableMic().
3. In Console run CC.disableMic().
4. 4 In Console run CC.enableMic().

Error:

RoomClient.js:995 mediasoup-demo:ERROR:RoomClient enableMic() | failed:OperationError: Failed to execute 'setLocalDescription' on 'RTCPeerConnection': Failed to set local offer sdp: RTP extension ID reassignment not supported (id=14, old_uri="http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00", new_uri="urn:ietf:params:rtp-hdrext:ssrc-audio-level"). (mid=3)

STR 2

1. Join a room with webcam producer and without mic producer: https://local.dev:5555/?roomId=xxxx&info=true&mic=false&webcam=true&datachannel=false
2. In Console run CC.disableWebcam().
3. In Console run CC.enableMic().

Error:

RoomClient.js:995 mediasoup-demo:ERROR:RoomClient enableMic() | failed:OperationError: Failed to execute 'setLocalDescription' on 'RTCPeerConnection': Failed to set local offer sdp: RTP extension ID reassignment not supported (id=3, old_uri="urn:3gpp:video-orientation", new_uri="http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01"). (mid=2)

[ibc]

So let's see how SDPs look like when testing the STR 2 above:

NOTE: Some SDP attributes and fields removed to simplify the review.

1. Join a room with webcam producer and without mic producer: https://local.dev:5555/?roomId=xxxx&info=true&mic=false&webcam=true&datachannel=false

createOffer()

v=0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS df9e47ac-a944-4402-a842-65cdd32c1807

m=video 9 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:13 https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension
a=extmap:14 http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00
a=sendonly
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 36f3d7f1-6517-4c7f-8519-a2517c4a0795
a=rid:r0 send
a=rid:r1 send
a=rid:r2 send
a=simulcast:send r0;r1;r2

setLocalDescription() (munged) 

v=0
a=extmap-allow-mixed
a=msid-semantic: WMS df9e47ac-a944-4402-a842-65cdd32c1807
a=group:BUNDLE 0

m=video 9 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:13 https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension
a=extmap:14 http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=mid:0
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 36f3d7f1-6517-4c7f-8519-a2517c4a0795
a=sendonly
a=rid:r0 send
a=rid:r1 send
a=rid:r2 send
a=simulcast:send r0;r1;r2

setRemoteDescription()

v=0
a=extmap-allow-mixed
a=msid-semantic: WMS *
a=group:BUNDLE 0

m=video 7 UDP/TLS/RTP/SAVPF 96 97
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:3 urn:3gpp:video-orientation
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=mid:0
a=recvonly
a=rid:r0 recv
a=rid:r1 recv
a=rid:r2 recv
a=simulcast:recv r0;r1;r2

2. In Console run CC.disableWebcam()

createOffer()

v=0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS df9e47ac-a944-4402-a842-65cdd32c1807

m=video 58264 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=sendonly
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 36f3d7f1-6517-4c7f-8519-a2517c4a0795
a=rid:r0 send
a=rid:r1 send
a=rid:r2 send
a=simulcast:send r0;r1;r2

setLocalDescription() (NOT munged) 

v=0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS df9e47ac-a944-4402-a842-65cdd32c1807

m=video 58264 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=sendonly
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 36f3d7f1-6517-4c7f-8519-a2517c4a0795
a=rid:r0 send
a=rid:r1 send
a=rid:r2 send
a=simulcast:send r0;r1;r2

setRemoteDescription()

v=0
a=extmap-allow-mixed
a=msid-semantic: WMS *
a=group:BUNDLE 0

m=video 7 UDP/TLS/RTP/SAVPF 96 97
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:3 urn:3gpp:video-orientation
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=mid:0
a=inactive

3. In Console run CC.enableMic()

createOffer()

v=0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS df9e47ac-a944-4402-a842-65cdd32c1807

m=video 58264 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=sendonly
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 36f3d7f1-6517-4c7f-8519-a2517c4a0795
a=rid:r0 send
a=rid:r1 send
a=rid:r2 send
a=simulcast:send r0;r1;r2

m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 3a03e896-ea8b-4d3c-b02e-9bb0a0116636

setLocalDescription() (munged) 

v=0
a=extmap-allow-mixed
a=msid-semantic: WMS df9e47ac-a944-4402-a842-65cdd32c1807
a=group:BUNDLE 0 1

m=video 58264 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=mid:0
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 36f3d7f1-6517-4c7f-8519-a2517c4a0795
a=sendonly
a=rid:r0 send
a=rid:r1 send
a=rid:r2 send
a=simulcast:send r0;r1;r2

m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
a=extmap:14 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
a=mid:1
a=msid:df9e47ac-a944-4402-a842-65cdd32c1807 3a03e896-ea8b-4d3c-b02e-9bb0a0116636
a=sendonly

Error:

Failed to set local offer sdp: RTP extension ID reassignment not supported (id=14, old_uri="http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00", new_uri="urn:ietf:params:rtp-hdrext:ssrc-audio-level"). (mid=1)

[ibc]

Ok, SDPs of STR 2 are exposed in my previous comment. There we should be able to see the problem. @panov-va @pnts-se-whereby could you also please check those SDPs? I'm doing it by more eyes are welcome.

[ibc]

AFAIS the problem is that in step 3. In Console run CC.enableMic(), when calling pc.createOffer() Chrome generates a SDP like this (simplified):

m=video 58264 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time

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

Notice the line a=extmap:14 urn:ietf:params:rtp-hdrext:ssrc-audio-level in the audio media section (mid 1). It's id 14, same id as the one that Chrome generated in createOffer() for the the video media section (mid 0) in the step 1:

m=video 9 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 49 50 123 124 125
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=extmap:13 https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension
a=extmap:14 http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00

So AFAIU this is a bug in libwebrtc, do you agree?

[jmillan]

The SDP upon step 2 (disable webcam) does NOT have RTP extension ID 14. That step is prior to the one you're indicating.

[jmillan]

So AFAIU this is a bug in libwebrtc, do you agree?

Yes, it is the one reusing the RTP extension ID.

[pnts-se-whereby]

So AFAIU this is a bug in libwebrtc, do you agree?

Looks that way to me too.

If libwebrtc has assigned extension ID 14 to http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00, and keep track of the mapping internally, it should not consider the extension ID as free, and attempt to use it for urn:ietf:params:rtp-hdrext:ssrc-audio-level.

[ibc]

I'm reporting the bug in libwebrtc although I found it already so I'm adding the above SDPs

[ibc]

Issue reported in libwebrtc (I've added a comment):

https://issues.webrtc.org/issues/503013383