Why voice needs its own envelope
By now you know the shape of the problem. A phone call is conversational real-time media: it has a strict budget of about 150 milliseconds end to end before the conversation starts to feel awkward, it tolerates a little loss but not delay, and its true enemy is uneven arrival, or jitter. From the previous guide you also know the cure: a playout buffer that holds early packets briefly so each can be played at its proper moment. But a buffer can only do that job if every packet tells it two things — which one it is, and when it was meant to be heard. Plain network packets carry neither. We need a small extra header to supply them.
That header is RTP, the Real-time Transport Protocol. Do not let the grand name fool you: RTP is not a transport in the sense that UDP or TCP is. It does not move the bits across the network — UDP does that. RTP is just a thin wrapper that rides inside a UDP datagram and adds the few fields a media player actually needs. Think of it as the sender, having sliced your voice into 20-millisecond chunks, slipping each chunk into a small labelled envelope before handing it to the postal service. The envelope is RTP; the postal service is UDP and IP.
Inside the RTP header: a number and a clock
The RTP header is small, and its two most important fields are exactly the two the playout buffer was crying out for. The sequence number counts the packets: 4011, 4012, 4013, and so on, ticking up by one each time. With it the receiver can sort packets back into order and notice instantly when one is missing — if 4012 never shows, there is a gap right there. The timestamp is a clock reading that says when this chunk's first sample was captured. It is what lets the buffer schedule each chunk for its proper playout instant, so that even though packets arrive jittered, your voice comes out evenly spaced.
Two more fields are worth a glance. The payload type says what is inside — which audio codec encoded this chunk, so the receiver knows how to decode it back into sound. And the SSRC, a random source identifier, names who is speaking; in a conference with several talkers, each gets its own SSRC so their streams stay untangled. Notice what RTP does not promise: nothing about timely delivery, nothing about no loss. It carries no guarantee at all. RTP only supplies the labels; the receiver does the clever work of reordering, scheduling, and patching over gaps.
One UDP datagram carrying one RTP packet of voice: +-----------------------------------------+ | IP header (source + dest IP address) | +-----------------------------------------+ | UDP header (source + dest port) | +-----------------------------------------+ | RTP header | | payload type : 0 (a voice codec) | | sequence # : 4012 (+1 per packet) | | timestamp : 642880 (a clock value) | | SSRC : 0x5A3F (who is talking)| +-----------------------------------------+ | payload: ~20 ms of compressed audio | +-----------------------------------------+ The envelopes nest: audio inside RTP inside UDP inside IP.
RTCP: the quiet report card
Travelling alongside the RTP media stream is a second, much quieter stream called RTCP, the RTP Control Protocol. It carries no voice at all. Instead, every few seconds, each side mails the other a little report card describing how the call is going: how many packets I sent, how many of yours I lost, how much jitter I am seeing, and the round-trip delay between us. It is the feedback channel that lets each end actually measure the three enemies — delay, loss, and jitter — rather than guess at them.
Why bother? Because a smart application can act on these numbers. If RTCP reports that loss is climbing, the sender can switch to a more robust, lower-bitrate codec, easing the load it puts on a congested path — much the way an adaptive video player drops to a lower resolution when the network struggles. RTCP does not fix anything by itself; it is purely the messenger. But it turns a blind one-way spray of packets into a loop where each side can see the call's health and adapt. To keep its own traffic from crowding out the voice, RTCP politely limits itself to a small slice — by convention, around five percent of the bandwidth the media uses.
SIP: the matchmaker that finds the other phone
RTP and RTCP carry and report on the media, but they answer none of the setup questions. Where is the person I am calling? Is their phone even on? Which codec can we both speak? Which IP address and port should I send the audio to? Solving all of that is the job of a separate protocol, SIP, the Session Initiation Protocol. SIP is the matchmaker and the doorbell; once it has joined the two parties and agreed the terms, it steps aside and the RTP media flows directly between the phones.
Two ideas make SIP click. First, you are reached by a name, not a fixed location: a SIP address looks like an email address, say sip:[email protected], and a registration step keeps the network up to date on which device that name is currently sitting at — the same problem the DNS solves for web servers, here solved for people who roam between phones, laptops, and apps. Second, SIP looks reassuringly familiar: it is a text-based request-and-reply protocol with methods like INVITE and BYE and numeric status codes, modelled closely on HTTP. If you have read the earlier rungs, reading a SIP message will feel like reading an HTTP request with the verbs renamed.
The whole call, start to finish
Let us trace one VoIP call end to end and watch every piece take its turn. Mia, on her laptop, calls Theo, on his phone, across an ocean. Notice how SIP does the introductions, then RTP and RTCP carry the conversation, and the playout buffer from last guide quietly smooths it all out.
- Mia's laptop sends a SIP INVITE addressed to sip:[email protected]. It rides through her provider's SIP servers, which look up where Theo's name is currently registered and forward the invite to his phone. Tucked inside the INVITE is Mia's offer: the codecs she speaks and the IP and port she wants the audio sent to.
- Theo's phone rings (a SIP 180 Ringing flows back to Mia, which is why she hears a ringtone). When Theo taps answer, his phone replies 200 OK, and inside it sends back his own answer: the codec he picks from her list, plus the IP and port he wants the audio on. Mia's laptop confirms with a SIP ACK. The terms are now agreed.
- Now SIP steps aside. Each phone packetises its microphone into ~20 ms chunks, wraps each in an RTP envelope with a rising sequence number and a timestamp, drops it into a UDP datagram, and sends it straight to the address the other side named. Two RTP streams now flow in parallel, one each way — this is the actual voice.
- As the packets arrive jittered, each receiver does not play them the instant they land. It drops them into its playout buffer, sorts them by sequence number, and releases each at the moment its timestamp dictates — paying a fixed delay of a few tens of milliseconds to convert lumpy arrivals into smooth, evenly spaced speech.
- Throughout, RTCP report cards cross between them every few seconds. If Theo's network starts losing packets, his phone sees it and may switch to a tougher, lower-bitrate codec on the fly. If a packet does vanish, the receiver hides the gap with loss concealment rather than waiting for a doomed retransmission.
- When Mia hangs up, her laptop sends a SIP BYE. Theo's phone answers 200 OK, both sides stop their RTP streams, and the session is over. Signalling opened the call and signalling closes it; the media simply stops flowing.
Step back and admire how cleanly the pieces split. SIP finds the other party and negotiates the terms, then bows out. RTP labels each scrap of audio with a number and a clock so it can be reassembled in order and in time. RTCP whispers quality reports so each side can adapt. UDP and IP do the actual hauling, asking no questions and making no promises. And every one of these tools is just a smart end-system trick layered on top of a best-effort network that, true to form, still guarantees nothing. The miracle is not that the network got better — it did not. It is that the endpoints got clever.