Advices on dealing with unreliable networks

I am looking for advice when dealing with mediasoup libraries if used on unreliable networks (ex. mediasoup-client app running on a mobile device). I know that this is only related to mediasoup, so my questions relate more to mediasoup elements: consumers/producers/transports. For example:

On the client: do you recommend watching the “connectionstatechange” in order to take app-specific decisions about the local behaviour (including closing of the consumers/producers/transports) or should build a separate mechanism? How soon after a network loss is this event triggered?

On the server: do you recommend watching the consumer “score” event in order to take mediasoup and app-specific decisions or should build a separate mechanism? How soon after a network loss is an event with consumer score of 0 is triggered?

Do you have any recommendations regarding mediasoup specific elements cleanup on network loss? How soon would you close consumers/producers/transports on a network loss (network might recover quickly or never)? This is, of course, very much app related, but I am just looking for advices from other people that do real-time media transmission.

1 Like
  • If it becomes “disconnected” warn the user. But don’t close things because it may become “connected” later.
  • If it becomes “failed”, that’s a fatal error, so close everything and restart everything etc.

If video consumers are consuming simulcast or SVC videos you don’t need to do nothing. However if single stream videos, you may want to pause some video consumers and warn the user.

2 Likes

OMG…!!! I am using a single stream…

I’m using mediasoup to teach kids online. And I don’t use Simulcast or SVC because I only use screen share and it becomes blurry if simulcast is on - the server starts sending low res stream. The app works great normally but whenever one of the kids are having poor connection the screen freezes and does not come back even after the network stabilizes. But when we reload the app everything works fine again. I am pretty sure that the internet does not go off totally it just goes to a low bitrate.

It would be a huge favor if you can coach me on what should I look for to fix it. All of them like it better than zoom because of the screen share quality but its just this one problem that causes distractions.

Apologies if this is not the appropriate place for such a question, I was about to open a thread but I saw one relating to this already therefore I asked here.

Thanks! :+1:

PS: In your comment above, do you mean pause the consumer on the client. or on the server??

I mean, pause the consumer in the server so mobiles just receive a few videos at the same time (depending who is speaking, or just your video, etc).

And also reduce bitrate by passing maxBitrate into an entry in encodings parameters in client side when calling transport produce. Check the related API in the doc.

1 Like

Thanks allot. This gives me new things to try… :smiley:
:+1:

If video consumers are consuming simulcast or SVC videos you don’t need to do nothing.

Hey @ibc the consumer setPreferredLayer, producer setMaxLayer and consumer setPriority APIs could be used as well to achieve optimisations right? (forgive any typo, didn’t double check the methods names).

consumer.setPreferredLayers(preferredLayers)
Sets the preferred (highest) spatial and temporal layers to be sent to the consuming endpoint. Just valid for simulcast and SVC consumers.

Does this method always apply the given layer or its just a suggestion that can be override by something like codecs… Very frequently I don’t see the layer changes being applied client-side and server-side. You briefly mentioned the need of a keyframe to be sent for this to be applied.

Thanks.

  • Client side producer.setMaxSpatialLayer() is just for limiting max simulcast stream sent by the browser.
  • Server side consumer.setPreferredLayer() is indeed to set max layers to be received by the endpoint.
  • Server side consumer.setPriority() is a way to prioritize video from this Consumer over others if there is no enough downlink bandwidth for all in a given time.