Environment:
mediasoup-client: 3.18.7
Firefox: 149.0
Works correctly in Chrome/Chromium
Description:
When consuming multiple producers on a recv transport in Firefox, after some consumers are closed (m-lines become inactive with port 0), mediasoup-client recycles those m-lines for new consumers. If the new consumer has a different media kind than the original m-line (e.g., the m-line was originally audio but is now reused for video), Firefox rejects the SDP with:
DOMException: Remote description changes the media type of m-line 7
After this first failure, the internal SDP state becomes corrupted, and all subsequent consume() calls fail with:
DOMException: mid '13' appears more than once in a BUNDLE group
Additionally, closePendingConsumers() also fails with the same error:
mediasoup-client:ERROR:Transport closePendingConsumers() | failed to close Consumers:
DOMException: mid '13' appears more than once in a BUNDLE group
The recv transport is permanently broken, no new consumers can be created for the lifetime of the session.
Steps to reproduce:
Join a room with multiple participants on Firefox (3+ peers, each producing audio + video)
Wait for some peers to leave (their consumers are closed, m-lines become inactive)
New peers join, mediasoup-client tries to recycle the inactive m-lines
If a recycled m-line's original media type differs from the new consumer's kind, failure
SDP evidence:
The Firefox answer SDP before the failure shows inactive m-lines from closed consumers:
m=audio 0 UDP/TLS/RTP/SAVPF 0 <- mid:10, inactive (was audio)
m=video 0 UDP/TLS/RTP/SAVPF 120 <- mid:11, inactive (was video)
Then mediasoup-client sends a new remote offer with BUNDLE group 0 1 2 3 4 5 probator 13 12, where mid 13 maps to the recycled m-line 7 (originally audio, now video), Firefox rejects it.
Impact:
First consumer failure: only that specific consumer is lost (video from one peer)
Cascade: SDP state is permanently corrupted, ALL subsequent consumers fail (audio + video from newly joining peers)
Only fix for the user: full page reload
Workaround attempted:
We added retry logic (500ms delay + 1 retry) on the application level, but since the SDP state is corrupted after the first failure, retries also fail with the duplicate mid error.
Expected behavior:
mediasoup-client should not recycle m-lines with a different media type on Firefox, or should allocate a new m-line instead of recycling when the media type doesn't match.
Environment:
mediasoup-client: 3.18.7
Firefox: 149.0
Works correctly in Chrome/Chromium
Description:
When consuming multiple producers on a recv transport in Firefox, after some consumers are closed (m-lines become inactive with port 0), mediasoup-client recycles those m-lines for new consumers. If the new consumer has a different media kind than the original m-line (e.g., the m-line was originally audio but is now reused for video), Firefox rejects the SDP with:
DOMException: Remote description changes the media type of m-line 7
After this first failure, the internal SDP state becomes corrupted, and all subsequent consume() calls fail with:
DOMException: mid '13' appears more than once in a BUNDLE group
Additionally, closePendingConsumers() also fails with the same error:
mediasoup-client:ERROR:Transport closePendingConsumers() | failed to close Consumers:
DOMException: mid '13' appears more than once in a BUNDLE group
The recv transport is permanently broken, no new consumers can be created for the lifetime of the session.
Steps to reproduce:
Join a room with multiple participants on Firefox (3+ peers, each producing audio + video)
Wait for some peers to leave (their consumers are closed, m-lines become inactive)
New peers join, mediasoup-client tries to recycle the inactive m-lines
If a recycled m-line's original media type differs from the new consumer's kind, failure
SDP evidence:
The Firefox answer SDP before the failure shows inactive m-lines from closed consumers:
m=audio 0 UDP/TLS/RTP/SAVPF 0 <- mid:10, inactive (was audio)
m=video 0 UDP/TLS/RTP/SAVPF 120 <- mid:11, inactive (was video)
Then mediasoup-client sends a new remote offer with BUNDLE group 0 1 2 3 4 5 probator 13 12, where mid 13 maps to the recycled m-line 7 (originally audio, now video), Firefox rejects it.
Impact:
First consumer failure: only that specific consumer is lost (video from one peer)
Cascade: SDP state is permanently corrupted, ALL subsequent consumers fail (audio + video from newly joining peers)
Only fix for the user: full page reload
Workaround attempted:
We added retry logic (500ms delay + 1 retry) on the application level, but since the SDP state is corrupted after the first failure, retries also fail with the duplicate mid error.
Expected behavior:
mediasoup-client should not recycle m-lines with a different media type on Firefox, or should allocate a new m-line instead of recycling when the media type doesn't match.