Early media causes audio playback to stop
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox97 | --- | wontfix |
firefox98 | --- | wontfix |
firefox99 | --- | verified |
People
(Reporter: drno, Assigned: drno)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details |
When looking into this Jitsi issue https://github.com/jitsi/jitsi-meet/issues/10826 I found the following problem with full debug logs:
[Child 36001: WebrtcCallThread #1]: D/signaling [WebrtcCallThread #1|WebrtcAudioSessionConduit] AudioConduit.cpp:493: OnRtpReceived: switching from SSRC 2386953618 to 3390540166 [Child 36001: WebrtcCallThread #1]: D/signaling [WebrtcCallThread #1|WebrtcAudioSessionConduit] AudioConduit.cpp:570: StopReceiving Stopping recv stream
Followed by a renegotiation which includes SSRC 3390540166. Which then results in the following log messages:
[Child 36001: WebrtcCallThread #1]: D/webrtc_trace (audio_receive_stream.cc:125): AudioReceiveStream: 3390540166 [Child 36001: WebrtcCallThread #1]: D/webrtc_trace (rtp_demuxer.cc:191): {mid: <empty>, rsid: <empty>, ssrcs: [3390540166, ], payload_types = []} would conflict with existing sink = 110f1800 binding by SSRC=3390540166 [Child 36001: WebrtcCallThread #1]: D/webrtc_trace (rtp_demuxer.cc:116): Unable to add sink = 110f5800 due conflicting criteria {mid: <empty>, rsid: <empty>, ssrcs: [3390540166, ], payload_types = []} [Child 36001: WebrtcCallThread #1]: D/webrtc_trace (rtp_stream_receiver_controller.cc:26): RtpStreamReceiverController::Receiver::Receiver: Sink could not be added for SSRC=3390540166. [Child 36001: WebrtcCallThread #1]: D/webrtc_trace (audio_receive_stream.cc:383): AudioReceiveStream::ConfigureStream: {rtp: {remote_ssrc: 3390540166, local_ssrc: 3541097694, transport_cc: off, nack: {rtp_history_ms: 0}, extensions: [{uri: urn:ietf:params:rtp-hdrext:ssrc-audio-level, id: 1}], rtcp_event_observer: (rtcp_event_observer)}, rtcp_send_transport: (Transport)} [Child 36001: WebrtcCallThread #1]: D/webrtc_trace (call.cc:1162): UpdateAggregateNetworkState: aggregate_state remains at up [Child 36001: WebrtcCallThread #1]: D/webrtc_trace (rtp_transport_controller_send.cc:352): SignalNetworkState Up [Child 36001: WebrtcCallThread #1]: D/signaling [WebrtcCallThread #1|WebrtcAudioSessionConduit] AudioConduit.cpp:588: StartReceiving Starting receive stream (SSRC 3390540166 (0xca178986))
The result is that the audio from that participant can not be heard by the Firefox user.
My reading of the above is that because of receiving early media (as in media before the signaling) Firefox restarts the audio receiver, which appears to work fine. But when Firefox tries to reconfigure the audio receiver libwebrtc chokes, because it doesn't like to reconfigure for the same SSRC?!
Which then results in the sink not being added and therefor the audio not being played to the user.
I'm assuming this is a regression from the libwebrtc update in bug 1654112 (haven't verified this), because I think that update introduced reconfiguring of receivers.
Would it be possible to check for the SSRC being already used by the receiver before trying to reconfiguring it (assuming that it what causes libwebrtc to choke)?
Comment 1•3 years ago
|
||
Looking at code this doesn't seem possible within an AudioConduit. But it would in theory be possible if there were two receiving AudioConduits trying to receive for the same ssrc. I.e., two audio receivers. Could there be early media for one that was intended for the other?. If that's the case we'd need the same ssrc collision handling in AudioConduit as in VideoConduit. There were no changes to this handling in AudioConduit in bug 1654112. So your regression was triggered by, I think, timing and/or rtp-recv-handling changes on our end in bug 1654112, libwebrtc allowing duped recv ssrcs prior to bug 1654112 (doubtful, but haven't checked), or something on your end.
Can you confirm whether two audio receivers are present in your STR case?
Assignee | ||
Comment 2•3 years ago
|
||
First of all steps to repro:
- go to https://meet.jit.si
- click the "start meeting" button
- on the pre-meeting screen disable the camera for easier debugging
- click "start meeting" button - this is participant A
- in another tab open the same meeting URL - this will be participant B
- in the pre-meeting screen disable camera and microphone
- click "join meeting" button
- for participant B enable the microphone
- for participant A disable the microphone to avoid the audio feedback loop
- we should be able to hear participants B audio, but don't hear anything
There is a couple of things to note here:
- Jitsi doesn't use the MID RTP header yet.
- The initial call between the two participants only uses one audio m-section and a second video m-section (which is set to recvonly for both participants, since they both have video turned off)
- once participant B turns on his/her microphone the signaling adds another audio m-section for the audio of participant B
I think what happens is that Firefox has only a single audio receiver running for the initial audio m-section. Then RTP packets for an unknown SSRC are received (since the signaling hasn't come in yet), so the audio receiver switches the SSRC to that new SSRC assuming this is the new SSR. When the new signaling comes in another audio receiver gets added, which then claims to want to use the same SSRC as now is being received by the first audio receiver.
Comment 3•3 years ago
|
||
Thanks! I agree with your analysis.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Set release status flags based on info from the regressing bug 1654112
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
Assignee | ||
Comment 7•3 years ago
|
||
(In reply to Nils Ohlmeier [:drno] from comment #6)
Try run https://treeherder.mozilla.org/#/jobs?repo=try&revision=dcc1c5684df2485687e5c2985d7ec6e915c8ca8b
Try run looks good.
Comment 8•3 years ago
|
||
Thanks for the patch Nils! Byron is this something you plan on landing?
Updated•3 years ago
|
Pushed by bcampen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a0a3a33a43e0 disable SSRC changes for bundled audio RTP r=bwc
Comment 10•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 11•3 years ago
|
||
The patch landed in nightly and beta is affected.
:drno, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Comment 12•3 years ago
|
||
Byron, is that something we could uplifti to 98 beta ? (we have 2 betas left before RC) or should we ship this fix in the 99 release? Thanks
Comment 13•3 years ago
|
||
Yeah, this would probably be a good candidate for uplift.
Comment 14•3 years ago
|
||
Comment on attachment 9262985 [details]
Bug 1754027: disable SSRC changes for bundled audio RTP
Beta/Release Uplift Approval Request
- User impact if declined: Poor user experience resulting from lack of audio on webrtc calls with some services.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This just duplicates logic that we already have for video, that we know works already.
- String changes made/needed: None.
Comment 15•3 years ago
|
||
Comment on attachment 9262985 [details]
Bug 1754027: disable SSRC changes for bundled audio RTP
Fix a recent regression in webrtc calls confirmed by Jitsi, uplift approved for 98 beta 9, thanks.
Comment 16•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Verified as fixed on Windows 10 x64, Ubuntu 20.04 x64 and on macOS 11.6.
Comment 18•3 years ago
|
||
backout bugherder uplift |
https://hg.mozilla.org/releases/mozilla-release/rev/97dfb71c2282
Backed out changeset 974fb4e6468c (bug 1754027) for breaking Google Voice on beta (bug 1756222)
Updated•3 years ago
|
Comment 19•3 years ago
|
||
I am leaving the bug as FIXED, note that this was backed out on mozilla-release in RC week but not on mozilla-central, if we can't get a fix before the merge of 99 to beta, we should consider backing it out on mozilla-central as well.
Updated•3 years ago
|
![]() |
||
Comment 20•3 years ago
|
||
Pascal, we'd like to go ahead and back this out from 99 for now and work with Google to get a fix in on their side. Any chance you can help with that?
![]() |
||
Updated•3 years ago
|
![]() |
||
Updated•3 years ago
|
Comment 21•3 years ago
|
||
:jimm 99 is currently in nightly. The sheriffs handle backing out changes on central.
You can reach out on the #sheriffs channel on Matrix and request a backout from central. They will take it from there.
Updated•3 years ago
|
Comment 22•3 years ago
|
||
A fix seems forthcoming in bug 1756222 comment 19, so we may not need to back this out of 99.
![]() |
||
Updated•3 years ago
|
![]() |
||
Updated•2 years ago
|
Description
•