Imagine you’re troubleshooting a choppy voice call, but the codec settings look fine. The real culprit might be hidden in the raw data. That’s where packet capture comes in. By recording actual network traffic, you can measure exactly how much bandwidth each VoIP call consumes and identify quality issues like jitter or packet loss that simple calculators miss.
This guide walks you through the process of using Real-time Transport Protocol (RTP) throughput analysis to get accurate, packet-level evidence of your VoIP performance. Whether you’re planning capacity for a new WAN link or debugging an SLA violation, this method gives you the ground truth.
Why Packet Capture Beats Theoretical Calculators
Most engineers start with a theoretical calculator. You pick a codec like G.711, set a 20 ms packetization interval, and get a number around 80 kbit/s. It’s clean and predictable. But real networks aren’t clean. They have silence suppression, voice activity detection (VAD), retransmissions, and encryption overhead from IPsec or GRE tunnels.
Theoretical formulas don’t account for these variables. A G.711 call calculated at 80 kbit/s might actually consume 120 kbit/s on a WAN link wrapped in IPsec. If you plan your QoS policies based only on the theoretical number, you’ll end up with congestion during peak hours. Packet capture solves this by measuring the actual bits hitting the wire, including all headers and overheads.
- Real-world accuracy: Captures reflect actual traffic, not idealized scenarios.
- Quality correlation: You see bandwidth spikes alongside jitter and loss events.
- Path verification: Compare captures at source and destination to isolate where drops occur.
Setting Up Your Capture: Filters and Ports
Before you open any analyzer, you need to capture the right traffic. VoIP media streams typically run over UDP ports in the range of 16384 to 32767. To keep your capture file manageable, use a capture filter when you start recording.
- Open your packet capture tool (like Wireshark).
- Apply the capture filter:
udp portrange 16384-32767. - Start the capture while the test call is active.
If you’re targeting a specific call, add IP address filters to narrow it down further. For example, if you know the caller’s IP is 192.168.10.146, you can refine the filter to include ip.addr == 192.168.10.146. This reduces noise and makes the subsequent analysis faster.
Analyzing RTP Streams in Wireshark
Once you have your .pcap file, it’s time to dig into the RTP statistics. Wireshark is the standard tool for this, and its built-in RTP analysis features are powerful. Here’s how to find the bandwidth metrics:
- Open the capture file in Wireshark.
- Navigate to Telephony → RTP → Show All Streams.
- In the list, you’ll see columns for SSRC, Payload Type, Packets, Lost, Max Delta, Max Jitter, and BW (Bandwidth).
- Select the stream you want to analyze. Use "Find Reverse" to locate the opposite direction of the call.
- Click Analyze to open the detailed dialog.
The BW column shows the bandwidth at the IP level. This includes the RTP payload, RTP header, UDP header, and IP header. It excludes lower-layer headers like Ethernet, which would add another 14 bytes per packet. Keep this distinction in mind when comparing numbers with other tools.
| Level | Includes | Typical Overhead (G.711, 20ms) | Use Case |
|---|---|---|---|
| RTP Only | Payload + 12-byte RTP Header | ~76 kbit/s | Application layer design |
| UDP/IP | RTP + 8-byte UDP + 20-byte IP | ~87 kbit/s | Wireshark default BW metric |
| Link Layer | UDP/IP + 14-byte Ethernet (+ VLAN) | ~94+ kbit/s | Physical wire utilization |
Interpreting Throughput and Quality Metrics
Bandwidth isn’t the only number that matters. The same RTP analysis window provides jitter, delay, and packet loss statistics. These metrics correlate directly with Mean Opinion Score (MOS), which measures perceived voice quality.
Jitter represents the variation in packet arrival times. High jitter causes the receiver to buffer packets, adding latency. If jitter exceeds 30 ms, users may notice robotic or choppy audio. In Wireshark’s graph view, look for spikes in the jitter line. Correlate these spikes with timestamps of lost packets or bandwidth fluctuations. Often, a burst of background traffic will cause both increased jitter and temporary bandwidth spikes.
Packet loss is straightforward: if the sequence numbers skip, packets were dropped. A loss rate below 1% is generally acceptable for voice. Above 2%, quality degrades significantly. The dual-capture technique-recording at both the sender and receiver-is crucial here. If the sender shows no loss but the receiver does, the problem is in the network path, not the endpoint.
Common Pitfalls and How to Avoid Them
Even experienced engineers make mistakes with RTP analysis. Here are the most common traps:
- Misidentifying streams: Not all UDP traffic in the 16k-32k range is RTP. Always verify via the Telephony → VoIP Calls menu to ensure you’re looking at a valid SIP dialog.
- Ignoring encapsulation: If your network uses SRTP or IPsec, the visible bandwidth in Wireshark might differ from what’s actually on the wire if the tunnel is encrypted before capture. Ensure your capture point is after decryption if possible.
- Averaging errors: Wireshark’s BW metric is calculated over a one-second window. Don’t assume this is the average for the entire call. Look at the graph to see variability.
- Header confusion: Remember that Wireshark’s BW includes IP/UDP headers. If you compare this to a calculator that only counts RTP payload, you’ll see a difference of at least 28 bytes per packet (11.2 kbit/s at 50 packets/sec).
Tools Beyond Wireshark
While Wireshark is the gold standard for manual analysis, automated tools can speed up the process. Platforms like VoIPTest allow you to upload .pcap files directly. They automatically extract RTP streams, map SIP dialogs, and generate per-stream quality metrics, including estimated MOS. This is ideal for managed service providers processing dozens of captures daily.
For pre-deployment planning, theoretical calculators like Packetizer’s VoIP Bandwidth Calculator are still useful. They let you specify whether to include RTP, UDP, IP, or link-layer headers, helping you bridge the gap between design estimates and measured reality. Use them to set expectations, then validate with packet captures once the system is live.
Frequently Asked Questions
What is the best capture filter for VoIP RTP traffic?
The standard filter is udp portrange 16384-32767. This covers the typical dynamic port range used by SIP phones and softphones for media streams. For more precision, combine it with specific IP addresses involved in the call.
Does Wireshark’s BW metric include Ethernet headers?
No. The BW column in the RTP Streams dialog calculates bandwidth at the IP level. It includes the IP header (20 bytes) and UDP header (8 bytes) plus the RTP payload and header. Ethernet headers (14 bytes) are excluded unless you manually calculate them or use a different display filter.
How do I distinguish between forward and reverse RTP streams?
In the RTP Streams window, select a stream and click "Find Reverse." This identifies the corresponding stream in the opposite direction. Analyzing both directions is critical because one side might suffer from congestion while the other remains clear.
What is a good threshold for jitter in VoIP calls?
Jitter under 30 ms is generally considered acceptable for voice quality. Between 30-50 ms may cause noticeable degradation. Above 50 ms, users often experience significant issues. Always correlate jitter spikes with packet loss events for a complete picture.
Can I use packet capture to verify SLA compliance?
Yes. By capturing traffic at both ends of a managed connection, you can prove where packet loss or latency occurs. If the provider claims the network is stable, but your capture at the edge shows high jitter, you have concrete evidence to dispute the SLA report.
Write a comment