CodeParkThey use UDP because in a live call, late data is useless. Audio plays on a strict schedule. A packet that arrives after its playback time is as bad as a lost packet.
TCP guarantees in-order delivery. So when one segment (a TCP packet) is lost, everything behind it waits in the receive buffer until the resent copy arrives. That takes at least one round trip, and longer if a timeout is involved. This is head-of-line blocking: one lost packet becomes a stall that delays all the audio after it. TCP's congestion control also cuts the sending rate sharply after a loss.
Over UDP, the application decides what to do:
- A jitter buffer holds packets briefly to smooth out uneven arrival times.
- A lost packet is hidden (concealed) or rebuilt with forward error correction (FEC: extra data sent so lost data can be rebuilt).
- The codec (the audio or video encoder) changes its bitrate to match the network.
The application can still resend some data when it's worth it. RTP (Real-time Transport Protocol), the protocol for media in VoIP and WebRTC, normally runs over UDP for these reasons.
- Real-time data has a deadline, so late data is as bad as lost data.
- TCP's in-order delivery causes head-of-line blocking after a loss.
- Retransmission costs at least one round trip.
- UDP lets the app use jitter buffers, concealment and FEC (forward error correction).
- Head-of-line blocking (https://en.wikipedia.org/wiki/Head-of-line_blocking)en.wikipedia.org
- UDP (MDN) (https://developer.mozilla.org/en-US/docs/Glossary/UDP)developer.mozilla.org