Internet Engineering Task Force Johan Sjoberg, Ericsson Audio Video Transport WG Magnus Westerlund, Ericsson INTERNET-DRAFT Ari Lakaniemi, Nokia May 16, 2001 Petri Koskelainen, Nokia Expires: November 16, 2001 Bernhard Wimmer, Siemens Tim Fingscheidt, Siemens Qiaobing Xie, Motorola Sanjay Gupta, Motorola RTP payload format and file storage format for AMR and AMR-WB audio Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document specifies a real-time transport protocol (RTP) payload format to be used for AMR and AMR-WB speech encoded signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats. Furthermore, a file format for storage of AMR and AMR-WB speech data is specified. Two separate MIME type registrations, one for AMR and one for AMR-WB, describing both RTP payload format and storage format are included. Sjoberg et al. [Page 1] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 1. Introduction This payload description applies to the packetization of data from two different codecs, the Adaptive Multi-Rate (AMR) codec and the Adaptive Multi-Rate Wideband (AMR-WB) codec. It is important to remember that these are different codecs and they MUST always be handled as different payload types in RTP. 1.1. The Adaptive Multi-Rate speech codec The adaptive multi-rate (AMR) speech codec [1] was developed by the European Telecommunications Standards institute (ETSI). The AMR codec is standardized for GSM, and is also chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation systems. The AMR codec will be widely used in cellular systems. The AMR codec is a multi-mode codec with 8 narrow band speech modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency is 8000 Hz and processing is done on 20 ms frames, i.e. 160 samples per frame. The AMR modes are closely related to each other and use the same coding framework. Three of the AMR modes are already adopted standards of their own, the 6.7 kbps mode as PDC-EFR [10], the 7.4 kbps mode as IS-641 codec in TDMA [9], and the 12.2 kbps mode as GSM- EFR [8]. 1.2. The Adaptive Multi-Rate Wideband speech codec The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G systems. The AMR-WB codec will be widely used in cellular systems. The AMR-WB codec is a multi-mode speech codec with 9 wideband speech coding modes with bit-rates between 6.6 and 23.85 kbps. The sampling frequency is 16000 Hz and processing is performed on 20 ms frames, i.e. 320 speech samples per frame. The AMR-WB modes are closely related to each other and employ the same coding framework. 1.3. Common Characteristics for AMR and AMR-WB The multi-mode feature is used to preserve high speech quality under a wide range of transmission conditions. In mobile radio systems (e.g. GSM) mode adaptation allows the system to adapt the balance between speech coding and error protection to enable best possible speech quality in prevailing transmission conditions. Mode adaptation can also be utilized to adapt to the varying available transmission bandwidth. Every codec implementation MUST support all specified speech coding modes. The codecs can handle mode switching to any Sjoberg et al. [Page 2] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 mode at any time, but some transport systems have limitations in the number of supported modes and on how often the mode can change. The mode information must therefore be transmitted together with the speech encoded bits, to indicate the mode. To realize rate adaptation the decoder needs to signal the mode it prefers to receive to the encoder. It is RECOMMENDED that the encoder follows a received mode request, but if the encoder has reason for not follow the mode request, e.g. congestion control, it may use another mode. No codec mode request MUST be sent for packets sent to a multicast group, and the encoder in the sender SHOULD ignore mode requests when sending to a multicast session but MAY use RTCP feedback information as a hint that a mode change is needed. Both codecs include voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce the number of transmitted bits and packets during silence periods to a minimum. The operation to send CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The frames containing CN parameters are called Silence Indicator (SID) frames. Due to the flexibility and robustness of these codecs, they are suitable also for other purposes than circuit switched cellular systems. Other suitable applications are real-time services over packet switched networks. The RTP payload format should be designed for robustness against both bit errors and packet loss. The speech encoded bits have different perceptual sensitivity to bit errors and cellular systems exploit this by using unequal error protection and detection (UEP and UED). The standard transport is RTP/UDP/IP and the utilization of UEP and UED discussed below is OPTIONAL. The UED/UEP mechanism focus the correction and detection of corrupted bits to the perceptually most sensitive bits. A speech frame is only declared damaged if there are bit errors in the most sensitive bits, i.e. the class A bits see table 1 (AMR) and [4] (AMR-WB). It is acceptable to have some bit errors in the other bits, i.e. class B and C. Also a damaged frame is still useful for error concealment in the decoding, which uses some of the less sensitive bits. This improves the speech quality compared to discarding the data. Today there exist some link layers that do not discard packets with bit errors, e.g. SLIP and some wireless links. With the Internet traffic pattern shifting towards a more media-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums, for example those supported by UDP- Lite [13] (work in progress), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. Sjoberg et al. [Page 3] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant networks: 1) Utilizing a partial checksum to cover headers and the most important speech bits of the payload. It is recommended that at least all class A bits are covered by the checksum. 2) Utilizing a partial checksum to only cover headers, but a frame CRC to cover the class A bits of each speech frame in the payload. In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved. It is still important that the network designer pay attention to the class B and C residual bit error rate. Though less sensitive to errors than class A bits, class B bits are not insignificant and undetected errors in these bits cause degradation in speech quality. An example of residual error rates considered acceptable for AMR in UMTS can be found in [21] and for AMR-WB in [22]. Approach 1 is a bit efficient, flexible and simple way, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple frames in a payload there is the possibility that a single bit error in protected bits gets all the frames discarded. These disadvantages can be avoided if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. Secondly b), when transporting multiple frames in a payload the CRC's remove the possibility that a single bit error in a class A bit gets all the frames discarded. Avoiding that gives an improvement in speech quality when transporting multiple frames and subject to bit errors. The choice between the two approaches must be made based on the available bandwidth, and desired tolerance to bit errors. Neither solution is appropriate to all cases. The payload format supports several means to increase robustness against packet loss. The simple scheme of repetition of previously sent data is one possibility. Another possible scheme which is more bandwidth efficient is to use payload external FEC, e.g. RFC2733 [20], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is work in progress on a generic version of such a scheme [19]. Sjoberg et al. [Page 4] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 Several frames can be encapsulated into a single RTP packet to decrease protocol overhead. One of the drawbacks of such approach is that in case of packet loss this means loss of several consecutive speech frames, which usually causes clearly audible distortion in reconstructed speech. Interleaving of frames can improve the speech quality in such cases by distributing the consecutive losses into series of single frame losses. However, interleaving and bundling several frames per payload will also increase end-to-end delay and is therefore not applicable to all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions. 2. Payload format 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 [5]. The AMR and AMR-WB payload format supports transmission of multiple frames per payload, the use of fast codec mode adaptation, and robustness against packet loss and bit errors. The payload format consists of one payload header with an optional interleaving extension, a table of contents, optionally one CRC per payload frame and zero or more payload frames. The payload format is either bandwidth efficient or octet aligned, the mode of operation to use has to be signalled at session establishment. Only the octet aligned format has the possibility to use the robust sorting, interleaving and CRC to make it robust to packet loss and bit errors. In the octet aligned format the payload header, table of contents entries and the payload frames are individually octet aligned to make implementations efficient, but in the bandwidth efficient format only the full payload is octet aligned. If the option to transmit a robust sorted payload is signaled the full payload SHALL finally be ordered in descending bit error sensitivity order to be prepared for unequal error protection or unequal error detection schemes. The encoded bit streams are defined in sensitivity order in Annex B of [2] and [4], the original order as delivered from the speech encoder is defined in [1] and [3]. Octet alignment of a field or payload means that the last octet MUST be padded with zeroes at the end to fill the octet. Note that this padding is separate from padding indicated by the P bit in the RTP header. The AMR frame types, or modes, are defined in [2] and the corresponding description for AMR-WB is found in [4]. The extra comfort noise types specified in table 1a in [2], i.e. frame type 9- 11 GSM-EFR CN, IS-641 CN and PDC-EFR CN, MUST NOT be used in this payload format. Frame type 14 (only available for AMR-WB), Sjoberg et al. [Page 5] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 SPEECH_LOST, and 15, NO_DATA, are needed to indicate not transmitted frames or lost frames. NO_DATA could mean both no data produced by the speech encoder for this frame or no data transmitted in this payload, i.e. valid data for this frame could be sent in an earlier or following packets. For example, when multiple frames are sent in each payload and comfort noise starts. A frame type sequence in a payload with 8 speech frames using AMR mode 7 is interrupted by DTX operation in the fifth frame, looks like: {7,7,7,7,8,15,15,8}. Note that packets containing only NO_DATA frames SHOULD not be transmitted. Also, NO_DATA frames at the end of a packet SHOULD NOT be transmitted, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7]. Robustness against packet loss can be accomplished by using the possibility to retransmit previously transmitted frames together with the current frame or frames. This is done by using a sliding window to group the speech frames to send in each payload, see figure 1. A packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions (encoded with different modes) of a frame for a certain timestamp if no packet losses are experienced. If multiple versions of a speech frame is received, it is RECOMMENDED that the mode with the highest rate is used by the speech decoder. --+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | --+--------+--------+--------+--------+--------+--------+--------+-- <- p(n-2) -> <- p(n-1) -> <- p(n) -> <- p(n+1) -> <- p(n+2) -> <- p(n+3) -> Figure 1: An example of retransmission where each frame is retransmitted one time in the following payload. f(n-2)..f(n+4) denotes a sequence of speech frames and p(n-2)..p(n+3) a sequence of payloads. The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g. RTCP receiver reports. To avoid congestion problems, congestion control MUST be considered, see also section 3. With AMR it is possible to add redundancy with little or no extra bandwidth by switching to an AMR mode with lower rate. Another approach to increase robustness against packet loss is to use the OPTIONAL frame interleaving to reduce the speech quality effect of packet losses. The interleaving improves perceived speech quality since it introduces single frame errors instead of several consecutive frame errors. Note that interleaving can be applied only Sjoberg et al. [Page 6] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 if the receiver has signaled support for it in capability description. The performance over error tolerant links can be improved by delivering also speech frames with bit errors. Unequal error detection is needed since bit errors SHOULD only be allowed in the least error sensitive bits. This payload format provides two alternative methods to implement unequal error detection: A. CRC calculation over the class A speech bits The OPTIONAL CRC MAY be used to protect the class A speech bits. The number of class A bits is specified as informative for AMR in [2] and therefore copied into table 1 as normative for this payload format. The number of class A bits for AMR-WB are specified as normative in table 2 in [4] and these numbers MUST be used also for this payload format. Speech frames with errors in class A bits MUST be marked with SPEECH_BAD for corrupted speech frames (FT=0..7 for AMR and FT=0..8 for AMR-WB) or SID_BAD for corrupted SID frames (FT=8 for AMR and FT=9 for AMR- WB) and be sent to the speech decoder, see [6] and [7]. In this case the RTP header, payload header and table of contents SHOULD be covered by a transport layer checksum, e.g. UDP-lite [13]. Packets SHOULD be discarded if the transport layer checksum detects errors. B. Robust sorting of payload bits Robust behavior can also be accomplished by robust sorting of the payload. This enables the use of UED (e.g. UDP-lite) and UEP (e.g. ULP [19]). The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents and class A bits. Support for unequal error detection is OPTIONAL. If either scheme is to be used, it MUST be signaled out of band (see chapter 6). Class A total speech Index Mode bits bits ---------------------------------------- 0 AMR 4.75 42 95 1 AMR 5.15 49 103 2 AMR 5.9 55 118 3 AMR 6.7 58 134 4 AMR 7.4 61 148 5 AMR 7.95 75 159 6 AMR 10.2 65 204 7 AMR 12.2 81 244 8 AMR SID 39 39 Table 1. The number of class A bits for the AMR codec. Sjoberg et al. [Page 7] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 A frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [17] and other transport formats. The speech quality is improved if damaged frames are forwarded to the speech decoder error concealment unit and not dropped. In many communication scenarios the AMR or AMR- WB encoded bits will be transmitted from one IP/UDP/RTP terminal to a terminal in a system with another transport format and/or vice versa. The transport format transcoding will be done in a gateway. A second likely scenario is that IP/UDP/RTP is used as transport between other systems, i.e. IP is originated and terminated in gateways on both sides of the IP transport. AMR or AMR-WB over I.366.{2,3} or +------+ +----------+ 3G Iu or | | IP/UDP/RTP/AMR | | -------------->| GW |----------------------->| TERMINAL | GSM Abis | | | | etc. +------+ +----------+ Figure 2: GW to VoIP terminal scenario AMR or AMR-WB AMR or AMR-WB over over I.366.{2,3} or +------+ +------+ I.366.{2,3} or 3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or -------------->| GW |-------------------->| GW |---------------> GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis etc. +------+ +------+ etc. Figure 3: GW to GW scenario The complete payload consists of one payload header (section 2.2) a table of contents (section 2.3) and one or more speech frames (section 2.4) sorted in either simple or robust order. The process by which the complete payload is assembled is described in section 2.5. 2.1. RTP header usage The RTP header marker bit (M) is used to mark (M=1) the packages containing as their first frame the first speech frame after a comfort noise period in DTX operation. For all other packets the marker bit is set to zero (M=0). The timestamp corresponds to the sampling instant of the first sample encoded for the first frame in the packet. A frame can be either encoded speech, comfort noise parameters, NO_DATA, or SPEECH_LOST (only for AMR-WB). The timestamp unit is in samples. The duration of one speech frame is 20 ms and the sampling frequency is 8 kHz, Sjoberg et al. [Page 8] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 corresponding to 160 encoded speech samples per frame for AMR and 16 kHz corresponding to 320 samples per frame in AMR-WB. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame. All frames in a packet MUST be successive 20 ms frames except if interleaving is employed, then frames encapsulated into a payload MUST be picked as defined in section 2.2. The payload MAY be padded using P bit in the RTP header. The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range SHOULD be chosen. 2.2. The payload header The payload header consists of a 4 bit codec mode request.If octet aligned operation is used the payload header is padded to fill an octet and optionally an 8 bit interleaving header may extend the payload header. The bits in the header are specified as follows: CMR (4 bits): Indicates Codec Mode Requested for the other communication direction. It is only allowed to request one of the speech modes of the used codec, frame type index 0..7 for AMR, see Table 1a in [2] or frame type index 0..8 for AMR-WB, see Table 1a in [4]. CMR value 15 indicates that no mode request is present, other values are for future use. It is RECOMMENDED that the encoder follows a received mode request, but if the encoder has reason for not follow the mode request, e.g. congestion control, it MAY use another mode. The codec mode request (CMR) MUST be set to 15 for packets sent to a multicast group. The encoder in the sender SHOULD ignore mode requests when sending to a multicast session but MAY use RTCP feedback information as a hint that a mode change is needed. The codec mode selection MAY be restricted by the mode set definition at session set up. If so, the selected codec mode MUST be in the signaled mode set. R: Is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver. 0 0 1 2 3 +-+-+-+-+ | CMR | +-+-+-+-+ Figure 4: Payload header for bandwidth efficient operation. Sjoberg et al. [Page 9] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | CMR |R|R|R|R| +-+-+-+-+-+-+-+-+ Figure 5: Payload header for octet aligned operation. If the use of interleaving is signaled out of band at session set up, octet aligned operation MUST be used. When interleaving is used the payload header is extended with two 4 bit fields, ILL and ILP, used to describe the interleaving scheme. ILL (4 bits): OPTIONAL field that is present only if interleaving is signaled. The value of this field specifies the interleaving length used for frames in this payload. ILP (4 bits): OPTIONAL field that is present only if interleaving is signaled. The value of this field indicates the interleaving index for frames in this payload. The value of ILP MUST be smaller than or equal to the value of ILL. Erroneous value of ILP SHOULD cause the payload to be discarded. The value of the ILL field defines the length of an interleave group: ILL=L implies that frames in (L+1)-frame intervals are picked into the same interleaved payload, and the interleave group consists of L+1 payloads. The size of the interleaving group is the N*(L+1), if N is the number of frames per payload. The value of ILL MUST only be changed between interleave groups. The value of ILP=p in payloads belonging to the same group runs from 0 to L. The interleaving is meaningful only when the number of frames per payload (N) is greater than or equal to 2. All payloads in an interleave group MUST contain equally many speech frames. When N frames are transmitted in each payload of a group, the interleave group consists of payloads with sequence numbers s...s+L, and frames encapsulated into these payloads are f...f+N*(L+1)-1. To put this in a form of an equation, assume that the first frame of an interleave group is n, the first payload of the group is s, number of frames per payload is N, ILL=L and ILP=p (p in range 0...L), the frames contained by the payload s+p are n + p + k*(L+1), where k runs from 0 to N-1. I.e. The first packet of an interleave group: ILL=L, ILP=0 Payload: s Frames: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1) The second packet of an interleave group: ILL=L, ILP=1 Payload: s+1 Frames: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1) Sjoberg et al. [Page 10] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 ... The last packet of an interleave group: ILL=L, ILP=L Payload: s+L Frames: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR |R|R|R|R| ILL | ILP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Octet aligned operation payload header with interleaving extension. 2.3. The payload table of contents and CRCs The table of contents (ToC) consists of one entry for each speech frame in the payload. A table of contents entry includes several specified fields as follows: F (1 bit): Indicates if this frame is followed by further speech frames in this payload or not. F=1 further frames follow, F=0 last frame. FT (4 bits): Frame type indicator, indicating the AMR or AMR-WB speech coding mode or comfort noise (SID) mode. The mapping of existing modes to FT is given in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. If FT=14 (speech lost, available only in AMR- WB) or FT=15 (No transmission/no reception) no CRC or payload frame is present. Q (1 bit): The payload quality bit indicates, if not set, that the payload is severely damaged and the receiver should set the RX_TYPE, see [6], to SPEECH_BAD or SID_BAD depending on the frame type (FT). P: Is a padding bit, MUST be set to zero. 0 0 1 2 3 4 5 +-+-+-+-+-+-+ |F| FT |Q| +-+-+-+-+-+-+ Figure 7: Table of contents entry field for bandwidth efficient operation. Sjoberg et al. [Page 11] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| FT |Q|F| FT |Q|F| FT |Q| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: An example of a ToC when using bandwidth efficient operation. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| FT |Q|P|P| +-+-+-+-+-+-+-+-+ Figure 9: Table of contents entry field for octet aligned operation. CRC (8 bits): OPTIONAL field, exists if the use of CRC is signaled at session set up and SHALL only be used in octet aligned operation. The 8 bit CRC is used for error detection. The algorithm to generate these 8 parity bits are defined in section 4.1.4 in [2]. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | CRC | +-+-+-+-+-+-+-+-+ Figure 10: CRC field The ToC and CRCs are arranged with all table of contents entries fields first followed by all CRC fields. The ToC starts with the frame data belonging to the oldest speech frame. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| FT |Q|P|P|F| FT |Q|P|P|F| FT |Q|P|P| CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC | CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: The ToC and CRCs for a payload with three speech frames when using octet aligned operation. 2.4. Speech frame A speech frame represents one frame encoded with the mode according to the ToC field FT. The length of this field is implicitly defined Sjoberg et al. [Page 12] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 by the mode in the FT field. The bits SHALL be sorted according to Annex B of [2] for AMR and Annex B of [4] for AMR-WB. If octet aligned operation is used, the last octet of each speech frame MUST be padded with zeroes at the end if not all bits are used. 2.5. Compound payload The compound payload consists of one payload header, the table of contents and one or more speech frames, see section 2.2, 2.3 and 2.4. These elements SHALL be put together to form a payload with either simple or robust sorting. If the bandwidth efficient operation is used, simple sorting MUST be used. Definitions for describing the compound payload: b(m) - bit m of the compound payload, octet aligned o(n,m) - bit m of octet n in the octet description of the compound payload, bit 0 is MSB t(n,m) - bit m in the table of contents entry for speech frame n p(n,m) - bit m in the CRC for speech frame n f(n,m) - bit m in speech frame n F(n) - number of bits in speech frame n, defined by FT h(m) - bit m of payload header C(n) - number of CRC bits for speech frame n, 0 or 8 bits P(n) - number of padding bits for speech frame n N - number of payload frames in the payload S - number of unused bits Payload frames f(n,m) are ordered in consecutive order, where frame n is preceding frame n+1. Within one payload with multiple speech frames the sequence of speech frames MUST contain all speech frames in the sequence. If interleaving is used the interleaving rules defined in section 2.2 applies for which frames that are contained in the payload. If speech data is missing for one or more frames in the sequence of frames in the payload, due to e.g. DTX, send the NO_DATA frame type in the ToC for these frames. This does not mean that all frames must be sent, only that the sequence of frames in one payload MUST indicate missing frames. Payloads containing only NO_DATA frames SHOULD NOT be transmitted. The compound payload, b, is mapped into octets, o, where bit 0 is MSB. 2.5.1. Simple payload sorting If multiple new frames are encapsulated into the payload and robust payload sorting is not used, the payload is formed by concatenating the payload header, the ToC, optional CRC fields and the speech Sjoberg et al. [Page 13] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 frames in the payload. However, the bits inside a frame are ordered into sensitivity order as defined in [2] for AMR and [4] for AMR-WB. 2.5.1.1. Simple payload sorting for bandwidth efficient operation The simple payload sorting algorithm is defined in C-style as: /* payload header */ k=0; H=4; for (i = 0; i < H; i++){ b(k++) = h(i); } /* table of contents */ T=6; for (j = 0; j < N; j++){ for (i = 0; i < T; i++){ b(k++) = t(j,i); } } /* payload frames */ for (j = 0; j < N; j++){ for (i = 0; i < F(j); i++){ b(k++) = f(j,i); } } /* padding */ S = (k%8 == 0) ? 0 : 8 - k%8; for (i = 0; i < S; i++){ b(k++) = 0; } /* map into octets */ for (i = 0; i < k; i++){ o(i/8,i%8)=b(i) } 2.5.1.2. Simple payload sorting for octet aligned operation In octet aligned operation is the simple payload sorting algorithm defined in C-style as: /* payload header */ k=0; H=8; if (interleaving){ H+=8; /* Interleaving extension */ } for (i = 0; i < H; i++){ b(k++) = h(i); } Sjoberg et al. [Page 14] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 /* table of contents */ T=8; for (j = 0; j < N; j++){ for (i = 0; i < T; i++){ b(k++) = t(j,i); } } /* CRCs, only if signaled */ if (crc) { for (j = 0; j < N; j++){ for (i = 0; i < C(j); i++){ b(k++) = p(j,i); } } } /* payload frames */ for (j = 0; j < N; j++){ for (i = 0; i < F(j); i++){ b(k++) = f(j,i); } /* padding of each speech frame */ S = (k%8 == 0) ? 0 : 8 - k%8; for (i = 0; i < S; i++){ b(k++) = 0; } } /* map into octets */ for (i = 0; i < k; i++){ o(i/8,i%8)=b(i) } 2.5.2. Robust payload sorting Robust payload sorting is only supported in octet aligned operation and MUST be signaled at session set up. A bit error in a more sensitive bit is subjectively more annoying than in a less sensitive bit. Therefore, to be able to protect only the most sensitive bits in a payload packet with a forward error detection or correction code, e.g. a checksum outside RTP or ULP [19], the bits inside a frame are ordered into sensitivity order. The protection SHOULD cover an appropriate number of octets from the beginning of the payload, covering at least the payload header, ToC and class A bits, see table 1 (AMR) and [4] (AMR-WB). If CRCs are used together with robust sorting only the payload header and the ToC should be covered by the transport checksum. Exactly how many octets need protection depends on the network and application. To maintain sensitivity ordering inside the payload, when more than one speech Sjoberg et al. [Page 15] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 frame is transmitted in one payload, reordering of the data is needed. When robust sorting mode is used, the reordering to maintain the sensitivity ordered payload SHALL be performed on octet level. The payload header, ToC and CRCs SHALL still be placed unchanged in the beginning of the payload. Thereafter, the payload frames are sorted with one octet alternating from each payload frame. The robust payload sorting algorithm is defined in C-style as: /* payload header */ k=0; H=8; if (interleaving){ H += 8; /* interleaving extension */ } for (i = 0; i < H; i++){ b(k++) = h(i); } /* table of contents */ for (j = 0; j < N; j++){ for (i = 0; i < 8; i++){ b(k++) = t(j,i); } } /* CRCs */ if (crc){ for (j = 0; j < N; j++){ for (i = 0; i < C(j); i++){ b(k++) = p(j,i); } } } /* payload frames */ for (j = 0; j < N; j++){ P(j) = F(j)%8 == 0 ? 0 : 8 - F(j)%8; } max = max(F(0),..,F(N-1)); for (i = 0; i < max; i+=8){ for (j = 0; j < N; j++){ for (l = 0; l < 8; l++){ if (i+l < F(j)+P(j)){ if (i+l< F(j)){ b(k++) = f(j,i+l); }else{ b(k++) = 0; } } } } } Sjoberg et al. [Page 16] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 /* map into octets */ for (i = 0; i < k; i++){ o(i/8,i%8)=b(i) } 2.6. Decoding security consideration If the payload length calculation, using the information from signaling plus the F and FT fields, does not indicate the same length as the size of the payload actually received, the payload SHOULD be dropped. Decoding a packet that has errors in length indicator bits could severely degrade the speech quality. Furthermore, all receivers MUST be able to receive any speech frame multiple times, both exact duplicates and in different AMR modes. 2.7. Implementation considerations Implementations SHOULD include both bandwidth efficient and octet aligned operation to give a high possibility of interoperability. The implementation of robust sorting, interleaving and CRCs are OPTIONAL. 3. Congestion Control The need of congestion control for data transported with RTP has to be considered. AMR and AMR-WB speech data have some elastic properties due to the different bandwidth demand for each mode. Another parameter that can reduce the bandwidth demand for AMR and AMR-WB is how many frames of speech data that are encapsulated in each payload. This will reduce the number of packets and the overhead from IP/UDP/RTP headers. If using forward error correction (FEC) there is also the need to regulate the amount, so the FEC itself does not worsen the problem. Therefore, it is RECOMMENDED that applications using this payload implement congestion control. The actual mechanism for congestion control is not specified but should be suitable for real-time flows, e.g. "Equation-Based Congestion Control for Unicast Applications" [18]. 4. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [11]. 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. Sjoberg et al. [Page 17] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat. As this format transports encoded speech, the main security issues are decoding security (see section 2.6), confidentiality and authentication of the speech itself. The payload format itself does not have any support for security. These issues have to be solved by a payload external mechanism, e.g. SRTP [23]. Interleaving MAY affect encryption. Depending on the used encryption scheme there MAY be restrictions on for example the time when keys can be changed. 4.1. Confidentiality To achieve confidentiality of the encoded speech all speech data bits must be encrypted. There is less need to encrypt the payload header or the table of contents as they only carry information about the requested speech mode, frame type and frame quality. This information could be useful to some third party, e.g. quality monitoring. The type of encryption used can not only have impact on the confidentiality but also on error robustness. The error robustness against bit errors will be none, unless an encryption method without error-propagation is used, e.g. a stream cipher. This is only an issue when using UEP/D, when bit errors can be accepted in some part of the payload. 4.2. Authentication To authenticate the sender of the speech an external mechanism has to be added. It is RECOMMENDED that such a mechanism protects all the speech data bits. Note that the use of UED/UEP is difficult to combine with authentication. To prevent a man in the middle from tampering with the packetization of the speech data, some extra data SHOULD be protected. The data is: the payload header, ToC, CRCs, RTP timestamp, RTP sequence number, and the RTP marker bit. Tampering could result in erroneous depacketization/decoding that could lower speech quality. Tampering with the codec mode request field can result in that the sender must receive speech in a different quality than desired. Sjoberg et al. [Page 18] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 5. Examples 5.1. Bandwidth efficient examples 5.1.1. Single frame example The bandwidth efficient single frame per payload example is employing AMR, no valid Codec Mode Request CMR is sent (CMR=15), the payload was not damaged at IP origin (Q=1). The mode is AMR 7.4 kbps (FT=4). The speech encoded bits are put into f(0) to f(147) in descending sensitivity order according to [2]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR |F| FT |Q|f(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f(147)|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: One frame per packet example. 5.1.2. Multi frame example The bandwidth efficient multiple frame per payload example is employing AMR-WB, a Codec Mode Request CMR for the AMR-WB 8.85 kbps mode is sent (CMR=1), the payloads were not damaged at IP origin (Q=1). The mode is AMR-WB 6.6 kbps (FT=0) for the first frame, f(0) to f(131), and AMR-WB 8.85 kbps (FT=1) for the second frame, g(0) to g(176). The speech encoded bits are put into f(0) to f(131) and g(0) to g(176) in descending sensitivity order according to [4]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR |F| FT |Q|F| FT |Q|f(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sjoberg et al. [Page 19] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 | f(131)|g(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g(176)|P|P|P| +-+-+-+-+-+-+-+-+ Figure 13: Two frame per packet example. 5.2. Octet aligned operation examples In this example octet aligned operation of the payload format is used. Two AMR frames with 7.95 kbps mode (FT=5) are sent in the payload. A mode request is sent, requesting the 10.2 kbps mode for the other link(CMR=6). CRC is used. Interleaving is used with depth ILL=1 and index ILP=0. The first frame is frame 1, f1(0..158), and the second frame in the payload is frame 3 due to interleaving, f3(0..158). For each payload frame a CRC is calculated CRC1(0..7) for frame 1 and CRC3(0..7) for frame 3. Robust payload sorting is used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR |R|R|R|R| ILL | ILP |F| FT |Q|P|P|F| FT |Q|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC1 | CRC3 | f1(0..7) | f3(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(8..15) | f3(8..15) | f1(16..23) | f3(16..23) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f1(152..158) |P|f3(152..158) |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Example with CRCs, interleaving and robust sorting. 6. MIME type registration This chapter defines the MIME types for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) speech codecs, [1] and [3], respectively. To distinguish between the two codecs and emphasize Sjoberg et al. [Page 20] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 that seamless switching is possible only within each of these two codecs the MIME types are kept separate although they are very similar. The data format and parameters are specified for both real- time transport and for storage type applications (e.g. e-mail attachment, multimedia messaging). The former is referred to as RTP mode and the latter as storage mode. Implementations according to [1] and [3] MUST support all eight coding modes for AMR and all nine coding modes for AMR-WB. The mode change within each codec can occur at any time during operation and therefore the mode information is transmitted in-band together with speech bits to allow mode change without any additional signaling. In addition to the speech codec, AMR and AMR-WB specifications also include Discontinuous Transmission / comfort noise (DTX/CN) functionality [14] and [15]. The DTX/CN switches the transmission off during silent parts of the speech and only CN parameter updates, SID frames, are sent at regular intervals. 6.1. RTP mode It is possible that the decoder may want to receive a certain speech mode or a subset of modes, due to link limitations in some cellular systems, e.g. the GSM radio link can only use a subset of at most four modes. A GSM subset can consist of any combination of the 8 AMR modes or 9 AMR-WB modes. Therefore, it is possible to request a specific set of speech modes in capability description and the encoder MUST abide by this request. If the request for mode set is not given any mode may be used or requested. The codec can in principle perform a mode change at any time between any two modes. To support interoperability with GSM through a gateway it is possible to set limitations for mode changes. The decoder has the possibility to define the minimum number of frames between mode changes and to limit the mode change to transition into neighboring modes only. It is also possible to limit the number of speech frames encapsulated into one RTP packet. This is an OPTIONAL feature and if no parameter is given in the capability description, the transmitter MAY encapsulate any number of speech frames into one RTP packet. The payload CRC UED MUST be used if the receiver has signaled the use of this functionality in the capability description. To support unequal error protection and/or detection the payload format supports robust payload sorting. The robust payload sorting is an OPTIONAL feature and SHALL be used if the receiver has signaled the use of this functionality in the capability description. Sjoberg et al. [Page 21] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 The speech quality in case of packet losses when transmitting several speech frames per packet can be improved by using the OPTIONAL frame level interleaving. The interleaving improves perceived speech quality since it introduces series of single frame errors instead of several consecutive frame errors. Interleaving MUST be applied if the receiver has signaled the use of it in the capability description, and the interleaving length MUST NOT exceed the limitation given in capability description. Note that the receiver can use the MIME parameters to limit increased buffering requirements caused by the interleaving. For example, interleaving=I defines the maximum size of an interleave group to I=N*(L+1) (see section 2.2 for details on interleaving). 6.2. Storage mode The storage mode is used for storing speech frames, e.g. as a file or e-mail attachment. The file begins with a magic number to identify that it is an AMR or AMR-WB file. AMR and AMR-WB have different magic numbers. The magic number for AMR corresponds to the ASCII character string "#!AMR\n" and for AMR-WB "#!AMR-WB\n", i.e. 0x2321414d520a and 0x2321414d522d57420a. The speech frames are stored in consecutive order in octet aligned manner. This implies that the first octet after the last octet of frame n must be the first octet of frame n+1. The first octet of each stored speech frame consists of a 4-bit FT field (see definition in section 2.3)and a Q bit. The positions of the fields correspond to the positions of the corresponding fields of an octet aligned table of contents entry, see figure 9. Following this first octet comes the encoded speech frames bits (see section 2.4). The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment. An example is given in figure 15. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| FT |Q|P|P| | +-+-+-+-+-+-+-+-+ + | | + Speech bits for frame n + | | + +-+-+ | |P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: An example of storage format with one AMR 5.9 kbit/s frames (118 speech bits). Note that bits marked with P, "padding" MUST be set to zero. Sjoberg et al. [Page 22] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 Speech frames lost in transmission and non-received frames between SID updates during non-speech period MUST be stored as NO_DATA frames (frame type 15, see definition in [2] and [4]) or SPEECH_LOST (only available for AMR-WB) to keep synchronization with the original media. 6.3. AMR MIME Registration MIME-name for the AMR codec is allocated from IETF tree since AMR is expected to be widely used speech codec in VoIP applications. Some parts of this chapter will distinguish between RTP and storage modes. Media Type name: audio Media subtype name: AMR Required parameters: none Optional parameters for RTP mode: octet-align: If present, octet aligned operation SHALL be used. If not present and no other signal indicate octet aligned operation, bandwidth efficient operation is employed. mode-set: Requested AMR mode set. Restricts the active codec mode set to a subset of all modes. Possible values are comma separated list of modes: 0,...,7 (see Table 1a [2] an example is given in section 6.5). If not present, all speech modes are available. mode-change-period: Defines a number N which restricts the mode changes in such a way that mode changes are only allowed on multiples of N, initial state of the phase is arbitrary. If this parameter is not present, mode change can happen at any time. mode-change-neighbor: If present, mode changes SHALL only be made to neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, both higher and lower rate included. If not present, change between any two modes in the active codec mode set is allowed. maxframes: Maximum number of speech frames in one RTP packet. The receiver MAY set this parameter in order to limit the buffering requirements or delay. crc: If present, CRCs SHALL be included in the payload, otherwise not. Implies automatically that octet-align operation is used. robust-sorting: If present, the payload SHALL employ robust payload sorting. If not present simple payload sorting SHALL be used. Implies automatically that octet-align operation is used. interleaving: Indicates that frame level interleaving SHALL be used Sjoberg et al. [Page 23] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 and its value defines a maximum number of frames in the interleaving group (see section 2.2). If this parameter is not present, interleaving SHALL not be used. Implies automatically that octet-align operation is used. Optional parameters for storage mode: none Encoding considerations for RTP mode: See chapter 2 of RFC XXXX. Encoding considerations for storage mode: See section 6.2 of RFC XXXX. Security considerations: see chapter 4 "Security" of RFC XXXX. Public specification: please refer to chapter 7 "References" of RFC XXXX. Additional information for storage mode: Magic number: #!AMR\n File extensions: amr, AMR Macintosh file type code: none Object identifier or OID: none Person & email address to contact for further information: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type. Author/Change controller: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com IETF Audio/Video transport working group 6.4. AMR-WB MIME Registration MIME-name for the AMR-WB codec is allocated from IETF tree since AMR- WB is expected to be widely used speech codec in VoIP applications. Some parts of this chapter will distinguish between RTP and storage modes. Media Type name: audio Media subtype name: AMR-WB Required parameters: none Optional parameters for RTP mode: octet-align: If present, octet aligned operation SHALL be used. If Sjoberg et al. [Page 24] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 not present and no other signal indicate octet aligned operation, bandwidth efficient operation is employed. mode-set: Requested AMR-WB mode set. Restricts the active codec mode set to a subset of all modes. Possible values are comma separated list of modes: 0,...,8 (see Table 1a [4]).If not present, all speech modes are available. mode-change-period: Defines a number N which restricts the mode changes in such a way that mode changes are only allowed on multiples of N, initial state of the phase is arbitrary. If this parameter is not present, mode change can happen at any time. mode-change-neighbor: If present, mode changes SHALL only be made to neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, both higher and lower rate included. If not present, change between any two modes in the active codec mode set is allowed. maxframes: Maximum number of speech frames in one RTP packet. The receiver MAY set this parameter in order to limit the buffering requirements or delay. crc: If present, CRCs SHALL be included in the payload, otherwise not. Implies automatically that octet-align operation is used. robust-sorting: If present, the payload SHALL employ robust payload sorting. If not present simple payload sorting SHALL be used. Implies automatically that octet-align operation is used. interleaving: Indicates that frame level interleaving SHALL be used and its value defines a maximum number of frames in the interleaving group (see section 2.2). If this parameter is not present, interleaving SHALL not be used. Implies automatically that octet-align operation is used. Optional parameters for storage mode: none Encoding considerations for RTP mode: See chapter 2 of RFC XXXX. Encoding considerations for storage mode: See section 6.2 of RFC XXXX. Security considerations: see chapter 4 "Security" of RFC XXXX. Public specification: please refer to chapter 7 "References" of RFC XXXX. Additional information for storage mode: Magic number: #!AMR-WB\n File extensions: awb, AWB Macintosh file type code: none Object identifier or OID: none Sjoberg et al. [Page 25] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 Person & email address to contact for further information: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type. Author/Change controller: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com IETF Audio/Video transport working group 6.5 Mapping to SDP Parameters Please note that this chapter applies only to the RTP mode. Example of usage of AMR in SDP [16], possible GSM gateway scenario: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change- neighbor; maxframes=1 Example of usage of AMR-WB in SDP [16], possible VoIP scenario: m=audio 49120 RTP/AVP 98 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 octet-align Example of usage of AMR-WB in SDP [16], possible streaming scenario: m=audio 49120 RTP/AVP 99 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 maxframes=3; interleaving=15 7. References [1] 3G TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding". [2] 3G TS 26.101, "AMR Speech Codec Frame Structure". [3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding functions". [4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure". [5] IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels". [6] 3G TS 26.093, "AMR Speech Codec; Source Controlled Rate operation". Sjoberg et al. [Page 26] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 [7] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation". [8] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding". [9] TIA/EIA -136-Rev.A, part 410 - "TDMA Cellular/PCS - Radio Interface, Enhanced Full Rate Voice Codec (ACELP). Formerly IS- 641. TIA published standard, 1998". [10] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard". [11] IETF RFC1889, "RTP: A Transport Protocol for Real-Time Applications". [12] IETF draft-westberg-realtime-cellular-01.txt, "Realtime Traffic over Cellular Access Networks". [13] IETF draft-larzon-udplite-04.txt, "The UDP Lite Protocol". [14] GSM 06.92, "Comfort noise aspects for Adaptive Multi-Rate (AMR) speech traffic channels". [15] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise aspects". [16] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 [17] 3G TS 25.415 "UTRAN Iu Interface User Plane Protocols" [18] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000, Stockholm, Sweden [19] IETF draft-ietf-avt-ulp-00.txt, "An RTP Payload Format for Generic FEC with Uneven Level Protection ". [20] IETF RFC2733, "An RTP Payload Format for Generic Forward Error Correction". [21] 3G TS 26.102, "AMR speech codec interface to Iu and Uu". [22] 3GPP TS 26.202 "AMR Wideband speech codec; Interface to Iu and Uu". [23] draft-ietf-avt-srtp-00.txt, "The Secure Real Time Transport Protocol". Sjoberg et al. [Page 27] INTERNET-DRAFT RTP Payload Format for AMR and AMR-WB May 16, 2001 8. Authors' addresses Johan Sjoberg Tel: +46 8 50878230 Ericsson Research EMail: Johan.Sjoberg@ericsson.com Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN Magnus Westerlund Tel: +46 8 4048287 Ericsson Research EMail: Magnus.Westerlund@ericsson.com Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN Ari Lakaniemi Tel: +358 50 4837698 Nokia Research Center EMail: ari.lakaniemi@nokia.com P.O.Box 407 FIN-00045 Nokia Group, FINLAND Petri Koskelainen Nokia Research Center EMail: petri.koskelainen@nokia.com P.O.Box 100 FIN-33721 Tampere, FINLAND Tim Fingscheidt Tel: +49 89 722 57658 Siemens AG, ICP CD Fax: +49 89 722 46489 Grillparzerstrasse 10-18 EMail: Tim.Fingscheidt@mch.siemens.de D - 81675 Munich, GERMANY Bernhard Wimmer Tel: +49 89 722 23247 Siemens AG, ICP CD Fax: +49 89 722 46489 Grillparzerstrasse 10-18 EMail: Bernhard.Wimmer@mch.siemens.de D - 81675 Munich, GERMANY Qiaobing Xie Tel: +1-847-632-3028 Motorola, Inc. EMail: qxie1@email.mot.com 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004, USA Sanjay Gupta Tel: +1-847-435-0306 Motorola, Inc. EMail: QA4496@email.mot.com 1501 W. Shure Drive, #3205 Arlington Heights, IL 60004, USA This Internet-Draft expires November 28, 2001. Sjoberg et al. [Page 28]