Packet Loss Rate
Percentage of RTP packets lost in transit — the most direct indicator of network reliability for VoIP traffic.
Packet Loss Rate
| Property | Value |
|---|---|
| Key | fraction_lost |
| Unit | Percentage (%) |
| Type | Gauge |
| Direction | Send and Receive |
| RFC | RFC 3550 Section 6.4.1 |
What It Measures
Packet Loss Rate is the percentage of RTP packets that were sent but never reached the receiver. It is the most straightforward indicator of whether the network is reliably delivering voice or video data.
If 1,000 packets were sent and 990 arrived, the packet loss rate is 1%. This is reported per RTCP interval using the "fraction lost" field defined in RFC 3550 Receiver Reports.
Unlike the cumulative Packets Lost count, fraction lost measures loss over the most recent reporting interval, making it responsive to current network conditions.
Why It Matters
Packet loss has a disproportionate impact on call quality compared to other impairments:
| Loss Rate | Impact |
|---|---|
| 0% | Perfect delivery |
| 0.5% - 1% | Barely perceptible. Some codecs conceal this fully. |
| 1% - 3% | Audible artifacts. Users notice occasional glitches. |
| 3% - 5% | Significant degradation. Words or syllables missing. |
| Above 5% | Severe. Conversation becomes difficult to maintain. |
For video, the impact is even more pronounced. A single lost packet in a video frame can corrupt the entire frame, causing visual artifacts or freezes until the next keyframe arrives.
How CallMeter Measures It
CallMeter reads the fraction lost field from RTCP Receiver Reports exchanged between endpoints during the call. This gives a per-interval loss rate that reflects current network conditions. The value is normalized to a percentage and reported every second.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 1% or below | Codec concealment handles this |
| Warning | 1% - 5% | Users will notice degradation |
| Critical | Above 5% | Call quality is unacceptable |
What Causes High Packet Loss
- Network congestion — The most common cause. When link utilization exceeds capacity, routers drop packets from their queues. VoIP UDP traffic is typically dropped first because it has no retransmission mechanism at the transport layer.
- Firewall or NAT issues — Stateful firewalls with aggressive timeout settings may close UDP "connections" mid-call. Deep packet inspection may introduce drops under load.
- Rate limiting — Network devices or ISPs may apply per-flow or aggregate rate limits that throttle RTP streams.
- Buffer overflow — Small buffers on intermediate devices (especially in cloud environments) overflow during traffic bursts.
- Wireless last mile — WiFi and cellular links introduce loss through radio interference, handover events, and signal degradation.
- MTU and fragmentation — If RTP packets exceed the path MTU and get fragmented, losing any fragment loses the entire packet.
How to Fix It
- Apply QoS markings. Mark RTP with DSCP EF and ensure every hop respects the marking. This is the single most effective fix.
- Check firewall rules. Verify UDP port ranges for RTP are open and that connection tracking timeouts exceed your call duration.
- Verify link capacity. Compare your RTP bitrate against available bandwidth. A G.711 call uses about 87 kbps including headers; H.264 video can use 500 kbps or more.
- Reduce fragmentation. Set the path MTU appropriately and avoid RTP payloads that exceed it.
- Use wired connections. Eliminate WiFi from the media path for production SIP infrastructure.
- Test at different times. If loss varies with time of day, the cause is likely shared bandwidth contention.
Codec Concealment Masks Reality
Modern codecs like Opus can conceal up to 5% packet loss with minimal audible impact. This means the call might sound acceptable even when loss is high. Do not rely on subjective quality alone — always check the measured loss rate.
Related Metrics
- Packets Lost — Absolute count of lost packets
- MOS Score — Loss is the highest-impact factor in MOS calculation
- R-Factor — Loss drives the effective equipment impairment factor (Ie-eff)
- Jitter — High jitter can cause effective loss at the jitter buffer
- Duplicate Packets — May indicate loss recovery attempts