Debugging stream discontinuity.

This problem is intermittent, and that’s really annoying, so this ticket is more of a request for help in catching the issue.

I’ve been doing performance tesitng with low bandwidth connections it seems to work fine. But sometimes when there’s an internet unavailability the video and audio completely stop, and unless a total restart of the send and receive transports is done the transport does not recover on its own.

I am using mediasoup-client for sending and receiving audio and video streams, no data channels. This happens on all browsers, albeit its easier to encounter on mobiles.

What recovery mechanism is responsible for handling this. How do I ensure I have it in place correctly.

From my limited understanding of the concepts. I’ve added a listener to the state change event on both send and receive transports, and upon receiving a ‘disconnected’ state I do an ICE restart. That certainly does work much better than without it, but still there are times when the call cannot at all recover on its own and must require user input to restart the roomClient - Using mediasoup-demo as my base implementation, yes.


As per the description, it may be happening that there is not enough bandwidth for sending the media.

Enable the bwe trace event in the send transport. Check the availableBitrate and the effectiveDesiredBitrate values. Also print the stats for the audio/video producers in order to check their bitrate.

In case the available bitrate is lower than the desired, it means that the receiving endpoint cannot handle the media bitrate that mediasoup would send otherwise.

1 Like

I will surely check that. But I must re-iterate the actual problem is not being able to send media in case of low bandwidth availability, rather when the bandwidth recovers the vide/audio still does not start playing.

Thanks, I will turn this log on and check when this happens.

Do you mean that mediasoup forwards RTP to the remote consumer and the endpoint does not play it?

I think I’m not even sure weather it start sending RTP after the connection has recovered. Is there a way for me to verify that this happens? Can I use webrtc-internals on chrome to monitor this?

Yes, webrtc-internals