| delay since last SR (DLSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ `
Fraction Lost versus Cumulative Number of Packets Lost
The report block conveys two distinct packet loss indicators: an 8-bit fraction lost value and a 24-bit signed cumulative number of packets lost. The cumulative counter records the total number of packets dropped since reception began, calculated as the difference between the expected packet count and the received packet count. It can decrement if duplicate packets arrive after being marked missing, and it clamps at 0x7FFFFF on overflow.
The fraction lost field provides the instantaneous loss rate experienced strictly within the last reporting interval. As specified in RFC 3550:
"The fraction lost parameter is the fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number with the binary point at the left edge of the field."
To map this field to an operational loss percentage, divide the raw integer value by 256. A value of 13 represents approximately 5.08% loss (13 / 256), whereas a value of 64 represents exactly 25.0% loss.
If your packet capture displays a high cumulative loss value alongside a fraction lost of 0, the link is not currently dropping packets. The impairment happened in a previous reporting window. If you observe fraction lost spiking while cumulative loss remains low, the call has just entered a degraded network segment, or the reporting endpoint recently experienced an extended sequence number wraparound that reset its local counters.
Interarrival Jitter and Clock Units
The interarrival jitter field estimates the statistical variance of RTP data packet interarrival times, measured in timestamp units and stored as a 32-bit unsigned integer. The receiving endpoint calculates the transit time difference $D(i, j)$ for adjacent packets $i$ and $j$:
$$D(i, j) = (R_j - R_i) - (S_j - S_i) = (R_j - S_j) - (R_i - S_i)$$
where $S$ is the RTP timestamp from the packet header and $R$ is the arrival timestamp in the receiver's local clock base. The running jitter $J(i)$ updates continuously using a first-order estimator:
$$J(i) = J(i - 1) + \frac{|D(i - 1, i)| - J(i - 1)}{16}$$
A recurrent engineering mistake is reading the raw jitter integer directly as milliseconds. Jitter is defined in the media clock rate of the payload. For a G.711 call operating at an 8000 Hz sample rate, one clock tick equals 0.125 ms; an interarrival jitter value of 160 indicates a variance of 20 ms. For an Opus stream mapped to a 48000 Hz RTP clock pursuant to RFC 6716, one clock tick is 0.0208 ms; a value of 960 corresponds to 20 ms of variance. Comparing raw jitter values across disparate codecs without normalizing by the payload clock rate produces false anomalies.
What does quantifying Path Delay and Asymmetry actually mean?
RTCP provides an explicit mechanism to measure network round-trip time (RTT) without requiring clock synchronization between endpoints, but it offers zero visibility into one-way path asymmetry.
Round-Trip Time Calculation via DLSR and LSR
The receiver uses the last SR (LSR) and delay since last SR (DLSR) fields to calculate the round-trip propagation delay. The sender writes the middle 32 bits of the 64-bit NTP timestamp from its most recent SR into the RR. When the receiving host emits an RR, it records the elapsed time between receiving that SR and formatting the RR into the DLSR field, measured in units of 1/65536 seconds.
Upon receiving the RR at arrival instant $A$ (represented in compact 32-bit NTP format), the original sender evaluates:
$$\text{RTT} = A - \text{LSR} - \text{DLSR}$$
For example, if an endpoint transmits an SR with an NTP timestamp whose middle 32 bits are 0x00058000, and receives an RR at NTP arrival instant 0x0005C000 containing an LSR of 0x00058000 and a DLSR of 0x00002000 (which corresponds to 125 ms, or 8192/65536):
$$\text{Elapsed Time} = 0x0005C000 - 0x00058000 = 0x00004000 = 16384 \text{ units (250 ms)}$$ $$\text{RTT} = 250\text{ ms} - 125\text{ ms} = 125\text{ ms}$$
One-Way Delay Ambiguities
RFC 3550 assumes the transmission path is symmetric. The calculated RTT is divided by two to estimate one-way transit delay. In production deployments, asymmetric routing—such as cellular uplink scheduling delays or traffic shaping across enterprise edge firewalls—routinely skews forward and reverse path transit times. If the forward path consumes 110 ms and the return path consumes 15 ms, base RTCP reports an aggregate RTT of 125 ms and attributes 62.5 ms to each direction.
When troubleshooting caller reports of talk-over collisions, standard RR blocks will not identify which direction is backlogged. For directional latency attribution, I would check for RTCP Extended Reports (XR) containing delay metrics or check intermediate session border controller packet timestamps against a synchronized PTP or NTP stratum-1 clock. RFC 3550 does not solve direction-specific latency isolation.
Extended Reports and Media Adaptation Signals
Standard RTCP reports are transmitted periodically, scaled according to session bandwidth rules that typically constrain RTCP traffic to 5% of the overall media allocation. In an active two-party call, this produces report intervals fluctuating between 2.5 and 5.0 seconds. This granularity is far too coarse to trace transient burst losses.
RTCP Extended Reports Metrics
RFC 3611 defines RTCP Extended Reports (XR), providing specialized payload formats like the VoIP Metrics Report Block. This block separates packet losses into distinct bursts and gaps using a Markov chain model:
` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ `
The VoIP Metrics block differentiates network drop behavior from receiver playout behavior via the loss rate and discard rate fields. The loss rate metric records packets dropped exclusively on the IP transit link. The discard rate records packets that arrived successfully at the socket layer but were discarded by the local jitter buffer due to late arrival.
If an RTCP XR block reports a loss rate of 0% alongside a discard rate of 12%, diagnosing the network layer for bad physical links or policing drops is a mistake. The packets are arriving, but interarrival variance is exceeding the adaptive jitter buffer's dynamic playout horizon.
Adaptation Mechanics Across Layers
When network degradation occurs, codecs do not automatically adapt on their own. The receiving host processes the incoming packet stream, derives reception statistics, and issues feedback. The sending host's media engine consumes this feedback and calls local encoder APIs to mutate state.
Under sustained loss signaled via standard RR blocks or immediate AVPF feedback messages defined in RFC 4585, the transmitting control plane adjusts encoder parameters. For an Opus encoder running at 32 kbps with 20 ms frame sizes (960 audio samples at 48000 Hz):
1. The media engine reads an RTCP fraction lost of 38 (approximately 14.8%). 2. The control layer invokes the encoder interface: opus_encoder_ctl(enc, OPUS_SET_PACKET_LOSS_PERC(15)). 3. The control layer instructs the encoder to enable in-band Forward Error Correction (FEC): opus_encoder_ctl(enc, OPUS_SET_INBAND_FEC(1)). 4. If the fraction lost exceeds 20%, the application reduces the target audio bitrate from 32 kbps to 16 kbps using OPUS_SET_BITRATE(16000) to reclaim headroom. 5. If bandwidth constraints are severe, the application re-packetizes audio into 40 ms or 60 ms frames to reduce RTP/UDP/IP header overhead from 50 packets per second down to 25 or 16.6 packets per second.
` RTCP RR / AVPF Feedback --> Media Engine Parser | v Fraction Lost Calculated (14.8%) | +--> OPUS_SET_INBAND_FEC(1) +--> OPUS_SET_PACKET_LOSS_PERC(15) +--> OPUS_SET_BITRATE(16000) `
In-band FEC embeds a redundant, lower-bitrate representation of frame $N-1$ inside the payload of frame $N$. If frame $N-1$ drops, the receiver decodes the secondary payload from frame $N$, avoiding interpolation. This fails when loss occurs in consecutive bursts.
Playout Failures Under Burst Loss and Latency Spikes
Standard packet loss concealment (PLC) algorithms reconstruct missing audio waveforms by extrapolating pitch periods from previous valid frames or generating comfort noise. Most audio PLC mechanisms tolerate a single 20 ms frame loss with negligible audible distortion. When a burst drop spans 60 ms to 80 ms (three to four consecutive packets), the extrapolator exhaustively dampens the predicted signal to prevent high-energy artifacts, leading directly to dropped syllables. Concurrently, if the network experiences an abrupt jitter spike of 150 ms, the adaptive jitter buffer faces a deterministic tradeoff: it must either inflate its internal buffer to avoid starving the DAC, which introduces conversational latency, or aggressively purge late-arriving packets as discards. When the buffer expands, listeners report an unnatural pause followed by overlapping speech; when it purges, the PLC engine starves, forcing silence insertion into the audio hardware queue.
Reading the Sequence
When debugging real-time audio impairments:
1. Check fraction lost to evaluate immediate link drops during the last 5 seconds. 2. Check cumulative packets lost to determine whether loss is continuous or historical. 3. Normalize interarrival jitter against the payload sample rate; do not read it directly as time. 4. Calculate RTT using LSR and DLSR, and never assume the forward and reverse transit delays are equal. 5. Check discard rate against loss rate in XR blocks to determine whether audio breaks at the network layer or at the receiver's jitter buffer.
Correlate RTP sequence numbers with RTCP reception snapshots before touching encoder parameters. If the receiver reports drops while the jitter buffer discard count matches the reported loss, the network is delivering packets; it is just delivering them too late to be spoken.
Terms used in this note
A codec is an algorithm that compresses audio for transmission. A jitter buffer is a queue that absorbs variable arrival times before playback. Packet loss concealment is the substitution a decoder performs when a frame never arrives.
- Sample rate — how many times per second the signal is measured
- Frame size — the block of samples a codec encodes at once
- Lookahead — the delay a codec needs before it can encode
- Bitrate — bits per second the stream consumes
- Jitter — variation in packet arrival time
- Playout delay — total time from capture to speaker
- Concealment — what the decoder invents for a missing frame
- Transcoding — decoding and re-encoding between formats
- Comfort noise — synthetic background added during silence
- RTP — the transport that carries real-time media
- RTCP — the control protocol reporting on an RTP session
- Narrowband — speech-band audio, roughly 300 to 3400 Hz