Preferred transport to deal with packet loss from real-time video producers

Hi friends. Some of the video producers in my use case come from mobile internet clients prone to some degree of packet loss. It’s not really a big deal, I just wanted to get an idea how you’ve all approached this problem to make sure I’m doing it the right way.

From perusing the forum and looking at mediasoup-examples it seems that UDP is generally the preferred transport medium:

createWebRtcTransport (
    enableTcp: true,
    enableUdp: true,
    preferUdp: true
)

I’ve done some testing simulating poor network conditions (randomly dropped packets) with both TCP and UDP sendtransports (single stream, no SVC or simulcast). The video bitrate is throttled down in both cases. With UDP the video framerate becomes intermittently choppy (dropped frames?) until the network stabilizes (and then the bitrate ramps back up). With TCP, the framerate remains stable despite packet loss (preferable), however the bitrate stays low even after network stabilization (undesirable).

Two questions;

  • Should I retain the preferUdp option, or is it best to let the client choose (renegotiate?) the optimal ICE candidate?
  • Is there any way to promote bitrate recovery for TCP transports once network conditions improve?

Should I retain the preferUdp option, or is it best to let the client choose (renegotiate?) the optimal ICE candidate?

Force UDP but allow TCP.
–Best Results–

If not mistaken either but can be corrected, the bitrate will automatically improve when connection improves. There shouldn’t be a continual loss as connection slows down? If speaking on recovering lost packets it’d just result in added latency or weird mutated voices, best to let that data slip to network poops.

Thanks @CosmosisT !

I’ll do a little more testing with TCP - bitrate seemed stuck in place (but I might not have observed the stream for long enough). Not that important I guess since you’re saying that performance is best with preferUdp.