1727800 - Receiving transceiver not showing correct CSRC when switching MediaStreams

Status: UNCONFIRMED

(Core :: WebRTC: Networking, defect)

Description

[btham]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

Steps to reproduce:

1. Perform a WebRTC video call between 2 clients.
2. On the sender side, switch from one MediaStream to another MediaStream.

Actual results:

On the receiver side, calling getContributingSources() on the transceiver repeatedly will alternate between showing 1 CSRC (the old CSRC) and then 2 CSRCs (the old CSRC and the new CSRC) and then 1 CSRC (the old CSRC) again.

Expected results:

On the receiver side, calling getContributingSources() on the transceiver repeatedly will show 2 CSRCs (the old CSRC and the new CSRC) all the time for several seconds, then 1 CSRC (the new CSRC) all the time (this is the behavior on Chrome).

Comment 1

[btham]

Attachment: ff-csrc-bug.png

Here is a screenshot from one of our logs that shows this issue.

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,
Thanks btham for the report.
Setting a component for this in order to get the dev team involved.
(If the team feels it's an incorrect one please feel free to change it to a more appropriate one.)
Best,
Clara

Comment 3

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

Hi btham, thanks for reporting! — I have some questions about your setup.

1. Perform a WebRTC video call between 2 clients.

Is this a pure p2p call with no server/SFU in between? — If you're seeing CSRCs, it makes me think there has to be a server involved.

Because in a pure p2p call I'm seeing zero CSRCs in both Chrome and Firefox: https://jsfiddle.net/jib1/tj0x3sv1/ (unless you mean SSRCs?)

2. On the sender side, switch from one MediaStream to another MediaStream.

How exactly are you switching between "MediaStream"s? Are you using pc.replaceTrack(), or pc.removeTrack() + pc.addTrack() + renegotiating?

Only in the former case is a transceiver reused.

Comment 4

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

Also, are you observing the audio or video track? Is the symptom limited to one or the other?

Comment 5

[btham]

Yes, we have a media server. For context, I am a Webex developer and this is affecting our browser client.

So actually, I misspoke when I said we switch MediaStreams. We actually use the same MediaStream, but the server will switch the source depending on who is talking. So the MediaStream will have a different CSI if a new person speaks.

Apologies for the confusion. Hope this clarifies.

Comment 6

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Btham, if there is some way that you could produce a minimal test case for us, perhaps using something like JS fiddle. That would be helpful for us to debug this issue.

Comment 7

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

Based on comment 5 it seems the symptom requires an SFU server to switch what it forwards to this browser client receiver, to trigger the switching CSRCs (and presumably SSRCs as well).

On the receiver side, calling getContributingSources() on the transceiver repeatedly will alternate between showing 1 CSRC (the old CSRC) and then 2 CSRCs (the old CSRC and the new CSRC) and then 1 CSRC (the old CSRC) again.

The symptom (continuing to see both CSRCs instead of a clean replace over time) reminds me of bug 1608118 for some reason. Even though we fixed that one in the media pipeline, I don't think we ever answered where the other media was coming from.

Nico, do we have any reason to think the lingering CSRC is phantom (a client problem), or is it more likely to be a server issue? Do the timestamps look right (or do we have an aging problem in the client)?

Comment 8

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

Btham, could you check if you see the same symptom in getSynchronizationSources()?

Also, are there any media symptoms? Any visual flickering or stuttering?

Comment 9

[btham]

Hi all, thanks for looking into this.

(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #6)

Btham, if there is some way that you could produce a minimal test case for us, perhaps using something like JS fiddle. That would be helpful for us to debug this issue.

Unfortunately this would be quite difficult for us, since it requires us to set up a complete client/server configuration. Not sure we have time to do it.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #8)

Btham, could you check if you see the same symptom in getSynchronizationSources()?

Also, are there any media symptoms? Any visual flickering or stuttering?

We're using a single SSRC (the SSRC never changes in the server) so I can't speak about whether getSynchronizationSources() has the same issue. As far as media symptoms, there are none.