[RTW] Realtime communication over HTTP (Re: Baseline in or out of scope)
Timothy B. Terriberry
tterriberry at mozilla.com
Sun Feb 27 00:54:35 CET 2011
> When we encounter congestion, audio-over-TCP will experience this as
> jitter, while audio-over-UDP will experience this as packet loss, so the
> experience may be different.
"Jitter" is equivalent to packet loss in a real-time system. If you
don't have decoded audio ready to go when it's time to play it out,
there's nothing to be done but invoke your packet loss concealment
algorithms, regardless of whether the packet is simply late, or not
coming at all. UDP encounters this just as much as TCP does, and while
you can attempt to mitigate the effect with a jitter buffer, there are
limits to what it can do. You can also snapshot internal codec state and
go back and re-decode if a packet does arrive late, but this is
expensive and complicated, and the only benefit is a slightly faster
recovery time: it's too late to fix the initial loss.
The practical difference between TCP and UDP is that, when you encounter
congestion, TCP wastes time and bandwidth continually trying to
re-transmit packets that you no longer care about (making the congestion
worse), while UDP does not. There are many other differences, but this
is the one that can't be engineered around. Thus, http will always be
suboptimal. It's better than nothing if you're behind a firewall that
doesn't allow UDP, but that doesn't mean that everyone should have to
use a suboptimal solution just because 5-10% of users do.
More information about the RTC-Web
mailing list