Tracks muted by incorrect RTCP BYEs are never unmuted again, even though they continue to receive data.
Categories
(Core :: WebRTC: Networking, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | affected |
People
(Reporter: jib, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [WebRTC])
+++ This bug was initially created as a clone of Bug #1232234 +++
In Bug 1232234 comment 10 I confirmed Chrome (89-92) also sends RTCP BYE on renegotiations, just like Firefox, using a new jsfiddle and the STRs below.
In the process, I also discovered a bug (this bug) where the receiver tracks we fire mute
on remain in muted state (or at least never fire unmute
), while they're clearly continuing to receive (video and audio) data.
STRs:
- Set
media.peerconnection.mute_on_bye_or_timeout
totrue
in about:config - Open https://jsfiddle.net/jib1/b39qvu8c/show in both Chrome and Firefox
- Bootstrap negotiation (Chrome: click
Offer:
, ⌘+c. Firefox: click "Paste offer here", ⌘+v, ENTER, ⌘+c. Chrome: click "Paste answer here", ⌘+v, ENTER) - In Chrome: click
AddTrack
, clickNegotiate
, then wait 5 seconds for this Firefox output:
video 1 unmute
audio 2 unmute
- In Chrome: click
Negotiate
again, then wait another 5 seconds
Expected Firefox output:
- Ideally
...or at the very least
video 1 mute
audio 2 mute
video 1 unmute
audio 2 unmute
Actual output Firefox output:
video 1 mute
audio 2 mute
...i.e. the audio and video tracks remain muted, or at least never have unmute
fired on them, even though they're clearly continuing to receive (audio and video) data, as seen in the video element.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 1•3 years ago
|
||
I suppose this bug is moot now too, with bug 1654112 landed?
Though there are still things that trigger stream recreation, so we should look closer at those modes first.
Apart from ssrc changes, notable ones are:
- audio-recv: extension changes
- video-recv: extension changes
- video-recv: codec changes
- video-recv: rtp config changes (which covers a lot of ground...)
Comment 2•3 years ago
|
||
Depending on how we handle things a layer up (I'm not too familiar with specs on negotiation) I suppose these paths might not be hit without already having created new tracks (for ssrc changes maybe?), and then it's not a problem. Though video-recv codec and rtp config changes seem to me like candidates for updating an existing track. There is no upstream API to update a video-recv-stream on the fly.
Reporter | ||
Comment 3•3 years ago
|
||
(In reply to Andreas Pehrson [:pehrsons] from comment #1)
- audio-recv: extension changes
- video-recv: extension changes
The headerExtensions JS API is thankfully readonly. But it can change in the SDP (user agent or through munging by apps). Byron says in SDP it's generally allowed for a=extmap
lines associated with an m=
line to change on renegotiation, provided a previously used extension id isn't repurposed. Whether any webrtc end-point relies on this is a different matter.
- video-recv: codec changes
Same here. [[SendCodecs]] is updatable by renegotiation, except here there's a JS API in bug 1396922.
- video-recv: rtp config changes (which covers a lot of ground...)
Yeah, but how much of that is ever changed dynamically (apart from the above)? I'm having trouble walking backwards through the code here.
Reporter | ||
Comment 4•3 years ago
|
||
Renaming this since with bug 1654112 fixed, this issue is now isolated to edge cases: SDP manipulation by apps or SFUs, or apps using setCodecPreferences
in other browser end-points.
Comment 5•3 years ago
|
||
If there's a chance to cause a RTCP BYE against spec, even if uncommon, will we need a path to unmute the track again?
Comment 6•3 years ago
|
||
So while we've fixed bug 1232234 with the libwebrtc update, we've got to interop with ourselves until ESR has the libwebrtc update. For now, we probably need to work around this.
Reporter | ||
Comment 7•3 years ago
|
||
According to spec: "Whenever an RTCRtpReceiver receives data on an RTP source whose corresponding MediaStreamTrack is muted, but not ended, and the [[Receptive]] slot of the RTCRtpTransceiver object the RTCRtpReceiver is a member of is true, it MUST queue a task to set the muted state of the corresponding MediaStreamTrack to false."
In English: Unless we're "recvonly", "inactive" or "stopped", when rtp data arrives, we should unmute.
Comment 8•3 years ago
|
||
Ok, so. We have code to unmute, but the logic to unmute is only enabled after MediaPipeline::Start()
, which is called after transceiver updates (negotiation?). We'd need to enable this logic also on rtcp bye and rtcp timeout.
Should be straight forward.
And somehow write a test.. Might not be so straight forward.
Updated•2 years ago
|
Description
•