Summary

  • RFC 5577 replaced the earlier RTP payload specification to support G.722.1 Annex C’s 14 kHz audio, a 32 kHz sampling clock and a 48 kbit/s mode.
  • It did not prescribe a clean break: the RFC recommends offering the older 16 kHz profile for backward interoperability, while requiring each intended clock-rate and bitrate configuration to be declared through SDP.

The successor did not erase its predecessor’s peers

When RFC 5577 appeared in July 2009, its header said it “Obsoletes: 3047.” The wording can sound like a switch was thrown: one specification out, the next one in. But the document’s interoperability section tells a more practical story. RFC 3047 had described G.722.1 with a 16 kHz sampling clock. The later revision added support for the superwideband audio defined in Annex C of the revised ITU-T recommendation, extending the audio bandwidth to 14 kHz and adding a 32 kHz clock configuration and a 48 kbit/s rate.

Those are separate measurements. The 14 kHz figure describes the encoded audio bandwidth; 16 or 32 kHz is the sampling clock used for RTP timestamps; 24, 32 or 48 kbit/s describes the codec’s encoded rate. RFC 5577 did not turn those dimensions into a single “quality” setting. It gave session signaling a way to name a usable combination.

The codec bitstream carried no in-band notice when its bitrate changed. RFC 5577 therefore required a separate signaling method and held the bitrate constant for each RTP payload type. An application could switch profiles from packet to packet, but only by assigning distinct payload-type values. In SDP, the a=rtpmap line identifies the encoding and clock rate; a=fmtp supplies the bitrate. The combination describes the configuration the receiving side is being asked to understand.

The Offer/Answer rules made that declaration consequential. RFC 5577 says every configuration an offerer intends to use must be declared. It then notes the compatibility gap directly: the old RFC supported only the 16 kHz clock, so a system seeking interoperability should offer a 16 kHz payload type as well. The sample offer lists both a 16 kHz/24 kbit/s option and a 32 kHz/48 kbit/s option under separate payload types.

That does not mean every older terminal could negotiate successfully, nor that the newer profile automatically fell back. An offer is a statement of supported choices, not proof of the answer or of audio reaching a listener. The receiving endpoint still has to select a configuration it supports, and the session has to carry the agreed profile. RFC 5577 preserved a path; it did not certify who used it.

The packet format kept another boundary intact. Frames remained 20 milliseconds long. At standard rates, each frame occupied 60, 80 or 120 octets. A packet could aggregate consecutive frames, but they had to share bitrate and clock rate, and a frame could not straddle packets. The number of frames was inferred from payload length and the expected size per frame rather than announced in an extra payload header. RFC 5577 recommended fewer frames where delay mattered and allowed more where streaming or messaging could tolerate it. It set no universal latency figure.

Read as a migration document, RFC 5577 is less about “new codec replaces old codec” than about keeping the choice legible. Its Obsoletes line replaced the specification. The 16 kHz offer kept the older compatibility boundary visible. Neither statement, by itself, tells us how many endpoints implemented either side.

Sources