Closed Bug 1768729 Opened 3 years ago Closed 2 years ago

[jitsi] Moving SSRC to another m-section fails to render stream

Categories

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

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr91 --- unaffected
firefox100 --- wontfix
firefox101 --- fix-optional
firefox102 --- fix-optional

People

(Reporter: drno, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

In Jitsi there are certain scenarios where we keep an SSRC, but move it from a previously used m-section to another m-section. It appears that since the libwebrtc update in bug 1654112 this no longer works and the moved RTP stream no longer gets rendered.

Step to reproduce:

  • create a new conference with Chrome on meet.jit.si, but join from the beginning muted
  • join the conference with Firefox (joining muted results in one less stream to worry about)
  • in Chrome start sharing another browser tab which is playing sound, e.g. a YouTube video
    • this adds another audio m-section to transport the audio from Chrome
  • this new audio stream is audible in Firefox
  • stop sharing the Chrome tab in Chrome
  • no sound, as expected (note: the audio m-section is set to inactive now; the AudioConduit gets stopped)
  • turn on the microphone in Chrome
  • this results in the SSRC from the tab sharing to get moved into a new m-section
  • result: their is no audio played in Firefox

Note: the same scenario above works fine in Firefox ESR 91.9.0

Firefox logs indicate that adding the audio receiver actually did not succeed, but no error gets reported to JS about that.

[Child 63849: WebrtcCallThread #1]: D/webrtc_trace (rtp_demuxer.cc:191): {mid: <empty>, rsid: <empty>, ssrcs: [3769479731, ], payload_types = []} would conflict with existing sink = a1d22000 binding by SSRC=3769479731
...
[Child 63849: WebrtcCallThread #1]: D/webrtc_trace (rtp_demuxer.cc:116): Unable to add sink = 120d6000 due conflicting criteria {mid: <empty>, rsid: <empty>, ssrcs: [3769479731, ], payload_types = []}
...
[Child 63849: WebrtcCallThread #1]: D/webrtc_trace (rtp_stream_receiver_controller.cc:26): RtpStreamReceiverController::Receiver::Receiver: Sink could not be added for SSRC=3769479731.
...
[Child 63849: WebrtcCallThread #1]: D/webrtc_trace (audio_receive_stream.cc:383): AudioReceiveStream::ConfigureStream: {rtp: {remote_ssrc: 3769479731, local_ssrc: 1240486319, 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 63849: WebrtcCallThread #1]: D/webrtc_trace (rtp_transport_controller_send.cc:352): SignalNetworkState Up
[Child 63849: WebrtcCallThread #1]: D/signaling [WebrtcCallThread #1|WebrtcAudioSessionConduit] AudioConduit.cpp:588: StartReceiving Starting receive stream (SSRC 3769479731 (0xe0adb233))

Later on once RTP packets are received for the audio stream the log looks like this:

[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter inspecting seq# 5571 SSRC: 3769479731
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter SSRC: 3769479731 did not match any of 1 remote SSRCS.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter payload-type: 111 did not match any of 0 unique payload-types.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter packet failed to match any criteria. ignoring packet
[Child 63849: GraphRunner]: D/MediaPipeline MediaPipeline::NotifyQueuedChanges()
[Child 63849: Socket Thread]: D/webrtc_trace (rtp_utility.cc:360): Failed to find extension id: 3
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter inspecting seq# 5571 SSRC: 3769479731
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter SSRC: 3769479731 did not match any of 1 remote SSRCS.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter payload-type: 111 did not match any of 0 unique payload-types.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter packet failed to match any criteria. ignoring packet
[Child 63849: Socket Thread]: D/webrtc_trace (rtp_utility.cc:360): Failed to find extension id: 1
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter inspecting seq# 5571 SSRC: 3769479731
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter SSRC: 3769479731 did not match any of 2 remote SSRCS.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter payload-type: 111 did not match any of 0 unique payload-types.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter packet failed to match any criteria. ignoring packet
[Child 63849: Socket Thread]: D/webrtc_trace (rtp_utility.cc:360): Failed to find extension id: 3
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter inspecting seq# 5571 SSRC: 3769479731
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter SSRC: 3769479731 matched remote SSRC set. passing packet
[Child 63849: Socket Thread]: D/MediaPipeline {acce6f3a-59a8-4375-9703-b3e629eb2f1f}| Receive audio received RTP packet.
[Child 63849: WebrtcCallThread #1]: V/signaling [WebrtcCallThread #1|WebrtcAudioSessionConduit] AudioConduit.cpp:500: OnRtpReceived: seq# 5571, Len 106, SSRC 3769479731 (0xe0adb233) 
[Child 63849: Socket Thread]: D/webrtc_trace (rtp_utility.cc:360): Failed to find extension id: 3
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter inspecting seq# 5571 SSRC: 3769479731
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter SSRC: 3769479731 matched remote SSRC set. passing packet
[Child 63849: Socket Thread]: D/MediaPipeline {acce6f3a-59a8-4375-9703-b3e629eb2f1f}| Receive audio received RTP packet.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter inspecting seq# 1529 SSRC: 1772902955
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter SSRC: 1772902955 did not match any of 1 remote SSRCS.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter payload-type: 100 did not match any of 0 unique payload-types.
[Child 63849: Socket Thread]: D/MediaPipeline MediaPipelineFilter packet failed to match any criteria. ignoring packet
[Child 63849: WebrtcCallThread #1]: V/signaling [WebrtcCallThread #1|WebrtcAudioSessionConduit] AudioConduit.cpp:500: OnRtpReceived: seq# 5571, Len 106, SSRC 3769479731 (0xe0adb233) 

Which also appears to indicate that the RTP packets are still passed to the old stopped receiver and the new one. Maybe an inactive m-section should result in the RTP demuxer no longer passing along any RTP for that m-section?

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

Has Regression Range: --- → yes

Byron, any thoughts here?

Flags: needinfo?(docfaraday)

Sadly, we don't have much in the way of tests for this. Is this SSRC move being done on the fly, or with a renegotiation?

Flags: needinfo?(docfaraday) → needinfo?(drno)

Hi Nils, I'm not sure I follow the need to reuse an SSRC across m-sections here (is there spec support for this?). You and Byron know the low-level details here better than me! Let me see if I follow:

  • this adds another audio m-section to transport the audio from

You say "another"... how many audio m-sections are there at this point (when joining muted)?

  • stop sharing the Chrome tab in Chrome
  • no sound, as expected (note: the audio m-section is set to inactive now; the AudioConduit gets stopped)

Do I understand correctly that this change to "inactive" is renegotiated here?

  • turn on the microphone in Chrome
  • this results in the SSRC from the tab sharing to get moved into a new m-section
  • result: their is no audio played in Firefox

I assume the expected audio is that of the microphone here (since tab sharing stopped)? Are you using replaceTrack here? if not, how and why are m-sections or SSRCs being reused?

No longer blocks: webrtc-triage

This WFM when I try the repro steps in comment 0 now.

Flags: needinfo?(drno)

Nils, has this been fixed on jitsi's end, or can you still repro?

Flags: needinfo?(drno)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.