Fundamentals
RTP Explained: The Voice Itself
If SIP is the conversation about the call, RTP — the Real-time Transport Protocol, RFC 3550 — is the call. Your voice is sliced into tiny pieces (20 milliseconds each, by default), wrapped in RTP headers, and sent as a numbered, timestamped stream. The receiver reassembles the stream, buffers it briefly against irregular arrivals, and plays it out. Every audio-quality symptom in this site — choppiness, robotic voice, gaps — is a story about what happened to that stream.
RTP's header fields are small but mighty: they are how both endpoints and your capture tools measure the network's behavior without any separate instrumentation.
The header fields that run diagnostics
| Field | What it does | What it reveals |
|---|---|---|
| Sequence number | Increments by 1 per packet | Gaps = lost packets (or reordering); the basis of every loss statistic |
| Timestamp | Media clock ticks (8,000/sec for G.711) | Spacing reveals jitter: packets sent evenly that arrive bunched or late |
| SSRC | Identifies the stream source | Separates streams in a capture (each direction, hold music, conference legs) |
| Payload type | Names the codec/format | Confirms what was actually negotiated — and catches telephone-event (DTMF) streams |
| Marker bit | Marks the start of a talkspurt | Useful in analysis of silence suppression boundaries |
Packetization and RTCP: the supporting cast
The packetization interval (ptime, typically 20 ms) sets the stream's heartbeat: 50 packets per second per direction. Shorter intervals react faster but waste bandwidth on headers; longer intervals add delay. Silence suppression (VAD) may pause transmission during quiet gaps — visible in captures and a suspect when the first syllable after pauses clips. Alongside the media, RTCP (RTP Control Protocol) periodically exchanges reception reports: fraction lost, cumulative loss, interarrival jitter, and delay estimates. Those reports are what your provider's MOS dashboard is built from — and why a capture at one end knows what the far end experienced. SRTP is RTP with encryption and authentication, negotiated in signaling (see the encryption guide).
Reading an RTP stream like an engineer
- In Wireshark (Telephony → RTP Streams), sort by lost packets and jitter; the worst stream in a 'bad calls' window is your patient zero.
- Check packet counts per direction for symmetry (one-way audio announces itself here).
- Graph a single bad stream: sequence gaps cluster at loss events; timestamp spacing shows jitter's shape (spikes vs constant).
- Confirm payload types match the SDP negotiation — a stream claiming one codec while endpoints expected another is a transcoding clue.
- Correlate stream start/stop with the SIP dialog (same call) to separate signaling events from media events in the timeline.
Frequently asked questions
- Why doesn't RTP retransmit lost packets like TCP does?
- Because late voice is worthless voice: a retransmitted syllable arriving 300 ms late cannot be inserted into a live conversation. RTP chooses timeliness over completeness, and hides small losses with concealment — which is also why it rides on UDP.
- What packet rate should I see in a healthy call?
- With 20 ms packetization, 50 packets/second per direction while someone is talking (fewer with silence suppression). A capture showing wildly different rates points at a non-default ptime or a stream that isn't the voice you think it is.
- Can RTP run over TCP?
- It can be framed over TCP (some systems do for firewall traversal), at the cost of TCP's retransmission delays stacking into the audio. UDP remains the norm for media; TURN/TCP is a fallback for hostile networks.