Summary

  • RFC 3119's SDP instruction said mp3, although its registered media subtype and adjacent rtpmap example said mpa-robust; RFC 5219 made the encoding name consistent.
  • The successor retained the ADU-based RTP payload design and described its pseudocode edits as minor, non-normative clarifications. The standards record does not show whether deployed software used the inconsistent label or whether any session failed.

One name in the description, another in the example

The contradiction is small enough to miss on a quick read. RFC 3119, published in 2001, registers mpa-robust as the media subtype for its MP3 payload format. Yet its SDP section says that the encoding name SHALL be mp3. Immediately below, the example assigns dynamic payload type 121 and writes a=rtpmap:121 mpa-robust/90000.

Those lines describe the same format at different surfaces. RTP carries numbered payload types; for a dynamic number, an SDP rtpmap attribute tells the other endpoint which encoding and clock rate the number denotes. RFC 4566 defines that mapping. RFC 3119 therefore gave readers two incompatible names for the session-level description, even though its media subtype and worked mapping agreed with one another.

That distinction matters more than the short string suggests. A payload-type number is not self-explanatory. The endpoints need a shared mapping between the number in RTP packets and the encoding expected by the receiver. A format can have a coherent packet layout yet still be described inconsistently at the setup boundary. The document demonstrates a specification defect; it does not show what any real endpoint did with it.

Why the payload format existed

The original design addressed a specific property of MP3 Layer III. An MP3 frame can point backward into encoded data carried by earlier frames, so one frame is not always an independent decoder unit. RFC 3119 argued that ordinary frame-aligned RTP packets could make a lost packet damage the usefulness of data in other frames that arrived intact.

Its alternative rearranged the stream into Application Data Units (ADUs). Each ADU was preceded by a descriptor that stated its size and whether the data continued from another packet. Senders could optionally interleave ADUs so consecutive units travelled in non-consecutive packets. The proposal was not just “add redundancy”: it changed where packet boundaries fell relative to the decoder's data units while preserving the encoded information.

RFC 5219, issued in February 2008, republishes that basic approach. Its introduction again explains the back-pointer problem, ADUs, descriptors and optional interleaving. The successor's abstract says it obsoletes RFC 3119 to correct typographical errors in the SDP section and pseudocode appendices. Appendix C is even more precise: correcting the SDP encoding name is the primary change; Appendix A and B receive minor fixes and clarifications to non-normative pseudocode.

The correction is explicit. RFC 5219 says the SDP encoding name SHALL be mpa-robust, matching the registered media subtype, and its example maps dynamic payload type 121 to mpa-robust/90000. An RFC Editor verified erratum for RFC 3119 also records the underlying discrepancy and several code-example repairs: a backpointer is a value, not a size; one variable should be prevADU, not curADU; and two deinterleaving bounds should be 256 rather than 32. These clarify the written recipe. They are not evidence that deployed payloads changed after 2008.

A revision number is not an incident report

RFC 5219 gives a useful record of how standards can be repaired at more than one layer. The SDP name is normative session-description guidance: a correction there changes what the specification tells participants to call the encoding. The appendix edits concern sample pseudocode that RFC 5219 itself labels non-normative. Neither fact, alone, establishes the size of an operational problem.

The documents contain no implementation census, packet trace, failed call, vendor release note or before-and-after test. They do not say that an endpoint actually advertised mp3, that another endpoint rejected it, or that correcting the spelling improved interoperability in measured deployments. Even an erratum accepted by the RFC Editor proves a defect in the record, not how often software reproduced it.

That is the historical boundary worth keeping. RFC 5219 superseded a document because its session-description instruction needed correction and some implementation guidance needed repair. It retained the ADU payload model. The publication tells us what standards authors corrected; answering whether the correction mattered in live systems would require separate evidence from implementations and sessions.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3119.html
  2. https://www.rfc-editor.org/info/rfc3119/
  3. https://www.rfc-editor.org/rfc/rfc5219.html
  4. https://www.rfc-editor.org/info/rfc5219/
  5. https://datatracker.ietf.org/doc/rfc5219/
  6. https://www.rfc-editor.org/errata/eid331
  7. https://www.rfc-editor.org/rfc/rfc4566.html
  8. https://www.rfc-editor.org/rfc/rfc2250.html
  9. https://www.rfc-editor.org/rfc/rfc3550.html
  10. https://www.rfc-editor.org/rfc/rfc3551.html
  11. https://www.rfc-editor.org/rfc/rfc2736.html