Comments on: Why you should prefer UDP over TCP for your WebRTC sessions

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Fri, 12 Nov 2021 12:04:11 +0000

In reply to Chen.

Chen,

For WebRTC, TCP is bad no matter what. WebRTC is built for low latency – it can’t really do “high latency” use cases at all.

As such, the suggestions you make and the validity of TCP for them is all true, but in a way, it has nothing to do with WebRTC since I wouldn’t be using or recommending the use of WebRTC to scenarios where latency is less important than quality.

By: Chen

Chen — Fri, 12 Nov 2021 10:27:53 +0000

I'd argue that if frame skipping is a matter for you then TCP is still a must (it depends if you just talk, or you are actually transmit high quality content). Think about Streamyard/Teams where host is sharing screen with a video on screen (60 fps trailer or anything else where quality does matter). It will appear laggy if you use UDP

Then the more users you have in a WebRTC conference, the more chances you get packet loss.

And then there's also the use case where only a host speaks, and interaction is rare or not happening at all. There's no reason to prefer UDP when interaction is limited as latency doesn't matter

All of that doesn't make UDP as obvious as described here.

By: Philipp Hancke

Philipp Hancke — Fri, 09 Jul 2021 12:11:48 +0000

In reply to Steve Fox. I've rarely seen artifacts with WebRTC - the implementation in Chrome does not incomplete frames to the decoder even which avoids the artifacts you're talking about. NACK-based recovery works great. For higher losses flexfec helps.

By: viswanatha reddy

viswanatha reddy — Tue, 06 Jul 2021 16:01:53 +0000

Couple of things that makes VoIP frameworks resilient are the Jitter buffers, audio codecs , video codecs, FEC etc with right codecs and
media frameworks users can't perceive the loss of few packets of voice and few non important frames of Video,

UDP is perfect and only choice as of now for real time communications, as mentioned in the article in some rare cases TCP was forced option due to firewall.

webRTC is one of the best VoIP media frameworks available with easy to use interface in web, native devices..

By: Steve Fox

Steve Fox — Tue, 06 Jul 2021 15:24:57 +0000

"Prefer UDP over TCP for WebRTC" – this would be really practical if WebRTC would use a special video codec resilient to frame-loss.
But MPEG-based codecs are NOT resilient to frame loss. So, with H264 codec, if you lose couple of p-frames, you see ugly artifacts, and if you lose an i-frame, you are totally dead. Therefore, with H264 codec, if you have considerable packet loss, nothing can help you – neither TCP nor UDP; the quality will not be acceptable either way.

With US-European public networks quality of 2020-s, TCP is not much different from UDP; the packet loss and retransmissions are rare. Therefore, it's preferable to use TCP for WebRTC, just to deliver that rare packet that may be occasionally lost. If it's just one-two packets per minute, browsers will play these packets and you will not notice any degradation, so TCP will help.

But if it's 1-2% or higher packet loss, like in Asian public networks, then, like I say before, nothing can help for WebRTC – it will not work right.
With UDP you will see a lot of artifacts and freezes; with TCP you will see increasing latency and gaps in video.