Summary

  • RFC 2448 made reliability a codec-aware choice: send high-priority (HP) information more dependably while leaving low-priority (LP) video on its ordinary path.
  • This was not end-to-end proof of a usable picture. Classification, delivery, version alignment, decoding and timely display remained separate conditions.

The design began with an uncomfortable fact about compressed video: bits do not all carry equal consequences. Some describe picture structure or decoding parameters. Others carry much of the visual payload. A packet network that treats each packet alike cannot know which loss will matter more to the codec.

RFC 2448 therefore placed the judgment at the encoding/application edge. The sender divided a bitstream into HP segments, considered vital for decoding, and LP segments containing the remainder. It could send HP information reliably before the main stream, carry it in distinct RTP packets, duplicate it alongside an unpartitioned stream, or send reusable information out of band for later caching. The network did not need to provide packet priority; the sender arranged a separate reliability path.

That separation made the classifier the crucial decision-maker. The RFC says HP identification depends on the codec’s syntax and semantics; it offers no universal rule for every bitstream. Its MPEG-2 example makes the cost visible. A header-only HP portion was usually below two per cent of the video data. Adding DC coefficients could raise the portion to about 40 per cent and leave something usable in HP alone—but far more data then had to be delivered reliably. These are examples in the memo, not general measurements of video.

Pre-delivery trades loss exposure for startup time. The receiver may wait while HP arrives over a reliable transport before LP begins. Separate RTP packets can use a distinct payload type while sharing timestamp conventions and SSRC space with the main stream. Those shared identifiers describe coordination, not a shared delivery guarantee. A sender can also keep HP in the original stream and send extra copies for recovery. For reusable out-of-band HP, ordinary timestamps may be meaningless: a keyframe, and where available a marker, can help the receiver decide where that state belongs.

So the receiver must answer more than “did the reliable transfer finish?” It must establish that the protected information belongs to this codec version and this point in the LP stream; that the needed LP data arrived; that the decoder produced output before its deadline; and, separately, that a rendering surface displayed it. The standard’s packets and identifiers cannot collapse those facts into one receipt.

RFC 2448 was published in November 1998 as an Informational RFC, not an Internet Standard. It identified AT&T/Lucent patent material and said the IESG and IETF took no position on validity, scope or license availability. The document describes a technique; it does not establish adoption, present-day deployment, interoperability or audience benefit. The historical lesson is narrower and more useful: selective reliability moves a transport problem into a codec policy, and every added path creates a join condition that must be observed rather than assumed.

Sources

RFC 2448; RFC 2448 record; IETF Datatracker record; RFC 2448 errata; RFC 2250, RTP payload format for MPEG; RFC 3550, RTP; RFC 2198, redundant audio data; RFC 2733, RTP payload FEC; RFC 5109, RTP generic FEC; RFC 4588, RTP retransmission; RFC 1191, Path MTU discovery; RFC 1889, earlier RTP specification; Heng Lu, Running-Code Primacy; Heng Lu, specification and voluntary adoption.