Summary
- RFC 3558 interleaves EVRC or SMV speech frames so a lost RTP packet can create nonconsecutive erasures. The benefit is a less concentrated loss pattern, not restoration of the missing speech.
- The receiver's
maxinterleavedeclaration is a ceiling the sender must respect in a one-to-one session. It does not prove that memory was allocated, packets arrived before playout, the group was reconstructed, the decoder consumed it or listeners received acceptable speech.
A packet can fail once and make the receiver wait many times. This is the operational paradox inside RFC 3558, the July 2003 Proposed Standard for carrying Enhanced Variable Rate Codec and Selectable Mode Vocoder frames in RTP.
Both codecs process speech in 20-millisecond frames. A simple packetizer can place adjacent frames together: if that packet is lost, the missing speech is consecutive. The Interleaved/Bundled format can instead distribute neighboring frames across several sequential packets. Losing one packet then removes positions separated in reconstructed time. Speech decoders generally tolerate isolated erasures better than a long uninterrupted run.
Nothing has been recovered. The sender has changed the geometry of failure, while the receiver has accepted a reconstruction obligation.
The group exists in two orders
The payload's first octet carries a three-bit interleave length, LLL, and a three-bit interleave index, NNN. The second carries a mode request and a five-bit frame count. Because the count represents one less than the number of frames, a packet can declare from one to 32 frames. LLL equal to zero means ordinary bundling; a positive value invokes interleaving, and NNN must not exceed LLL.
Let B be the number of frames placed in each packet and L the interleave length. A group then covers B multiplied by L plus one frames and spans L plus one RTP packets. Packet N carries frame positions N, N plus L plus one, and onward through the group. Packets are transmitted in increasing NNN order, but the decoder needs the frames in their reconstructed time order.
This creates two legitimate clocks. Network arrival follows RTP packets. Speech playback follows 20-millisecond frame positions. A group receipt must preserve both. Recording only the packet sequence cannot show when the earliest playable frame became available; recording only the reconstructed sequence hides which datagram created each gap.
The standard says increasing NNN minimizes receiver delay. “Minimizes” is not “eliminates” and not “guarantees”. Reordering, jitter and a late final group member can still make the receiver choose among waiting, substituting an erasure frame or missing a playout deadline.
Dispersed loss is still lost speech
RFC 3558 distinguishes speech frames from two zero-bit conditions. A null frame represents no codec output and is normally not transmitted. An erasure frame is a receiver-side substitute when a frame is missing or damaged. Passing an erasure to the decoder advances its state by one frame interval. It does not recreate the speaker's waveform, syllable or intent.
Interleaving can make those substitutes nonconsecutive. Consider four packets whose frames are woven across one group. If the second packet disappears, several time positions may be marked as erasures with received speech between them. The decoder avoids one contiguous gap, but every missing position remains uncertain.
That distinction matters in incident reports. “The decoder continued” means its state machine advanced. It does not mean speech was recovered, understood or acceptable. A service may remain technically live while names, digits or commands are selectively damaged. The evidence chain must retain the erasure map alongside any quality score or application result.
The receiver advertises a ceiling, not a reservation receipt
In session description, maxinterleave tells the sender the largest interleave length the receiver is prepared to accept. RFC 3558 gives a default of five when the parameter is absent. In a one-to-one session the sender must not exceed the announced value. The receiver may reduce it during the session, but the sender must remain inside the current ceiling.
This enables a receiver to know the maximum buffer it may need. It does not prove that the implementation reserved that buffer, retained every group member, applied the new value at the same instant as the sender or met the playout deadline. Capability metadata is not resource telemetry.
The neighboring maxptime parameter limits the media duration put in one packet and defaults to 200 milliseconds. It constrains bundling; maxinterleave constrains how far frames can be distributed. Neither one alone determines end-to-end delay. The observed result also depends on B, L, packet spacing, jitter policy, reorder depth, decoder scheduling and the application's latency budget.
Operations should therefore record the offered and answered values, their effective times, the packetizer version, the computed group size, allocated bytes, occupancy high-water mark, first-frame deadline and every forced early reconstruction. A clean offer/answer exchange proves only that two endpoints exchanged descriptions.
The late packet exposes the real decision
An interleaved packet may arrive too late for its earliest frame but early enough for later frame positions in the same packet. A receiver that discards the whole datagram wastes usable speech. A receiver that waits for every position can damage conversational latency. A receiver that salvages later frames needs a precise per-frame deadline and a way to record the partial use.
This is where protocol compliance turns into local policy. The RFC supplies the indexing needed to locate frames; it does not choose an application's patience. The operating system, jitter buffer, decoder interface and service objective make that choice together.
A useful receipt says: packet P arrived at time T; frame F1 had already crossed its deadline and became an erasure; frames F2 and F3 remained timely and entered the decoder; playback advanced under policy version V. “Packet received” is too coarse. “Audio played” is too late and too vague.
Header-Free is not an inferior mode
RFC 3558 also defines a Header-Free format containing one codec frame without the table-of-contents and interleave headers. It offers no bundling and no interleaving. That removes the reconstruction group and reduces packetization delay, at the cost of more packet headers per unit of speech.
For an interactive conversation, latency may be scarcer than bandwidth. The RFC recommends LLL equal to zero or Header-Free operation when delay matters, while values around four or five may be suitable when robustness matters more than immediacy. This is not a universal ranking. It is an explicit invitation to name the constrained resource.
The decision record should compare measured header cost, path loss pattern, jitter, available buffer, dialogue tolerance and decoder concealment behavior. Interleaving because the feature exists is not an engineering rationale. Refusing it because it adds delay is equally incomplete when burst loss destroys intelligibility.
RFC 2508 and RFC 3095 provide header-compression context. Compression may change the cost of sending single-frame packets, but a supported compression profile is not proof that its context remained healthy on the observed path.
A mode request is a request, not an acknowledgement
The payload can carry a mode request for the encoder in the reverse direction. In a one-to-one session the peer is recommended to honor it; in a multiparty setting it should be ignored. The request is repeated because a single request may be lost.
Repetition improves the chance that a request is seen. It does not acknowledge application, identify the first conforming frame or establish why the encoder chose a mode. Treating the outgoing request as a completed change erases the most important evidence boundary.
Keep the request, each transmission attempt, peer receipt if available, encoder decision, first resulting frame, and any refusal or constraint separately. The same principle applies to interleave changes: the declaration, sender adoption and observed packet stream are distinct events.
Validation failure should remain visible
The table of contents describes each frame's type and size. Invalid combinations of LLL, NNN, frame count or frame bytes can make a packet unusable. A receiver may discard it or substitute erasures. That is a protocol-valid survival behavior, not evidence that the payload was harmless.
Telemetry should distinguish network loss from received-but-invalid payload, unsupported frame type, late arrival and local buffer eviction. All may become erasures at the decoder, yet they require different owners and remedies. Collapsing them into “packet loss” rewards the wrong layer and prevents recurrence analysis.
RFC 4788 later updated this payload family for EVRC-B, compact bundled operation, discontinuous transmission and revised registrations and offer/answer details. It should be treated as later protocol context, not silently projected backwards into every RFC 3558 deployment.
Evidence boundary
This Article identifies no operator, vendor, endpoint, call, user, incident, measured loss rate, allocated buffer or quality result. Its examples explain the mechanics defined by the standards; they do not claim that any production session used them.
RFC 3550 and RFC 3551 provide the RTP framework and profile context. RFC 3264 supplies offer/answer behavior; RFC 2327 was the session-description context at publication and RFC 8866 is later status context. RFC 2508 and RFC 3095 describe compression alternatives. RFC 8174 clarifies requirement language. RFC 4788 is a later update, not evidence of a particular implementation.
Heng Lu's Running-Code Primacy and Minimum Initial Specification essays are disclosed editorial lenses. They motivate demanding runtime receipts beyond declared capability and keeping the common protocol boundary smaller than local policy. They are not evidence of the RFC authors' intent or of a deployment outcome.
The bounded conclusion is narrow: RFC 3558 interleaving can disperse the frame positions damaged by one lost packet, but it transfers work into buffering, deadline management and temporal reconstruction. A receiver ceiling constrains the sender. Only observed receipts can show that the resources existed and the service outcome survived.
Sources
- https://www.rfc-editor.org/rfc/rfc3558.html
- https://www.rfc-editor.org/info/rfc3558
- https://datatracker.ietf.org/doc/rfc3558/
- https://www.rfc-editor.org/rfc/rfc4788.html
- https://www.rfc-editor.org/info/rfc4788
- https://datatracker.ietf.org/doc/rfc4788/
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc3551.html
- https://www.rfc-editor.org/rfc/rfc3264.html
- https://www.rfc-editor.org/rfc/rfc2327.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.rfc-editor.org/rfc/rfc2508.html
- https://www.rfc-editor.org/rfc/rfc3095.html
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
