Expected Packets — VoIP Network Metric
RTP expected packet count from sequence number tracking — the RFC 3550 denominator used to calculate precise packet loss on SIP and WebRTC calls.
Expected Packets
| Property | Value |
|---|---|
| Key | expected_packets |
| Unit | Count |
| Type | Cumulative counter |
| Direction | Receive |
| RFC | RFC 3550 Section 6.4.1 (Receiver Report RTCP Packet) |
What It Measures
Expected Packets is the total number of RTP packets that should have been received, calculated from the sequence number range observed during the call. RFC 3550 defines this as: extended_max_seq - initial_seq, where extended_max_seq accounts for 16-bit sequence number wraparound using an extended 32-bit counter.
This is the denominator in the packet loss calculation. The number of lost packets is simply: expected_packets - received_packets. Packet loss rate is then lost / expected.
Why It Matters
Expected packets is not a metric you tune — it is a measurement foundation. Its value is in what it enables:
Precise loss calculation without gaps in the sequence. RTP sequence numbers are 16-bit integers that wrap at 65,535. Any loss calculation that does not account for wraparound will produce incorrect results for calls lasting more than ~22 minutes at 50 packets/second. CallMeter implements the RFC 3550 extended sequence number counter to handle this correctly.
Cross-check for sequence number anomalies. If expected packets diverges significantly from what you would predict based on call duration and ptime, it means the sequence number stream is discontinuous — indicating Sequence Resets, Sequence Jumps, or SSRC conflicts.
Baseline for derived metrics. Several network health metrics are expressed as ratios of expected packets: packet loss rate, receive rate, and duplicate rate. When expected packets is inaccurate (due to sequence anomalies), all downstream ratio metrics inherit the error.
For high-volume load testing, expected packets gives you a sanity check on call fidelity: did each test call generate the packet count you expected for its configured duration? A systematic shortfall across hundreds of calls suggests early call termination or silent media path failures.
Thresholds
Expected packets itself has no quality threshold — it is a measurement input, not a quality indicator. What matters is the relationship between expected and received:
| Condition | Concern |
|---|---|
received_packets well below expected_packets | Packet loss — see Packet Loss Rate |
received_packets above expected_packets | Duplicate packets — see Duplicate Packets |
expected_packets does not match duration × codec rate | Sequence discontinuity — check sequence reset metrics |
How to Fix It
- Use expected packets as a floor, not a ceiling. If received exceeds expected, you have duplicates. If it is far below, check for early SSRC changes that reset the expected counter.
- Monitor sequence resets. When an SSRC resets mid-call, the expected packet counter restarts. This causes expected packets to undercount the total packets that should have arrived, making loss appear lower than it is.
- Cross-reference with call duration. For a known ptime and codec, expected packets should approximate
call_duration_ms / ptime_ms. Significant deviation warrants investigation.
Related Metrics
- Packets Received — Actual received count; loss = expected minus received
- Packets Lost — Derived directly from expected minus received
- Packet Loss Rate — Derived as lost divided by expected
- Sequence Resets — Can corrupt the expected packet count mid-call