Network Working Group R. Zopf Request for Comments: 3389 Lucent Technologies Category: Standards Track September 2002 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) 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) The Internet Society (2002). All Rights Reserved.
AbstractThis document describes a Real-time Transport Protocol (RTP) payload format for transporting comfort noise (CN). The CN payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711, G.726, G.727, G.728, and G.722. RFC-2119 . 1] payload format for transporting comfort noise. The payload format is based on Appendix II of ITU-T Recommendation G.711  which defines a comfort noise payload format (or bit-stream) for ITU-T G.711  use in packet-based multimedia communication systems. The payload format is generic and may also be used with other audio codecs without built-in Discontinuous Transmission (DTX) capability such as ITU-T Recommendations G.726 , G.727 , G.728 , and G.722 . The payload format provides a minimum interoperability specification for communication of comfort noise parameters. The comfort noise analysis and synthesis as well as the Voice Activity Detection (VAD) and DTX algorithms are unspecified and left implementation-specific.
However, an example solution for G.711 has been tested and is described in the Appendix . It uses the VAD and DTX of G.729 Annex B  and a comfort noise generation algorithm (CNG) which is provided in the Appendix for information. The comfort noise payload, which is also known as a Silence Insertion Descriptor (SID) frame, consists of a single octet description of the noise level and MAY contain spectral information in subsequent octets. An earlier version of the CN payload format consisting only of the noise level byte was defined in draft revisions of the RFC 1890. The extended payload format defined in this document should be backward compatible with implementations of the earlier version assuming that only the first byte is interpreted and any additional spectral information bytes are ignored. Figure 1. The least significant bit of the noise level magnitude is packed into the least significant bit of the byte. The noise level is expressed in -dBov, with values from 0 to 127 representing 0 to -127 dBov. dBov is the level relative to the overload of the system. (Note: Representation relative to the overload point of a system is particularly useful for digital implementations, since one does not need to know the relative calibration of the analog circuitry.) For example, in the case of a u-law system, the reference would be a square wave with values +/- 8031, and this square wave represents 0dBov. This translates into 6.18dBm0.
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| level | +-+-+-+-+-+-+-+-+ Figure 1: Noise Level Packing 8]. Each reflection coefficient can have values between -1 and 1 and is quantized uniformly using 8 bits. The quantized value is represented by the 8 bit index N, where N=0..,254, and index N=255 is reserved for future use. Each index N is packed into a separate byte with the MSB first. The quantized value of each reflection coefficient, k_i, can be obtained from its corresponding index using: k_i(N_i) = 258*(N_i-127) for N_i = 0...254; -1 < k_i < 1 ------------- 32768 Figure 1. Quantized reflection coefficients are packed in subsequent bytes in ascending order as in Figure 2 where M is the model order. The total length of the payload is M+1 bytes. Note that a 0th order model (i.e., no spectral envelope information) reduces to transmitting only the energy level. Byte 1 2 3 ... M+1 +-----+-----+-----+-----+-----+ |level| N1 | N2 | ... | NM | +-----+-----+-----+-----+-----+ Figure 2: CN Payload Packing Format RFC 1890 , a static payload type of 13 is assigned for RTP timestamp clock rate of 8,000 Hz; if other rates are needed, they MUST be defined through dynamic payload types. The RTP packet SHOULD NOT have the marker bit set.
Each RTP packet containing comfort noise MUST contain exactly one CN payload per channel. This is required since the CN payload has a variable length. If multiple audio channels are used, each channel MUST use the same spectral model order 'M'. 8]. It uses the VAD and DTX of G.729 Annex B  and a comfort noise generation algorithm (CNG), which is provided in the Appendix for information. Additional guidelines for use such as the factors affecting system performance in the design of the VAD/DTX/CNG algorithms are described in the Appendix. 11] to specify RTP payload information, the use of comfort noise is indicated by the inclusion of a payload type for CN on the media description line. When using CN with the RTP/AVP profile  and a codec whose RTP timestamp clock rate is 8000 Hz, such as G.711 (PCMU, static payload type 0), the static payload type 13 for CN can be used: m=audio 49230 RTP/AVP 0 13
When using CN with a codec that has a different RTP timestamp clock rate, a dynamic payload type mapping (rtpmap attribute) is required. This example shows CN used with the G.722.1 codec (see RFC 3047 ): m=audio 49230 RTP/AVP 101 102 a=rtpmap:101 G7221/16000 a=fmtp:121 bitrate=24000 a=rtpmap:102 CN/16000 Omission of a payload type for CN on the media description line implies that this comfort noise payload format will not be used, but it does not imply that silence will not be suppressed. RTP allows discontinuous transmission (silence suppression) on any audio payload format. The receiver can detect silence suppression on the first packet received after the silence by observing that the RTP timestamp is not contiguous with the end of the interval covered by the previous packet even though the RTP sequence number has incremented only by one. The RTP marker bit is also normally set on such a packet.
Encoding considerations: This type is only defined for transfer via RTP [RFC 1889]. Security considerations: see Section 7 "Security Considerations". Interoperability considerations: none Published specification: This document and Appendix II of ITU-T Recommendation G.711 Applications which use this media type: Audio and video streaming and conferencing tools. Additional information: none Person & email address to contact for further information: Robert Zopf firstname.lastname@example.org Intended usage: COMMON Author/Change controller: Author: Robert Zopf Change controller: IETF AVT Working Group 1]. This implies that confidentiality of the media streams is achieved by encryption. Because the payload format is arranged end-to-end, encryption MAY be performed after encapsulation so there is no conflict between the two operations. As this format transports background noise, there are no significant security, confidentiality, or authentication concerns.  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.  ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) of voice frequencies.
 ITU Recommendation G.726 (12/90) - 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).  ITU Recommendation G.727 (12/90) - 5-, 4-, 3- and 2-bits sample embedded adaptive differential pulse code modulation (ADPCM).  ITU Recommendation G.728 (09/92) - Coding of speech at 16 kbits/s using low-delay code excited linear prediction.  ITU Recommendation G.722 (11/88) - 7 kHz audio-coding within 64 kbit/s.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Appendix II to Recommendation G.711 (02/2000) - A comfort noise payload definition for ITU-T G.711 use in packet-based multimedia communication systems.  Annex B (08/97) to Recommendation G.729 - C source code and test vectors for implementation verification of the algorithm of the G.729 silence compression scheme.  Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.  Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.  Luthi, P., "RTP Payload Format for ITU-T Recommendation G.722.1", RFC 3047, January 2001.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.