conversational real-time media

There is a world of difference between watching a recorded show and talking to someone live. When you watch, a few seconds of delay before play starts is invisible. But when you are talking, delay is brutal: pause too long after the other person stops and you both start speaking at once, then both stop, then both start again. Conversational real-time media is two-way, interactive audio and video — a phone call over the Internet (VoIP) or a video conference — where humans are reacting to each other in real time, so the timing budget is the tightest of any media class.

The reason it is so demanding is that you cannot buffer your way out of trouble. In stored streaming you can stockpile ten seconds ahead; in a conversation, every second you buffer is a second the other person waits to hear you, so the playout buffer must stay tiny — typically tens of milliseconds, not seconds. A rough rule of thumb: under about 150 milliseconds of one-way mouth-to-ear delay, conversation feels natural; from 150 to 400 it is noticeably awkward; beyond 400 it breaks down into talk-over and 'go ahead — no, you go' fumbling. Loss matters too, but because there is no time to ask for a resend, a lost packet is usually concealed or simply skipped rather than retransmitted.

Why it matters: this class drives most quality-of-service thinking, because it is the case where best-effort delivery is most likely to feel bad. It is almost always carried over UDP (via RTP), not TCP, for a blunt reason: TCP's retransmission would deliver a late-but-perfect copy of a sound that is already useless, while stalling everything behind it. Timeliness beats completeness here. The honest caveat: even with perfect protocols, you cannot beat propagation delay — a call routed across the planet has an unavoidable physical floor set by the speed of light.