1754027 - Early media causes audio playback to stop

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[Nils Ohlmeier [:drno]]

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

[Andreas Pehrson [:pehrsons]]

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?

Comment 2

[Nils Ohlmeier [:drno]]

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

[Andreas Pehrson [:pehrsons]]

Thanks! I agree with your analysis.

Comment 4

[Nils Ohlmeier [:drno]]

Attachment: Bug 1754027: disable SSRC changes for bundled audio RTP

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1654112

Comment 6

[Nils Ohlmeier [:drno]]

Try run https://treeherder.mozilla.org/#/jobs?repo=try&revision=dcc1c5684df2485687e5c2985d7ec6e915c8ca8b

Comment 7

[Nils Ohlmeier [:drno]]

(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

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks for the patch Nils! Byron is this something you plan on landing?

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a0a3a33a43e0
disable SSRC changes for bundled audio RTP r=bwc

Comment 10

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/a0a3a33a43e0

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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

[Pascal Chevrel:pascalc (PTO until April 26)]

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

[Byron Campen [:bwc]]

Yeah, this would probably be a good candidate for uplift.

Comment 14

[Byron Campen [:bwc]]

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

[Pascal Chevrel:pascalc (PTO until April 26)]

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

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-beta/rev/974fb4e6468c

Comment 17

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 x64, Ubuntu 20.04 x64 and on macOS 11.6.

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-release/rev/97dfb71c2282
Backed out changeset 974fb4e6468c (bug 1754027) for breaking Google Voice on beta (bug 1756222)

Comment 19

[Pascal Chevrel:pascalc (PTO until April 26)]

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.

Comment 20

[Jim Mathies [:jimm]]

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?

Comment 21

[Donal Meehan [:dmeehan]]

: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.

Comment 22

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

A fix seems forthcoming in bug 1756222 comment 19, so we may not need to back this out of 99.