tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4867

 Errata 
Proposed STD
Pages: 59
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: AVT

RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs

Part 1 of 3, p. 1 to 15
None       Next RFC Part

Obsoletes:    3267


Top       ToC       Page 1 
Network Working Group                                         J. Sjoberg
Request for Comments: 4867                                 M. Westerlund
Obsoletes: 3267                                                 Ericsson
Category: Standards Track                                   A. Lakaniemi
                                                                   Nokia
                                                                  Q. Xie
                                                                Motorola
                                                              April 2007


          RTP Payload Format and File Storage Format for the
  Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB)
                              Audio Codecs

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 IETF Trust (2007).

Abstract

   This document specifies a Real-time Transport Protocol (RTP) payload
   format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-
   Rate Wideband (AMR-WB) encoded speech signals.  The payload format is
   designed to be able to interoperate with existing AMR and AMR-WB
   transport formats on non-IP networks.  In addition, a file format is
   specified for transport of AMR and AMR-WB speech data in storage mode
   applications such as email.  Two separate media type registrations
   are included, one for AMR and one for AMR-WB, specifying use of both
   the RTP payload format and the storage format.  This document
   obsoletes RFC 3267.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
   2. Conventions and Acronyms ........................................4
   3. Background on AMR/AMR-WB and Design Principles ..................5
      3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5
      3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6
      3.3. Multi-Rate Encoding and Mode Adaptation ....................6
      3.4. Voice Activity Detection and Discontinuous Transmission ....7
      3.5. Support for Multi-Channel Session ..........................7
      3.6. Unequal Bit-Error Detection and Protection .................8
           3.6.1. Applying UEP and UED in an IP Network ...............8
      3.7. Robustness against Packet Loss ............................10
           3.7.1. Use of Forward Error Correction (FEC) ..............10
           3.7.2. Use of Frame Interleaving ..........................12
      3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12
      3.9. AMR or AMR-WB Speech over IP Scenarios ....................13
   4. AMR and AMR-WB RTP Payload Formats .............................15
      4.1. RTP Header Usage ..........................................15
      4.2. Payload Structure .........................................17
      4.3. Bandwidth-Efficient Mode ..................................17
           4.3.1. The Payload Header .................................17
           4.3.2. The Payload Table of Contents ......................18
           4.3.3. Speech Data ........................................20
           4.3.4. Algorithm for Forming the Payload ..................21
           4.3.5. Payload Examples ...................................21
                  4.3.5.1. Single-Channel Payload Carrying a
                           Single Frame ..............................21
                  4.3.5.2. Single-Channel Payload Carrying
                           Multiple Frames ...........................22
                  4.3.5.3. Multi-Channel Payload Carrying
                           Multiple Frames ...........................23
      4.4. Octet-Aligned Mode ........................................25
           4.4.1. The Payload Header .................................25
           4.4.2. The Payload Table of Contents and Frame CRCs .......26
                  4.4.2.1. Use of Frame CRC for UED over IP ..........28
           4.4.3. Speech Data ........................................30
           4.4.4. Methods for Forming the Payload ....................31
           4.4.5. Payload Examples ...................................32
                  4.4.5.1. Basic Single-Channel Payload
                           Carrying Multiple Frames ..................32
                  4.4.5.2. Two-Channel Payload with CRC,
                           Interleaving, and Robust Sorting ..........32
      4.5. Implementation Considerations .............................33
           4.5.1. Decoding Validation ................................34
   5. AMR and AMR-WB Storage Format ..................................35
      5.1. Single-Channel Header .....................................35
      5.2. Multi-Channel Header ......................................36

Top      ToC       Page 3 
      5.3. Speech Frames .............................................37
   6. Congestion Control .............................................38
   7. Security Considerations ........................................38
      7.1. Confidentiality ...........................................39
      7.2. Authentication and Integrity ..............................39
   8. Payload Format Parameters ......................................39
      8.1. AMR Media Type Registration ...............................40
      8.2. AMR-WB Media Type Registration ............................44
      8.3. Mapping Media Type Parameters into SDP ....................47
           8.3.1. Offer-Answer Model Considerations ..................48
           8.3.2. Usage of Declarative SDP ...........................50
           8.3.3. Examples ...........................................51
   9. IANA Considerations ............................................53
   10. Changes from RFC 3267 .........................................53
   11. Acknowledgements ..............................................55
   12. References ....................................................55
      12.1. Normative References .....................................55
      12.2. Informative References ...................................56

Top      ToC       Page 4 
1.  Introduction

   This document obsoletes RFC 3267 and extends that specification with
   offer/answer rules.  See Section 10 for the changes made to this
   format in relation to RFC 3267.

   This document specifies the payload format for packetization of AMR
   and AMR-WB encoded speech signals into the Real-time Transport
   Protocol (RTP) [8].  The payload format supports transmission of
   multiple channels, multiple frames per payload, the use of fast codec
   mode adaptation, robustness against packet loss and bit errors, and
   interoperation with existing AMR and AMR-WB transport formats on
   non-IP networks, as described in Section 3.

   The payload format itself is specified in Section 4.  A related file
   format is specified in Section 5 for transport of AMR and AMR-WB
   speech data in storage mode applications such as email.  In Section
   8, two separate media type registrations are provided, one for AMR
   and one for AMR-WB.

   Even though this RTP payload format definition supports the transport
   of both AMR and AMR-WB speech, it is important to remember that AMR
   and AMR-WB are two different codecs and they are always handled as
   different payload types in RTP.

2.  Conventions and Acronyms

   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 [5].

   The following acronyms are used in this document:

      3GPP   - the Third Generation Partnership Project
      AMR    - Adaptive Multi-Rate (Codec)
      AMR-WB - Adaptive Multi-Rate Wideband (Codec)
      CMR    - Codec Mode Request
      CN     - Comfort Noise
      DTX    - Discontinuous Transmission
      ETSI   - European Telecommunications Standards Institute
      FEC    - Forward Error Correction
      SCR    - Source Controlled Rate Operation
      SID    - Silence Indicator (the frames containing only CN
               parameters)
      VAD    - Voice Activity Detection
      UED    - Unequal Error Detection
      UEP    - Unequal Error Protection

Top      ToC       Page 5 
   The term "frame-block" is used in this document to describe the
   time-synchronized set of speech frames in a multi-channel AMR or
   AMR-WB session.  In particular, in an N-channel session, a frame-
   block will contain N speech frames, one from each of the channels,
   and all N speech frames represents exactly the same time period.

   The byte order used in this document is network byte order, i.e., the
   most significant byte first.  The bit order is also the most
   significant bit first.  This is presented in all figures as having
   the most significant bit leftmost on a line and with the lowest
   number.  Some bit fields may wrap over multiple lines in which cases
   the bits on the first line are more significant than the bits on the
   next line.

3.  Background on AMR/AMR-WB and Design Principles

   AMR and AMR-WB were originally designed for circuit-switched mobile
   radio systems.  Due to their flexibility and robustness, they are
   also suitable for other real-time speech communication services over
   packet-switched networks such as the Internet.

   Because of the flexibility of these codecs, the behavior in a
   particular application is controlled by several parameters that
   select options or specify the acceptable values for a variable.
   These options and variables are described in general terms at
   appropriate points in the text of this specification as parameters to
   be established through out-of-band means.  In Section 8, all of the
   parameters are specified in the form of media subtype registrations
   for the AMR and AMR-WB encodings.  The method used to signal these
   parameters at session setup or to arrange prior agreement of the
   participants is beyond the scope of this document; however, Section
   8.3 provides a mapping of the parameters into the Session Description
   Protocol (SDP) [11] for those applications that use SDP.

3.1.  The Adaptive Multi-Rate (AMR) Speech Codec

   The AMR codec was originally developed and standardized by the
   European Telecommunications Standards Institute (ETSI) for GSM
   cellular systems.  It is now chosen by the Third Generation
   Partnership Project (3GPP) as the mandatory codec for third
   generation (3G) cellular systems [1].

   The AMR codec is a multi-mode codec that supports eight narrow band
   speech encoding modes with bit rates between 4.75 and 12.2 kbps.  The
   sampling frequency used in AMR is 8000 Hz and the speech encoding is
   performed on 20 ms speech frames.  Therefore, each encoded AMR speech
   frame represents 160 samples of the original speech.

Top      ToC       Page 6 
   Among the eight AMR encoding modes, three are already separately
   adopted as standards of their own.  Particularly, the 6.7 kbps mode
   is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA
   [17], and the 12.2 kbps mode as GSM-EFR [16].

3.2.  The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec

   The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was
   originally developed by 3GPP to be used in GSM and 3G cellular
   systems.

   Similar to AMR, the AMR-WB codec is also a multi-mode speech codec.
   AMR-WB supports nine wide band speech coding modes with respective
   bit rates ranging from 6.6 to 23.85 kbps.  The sampling frequency
   used in AMR-WB is 16000 Hz and the speech processing is performed on
   20 ms frames.  This means that each AMR-WB encoded frame represents
   320 speech samples.

3.3.  Multi-Rate Encoding and Mode Adaptation

   The multi-rate encoding (i.e., multi-mode) capability of AMR and
   AMR-WB is designed for preserving high speech quality under a wide
   range of transmission conditions.

   With AMR or AMR-WB, mobile radio systems are able to use available
   bandwidth as effectively as possible.  For example, in GSM it is
   possible to dynamically adjust the speech encoding rate during a
   session so as to continuously adapt to the varying transmission
   conditions by dividing the fixed overall bandwidth between speech
   data and error protective coding.  This enables the best possible
   trade-off between speech compression rate and error tolerance.  To
   perform mode adaptation, the decoder (speech receiver) needs to
   signal the encoder (speech sender) the new mode it prefers.  This
   mode change signal is called Codec Mode Request or CMR.

   Since in most sessions speech is sent in both directions between the
   two ends, the mode requests from the decoder at one end to the
   encoder at the other end are piggy-backed over the speech frames in
   the reverse direction.  In other words, there is no out-of-band
   signaling needed for sending CMRs.

   Every AMR or AMR-WB codec implementation is required to support all
   the respective speech coding modes defined by the codec and must be
   able to handle mode switching to any of the modes at any time.
   However, some transport systems may impose limitations in the number
   of modes supported and how often the mode can change due to bandwidth

Top      ToC       Page 7 
   limitations or other constraints.  For this reason, the decoder is
   allowed to indicate its acceptance of a particular mode or a subset
   of the defined modes for the session using out-of-band means.

   For example, the GSM radio link can only use a subset of at most four
   different modes in a given session.  This subset can be any
   combination of the eight AMR modes for an AMR session or any
   combination of the nine AMR-WB modes for an AMR-WB session.

   Moreover, for better interoperability with GSM through a gateway, the
   decoder is allowed to use out-of-band means to set the minimum number
   of frames between two mode changes and to limit the mode change among
   neighboring modes only.

   Section 8 specifies a set of media type parameters that may be used
   to signal these mode adaptation controls at session setup.

3.4.  Voice Activity Detection and Discontinuous Transmission

   Both codecs support 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 of
   sending CN parameters at regular intervals during silence periods is
   usually called discontinuous transmission (DTX) or source controlled
   rate (SCR) operation.  The AMR or AMR-WB frames containing CN
   parameters are called Silence Indicator (SID) frames.  See more
   details about VAD and DTX functionality in [9] and [10].

3.5.  Support for Multi-Channel Session

   Both the RTP payload format and the storage format defined in this
   document support multi-channel audio content (e.g., a stereophonic
   speech session).

   Although AMR and AMR-WB codecs themselves do not support encoding of
   multi-channel audio content into a single bit stream, they can be
   used to separately encode and decode each of the individual channels.

   To transport (or store) the separately encoded multi-channel content,
   the speech frames for all channels that are framed and encoded for
   the same 20 ms periods are logically collected in a frame-block.

   At the session setup, out-of-band signaling must be used to indicate
   the number of channels in the session, and the order of the speech
   frames from different channels in each frame-block.  When using SDP
   for signaling, the number of channels is specified in the rtpmap
   attribute and the order of channels carried in each frame-block is

Top      ToC       Page 8 
   implied by the number of channels as specified in Section 4.1 in
   [12].

3.6.  Unequal Bit-Error Detection and Protection

   The speech bits encoded in each AMR or AMR-WB frame have different
   perceptual sensitivity to bit errors.  This property has been
   exploited in cellular systems to achieve better voice quality by
   using unequal error protection and detection (UEP and UED)
   mechanisms.

   The UEP/UED mechanisms focus the protection and detection of
   corrupted bits to the perceptually most sensitive bits in an AMR or
   AMR-WB frame.  In particular, speech bits in an AMR or AMR-WB frame
   are divided into class A, B, and C, where bits in class A are the
   most sensitive and bits in class C the least sensitive (see Table 1
   below for AMR and [4] for AMR-WB).  An AMR or AMR-WB frame is only
   declared damaged if there are bit errors found in the most sensitive
   bits, i.e., the class A bits.  On the other hand, it is acceptable to
   have some bit errors in the other bits, i.e., class B and C bits.

                                   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

   Moreover, a damaged frame is still useful for error concealment at
   the decoder since some of the less sensitive bits can still be used.
   This approach can improve the speech quality compared to discarding
   the damaged frame.

3.6.1.  Applying UEP and UED in an IP Network

   To take full advantage of the bit-error robustness of the AMR and
   AMR-WB codec, the RTP payload format is designed to facilitate
   UEP/UED in an IP network.  It should be noted however that the
   utilization of UEP and UED discussed below is OPTIONAL.

Top      ToC       Page 9 
   UEP/UED in an IP network can be achieved by detecting bit errors in
   class A bits and tolerating bit errors in class B/C bits of the AMR
   or AMR-WB frame(s) in each RTP payload.

   Link-layer protocols exist that do not discard packets containing bit
   errors, e.g., SLIP and some wireless links.  With the Internet
   traffic pattern shifting towards a more multimedia-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 [19]), bit error tolerant AMR and AMR-WB traffic could
   achieve better performance over these types of links.  The
   relationship between UDP-Lite's partial checksum at the transport
   layer and the checksum coverage provided by the link-layer frame is
   described in UDP-Lite specification [19].

   There are at least two basic approaches for carrying AMR and AMR-WB
   traffic over bit error tolerant IP networks:

   a) Utilizing a partial checksum to cover the IP, transport protocol
      (e.g., UDP-Lite), RTP and payload headers, and the most important
      speech bits of the payload.  The IP, UDP and RTP headers need to
      be protected, and it is recommended that at least all class A bits
      are covered by the checksum.

   b) Utilizing a partial checksum to only cover the IP, transport
      protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC
      to cover the class A bits of each speech frame in the RTP 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.

      Note, it is still important that the network designer pays
      attention to the class B and C residual bit error rate.  Though
      less sensitive to errors than class A bits, class B and C 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 the Universal Mobile
      Telecommunications System (UMTS) can be found in [24] and for
      AMR-WB in [25].

   The application interface to the UEP/UED transport protocol (e.g.,
   UDP-Lite) may not provide any control over the link error rate,
   especially in a gateway scenario.  Therefore, it is incumbent upon
   the designer of a node with a link interface of this type to choose a
   residual bit error rate that is low enough to support applications
   such as AMR encoding when transmitting packets of a UEP/UED transport
   protocol.

Top      ToC       Page 10 
   Approach 1 is bit efficient, flexible and simple, 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
   AMR or AMR-WB frames in a RTP payload, there is the possibility that
   a single bit error in protected bits will cause all the frames to be
   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.  For b), when transporting multiple frames in a
   payload, the CRCs remove the possibility that a single bit error in a
   class A bit will cause all the frames to be discarded.  Avoiding that
   improves the speech quality when transporting multiple AMR or AMR-WB
   frames over links subject to bit errors.

   The choice between the above two approaches must be made based on the
   available bandwidth, and the desired tolerance to bit errors.
   Neither solution is appropriate for all cases.  Section 8 defines
   parameters that may be used at session setup to choose between these
   approaches.

3.7.  Robustness against Packet Loss

   The payload format supports several means, including forward error
   correction (FEC) and frame interleaving, to increase robustness
   against packet loss.

3.7.1.  Use of Forward Error Correction (FEC)

   The simple scheme of repetition of previously sent data is one way of
   achieving FEC.  Another possible scheme which is more bandwidth
   efficient is to use payload-external FEC, e.g., RFC 2733 [23], 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 also a work in progress on a generic
   version of such a scheme [22] that can be applied to AMR or AMR-WB
   payload transport.

   With AMR or AMR-WB, it is possible to use the multi-rate capability
   of the codec to send redundant copies of a frame using either the
   same mode or another mode, e.g., one with lower bandwidth.  We
   describe such a scheme next.

Top      ToC       Page 11 
   This involves the simple retransmission of previously transmitted
   frame-blocks together with the current frame-block(s).  This is done
   by using a sliding window to group the speech frame-blocks to send in
   each payload.  Figure 1 below shows us an example.

   --+--------+--------+--------+--------+--------+--------+--------+--
     | f(n-2) | f(n-1) |  f(n)  | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
   --+--------+--------+--------+--------+--------+--------+--------+--

     <---- p(n-1) ---->
              <----- p(n) ----->
                       <---- p(n+1) ---->
                                <---- p(n+2) ---->
                                         <---- p(n+3) ---->
                                                  <---- p(n+4) ---->

              Figure 1: An example of redundant transmission

   In this example each frame-block is retransmitted one time in the
   following RTP payload packet.  Here, f(n-2)..f(n+4) denotes a
   sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of
   payload packets.

   The use of this approach does not require signaling at the session
   setup.  However, a parameter for providing a maximum delay in
   transmitting any redundant frame is defined in Section 8.  In other
   words, the speech sender can choose to use this scheme without
   consulting the receiver.  This is because 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 is lost.  If multiple versions of the same speech frame are
   received, it is recommended that the mode with the highest rate be
   used by the speech decoder.

   This redundancy scheme provides the same functionality as the one
   described in RFC 2198, "RTP Payload for Redundant Audio Data" [27].
   In most cases the mechanism in this payload format is more efficient
   and simpler than requiring both endpoints to support RFC 2198 in
   addition.  There are two situations in which use of RFC 2198 is
   indicated: if the spread in time required between the primary and
   redundant encodings is larger than the duration of 5 frames, the
   bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec
   is desired for the redundant encoding, the AMR payload format won't
   be able to carry it.

   The sender is responsible for selecting an appropriate amount of
   redundancy based on feedback about the channel, e.g., in RTCP

Top      ToC       Page 12 
   receiver reports.  A sender should not base selection of FEC on the
   CMR, as this parameter most probably was set based on non-IP
   information, e.g., radio link performance measures.  The sender is
   also responsible for avoiding congestion, which may be exacerbated by
   redundancy (see Section 6 for more details).

3.7.2.  Use of Frame Interleaving

   To decrease protocol overhead, the payload design allows several
   speech frame-blocks to be encapsulated into a single RTP packet.  One
   of the drawbacks of such an approach is that packet loss can cause
   loss of several consecutive speech frame-blocks, which usually causes
   clearly audible distortion in the reconstructed speech.  Interleaving
   of frame-blocks can improve the speech quality in such cases by
   distributing the consecutive losses into a series of single frame-
   block losses.  However, interleaving and bundling several frame-
   blocks per payload will also increase end-to-end delay and is
   therefore not appropriate for all types of applications.  Streaming
   applications will most likely be able to exploit interleaving to
   improve speech quality in lossy transmission conditions.

   This payload design supports the use of frame interleaving as an
   option.  For the encoder (speech sender) to use frame interleaving in
   its outbound RTP packets for a given session, the decoder (speech
   receiver) needs to indicate its support via out-of-band means (see
   Section 8).

3.8.  Bandwidth-Efficient or Octet-Aligned Mode

   For a given session, the payload format can be either bandwidth
   efficient or octet aligned, depending on the mode of operation that
   is established for the session via out-of-band means.

   In the octet-aligned format, all the fields in a payload, including
   payload header, table of contents entries, and speech frames
   themselves, are individually aligned to octet boundaries to make
   implementations efficient.  In the bandwidth-efficient format, only
   the full payload is octet aligned, so fewer padding bits are added.

      Note, octet alignment of a field or payload means that the last
      octet is padded with zeroes in the least significant bits to fill
      the octet.  Also note that this padding is separate from padding
      indicated by the P bit in the RTP header.

   Between the two operation modes, only the octet-aligned mode has the
   capability to use the robust sorting, interleaving, and frame CRC to
   make the speech transport more robust to packet loss and bit errors.

Top      ToC       Page 13 
3.9.  AMR or AMR-WB Speech over IP Scenarios

   The primary scenario for this payload format is IP end-to-end between
   two terminals, as shown in Figure 2.  This payload format is expected
   to be useful for both conversational and streaming services.

                +----------+                         +----------+
                |          |    IP/UDP/RTP/AMR or    |          |
                | TERMINAL |<----------------------->| TERMINAL |
                |          |    IP/UDP/RTP/AMR-WB    |          |
                +----------+                         +----------+

                   Figure 2: IP terminal to IP terminal scenario

   A conversational service puts requirements on the payload format.
   Low delay is one very important factor, i.e., few speech frame-blocks
   per payload packet.  Low overhead is also required when the payload
   format traverses low bandwidth links, especially as the frequency of
   packets will be high.  For low bandwidth links, it is also an
   advantage to support UED, which allows a link provider to reduce
   delay and packet loss, or to reduce the utilization of link
   resources.

   A streaming service has less strict real-time requirements and
   therefore can use a larger number of frame-blocks per packet than a
   conversational service.  This reduces the overhead from IP, UDP, and
   RTP headers.  However, including several frame-blocks per packet
   makes the transmission more vulnerable to packet loss, so
   interleaving may be used to reduce the effect that packet loss will
   have on speech quality.  A streaming server handling a large number
   of clients also needs a payload format that requires as few resources
   as possible when doing packetization.  The octet-aligned and
   interleaving modes require the least amount of resources, while CRC,
   robust sorting, and bandwidth-efficient modes have higher demands.

   Another scenario is when AMR or AMR-WB encoded speech is transmitted
   from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an
   IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.

Top      ToC       Page 14 
          AMR or AMR-WB
          over
          I.366.{2,3} or +------+                        +----------+
          3G Iu or       |      |   IP/UDP/RTP/AMR or    |          |
          <------------->|  GW  |<---------------------->| TERMINAL |
          GSM Abis       |      |   IP/UDP/RTP/AMR-WB    |          |
          etc.           +------+                        +----------+
                             |
           GSM/              |           IP network
           3GPP UMTS network |

                     Figure 3: GW to VoIP terminal scenario

   In such a case, it is likely that the AMR or AMR-WB frame is
   packetized in a different way in the non-IP network and will need to
   be re-packetized into RTP at the gateway.  Also, speech frames from
   the non-IP network may come with some UEP/UED information (e.g., a
   frame quality indicator) that will need to be preserved and forwarded
   on to the decoder along with the speech bits.  This is specified in
   Section 4.3.2.

   AMR's capability to do fast mode switching is exploited in some non-
   IP networks to optimize speech quality.  To preserve this
   functionality in scenarios including a gateway to an IP network, a
   codec mode request (CMR) field is needed.  The gateway will be
   responsible for forwarding the CMR between the non-IP and IP parts in
   both directions.  The IP terminal should follow the CMR forwarded by
   the gateway to optimize speech quality going to the non-IP decoder.
   The mode control algorithm in the gateway must accommodate the delay
   imposed by the IP network on the IP terminal's response to CMR.

   The IP terminal should not set the CMR (see Section 4.3.1), but the
   gateway can set the CMR value on frames going toward the encoder in
   the non-IP part to optimize speech quality from that encoder to the
   gateway.  The gateway can alternatively set a lower CMR value, if
   desired, as one means to control congestion on the IP network.

   A third likely scenario is that IP/UDP/RTP is used as transport
   between two non-IP systems, i.e., IP is originated and terminated in
   gateways on both sides of the IP transport, as illustrated in Figure
   4 below.

Top      ToC       Page 15 
   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.
                      |                           |
    GSM/              |          IP network       |  GSM/
    3GPP UMTS network |                           |  3GPP UMTS network

                        Figure 4: GW to GW scenario

   This scenario requires the same mechanisms for preserving UED/UEP and
   CMR information as in the single gateway scenario.  In addition, the
   CMR value may be set in packets received by the gateways on the IP
   network side.  The gateway should forward to the non-IP side a CMR
   value that is the minimum of three values:

      -  the CMR value it receives on the IP side;

      -  the CMR value it calculates based on its reception quality on
         the non-IP side; and

      -  a CMR value it may choose for congestion control of
         transmission on the IP side.

   The details of the control algorithm are left to the implementation.



(page 15 continued on part 2)

Next RFC Part