Burst Duration — VoIP Quality Metric
RTCP-XR average burst loss event duration in ms — longer VoIP burst events cause more perceptible audio dropouts than the same total loss in short bursts.
Burst Duration
| Property | Value |
|---|---|
| Key | burst_duration |
| Unit | ms |
| Type | Gauge |
| Direction | Receive |
| RFC | RFC 3611 Section 4.1 (RTP Control Protocol Extended Reports) |
What It Measures
Burst Duration is the average length of each burst loss event in milliseconds. Where Burst Density tells you what fraction of the call was spent in burst loss, burst duration tells you how long each individual burst event lasted.
A burst duration of 150ms means that, on average, each time the call entered a burst loss state, that burst continued for 150 milliseconds before returning to a gap (normal) period. This maps directly to the audio dropout length the listener experienced at each event.
Why It Matters
Burst duration is the bridge between network statistics and user perception. Two calls with identical burst density can produce completely different user experiences depending on burst duration:
- Short bursts (under 60ms): Codec concealment algorithms like Opus PLC can synthesize plausible audio for these gaps. Most users will not notice.
- Medium bursts (60ms – 200ms): Clearly audible. Users hear a distinct dropout or a synthetic artifact. They will notice, but may attribute it to the other person.
- Long bursts (above 200ms): Obvious conversation-breaking gaps. Users immediately perceive this as a call quality problem and will report it.
For a 20ms packetization interval (standard G.711 or Opus), a 200ms burst means 10 consecutive packets were lost. At that threshold, no concealment algorithm in production use today can fully hide the damage.
When testing SIP trunk SLAs, burst duration is often more predictive of end-user complaints than average packet loss. A carrier can deliver a "1% packet loss" SLA while concealing 300ms burst events that make the service unusable.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | Below 60ms | Below concealment threshold for most codecs |
| Warning | 60ms – 200ms | Audible dropouts, quality impact for users |
| Critical | Above 200ms | Obvious conversation gaps, users will report failures |
How to Fix It
- Correlate with Burst Density. High burst density with short burst duration means many small interruptions — often a jitter problem. High burst density with long burst duration means fewer but more severe events — often a routing or congestion event.
- Check for route instability. BGP or OSPF reconvergence events during a call are the most common cause of bursts above 200ms. Correlate burst timing with network events.
- Review firewall session state. Firewalls that drop UDP streams and require new state establishment can cause bursts of hundreds of milliseconds while the path reestablishes.
- Enable NACK or FEC. For video streams, NACK retransmission can recover packets mid-burst if round-trip time is low enough. For audio, Opus FEC can partially recover from bursts up to 1–2 packets.
- Increase QoS queue priority. Priority queuing ensures RTP traffic is served first during congestion, reducing the duration of any burst that does occur.
Related Metrics
- Burst Density — Fraction of call time spent in burst loss state
- Gap Duration — Average recovery time between burst events
- Sequence Gaps — Packet-level view of individual burst events
- PLC Events — Each burst event triggers one or more PLC events at the decoder