RTP and RTCP Basics for Troubleshooting Voice

Introduction¶

Once SIP has negotiated the media (see SIP registration and INVITE flow), the actual audio travels as RTP — small UDP packets, one every 20 ms for typical voice. RTCP rides alongside on the next port up, carrying quality statistics. Almost every "the call sounded terrible" complaint is explained by three RTP numbers: loss, jitter, and out-of-order.

The RTP header¶

Each RTP packet (over UDP) has a 12-byte header:

The receiver uses the sequence number to detect loss and the timestamp to place audio correctly in time regardless of when the packet actually arrived. That's what the jitter buffer does — hold packets briefly so a late one still plays in order.

Jitter, loss, and the jitter buffer¶

• Jitter = variation in inter-arrival time. Packets sent every 20 ms that arrive 20, 19, 25, 15, 30 ms apart have jitter. The jitter buffer absorbs it by adding latency. Too much jitter and packets arrive after their play-out slot — discarded, heard as loss.
• Packet loss — anything over ~1% is audible on G.711; codecs with packet loss concealment (Opus, G.729) tolerate a bit more. Bursty loss (5 in a row) is far worse than the same count spread out.
• Out-of-order — the jitter buffer reorders within its depth; beyond that, the late packet is dropped.

Rules of thumb for a good call: one-way latency < 150 ms, jitter < 30 ms, loss < 1%.

RTCP reports¶

Every few seconds each side sends an RTCP packet. The useful ones:

• Sender Report (SR) — packet/byte counts sent, plus an NTP timestamp used to compute round-trip time and align streams (lip-sync).
• Receiver Report (RR) — what the other end is experiencing:
• fraction lost — loss since the last report (0–255, so 13 ≈ 5%)
• cumulative packets lost
• interarrival jitter — in timestamp units (divide by 8 for ms at 8 kHz)
• last SR / delay since last SR — lets the SR sender compute RTT

RR is gold: it tells you what your peer hears, from their side of the network. If your outbound looks clean but their RR shows 8% loss, the problem is on the path to them.

Hands-on¶

# Capture RTP + RTCP for a call (adjust the port range to your PBX)
tcpdump -i any -s0 -w rtp.pcap 'udp portrange 10000-20000'

In Wireshark:

• Telephony → RTP → RTP Streams — per-stream loss %, max/mean jitter, problem flags. Select a stream → Analyze for a per-packet list showing exactly which sequence numbers were lost or late.
• Telephony → RTP → RTP Player — listen to the reconstructed audio; you can hear where the gaps are.
• Filter rtcp and expand a Receiver Report to read fraction lost and jitter straight from the wire.

On Asterisk:

asterisk -rx "rtp set debug on"          # very verbose; per-packet
asterisk -rx "core show channels verbose"
asterisk -rx "sip show channelstats"     # live loss/jitter per call (chan_sip)
asterisk -rx "pjsip show channelstats"

The CDR / CEL and RTPAUDIOQOS channel variable record per-call loss and jitter after hangup — log them and you can spot patterns (one trunk, one time of day).

Verification and troubleshooting¶

• Choppy audio, RTP stream shows scattered single-packet loss — network congestion or Wi-Fi. Check QoS/DSCP marking is preserved end to end (EF / DSCP 46 for voice); a switch or VPN stripping DSCP is common.
• Choppy audio, jitter high but loss near zero — jitter buffer too small, or a variable-latency link (Wi-Fi, overloaded router, a tunnel). Increase jitter buffer depth; fix the link.
• Robotic / underwater audio — codec mismatch tolerated by transcoding, or a sample-rate problem. Check both SDP a=rtpmap lines.
• One-way audio — only one SSRC/direction present in the capture. NAT or firewall blocking one RTP direction; the side that can't be heard is the one whose RTP isn't arriving. See the NAT notes in the SIP post.
• Audio starts fine then degrades — a path change (failover), a scheduled backup saturating the uplink, or thermal throttling on a cheap router.
• RTCP absent entirely — some devices don't send it, or a firewall allows the RTP port but not RTP+1. Not fatal, but you lose the peer's-eye view.
• Long silence at call start — RTP not flowing until the far end sends something (half-open NAT). "Comfort noise" or an early-media issue.

Related tools and reading¶

• On-site: Port Checker, Ping test, Traceroute.
• Related posts: SIP registration and INVITE flow, Understanding MTU and path MTU discovery.