RFC 5577

RTP Payload Format for ITU-T Recommendation G.722.1

📅 published July 2009, from ietf

RTP Payload Format for ITU-T Recommendation G.722.1 🎀

RFC 5577 💖

Title: RTP Payload Format for ITU-T Recommendation G.722.1 Authors: P. Luthi (Tandberg) and R. Even (Gesher Erove Ltd) ✨ Category: Standards Track 🦋 Date: July 2009 🌸 Obsoletes: RFC 3047 💅 Updates: nothing (this one doesn't update any other RFCs) 🧚 Stream: Network Working Group 🫶

Abstract ✨

okay so ITU-T Recommendation G.722.1 is a wide-band audio codec 🎧 this doc explains how to pack G.722.1 bit streams into an RTP packet 📦 it also covers the SDP parameters you need to actually set up a G.722.1 audio call 📞 literally everything you need in one place 💅

Status of This Memo 🌈

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💜

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 📜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🙈

Table of Contents 🍓

1. Introduction ....................................................2
2. Terminology .....................................................3
3. RTP Usage for G.722.1 ...........................................3
   3.1. RTP G.722.1 Header Fields ..................................3
   3.2. RTP Payload Format for G.722.1 .............................3
   3.3. Multiple G.722.1 Frames in an RTP Packet ...................5
   3.4. Computing the Number of G.722.1 Frames .....................6
4. IANA Considerations .............................................6
   4.1. Media Type Registration ....................................6
        4.1.1. Registration of Media Type audio/G7221 ..............6
5. SDP Parameters ..................................................8
   5.1. Usage with the SDP Offer/Answer Model ......................8
6. Security Considerations .........................................8
7. Changes from RFC 3047 ...........................................9
8. Acknowledgments .................................................9
9. References ......................................................9
   9.1. Normative References .......................................9
   9.2. Informative References ....................................10

1. Introduction 🧚

okay so [ITU.G7221] is a low-complexity coder that squishes 50 Hz - 14 kHz audio signals into one of these bit rates: 24 kbit/s, 32 kbit/s, or 48 kbit/s 🎶

it's giving versatile 💅 the coder works for speech, music, and other kinds of audio ✨

it's super suitable for stuff like:

  • Real-time communications such as videoconferencing and telephony 📞
  • Streaming audio 🎧
  • Archival and messaging 💌

[ITU.G7221] uses 20-ms frames and a sampling rate clock of 16 kHz or 32kHz 🦋 the encoding and decoding algorithm can change the bit rate at any 20-ms frame boundary, but no bit rate change notification is provided in-band with the bit stream 👀 so the change has to be signaled some other way 😭

for any given bit rate, the number of bits in a frame is a constant 💖 inside that fixed frame, G.722.1 uses variable-length coding (e.g., Huffman coding) to represent most of the encoded parameters 🧩 all the variable-length codes get sent from the leftmost bit (most significant bit -- MSB) to the rightmost bit (least significant bit -- LSB), see [ITU.G7221] for more details 🔥

the ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s, or 48 kbit/s at 32 Khz sample rate 🌸 but the coding algorithm itself can run at any user-specified bit rate (not just 24, 32, and 48 kbit/s) while still keeping an audio bandwidth of 50 Hz to 14 kHz 🤯 this rate change works by linearly scaling the codec operation, so frames end up with a size in bits equal to 1/50 of the corresponding bit rate ✨ this is so iconic ngl 👑

2. Terminology 💜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations 📜 these are the official vibes checks for how strict each rule is 🫶

3. RTP Usage for G.722.1 🦋

3.1. RTP G.722.1 Header Fields 🎀

the RTP header is defined in the RTP specification [RFC3550] 📖 this section explains how the fields in that header get used for G.722.1 ✨

  • Payload Type (PT): assigning an RTP payload type for this packet format is outside the scope of this document 🙈 it gets specified by the RTP profile this payload format is used under, or it's signaled dynamically out-of-band (e.g., using SDP) 🧚
  • Marker (M) bit: the M bit is set to zero 💅
  • Extension (X) bit: defined by the RTP profile used 🌈
  • Timestamp: a 32-bit word that corresponds to the sampling instant for the first frame in the RTP packet ⏰ the sampling frequency can be 16 Khz or 32 Khz 🎶 the RTP timestamp clock frequency of 32 Khz SHOULD be used unless only an RTP stream sampled at 16 Khz is going to be sent 💖

3.2. RTP Payload Format for G.722.1 🌸

the RTP payload for G.722.1 has the format shown in Figure 1 ✨ no extra header fields specific to this payload format are required, so it's giving minimalism 💅

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      RTP Header                               |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                                                               |
 +                 one or more frames of G.722.1                 |
 |                             ....                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: RTP payload for G.722.1.

because the bit rate isn't signaled in-band, a separate out-of-band method is REQUIRED to indicate the bit rate (see Section 5 for an example of signaling bit rate information using SDP) 📣 for the payload format specified here, the bit rate MUST remain constant for a particular payload type value 🔒 an application MAY switch bit rates and clock rates from packet to packet by defining different payload type values and switching between them 🔀

the use of Huffman coding means you can't identify the various encoded parameters/fields inside the bit stream without fully decoding the entire frame first 😵‍💫 for packetizing the bit stream in RTP, it's only necessary to consider the sequence of bits as output by the G.722.1 encoder and to present the same sequence to the decoder 🧠 the payload format described here keeps this sequence intact 🫶

when operating at 24 kbit/s, 480 bits (60 octets) are produced per frame 🍓 when operating at 32 kbit/s, 640 bits (80 octets) are produced per frame 🌷 when operating at 48 kbit/s, 960 bits (120 octets) are produced per frame 🌈 so all three bit rates allow for octet alignment without needing any padding bits 🎀

Figure 2 shows how the G.722.1 bit stream MUST be mapped into an octet-aligned RTP payload 🧚

      first bit                                          last bit
      transmitted                                     transmitted
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                         |
      + sequence of bits (480, 640, or 960) generated by the    |
      |            G.722.1 encoder for transmission             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      |           |           |                     |           |
      |           |           |     ...             |           |
      |           |           |                     |           |


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
      |MSB...  LSB|MSB...  LSB|                     |MSB...  LSB|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
        RTP         RTP                               RTP
        octet 1     octet 2                           octet
                                                   60, 80, 120

        Figure 2:  The G.722.1 encoder bit stream is split into
                   a sequence of octets (60, 80, or 120 depending on
                   the bit rate), and each octet is in turn
                   mapped into an RTP octet.

when operating at non-standard rates, the payload format MUST follow the guidelines illustrated in Figure 2 🛠️ it is RECOMMENDED that values in the range 16000 to 48000 be used 💫 non-standard rates MUST have a value that is a multiple of 400 🔢 this keeps octet alignment, so you don't end up needing (undefined) padding bits for each frame when it isn't octet aligned 🙌 for example, a bit rate of 16.4 kbit/s will result in a frame of size 328 bits or 41 octets, which is mapped into RTP per Figure 2 🦋

3.3. Multiple G.722.1 Frames in an RTP Packet 📦

a sender may include more than one consecutive G.722.1 frame in a single RTP packet ✨

senders have these extra restrictions:

  • Sender SHOULD NOT include more G.722.1 frames in a single RTP packet than will fit in the MTU of the RTP transport protocol 🚫
  • All frames contained in a single RTP packet MUST be of the same length and sampled at the same clock rate. They MUST have the same bit rate (octets per frame) 💅
  • Frames MUST NOT be split between RTP packets 🙅‍♀️

it is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application 🎯 for example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay 📞 but for a delay-insensitive streaming or messaging application, many frames per packet would be acceptable 🍿

3.4. Computing the Number of G.722.1 Frames ✨

Okay so here's the wild part 🫣: the RTP payload doesn't tell you how many G.722.1 frames are in it. Nowhere. The only way to figure it out is to count all the octets in the RTP packet and divide by the number of octets you expect per frame. And that expected count comes from the bit rate, which means it depends on the payload type. Math is the vibe here 🧮💖

4. IANA Considerations 🌸

This document updates the G7221 media type described in RFC 3047. Bestie, this is the registry moment 💅

4.1. Media Type Registration 🎀

This section covers the media types and names tied to this payload format. It registers the media types as per RFC 4288 [RFC4288].

4.1.1. Registration of Media Type audio/G7221 🦋

Media type name: audio

Media subtype name: G7221

Required parameters:

  • bitrate: the data rate for the audio bit stream. This one is mandatory, because the bit rate isn't signaled within the G.722.1 bit stream 🙈 At the standard G.722.1 bit rates, the value MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 32000, or 48000 at 32 Khz sample rate. If you're using non-standard bit rates, then it is RECOMMENDED that values in the range 16000 to 48000 be used. Non-standard rates MUST have a value that is a multiple of 400. This keeps things octet aligned, so you don't need (undefined) padding bits for each frame when it isn't octet aligned 🧸

Optional parameters:

  • rate: RTP timestamp clock rate, which is equal to the sampling rate. If the parameter isn't specified, a clock rate of 16 Khz is assumed 🌈
  • ptime: see RFC 4566. SHOULD be a multiple of 20 ms.
  • maxptime: see RFC 4566. SHOULD be a multiple of 20 ms.

Encoding considerations:

This media type is framed and binary, see Section 4.8 in [RFC4288].

Security considerations: See Section 6 🔐

Interoperability considerations:

Terminals SHOULD offer a media type at 16 Khz sample rate so they can interoperate with terminals that don't support the new 32 Khz sample rate. Main character energy for backwards compatibility 👑

Published specification: RFC 5577.

Applications that use this media type:

Audio and Video streaming and conferencing applications 🎧

Additional information: none

Person and email address to contact for further information:

Roni Even: ron.even.tlv@gmail.com

Intended usage: COMMON

Restrictions on usage:

This media type depends on RTP framing, so it's only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time 🚫

Author: Roni Even ✨

Change controller:

IETF Audio/Video Transport working group, delegated from the IESG.

5. SDP Parameters 🧚

The media types audio/G7221 get mapped to fields in the Session Description Protocol (SDP) [RFC4566] like this:

  • The media name in the "m=" line of SDP MUST be audio.
  • The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the media subtype).
  • The parameter "rate" goes in "a=rtpmap" as the clock rate parameter.
  • Only one bitrate SHALL be defined (using the "bitrate=" parameter in the a=fmtp line) for each payload type. One bitrate per payload type, periodt 💜

5.1. Usage with the SDP Offer/Answer Model 🍓

When you offer G.722.1 over RTP using SDP in an Offer/Answer model [RFC3264], these considerations come into play 👀

The combo of the clock rate in the rtpmap and the bitrate parameter defines the configuration of each payload type. Each configuration intended to be used MUST be declared. No sneaky undeclared configs 🙅‍♀️

There are two sampling clock rates defined for G.722.1 in this document. RFC 3047 [RFC3047] only supports the 16 Khz clock rate. So a system that wants to use G.722.1 SHOULD offer a payload type with clock rate of 16000 for backward interoperability 🫶

Here's an example of an offer that includes both the 16000 and 32000 clock rates:

m=audio 49000 RTP/AVP 121 122
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:122 G7221/32000
a=fmtp:122 bitrate=48000

6. Security Considerations 🔐💀

Okay, this section is serious, so read it carefully ⚠️

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined in this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity-protection mechanism. That cryptographic system may also allow the authentication of the payload's source. A suitable security mechanism for this payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining whether an RTP packet is from a member of the RTP session.

Note that the right mechanism for securing RTP and payloads following this memo may vary. It depends on the application, the transport, and the signaling protocol employed. So a single mechanism is not sufficient. Although, if it's suitable, using the Secure Real-time Transport Protocol (SRTP) is [RFC3711] recommended. Another mechanism that may be used is IPsec [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP). Other alternatives may exist 🧐

This RTP payload format and its media decoder don't show any significant non-uniformity in receiver-side computational complexity for packet processing, so they're unlikely to pose a denial-of-service threat from receiving pathological data. And the RTP payload format doesn't contain any active content ✨

7. Changes from RFC 3047 🔄

This specification obsoletes RFC 3047, adding support for the Superwideband (14 Khz) audio defined in annex C of the new revision of ITU-T G.722.1. Big upgrade energy 📈

Other changes:

Updated the text to match the current rules for RFCs, and media type registration now conforms to RFC 4288 📝

8. Acknowledgments 🫶

The authors would like to thank Tom Taylor for his contribution to this work. Thank you, Tom 🌷

9. References 📚

9.1. Normative References

[ITU.G7221] International Telecommunications Union, "Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss", ITU-T Recommendation G.722.1, 2005.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

9.2. Informative References

[RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation G.722.1", RFC 3047, January 2001.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Authors' Addresses 🏡

Patrick Luthi
Tandberg
Philip Pedersens vei 22
1366 Lysaker
Norway

EMail: patrick.luthi@tandberg.no
Roni Even
Gesher Erove Ltd
14 David Hamelech
Tel Aviv  64953
Israel

EMail: ron.even.tlv@gmail.com
📦 where this page comes from