Failed to add remote stream ssrc: # to {mid: #, media_type: video}

mediasoup libraries
1

We already have a stable video conferencing application utilizing Expo, with universal platform support [Web, iOS & Android].

After Chrome 111 upgrade, we’re facing a weird issue that has been occurring a lot.

Here’s our package versions:

mediasoup-client:

        "mediasoup-client": "^3.6.84",
        "expo": "~47.0.8",
        "react-native": "0.70.8",
        "react-native-webrtc": "^111.0.0",

EDIT: ignore react-native & react-native-webrtc, those are for mobile app, for the web variant the direct webrtc available is utilized.

mediasoup:

        "mediasoup": "^3.11.13",

Multiple people can join conference but randomly or when toggling video on/off continuously causes this error, consider Participant A with video off, and Participant B. When Participant A toggles video on or joins with video on; Participant B gets this error:

Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote offer sdp: Failed to add remote stream ssrc: 212544496 to {mid: 32, media_type: video}

Now, following are the SDP exchanges, I’ll give the two scenarios, one normal and one where the error occurs:

Normal:

Person A normal:

Person A turned camera on:

setLocalDescription: Offer: Person A _normal_ - setLocalDescription - Offer - TextBin

setRemoteDescription: answer: Person A _normal_ - setRemoteDescription - answer - TextBin

Person B normal:

Person A turned camera on.

setRemoteDescription: offer: Person B _normal_ - setRemoteDescription - offer - TextBin

setLocalDescription: answer: Person B _normal_ - setLocalDescription - answer - TextBin

Error:

Person A (error):

Person A turns video on:

setLocalDescription: offer: Person A _error_ - setLocalDescription - offer - TextBin

setRemoteDescription: answer: Person A _error_ - setRemoteDescription - answer - TextBin

Person B (error):

Person A turns camera on:

but before: this is the last event:

mediasoup-client:Chrome111 stopReceiving() | calling pc.setLocalDescription: type answer, sdp:

setRemoteDescription: offer:

The error then comes, specifically at this code, for Participant B:

transport.consume(p).then(...)

I’m not exactly sure what this error means, I’m uncertain how or what causes Synchronization Source [ssrc] error, but what I’ve tried is foremost upgrading all the mediasoup versions, then react-native-webrtc version. Lastly, I tried VP8 codec; seeing as whether it was a h264 profile-level-id issue, but the same error occurs.

Any leads or even input would highly be appreciated. Thanks!

1 Like
2

Honestly no idea. We’ve been using Chrome111 handler for long in Chrome >= 111 and never seen that error. I’ve tried to reproduce in the mediasoup demo with any luck.

3

Is Person B in the first, normal scenario the same person as in the second scenario? This would have been really strange, because only some ids and the session version were different in the remote descriptions.

4

By the way, I’m assuming it’s happening since Chrome111 as these exceptions started appearing only after it at our Sentry. [Logging goes back 2021], but before that we haven’t received any complaints or any logging either.

As for the scenarios, yes, they’re all the ‘same’ person as it’s reproduced locally, sorry I should’ve clarified that initially. I’ve just opened two windows, one incognito, and the other normal, and joined the conference. I’m easily able to reproduce it if I keep on toggling camera, though it can also randomly occur if I just join with camera on. Our sentry logging is spammed with these exceptions, and unfortunately for production we’re not logging any SDP / mediasoup-client verbose logs.

And, yeah you’re definitely right. I just tried my damndest to reproduce it on mediasoup-demo, no luck at all either. I understand what this signifies then but I’m clueless to where or what the issue is now. But in any case, thank you so much for your time and for looking it up! Much obliged!

5

Hey, I’ve also started seeing the same errors for some of my users who reported similar problems. We’re using mediasoup for a mix of audio with and without video chat rooms with 5 to 20 people and often there’ll be one or two users that suddenly stop showing video (sometimes audio) for a significant part of the other chatters. The only fix for that has been for both sides to reload the app, sometimes repeatedly.
The console logs show errors like this:

image
image1039×456 43.5 KB

I’m not familiar enough with the underlying WebRTC code to make any attempt at fixing this, so the best I could do in this case would be to just automatically retry the whole transport consume step until it works…
Any pointers or further help would be greatly appreciated!

6

Another similar error report:
image

7

Hey.

So we’re still facing this issue. We have a very similar case as yours, a conference with or without video. When it happens to someone, they’ll receive an error and won’t see that participant’s video anymore. Moreover, for new joinees as well who might join after getting this error, they won’t receive neither video or audio for that new participant and we will have that error. Furthermore if the participant whose video caused this also ‘reconnects’, now you won’t even hear their audio anymore apart from video itself.

The only hacky fix that’s working for now is this:

await transport.consume(p)
                .then(..).catch((e) => {
                     window.location.reload();
                });

So whoever gets this error just refreshes themselves. I’m not sure why for you it needs both sides to reload, maybe try this and let us know if it helped?

1 Like
8

I’ve also just encountered the issue again today. The reload on both sides is what our users are currently doing, but I’ll try some code that just re-initiates the whole WebRTC connection whenever this error happens and hopefully at least make it more usable that way.

1 Like
9

We got the same issue today.
We had 2 audio streams (Aa, Ba) and 1 video stream (Av) in the meeting. Then C joined the meeting.
And C resumed the streams (Ba, Aa, Av) sequentially. Ba and Aa done, but Av failed Failed to add remote stream ssrc: 411821819 to {mid: 2, media_type: video}.
And all new streams failed after that, got the same error message. So the ‘Av’ stream’s failure blocked all new streams.

1 Like
10

This is a libwebrtc error message. It means that function WebRtcVideoChannel::AddRecvStream failed. To learn the exact reason, you need to turn on WebRTC logging.

11

Unfortunately, I’ve been seeing an increase in these errors recently and am still wondering how to fix them.

image
image962×802 87.8 KB

Reloading sometimes helps, or forcing everyone to disable their video stream and then enabling them one by one sequentially. Neither is a really good solution though.
The problem happens across all browsers and OSes.

Unfortunately, I can’t really ask our users to turn on this level of logging and I am also not able to reproduce the bug locally. :confused:

12

I’m getting the same error and the refresh seems to resolve the problem. I have turned on the WebRTC logging and as far I can tell it seems that a same ssrc is used. I’m not aware how this is possible, can you advice me further on debugging? The logs of the Chrome are the following:

[42229:32:1107/152540.849548:ERROR:webrtc_video_engine.cc(2690)] Receive stream with SSRC '573597277' already exists.
[42229:31:1107/152540.849603:ERROR:sdp_offer_answer.cc(4810)] Failed to add remote stream ssrc: 573597277 to {mid: 51, media_type: video} (INVALID_PARAMETER)
[42229:31:1107/152540.849675:ERROR:sdp_offer_answer.cc(872)] Failed to set remote offer sdp: Failed to add remote stream ssrc: 573597277 to {mid: 51, media_type: video}
13

The fixes that solved the issue on our side were the following ones:

  1. Ensure that you close the consumer on client WHEN the media has been terminated (e.g. a user has turned of his camera)
  2. Ensure that you resume the consumer on server AFTER it has been initialized locally (on client-side)

If you do not ensure the above points then:

  1. You will have an endless increasing SDP which will delay the offer
  2. And as a result, you may send a video packet without the consumer being ready. Thus it will create a random media and when the local consumer will be ready, it will result in the above error (ssrc is used).

You can find more details in the documentation

  1. https://mediasoup.org/documentation/v3/mediasoup-client/api/#consumer-close
  2. https://mediasoup.org/documentation/v3/mediasoup/api/#transport-consume
14

Thank you very much, that sounds like it might have been the issue for us. I checked our code and it turns out we did neither 1.) nor 2.), so I added both changes. We’ll see if they’ll have an impact on the chat performance when there is a lot of load on the servers next time.

15

It looks like this has done the trick! Thank you so much, @RoCkAs!

1 Like