Summary

  • RFC 3555 made one registered media name portable between a MIME-style expression and SDP only by prescribing where the type, subtype, clock rate, channel count, packet-time advice and format-specific parameters had to go.
  • A valid registry entry and a syntactically correct SDP description did not prove that an endpoint implemented the payload format, accepted the session-local payload-number binding, received conforming packets or decoded useful media.

The most revealing line in RFC 3555 is not a codec name. It is an example:

audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15

Nothing in that line could simply be pasted into an RTP packet. To describe an RTP session, the standard split it into several places. audio became the media name on the SDP m= line. L16, the clock rate and the channel count became a=rtpmap:97 L16/48000/2. The format-specific emphasis setting went to a=fmtp:97 emphasis=50-15. Packet-time advice became a=ptime:5.

The number 97 did not come from the media-type registry. It was a dynamic payload type selected for that session. Its meaning existed only because the session description bound 97 to L16 with a particular clock and channel arrangement. Another session could use 97 for something else, or use another dynamic number for the same L16 format. The reusable identity was the registered format name and specification; the number was local coordination.

That separation was the design achievement. A common name could cross from a MIME-style content description into SDP, but its fields did not move as an undifferentiated blob. Every field had a destination chosen for the role it played.

One expression, four destinations

RFC 3555 assigned the top-level type to SDP's media line and the subtype to rtpmap. It put rate and channels beside the encoding name because those values determine the RTP timestamp clock and encoding parameters. It put ptime and maxptime in independent SDP attributes because they describe recommended or maximum media duration per packet rather than codec identity. It sent codec-specific material to fmtp, whose purpose was to convey opaque format parameters to the media tool.

This was not formatting trivia. If a gateway placed ptime inside an invented codec string, copied a clock rate into the wrong position, or treated fmtp as self-describing, two systems could display the same subtype and still disagree about the packets. The standard made translation inspectable.

It also drew an authority boundary. The set of allowed payload-format-specific parameters came from the RFC that specified the payload format. A MIME subtype registration could document how those parameters mapped into fmtp; it could not extend the set without a corresponding revision of the payload specification. The registry was not an escape hatch for changing running wire semantics.

Case folding did less than it appeared

RTP profile names were often printed in uppercase while media subtypes were commonly lowercase. RFC 3555 therefore made the encoding name case-insensitive in both positions. Parameter names were also case-insensitive in the media-type expression and the default fmtp mapping.

That rule did not make every value interchangeable. The grammar and the payload-format specification still governed parameter values. A parser that lowercased an opaque value because it had correctly lowercased the parameter name would cross a boundary the standard did not erase. Shared spelling reduced superficial mismatch; it did not eliminate semantic typing.

Registration, session binding and execution

The registration procedure required a published payload-format specification, including the RTP timestamp clock rate or rates. It allowed a type to be used over RTP and, when feasible, over other transports, but required the registration to say which parameters applied to which mode. Even in 2003, the name was not a universal promise that all transfer methods used identical framing.

The later repair is instructive. RFC 4855 and RFC 4856 obsoleted RFC 3555. RFC 4855 kept the mapping procedure, updated it to revised media-type rules and stated more explicitly when an RTP and a non-RTP file transfer could share a subtype. The data formats had to be equivalent under its stated test, and the required parameter sets had to match. Otherwise, separate types were required. RFC 4856 extracted the concrete RTP profile registrations and said the extraction made no technical change to them.

The standard was split because procedure, registration records and payload specifications had different maintenance lives. The current IANA snapshot still shows names such as audio/L16, audio/PCMA and audio/PCMU pointing to RFC 4856. In the frozen 2026-10-06 XML, the audio registry contains 165 records and the video registry 97; twenty records cite RFC 4856 directly. Those figures describe the registry on that date. They say nothing about the codecs installed on a particular device.

RFC 8866, today's SDP specification in the frozen source packet, preserves the architecture. rtpmap binds a payload type number to an encoding name, clock rate and encoding parameters. fmtp passes format-specific parameters without requiring SDP to understand them. A current parser can therefore reproduce the mapping discipline while still failing later: the endpoint may not implement the codec, may reject a parameter combination, may receive malformed packets, or may decode audio no application can use.

The evidence ladder matters. First ask whether a parser accepted the media-type string. Then ask whether the subtype was registered and allowed for the intended transport. Then verify that every parameter reached the correct SDP field. Then verify the session-local payload-number binding. Only after that come endpoint capability, packet conformance, decoding and application result.

RFC 3555's historical lesson is not that names solve interoperability. It is that a name becomes interoperable only when every context change has an explicit, reviewable map—and when the registry declines to impersonate the implementation that must finally run it.

Sources