From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5391.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc5391.txt (limited to 'doc/rfc/rfc5391.txt') diff --git a/doc/rfc/rfc5391.txt b/doc/rfc/rfc5391.txt new file mode 100644 index 0000000..d527257 --- /dev/null +++ b/doc/rfc/rfc5391.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group A. Sollaud +Request for Comments: 5391 France Telecom +Category: Standards Track November 2008 + + + RTP Payload Format for ITU-T Recommendation G.711.1 + +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 Notice + + Copyright (c) 2008 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 (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document specifies a Real-time Transport Protocol (RTP) payload + format to be used for the ITU Telecommunication Standardization + Sector (ITU-T) G.711.1 audio codec. Two media type registrations are + also included. + + + + + + + + + + + + + + + + + + + +Sollaud Standards Track [Page 1] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Background ......................................................2 + 3. RTP Header Usage ................................................3 + 4. Payload Format ..................................................4 + 4.1. Payload Header .............................................4 + 4.2. Audio Data .................................................5 + 5. Payload Format Parameters .......................................6 + 5.1. PCMA-WB Media Type Registration ............................7 + 5.2. PCMU-WB Media Type Registration ............................8 + 5.3. Mapping to SDP Parameters ..................................9 + 5.3.1. Offer-Answer Model Considerations ...................9 + 5.3.2. Declarative SDP Considerations .....................11 + 6. G.711 Interoperability .........................................11 + 7. Congestion Control .............................................12 + 8. Security Considerations ........................................12 + 9. IANA Considerations ............................................12 + 10. References ....................................................13 + 10.1. Normative References .....................................13 + 10.2. Informative References ...................................13 + +1. Introduction + + The ITU Telecommunication Standardization Sector (ITU-T) + Recommendation G.711.1 [ITU-G.711.1] is an embedded wideband + extension of the Recommendation G.711 [ITU-G.711] audio codec. This + document specifies a payload format for packetization of G.711.1 + encoded audio signals into the Real-time Transport Protocol (RTP). + + 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 [RFC2119]. + +2. Background + + G.711.1 is a G.711 embedded wideband speech and audio coding + algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is + fully interoperable with G.711. Hence, an efficient deployment in + existing G.711-based Voice over IP (VoIP) infrastructures is + foreseen. + + The codec operates on 5-ms frames, and the default sampling rate is + 16 kHz. Input and output at 8 kHz are also supported for narrowband + modes. + + + + + + +Sollaud Standards Track [Page 2] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + The encoder produces an embedded bitstream structured in three layers + corresponding to three available bit rates: 64, 80, and 96 kbps. The + bitstream can be truncated at the decoder side or by any component of + the communication system to adjust, "on the fly", the bit rate to the + desired value. + + The following table gives more details on these layers. + + +-------+------------------------+----------+ + | Layer | Description | Bit rate | + +-------+------------------------+----------+ + | L0 | G.711 compatible | 64 kbps | + | L1 | narrowband enhancement | 16 kbps | + | L2 | wideband enhancement | 16 kbps | + +-------+------------------------+----------+ + + Table 1: Layers description + + The combinations of these three layers results in the definition of + four modes, as per the following table. + + +------+----+----+----+------------+----------+ + | Mode | L0 | L1 | L2 | Audio band | Bit rate | + +------+----+----+----+------------+----------+ + | R1 | x | | | narrowband | 64 kbps | + | R2a | x | x | | narrowband | 80 kbps | + | R2b | x | | x | wideband | 80 kbps | + | R3 | x | x | x | wideband | 96 kbps | + +------+----+----+----+------------+----------+ + + Table 2: Modes description + +3. RTP Header Usage + + The format of the RTP header is specified in [RFC3550]. The payload + format defined in this document uses the fields of the header in a + manner consistent with that specification. + + marker (M): + G.711.1 does not define anything specific regarding Discontinuous + Transmission (DTX), a.k.a. silence suppression. Codec-independent + mechanisms may be used, like the generic comfort-noise payload + format defined in [RFC3389]. + + For applications that send either no packets or occasional + comfort-noise packets during silence, the first packet of a + talkspurt -- that is, the first packet after a silence period + during which packets have not been transmitted contiguously -- + + + +Sollaud Standards Track [Page 3] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + SHOULD be distinguished by setting the marker bit in the RTP data + header to one. The marker bit in all other packets is zero. The + beginning of a talkspurt MAY be used to adjust the playout delay + to reflect changing network delays. Applications without silence + suppression MUST set the marker bit to zero. + + payload type (PT): + The assignment of an RTP payload type for this packet format is + outside the scope of this document, and will not be specified + here. It is expected that the RTP profile under which this + payload format is being used will assign a payload type for this + codec or specify that the payload type is to be bound dynamically + (see Section 5.3). + + timestamp: + The RTP timestamp clock frequency is the same as the default + sampling frequency: 16 kHz. + + G.711.1 has also the capability to operate with 8-kHz sampled + input/output signals. It does not affect the bitstream, and the + decoder does not require a priori knowledge about the sampling + rate of the original signal at the input of the encoder. + Therefore, depending on the implementation and the audio acoustic + capabilities of the devices, the input of the encoder and/or the + output of the decoder can be configured at 8 kHz; however, a + 16-kHz RTP clock rate MUST always be used. + + The duration of one frame is 5 ms, corresponding to 80 samples at + 16 kHz. Thus, the timestamp is increased by 80 for each + consecutive frame. + +4. Payload Format + + The complete payload consists of a payload header of 1 octet, + followed by one or more consecutive G.711.1 audio frames of the same + mode. + + The mode may change between packets, but not within a packet. + +4.1. Payload Header + + The payload header is illustrated below. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |0 0 0 0 0| MI | + +-+-+-+-+-+-+-+-+ + + + + +Sollaud Standards Track [Page 4] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + The five most significant bits are reserved for further extension and + MUST be set to zero and MUST be ignored by receivers. + + The Mode Index (MI) field (3 bits) gives the mode of the following + frame(s) as per the table: + + +------------+--------------+------------+ + | Mode Index | G.711.1 mode | Frame size | + +------------+--------------+------------+ + | 1 | R1 | 40 octets | + | 2 | R2a | 50 octets | + | 3 | R2b | 50 octets | + | 4 | R3 | 60 octets | + +------------+--------------+------------+ + + Table 3: Modes in payload header + + All other values of MI are reserved for future use and MUST NOT be + used. + + Payloads received with an undefined MI value MUST be discarded. + + If a restricted mode-set has been set up by the signaling (see + Section 5), payloads received with an MI value not in this set MUST + be discarded. + +4.2. Audio Data + + After this payload header, the consecutive audio frames are packed in + order of time, that is, oldest first. All frames MUST be of the same + mode, indicated by the MI field of the payload header. + + Within a frame, layers are always packed in the same order: L0 then + L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode + R3. This is illustrated below. + + + + + + + + + + + + + + + + +Sollaud Standards Track [Page 5] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + +-------------------------------+ + R1 | L0 | + +-------------------------------+ + + +-------------------------------+--------+ + R2a | L0 | L1 | + +-------------------------------+--------+ + + +-------------------------------+--------+ + R2b | L0 | L2 | + +-------------------------------+--------+ + + +-------------------------------+--------+--------+ + R3 | L0 | L1 | L2 | + +-------------------------------+--------+--------+ + + The size of one frame is given by the mode, as per Table 3, and the + actual number of frames is easy to infer from the size of the audio + data part: + + nb_frames = (size_of_audio_data) / (size_of_one_frame). + + Only full frames must be considered. So if there is a remainder to + the division above, the corresponding remaining bytes in the received + payload MUST be ignored. + +5. Payload Format Parameters + + This section defines the parameters that may be used to configure + optional features in the G.711.1 RTP transmission. + + Both A-law and mu-law G.711 are supported in the core layer L0, but + there is no interoperability between A-law and mu-law. So two media + types with the same parameters will be defined: audio/PCMA-WB for + A-law core, and audio/PCMU-WB for mu-law core. This is consistent + with the audio/PCMA and audio/PCMU media types separation for G.711 + audio. + + The parameters are defined here as part of the media subtype + registrations for the G.711.1 codec. A mapping of the parameters + into the Session Description Protocol (SDP) [RFC4566] is also + provided for those applications that use SDP. In control protocols + that do not use MIME or SDP, the media type parameters must be mapped + to the appropriate format used with that control protocol. + + + + + + + +Sollaud Standards Track [Page 6] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + +5.1. PCMA-WB Media Type Registration + + This registration is done using the template defined in [RFC4288] and + following [RFC4855]. + + Type name: audio + + Subtype name: PCMA-WB + + Required parameters: none + + Optional parameters: + + mode-set: restricts the active codec mode set to a subset of all + modes. Possible values are a comma-separated list of modes + from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC + 5391). The modes are listed in order of preference; first is + preferred. If mode-set is specified, frames encoded with modes + outside of the subset MUST NOT be sent in any RTP payload. If + not present, all codec modes are allowed. + + ptime: the recommended length of time (in milliseconds) + represented by the media in a packet. It should be an integer + multiple of 5 ms (the frame size). See Section 6 of RFC 4566. + + maxptime: the maximum length of time (in milliseconds) that can + be encapsulated in a packet. It should be an integer multiple + of 5 ms (the frame size). See Section 6 of RFC 4566. + + Encoding considerations: This media type is framed and contains + binary data. See Section 4.8 of RFC 4288. + + Security considerations: See Section 8 of RFC 5391. + + Interoperability considerations: none + + Published specification: RFC 5391 + + Applications that use this media type: Audio and video conferencing + tools. + + Additional information: none + + Person & email address to contact for further information: Aurelien + Sollaud, aurelien.sollaud@orange-ftgroup.com + + Intended usage: COMMON + + + + +Sollaud Standards Track [Page 7] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + Restrictions on usage: This media type depends on RTP framing, and + hence is only defined for transfer via RTP. + + Author: Aurelien Sollaud + + Change controller: IETF Audio/Video Transport working group delegated + from the IESG + +5.2. PCMU-WB Media Type Registration + + This registration is done using the template defined in [RFC4288] and + following [RFC4855]. + + Type name: audio + + Subtype name: PCMU-WB + + Required parameters: none + + Optional parameters: + + mode-set: restricts the active codec mode-set to a subset of all + modes. Possible values are a comma-separated list of modes + from the set: 1, 2, 3, 4 (see Mode Index in Table 3 of RFC + 5391). The modes are listed in order of preference; first is + preferred. If mode-set is specified, frames encoded with modes + outside of the subset MUST NOT be sent in any RTP payload. If + not present, all codec modes are allowed. + + ptime: the recommended length of time (in milliseconds) + represented by the media in a packet. It should be an integer + multiple of 5 ms (the frame size). See Section 6 of RFC 4566. + + maxptime: the maximum length of time (in milliseconds) that can + be encapsulated in a packet. It should be an integer multiple + of 5 ms (the frame size). See Section 6 of RFC 4566. + + Encoding considerations: This media type is framed and contains + binary data. See Section 4.8 of RFC 4288. + + Security considerations: See Section 8 of RFC 5391. + + Interoperability considerations: none + + Published specification: RFC 5391 + + Applications that use this media type: Audio and video conferencing + tools. + + + +Sollaud Standards Track [Page 8] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + Additional information: none + + Person & email address to contact for further information: Aurelien + Sollaud, aurelien.sollaud@orange-ftgroup.com + + Intended usage: COMMON + + Restrictions on usage: This media type depends on RTP framing, and + hence is only defined for transfer via RTP. + + Author: Aurelien Sollaud + + Change controller: IETF Audio/Video Transport working group delegated + from the IESG + +5.3. Mapping to SDP Parameters + + The information carried in the media type specification has a + specific mapping to fields in the Session Description Protocol (SDP) + [RFC4566], which is commonly used to describe RTP sessions. When SDP + is used to specify sessions employing the G.711.1 codec, the mapping + is as follows: + + o The media type ("audio") goes in SDP "m=" as the media name. + + o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap" + as the encoding name. The RTP clock rate in "a=rtpmap" MUST be + 16000 for G.711.1. + + o The parameter "mode-set" goes in the SDP "a=fmtp" attribute by + copying it as a "mode-set=" string. + + o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and + "a=maxptime" attributes, respectively. + +5.3.1. Offer-Answer Model Considerations + + The following considerations apply when using SDP offer-answer + procedures [RFC3264] to negotiate the use of G.711.1 payload in RTP: + + o Since G.711.1 is an extension of G.711, the offerer SHOULD + announce G.711 support in its "m=audio" line, with G.711.1 + preferred. This will allow interoperability with both G.711.1 and + G.711-only capable parties. This is done by offering the PCMA + media subtype in addition to PCMA-WB, and/or PCMU in addition to + PCMU-WB. + + + + + +Sollaud Standards Track [Page 9] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + Below is an example part of such an offer, for A-law: + + m=audio 54874 RTP/AVP 96 8 + a=rtpmap:96 PCMA-WB/16000 + a=rtpmap:8 PCMA/8000 + + As a reminder, the payload format for G.711 is defined in Section + 4.5.14 of [RFC3551]. + + o The "mode-set" parameter is bi-directional; i.e., the restricted + mode-set applies to media both to be received and sent by the + declaring entity. If a mode-set was supplied in the offer, the + answerer MUST return either the same mode-set or a subset of this + mode-set. The answerer MAY change the preference order. If no + mode-set was supplied in the offer, the anwerer MAY return a mode- + set to restrict the possible modes. In any case, the mode-set in + the answer then applies for both offerer and answerer. The + offerer MUST NOT send frames of a mode that has been removed by + the answerer. + + For multicast sessions, if "mode-set" is supplied in the offer, + the answerer SHALL only participate in the session if it supports + the offered mode-set. + + o The parameters "ptime" and "maxptime" will in most cases not + affect interoperability. The SDP offer-answer handling of the + "ptime" parameter is described in [RFC3264]. The "maxptime" + parameter MUST be handled in the same way. + + o Any unknown parameter in an offer MUST be ignored by the receiver + and MUST NOT be included in the answer. + + Below are some example parts of SDP offer-answer exchanges. + + o Example 1 + + Offer: G.711.1 all modes, with G.711 fallback, prefers mu-law + m=audio 54874 RTP/AVP 96 97 0 8 + a=rtpmap:96 PCMU-WB/16000 + a=rtpmap:97 PCMA-WB/16000 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + + Answer: all modes accepted, both mu- and A-law. + m=audio 59452 RTP/AVP 96 97 + a=rtpmap:96 PCMU-WB/16000 + a=rtpmap:97 PCMA-WB/16000 + + + + +Sollaud Standards Track [Page 10] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + + o Example 2 + + Offer: G.711.1 all modes, with G.711 fallback, prefers A-law + m=audio 54874 RTP/AVP 96 97 8 0 + a=rtpmap:96 PCMA-WB/16000 + a=rtpmap:97 PCMU-WB/16000 + + Answer: wants only A-law mode R3 + m=audio 59452 RTP/AVP 96 + a=rtpmap:96 PCMA-WB/16000 + a=fmtp:96 mode-set=4 + + o Example 3 + + Offer: G.711.1 A-law with two modes, R2b and R3, with R3 preferred + m=audio 54874 RTP/AVP 96 + a=rtpmap:96 PCMA-WB/16000 + a=fmtp:96 mode-set=4,3 + + Answer: accepted + m=audio 59452 RTP/AVP 96 + a=rtpmap:96 PCMA-WB/16000 + a=fmtp:96 mode-set=4,3 + + If the answerer had wanted to restrict to one mode, it would have + answered with only one value in the mode-set, for example mode- + set=3 for mode R2b. + +5.3.2. Declarative SDP Considerations + + For declarative use of SDP, nothing specific is defined for this + payload format. The configuration given by the SDP MUST be used when + sending and/or receiving media in the session. + +6. G.711 Interoperability + + The L0 layer of G.711.1 is fully interoperable with G.711, and is + embedded in all modes of G.711.1. This provides an easy G.711.1 - + G.711 transcoding process. + + A gateway or any other network device receiving a G.711.1 packet can + easily extract a G.711-compatible payload, without the need to decode + and re-encode the audio signal. It simply has to take the audio data + of the payload, and strip the upper layers (L1 and/or L2), if any. + + If a G.711.1 packet contains several frames, the concatenation of the + L0 layers of each frame will form a G.711-compatible payload. + + + + +Sollaud Standards Track [Page 11] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + +7. Congestion Control + + Congestion control for RTP SHALL be used in accordance with [RFC3550] + and any appropriate profile (for example, [RFC3551]). + + The embedded nature of G.711.1 audio data can be helpful for + congestion control, since a coding mode with a lower bit rate can be + selected when needed. This property is usable only when multiple + modes have been negotiated (either no "mode-set" parameter in the SDP + or a "mode-set" with at least two modes). + + The number of frames encapsulated in each RTP payload influences the + overall bandwidth of the RTP stream, due to the header overhead. + Packing more frames in each RTP payload can reduce the number of + packets sent and hence the header overhead, at the expense of + increased delay and reduced error robustness. + +8. Security Considerations + + RTP packets using the payload format defined in this specification + are subject to the general security considerations discussed in the + RTP specification [RFC3550] and any appropriate profile (for example, + [RFC3551]). + + As this format transports encoded speech/audio, the main security + issues include confidentiality, integrity protection, and + authentication of the speech/audio itself. The payload format itself + does not have any built-in security mechanisms. Any suitable + external mechanisms, such as the Secure Real-time Transport Protocol + (SRTP) [RFC3711], MAY be used. + + This payload format and the G.711.1 encoding do not exhibit any + significant non-uniformity in the receiver-end computational load, + and thus they are unlikely to pose a denial-of-service threat due to + the receipt of pathological datagrams. In addition, they do not + contain any type of active content such as scripts. + +9. IANA Considerations + + Two new media subtypes (audio/PCMA-WB and audio/PCMU-WB) have been + registered by IANA. See Sections 5.1 and 5.2. + + + + + + + + + + +Sollaud Standards Track [Page 12] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + +10. References + +10.1. Normative References + + [ITU-G.711.1] International Telecommunications Union, "Wideband + embedded extension for G.711 pulse code modulation", + ITU-T Recommendation G.711.1, March 2008. + + [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. + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio + and Video Conferences with Minimal Control", STD 65, + RFC 3551, July 2003. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications + and Registration Procedures", BCP 13, RFC 4288, + December 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, February 2007. + +10.2. Informative References + + [ITU-G.711] International Telecommunications Union, "Pulse code + modulation (PCM) of voice frequencies", ITU-T + Recommendation G.711, November 1988. + + [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload + for Comfort Noise (CN)", RFC 3389, September 2002. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and + K. Norrman, "The Secure Real-time Transport Protocol + (SRTP)", RFC 3711, March 2004. + + + + + + +Sollaud Standards Track [Page 13] + +RFC 5391 RTP Payload Format for G.711.1 November 2008 + + +Author's Address + + Aurelien Sollaud + France Telecom + 2 avenue Pierre Marzin + Lannion Cedex 22307 + France + + Phone: +33 2 96 05 15 06 + EMail: aurelien.sollaud@orange-ftgroup.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sollaud Standards Track [Page 14] + -- cgit v1.2.3