e-speak

Notes on voice technology and real-time protocols

Voice on a network is a chain of compromises: sample the air, compress it, packetise it, ship it, jitter-buffer it, decompress it, and play it back before the talker notices.

These notes are about the links in that chain.

Scope and maintenance

This page is maintained alongside the technical notes rather than separately from them, which means it is revised when the notes are revised and never left pointing at a section that has since been rewritten. Two people read it before publication: the author, and one reader who does not work on voice systems and whose only job is to say where the explanation stops making sense.

The material covers what the page title says and stops there. Adjacent topics are linked rather than absorbed, because a reference page that sprawls is a page nobody finishes, and a reader who gives up halfway is worse off than one who never started.

Where behaviour has changed since publication, the change is noted in the body with a date rather than applied silently. This matters most for anything that depends on a specification: a document is amended, implementations follow slowly and unevenly, and a note that quietly updates itself hides the interesting part — the gap between the two.

Corrections go to the address on the contact page. A correction that names the claim and links the primary source that contradicts it is applied within days. One that describes a problem without a source usually is not applied at all, not out of stubbornness but because there is nothing to check it against.

Reference points

Two documents are worth having open while reading anything about real-time audio. The first is RFC 3550, which defines RTP and the timing model every voice stream inherits. The second is RFC 6716, the Opus specification, which is where most modern implementations start.

"The delay a codec adds is not negotiable at runtime; it is chosen when the mode is chosen." — the practical reading of RFC 6716's lookahead sections.

Three numbers are worth remembering because they bound almost every decision on this site: a 20 millisecond frame at 64 kbps costs roughly 50 packets per second per stream; a jitter buffer sized for 60 milliseconds of variation covers most consumer networks; and anything above 150 milliseconds of one-way delay starts to break conversational turn-taking. Six figures in total, and between them they explain most of what goes wrong in a live call.

Quick reference

What does this page not cover?

Product recommendations and purchasing advice, because a recommendation written without knowing a reader's constraints is worse than none. Also absent: benchmarks produced by an interested party, and anything that cannot be traced to a document you could read yourself.

Why does the scope stop here?

Because a reference page that sprawls is a page nobody finishes. Adjacent topics are linked rather than absorbed, which keeps each page answerable to a single question.

"A note that quietly updates itself hides the interesting part: the gap between the specification and what implementations actually do."

Recent notes

What this site covers

Codec selection and bitrate behaviour, real-time transport, and the signalling layers that connect calls to each other. Reference material rather than product reviews.

Starting points