tech-invite   World Map     

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

RFC 4867

 
 
 

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

Part 3 of 3, p. 38 to 59
Prev RFC Part

 


prevText      Top      Up      ToC       Page 38 
6.  Congestion Control

   The general congestion control considerations for transporting RTP
   data apply to AMR or AMR-WB speech over RTP as well.  However, the
   multi-rate capability of AMR and AMR-WB speech coding may provide an
   advantage over other payload formats for controlling congestion since
   the bandwidth demand can be adjusted by selecting a different coding
   mode.

   Another parameter that may impact the bandwidth demand for AMR and
   AMR-WB is the number of frame-blocks that are encapsulated in each
   RTP payload.  Packing more frame-blocks in each RTP payload can
   reduce the number of packets sent and hence the overhead from
   IP/UDP/RTP headers, at the expense of increased delay.

   If forward error correction (FEC) is used to combat packet loss, the
   amount of redundancy added by FEC will need to be regulated so that
   the use of FEC itself does not cause a congestion problem.

   It is RECOMMENDED that AMR or AMR-WB applications using this payload
   format employ congestion control.  The actual mechanism for
   congestion control is not specified but should be suitable for real-
   time flows, possibly "TCP Friendly Rate Control" [21].

7.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the general security considerations discussed in [8]
   and in any used profile, like AVP [12] or SAVP [26].

   As this format transports encoded speech, the main security issues
   include confidentiality, authentication, and integrity of the speech
   itself.  The payload format itself does not have any built-in
   security mechanisms.  External mechanisms, such as SRTP [26], need to
   be used for this functionality.  Note that the appropriate mechanism
   to provide security to RTP and the payloads following this memo may
   vary.  It is dependent on the application, the transport, and the
   signaling protocol employed.  Therefore, a single mechanism is not
   sufficient, although if suitable the usage of SRTP [26] is
   RECOMMENDED.  Other known mechanisms that may be used are IPsec [33]
   and TLS [34] (RTP over TCP), but other alternatives may also exist.

   This payload format does not exhibit any significant non-uniformity
   in the receiver side computational complexity for packet processing,
   and thus is unlikely to pose a denial-of-service threat due to the
   receipt of pathological data.

Top      Up      ToC       Page 39 
7.1.  Confidentiality

   To achieve confidentiality of the encoded AMR or AMR-WB speech, all
   speech data bits will need to be encrypted.  There is less of a need
   to encrypt the payload header or the table of contents due to a) that
   they only carry information about the requested speech mode, frame
   type, and frame quality, and b) that this information could be useful
   to some third party, e.g., quality monitoring.

   The packetization and unpacketization of the AMR and AMR-WB payload
   is done only at the endpoints.  Therefore encryption should be
   performed after packet encapsulation, and decryption should be
   performed before packet decapsulation.

   Encryption may affect interleaving.  Specifically, a change of keys
   should occur at the boundary between interleaving groups.  If it is
   not done at that boundary on both endpoints, the speech quality will
   be degraded during the complete interleaving group for any receiver.

   The encryption mechanism may impact the robustness of the error
   correcting mechanism.  This is discussed in Section 9.5 of SRTP [26].
   From this, UED/UEP based on robust sorting may be difficult to apply
   when the payload data is encrypted.


7.2.  Authentication and Integrity

   To authenticate the sender and to protect the integrity of the RTP
   packets in transit, an external mechanism has to be used.  As stated
   before, it is RECOMMENDED that SRTP [26] be used for common
   interoperability.  Note that the use of UED/UEP may be difficult to
   combine with some integrity protection mechanisms because any bit
   errors will cause the integrity check to fail.

   Data tampering by a man-in-the-middle attacker could result in
   erroneous depacketization/decoding that could lower the speech
   quality or produce unintelligible communications.  Tampering with the
   CMR field may result in a different speech quality than desired.

8.  Payload Format Parameters

   This section defines the parameters that may be used to select
   optional features of the AMR and AMR-WB payload formats.  The
   parameters are defined here as part of the media type registrations
   for the AMR and AMR-WB speech codecs.  The registrations are done
   following RFC 4855 [15] and the media registration rules [14].

Top      Up      ToC       Page 40 
   A mapping of the parameters into the Session Description Protocol
   (SDP) [11] is also provided for those applications that use SDP.
   Equivalent parameters could be defined elsewhere for use with control
   protocols that do not use media types or SDP.

   Two separate media type registrations are made, one for AMR and one
   for AMR-WB, because they are distinct encodings that must be
   distinguished by their own media type.

   Data formats are specified for both real-time transport in RTP and
   for storage type applications such as email attachments.

8.1.  AMR Media Type Registration

   The media type for the Adaptive Multi-Rate (AMR) codec is allocated
   from the IETF tree since AMR is a widely used speech codec in general
   VoIP and messaging applications.  This media type registration covers
   both real-time transfer via RTP and non-real-time transfers via
   stored files.

   Note, any unspecified parameter MUST be ignored by the receiver.

   Media Type name:     audio

   Media subtype name:  AMR

   Required parameters: none

   Optional parameters:

      These parameters apply to RTP transfer only.

      octet-align: Permissible values are 0 and 1.  If 1, octet-aligned
               operation SHALL be used.  If 0 or if not present,
               bandwidth-efficient operation is employed.

      mode-set: Restricts the active codec mode set to a subset of all
               modes, for example, to be able to support transport
               channels such as GSM networks in gateway use cases.
               Possible values are a comma separated list of modes from
               the set: 0,...,7 (see Table 1a [2]).  The SID frame type
               8 and NO_DATA (frame type 15) are never included in the
               mode set, but can always be used.  If mode-set is
               specified, it MUST be abided, and frames encoded with
               modes outside of the subset MUST NOT be sent in any RTP
               payload or used in codec mode requests.  If not present,
               all codec modes are allowed for the payload type.

Top      Up      ToC       Page 41 
      mode-change-period: Specifies a number of frame-blocks, N (1 or
               2), that is the frame-block period at which codec mode
               changes are allowed for the sender.  The initial phase of
               the interval is arbitrary, but changes must be separated
               by a period of N frame-blocks, i.e., a value of 2
               allows the sender to change mode every second frame-
               block.  The value of N SHALL be either 1 or 2.  If this
               parameter is not present, mode changes are allowed at
               any time during the session, i.e., N=1.

      mode-change-capability: Specifies if the client is capable to
               transmit with a restricted mode change period.  The
               parameter may take value of 1 or 2.  A value of 1
               indicates that the client is not capable of restricting
               the mode change period to 2, and that the codec mode may
               be changed at any point.  A value of 2 indicates that the
               client has the capability to restrict the mode change
               period to 2, and thus that the client can correctly
               interoperate with a receiver requiring a mode-change-
               period=2.  If this parameter is not present, the mode-
               change restriction capability is not supported, i.e.
               mode-change-capability=1.  To be able to interoperate
               fully with gateways to circuit switched networks (for
               example, GSM networks), transmissions with restricted
               mode changes (mode-change-capability=2) are required.
               Thus, clients RECOMMENDED to have the capability to
               support transmission according to
               mode-change-capability=2.

      mode-change-neighbor: Permissible values are 0 and 1.  If 1, the
               sender SHOULD only perform mode changes to the
               neighboring modes in the active codec mode set.

               Neighboring modes are the ones closest in bit rate to
               the current mode, either the next higher or next lower
               rate.  If 0 or if not present, change between any two
               modes in the active codec mode set is allowed.

      maxptime: The maximum amount of media which can be encapsulated
               in a payload packet, expressed as time in milliseconds.
               The time is calculated as the sum of the time that the
               media present in the packet represents.  The time SHOULD
               be an integer multiple of the frame size.  If this
               parameter is not present, the sender MAY encapsulate any
               number of speech frames into one RTP packet.

Top      Up      ToC       Page 42 
      crc: Permissible values are 0 and 1.  If 1, frame CRCs SHALL be
               included in the payload.  If 0 or not present, CRCs
               SHALL NOT be used.  If crc=1, this also implies
               automatically that octet-aligned operation SHALL be used
               for the session.

      robust-sorting: Permissible values are 0 and 1.  If 1, the
               payload SHALL employ robust payload sorting.  If 0 or if
               not present, simple payload sorting SHALL be used.  If
               robust-sorting=1, this also implies automatically that
               octet-aligned operation SHALL be used for the session.

      interleaving: Indicates that frame-block level interleaving SHALL
               be used for the session, and its value defines the
               maximum number of frame-blocks allowed in an
               interleaving group (see Section 4.4.1).  If this
               parameter is not present, interleaving SHALL NOT be
               used.  The presence of this parameter also implies
               automatically that octet-aligned operation SHALL be
               used.

      ptime: see RFC 4566 [11].

      channels: The number of audio channels.  The possible values
               (1-6) and their respective channel order is specified in
               Section 4.1 in [12].  If omitted, it has the default
               value of 1.

      max-red: The maximum duration in milliseconds that elapses between
               the primary (first) transmission of a frame and any
               redundant transmission that the sender will use.  This
               parameter allows a receiver to have a bounded delay when
               redundancy is used.  Allowed values are between 0 (no
               redundancy will be used) and 65535.  If the parameter is
               omitted, no limitation on the use of redundancy is
               present.

   Encoding considerations:
        The Audio data is binary data, and must be encoded for non-
        binary transport; the Base64 encoding is suitable for email.
        When used in RTP context the data is framed as defined in [14].

   Security considerations:
        See Section 7 of RFC 4867.

   Public specification:
        RFC 4867
        3GPP TS 26.090, 26.092, 26.093, 26.101

Top      Up      ToC       Page 43 
   Applications that use this media type:
        This media type is used in numerous applications needing
        transport or storage of encoded voice.  Some examples include;
        Voice over IP, streaming media, voice messaging, and voice
        recording on digital cameras.

   Additional information:
        The following applies to stored-file transfer methods:

        Magic numbers:
           single-channel:
              ASCII character string "#!AMR\n"
              (or 0x2321414d520a in hexadecimal)
           multi-channel:
             ASCII character string "#!AMR_MC1.0\n"
             (or 0x2321414d525F4D43312E300a in hexadecimal)
        File extensions: amr, AMR
        Macintosh file type code: "amr " (fourth character is space)

        AMR speech frames may also be stored in the file format "3GP"
        defined in 3GPP TS 26.244 [31], which is identified using the
        media types "audio/3GPP" or "video/3GPP" as registered by RFC
        3839 [32].

   Person & email address to contact for further information:
        Magnus Westerlund <magnus.westerlund@ericsson.com>
        Ari Lakaniemi <ari.lakaniemi@nokia.com>

   Intended usage: COMMON.
        This media type is widely used in streaming, VoIP, and messaging
        applications on many types of devices.

   Restrictions on usage:
        When this media type is used in the context of transfer over
        RTP, the RTP payload format specified in Section 4 SHALL be
        used.  In all other contexts, the file format defined in Section
        5 SHALL be used.

   Author:
        Magnus Westerlund <magnus.westerlund@ericsson.com>
        Ari Lakaniemi <ari.lakaniemi@nokia.com>

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

Top      Up      ToC       Page 44 
8.2.  AMR-WB Media Type Registration

   The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is
   allocated from the IETF tree since AMR-WB is a widely used speech
   codec in general VoIP and messaging applications.  This media type
   registration covers both real-time transfer via RTP and non-real-
   time transfers via stored files.

   Note, any unspecified parameter MUST be ignored by the receiver.

   Media Type name:     audio

   Media subtype name:  AMR-WB

   Required parameters: none

   Optional parameters:

      These parameters apply to RTP transfer only.

      octet-align: Permissible values are 0 and 1.  If 1, octet-aligned
               operation SHALL be used.  If 0 or if not present,
               bandwidth-efficient operation is employed.

      mode-set:  Restricts the active codec mode set to a subset of all
               modes, for example, to be able to support transport
               channels such as GSM networks in gateway use cases.
               Possible values are a comma-separated list of modes from
               the set: 0,...,8 (see Table 1a [4]).  The SID frame type
               9, SPEECH_LOST (frame type 14), and NO_DATA (frame type
               15) are never included in the mode set, but can always
               be used.  If mode-set is specified, it MUST be abided,
               and frames encoded with modes outside of the subset MUST
               NOT be sent in any RTP payload or used in codec mode
               requests.  If not present, all codec modes are allowed
               for the payload type.

      mode-change-period: Specifies a number of frame-blocks, N (1 or
               2), that is the frame-block period at which codec mode
               changes are allowed for the sender.  The initial phase of
               the interval is arbitrary, but changes must be separated
               by multiples of N frame-blocks, i.e., a value of 2
               allows the sender to change mode every second frame-
               block.  The value of N SHALL be either 1 or 2.  If this
               parameter is not present, mode changes are allowed at
               Any time during the session, i.e., N=1.

Top      Up      ToC       Page 45 
      mode-change-capability: Specifies if the client is capable to
               transmit with a restricted mode change period.  The
               parameter may take value of 1 or 2.  A value of 1
               indicates that the client is not capable of restricting
               the mode change period to 2, and that the codec mode may
               be changed at any point.  A value of 2 indicates that the
               client has the capability to restrict the mode change
               period to 2, and thus that the client can correctly
               interoperate with a receiver requiring a mode-change-
               period=2.  If this parameter is not present, the mode-
               change restriction capability is not supported, i.e.
               mode-change-capability=1.  To be able to interoperate
               fully with gateways to circuit switched networks (for
               example, GSM networks), transmissions with restricted
               mode changes (mode-change-capability=2) are required.
               Thus, clients are RECOMMENDED to have the capability to
               support transmission according to
               mode-change-capability=2.

      mode-change-neighbor: Permissible values are 0 and 1.  If 1, the
               sender SHOULD only perform mode changes to the
               neighboring modes in the active codec mode set.
               Neighboring modes are the ones closest in bit rate to
               the current mode, either the next higher or next lower
               rate.  If 0 or if not present, change between any two
               modes in the active codec mode set is allowed.

      maxptime: The maximum amount of media which can be encapsulated
               in a payload packet, expressed as time in milliseconds.
               The time is calculated as the sum of the time that the
               media present in the packet represents.  The time SHOULD
               be an integer multiple of the frame size.  If this
               parameter is not present, the sender MAY encapsulate any
               number of speech frames into one RTP packet.

      crc: Permissible values are 0 and 1.  If 1, frame CRCs SHALL be
               included in the payload.  If 0 or not present, CRCs
               SHALL NOT be used.  If crc=1, this also implies
               automatically that octet-aligned operation SHALL be used
               for the session.

      robust-sorting: Permissible values are 0 and 1.  If 1, the
               payload SHALL employ robust payload sorting.  If 0 or if
               not present, simple payload sorting SHALL be used.  If
               robust-sorting=1, this also implies automatically that
               octet-aligned operation SHALL be used for the session.

Top      Up      ToC       Page 46 
      interleaving: Indicates that frame-block level interleaving SHALL
               be used for the session, and its value defines the
               maximum number of frame-blocks allowed in an
               interleaving group (see Section 4.4.1).  If this
               parameter is not present, interleaving SHALL NOT be
               used.  The presence of this parameter also implies
               automatically that octet-aligned operation SHALL be
               used.

      ptime: see RFC 2327 [11].

      channels: The number of audio channels.  The possible values
               (1-6) and their respective channel order is specified in
               Section 4.1 in [12].  If omitted, it has the default
               value of 1.

      max-red: The maximum duration in milliseconds that elapses between
               the primary (first) transmission of a frame and any
               redundant transmission that the sender will use.  This
               parameter allows a receiver to have a bounded delay when
               redundancy is used.  Allowed values are between 0 (no
               redundancy will be used) and 65535.  If the parameter is
               omitted, no limitation on the use of redundancy is
               present.

   Encoding considerations:
        The Audio data is binary data, and must be encoded for non-
        binary transport; the Base64 encoding is suitable for email.
        When used in RTP context the data is framed as defined in [14].

   Security considerations:
        See Section 7 of RFC 4867.

   Public specification:
        RFC 4867
        3GPP TS 26.190, 26.192, 26.193, 26.201

   Applications that use this media type:
        This media type is used in numerous applications needing
        transport or storage of encoded voice.  Some examples include;
        Voice over IP, streaming media, voice messaging, and voice
        recording on digital cameras.

Top      Up      ToC       Page 47 
   Additional information:
        The following applies to stored-file transfer methods:

        Magic numbers:
          single-channel:
          ASCII character string "#!AMR-WB\n"
          (or 0x2321414d522d57420a in hexadecimal)
          multi-channel:
          ASCII character string "#!AMR-WB_MC1.0\n"
          (or 0x2321414d522d57425F4D43312E300a in hexadecimal)
        File extensions: awb, AWB
        Macintosh file type code: amrw
        Object identifier or OID: none

        AMR-WB speech frames may also be stored in the file format "3GP"
        defined in 3GPP TS 26.244 [31] and identified using the media
        type "audio/3GPP" or "video/3GPP" as registered by RFC 3839
        [32].

   Person & email address to contact for further information:
        Magnus Westerlund <magnus.westerlund@ericsson.com>
        Ari Lakaniemi <ari.lakaniemi@nokia.com>

   Intended usage: COMMON.
        This media type is widely used in streaming, VoIP, and messaging
        applications on many types of devices.

   Restrictions on usage:
        When this media type is used in the context of transfer over
        RTP, the RTP payload format specified in Section 4 SHALL be
        used.  In all other contexts, the file format defined in Section
        5 SHALL be used.

   Author:
        Magnus Westerlund <magnus.westerlund@ericsson.com>
        Ari Lakaniemi <ari.lakaniemi@nokia.com>

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

8.3.  Mapping Media Type Parameters into SDP

   The information carried in the media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [11], which is commonly used to describe RTP sessions.  When SDP is
   used to specify sessions employing the AMR or AMR-WB codec, the
   mapping is as follows:

Top      Up      ToC       Page 48 
      -  The media type ("audio") goes in SDP "m=" as the media name.

      -  The media subtype (payload format name) goes in SDP "a=rtpmap"
         as the encoding name.  The RTP clock rate in "a=rtpmap" MUST be
         8000 for AMR and 16000 for AMR-WB, and the encoding parameters
         (number of channels) MUST either be explicitly set to N or
         omitted, implying a default value of 1.  The values of N that
         are allowed are specified in Section 4.1 in [12].

      -  The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
         and "a=maxptime" attributes, respectively.

      -  Any remaining parameters go in the SDP "a=fmtp" attribute by
         copying them directly from the media type parameter string as a
         semicolon-separated list of parameter=value pairs.

8.3.1.  Offer-Answer Model Considerations

   The following considerations apply when using SDP Offer-Answer
   procedures to negotiate the use of AMR or AMR-WB payload in RTP:

      -  Each combination of the RTP payload transport format
         configuration parameters (octet-align, crc, robust-sorting,
         interleaving, and channels) is unique in its bit-pattern and
         not compatible with any other combination.  When creating an
         offer in an application desiring to use the more advanced
         features (crc, robust-sorting, interleaving, or more than one
         channel), the offerer is RECOMMENDED to also offer a payload
         type containing only the octet-aligned or bandwidth-efficient
         configuration with a single channel.  If multiple
         configurations are of interest to the application, they may all
         be offered; however, care should be taken not to offer too many
         payload types.  An SDP answerer MUST include, in the SDP answer
         for a payload type, the following parameters unmodified from
         the SDP offer (unless it removes the payload type): "octet-
         align"; "crc"; "robust-sorting"; "interleaving"; and
         "channels".  The SDP offerer and answerer MUST generate AMR or
         AMR-WB packets as described by these parameters.

      -  The "mode-set" parameter can be used to restrict the set of
         active AMR/AMR-WB modes used in a session.  This functionality
         is primarily intended for gateways to access networks such as
         GSM or 3GPP UMTS, where the access network may be capable of
         supporting only a subset of AMR/AMR-WB modes.  The 3GPP
         preferred codec configurations are defined in 3GPP TS 26.103
         [25], and it is RECOMMENDED that other networks also needing to
         restrict the mode set follow the preferred codec configurations
         defined in 3GPP for greatest interoperability.

Top      Up      ToC       Page 49 
         The parameter is bi-directional, i.e., the restricted set
         applies to media both to be received and sent by the declaring
         entity.  If a mode set was supplied in the offer, the answerer
         SHALL return the mode-set unmodified or reject the payload
         type.  However, the answerer is free to choose a mode-set in
         the answer only if no mode-set was supplied in the offer for a
         unicast two-peer session.  The mode-set in the answer is
         binding both for offerer and answerer.  Thus, an offerer
         supporting all modes and subsets SHOULD NOT include the mode-
         set parameter.  For any other offerer it is RECOMMENDED to
         include each mode-set it can support as a separate payload type
         within the offer.  For multicast sessions, the answerer SHALL
         only participate in the session if it supports the offered
         mode-set.  Thus, it is RECOMMENDED that any offer for a
         multicast session include only the mode-set it will require the
         answerers to support, and that the mode-set be likely to be
         supported by all participants.

      -  The parameters "mode-change-period" and "mode-change-
         capability" are intended to be used in sessions with gateways,
         for example, when interoperating with GSM networks.  Both
         parameters are declarative and are combined to allow a session
         participant to determine if the payload type can be supported.
         The mode-change-period will indicate what the offerer or
         answerer requires of data it receives, while the mode-change-
         capability indicates its transmission capabilities.

         A mode-change-period=2 in the offer indicates a requirement on
         the answerer to send with a mode-change period of 2, i.e.,
         support mode-change-capability=2.  If the answerer requires
         mode-change-period=2, it SHALL only include it in the answer if
         the offerer either has indicated support with mode-change-
         capability=2 or has indicated mode-change-period=2; otherwise,
         the payload type SHALL be rejected.  An offerer that supports
         mode-change-capability=2 SHALL include the parameter in all
         offers to ensure the greatest possible interoperability, unless
         it includes mode-change-period=2 in the offer.  The mode-
         change-capability SHOULD be included in answers.  It is then
         indicating the answerer's capability to transmit with that
         mode-change-period for the provided payload format
         configuration.  The information is useful in future
         re-negotiation of the payload formats.

      -  The parameter "mode-change-neighbor" is a recommendation to
         restrict the switching of codec modes to its neighbor and
         SHOULD be followed.  It is intended to be used in gateway
         scenarios (for example, to GSM networks) where the support of

Top      Up      ToC       Page 50 
         this parameter and the operations it implies improves
         interoperability.

         "mode-change-neighbor" is a declarative parameter.  By
         including the parameter, the offerer or answerer indicates that
         it desires to receive streams with "mode-change-neighbor"
         restrictions.

      -  In most cases, the parameters "maxptime" and "ptime" will not
         affect interoperability; however, the setting of the parameters
         can affect the performance of the application.  The SDP offer-
         answer handling of the "ptime" parameter is described in RFC
         3264 [13].  The "maxptime" parameter MUST be handled in the
         same way.

      -  The parameter "max-red" is a stream property parameter.  For
         send-only or send-recv unicast media streams, the parameter
         declares the limitation on redundancy that the stream sender
         will use.  For recvonly streams, it indicates the desired value
         for the stream sent to the receiver.  The answerer MAY change
         the value, but is RECOMMENDED to use the same limitation as the
         offer declares.  In the case of multicast, the offerer MAY
         declare a limitation; this SHALL be answered using the same
         value.  A media sender using this payload format is RECOMMENDED
         to always include the "max-red" parameter.  This information is
         likely to simplify the media stream handling in the receiver.
         This is especially true if no redundancy will be used, in which
         case "max-red" is set to 0.  As this parameter was not defined
         originally, some senders will not declare this parameter even
         if it will limit or not send redundancy at all.

      -  Any unknown parameter in an offer SHALL be removed in the
         answer.

8.3.2.  Usage of Declarative SDP

   In declarative usage, like SDP in RTSP [29] or SAP [30], the
   parameters SHALL be interpreted as follows:

   -  The payload format configuration parameters (octet-align, crc,
      robust-sorting, interleaving, and channels) are all declarative,
      and a participant MUST use the configuration(s) that is provided
      for the session.  More than one configuration may be provided if
      necessary by declaring multiple RTP payload types; however, the
      number of types should be kept small.

Top      Up      ToC       Page 51 
   -  Any restriction of the AMR or AMR-WB encoder mode-switching and
      mode usage through the "mode-set", and "mode-change-period" MUST
      be followed by all participants of the session.  The restriction
      indicated by "mode-change-neighbor" SHOULD be followed.  Please
      note that such restrictions may be necessary if gateways to other
      transport systems like GSM participate in the session.  Failure to
      consider such restrictions may result in failure for a peer behind
      such a gateway to correctly receive all or parts of the session.
      Also, if different restrictions are needed by different peers in
      the same session (unless a common subset of the restrictions
      exists), some peer will not be able to participate.  Note that the
      usage of mode-change-capability is meaningless when no negotiation
      exists, and can thus be excluded in any declarations.

   -  Any "maxptime" and "ptime" values should be selected with care to
      ensure that the session's participants can achieve reasonable
      performance.

   -  The usage of "max-red" puts a global upper limit on the usage of
      redundancy that needs to be followed by all that understand the
      parameter.  However, due to the late addition of this parameter,
      it may be ignored by some implementations.

8.3.3.  Examples

   Some example SDP session descriptions utilizing AMR and AMR-WB
   encodings follow.  In these examples, long a=fmtp lines are folded to
   meet the column width constraints of this document; the backslash
   ("\") at the end of a line and the carriage return that follows it
   should be ignored.

   In an example of the usage of AMR in a possible GSM gateway-to-
   gateway scenario, the offerer is capable of supporting three
   different mode-sets and needs the mode-change-period to be 2 in
   combination with mode-change-neighbor restrictions.  The other
   gateway can only support two of these mode-sets and removes the
   payload type 97 in the answer.  If the offering GSM gateway only
   supports a single mode-set active at the same time, it should
   consider doing the 1 out of N selection procedures described in
   Section 10.2 of [13]:

Top      Up      ToC       Page 52 
   Offer:

    m=audio 49120 RTP/AVP 97 98 99
    a=rtpmap:97 AMR/8000/1
    a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
      mode-change-capability=2; mode-change-neighbor=1
    a=rtpmap:98 AMR/8000/1
    a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \
      mode-change-capability=2; mode-change-neighbor=1
    a=rtpmap:99 AMR/8000/1
    a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
      mode-change-capability=2; mode-change-neighbor=1
    a=maxptime:20

   Answer:

    m=audio 49120 RTP/AVP 98 99
    a=rtpmap:98 AMR/8000/1
    a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \<
      mode-change-capability=2; mode-change-neighbor=1
    a=rtpmap:99 AMR/8000/1
    a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
      mode-change-capability=2; mode-change-neighbor=1
    a=maxptime:20

   The following example shows the usage of AMR between a non-GSM
   endpoint and a GSM gateway.  The non-GSM offerer requires no
   restrictions of the mode-change-period or mode-change-neighbor, but
   must signal its mode-change-capability in the offer and abide by
   those restrictions in the answer.

   Offer:

    m=audio 49120 RTP/AVP 97
    a=rtpmap:97 AMR/8000/1
    a=fmtp:97 mode-change-capability=2
    a=maxptime:20

   Answer:

    m=audio 49120 RTP/AVP 97
    a=rtpmap:97 AMR/8000/1
    a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \
      mode-change-capability=2; mode-change-neighbor=1
    a=maxptime:20

Top      Up      ToC       Page 53 
   Example of usage of AMR-WB in a possible VoIP scenario where UEP may
   be used (99) and a fallback declaration (98):

    m=audio 49120 RTP/AVP 99 98
    a=rtpmap:98 AMR-WB/16000
    a=fmtp:98 octet-align=1; mode-change-capability=2
    a=rtpmap:99 AMR-WB/16000
    a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2

   Example of usage of AMR-WB in a possible streaming scenario (two
   channel stereo):

    m=audio 49120 RTP/AVP 99
    a=rtpmap:99 AMR-WB/16000/2
    a=fmtp:99 interleaving=30
    a=maxptime:100

   Note that the payload format (encoding) names are commonly shown in
   upper case.  MIME subtypes are commonly shown in lower case.  These
   names are case-insensitive in both places.  Similarly, parameter
   names are case-insensitive both in MIME types and in the default
   mapping to the SDP a=fmtp attribute.

9.  IANA Considerations

   Two media types (audio/AMR and audio/AMR-WB) have been updated; see
   Section 8.

10.  Changes from RFC 3267

   The differences between RFC 3267 and this document are as follows:

   -  Added clarification of behavior in regards to mode change period
      and mode-change neighbor that is expected from an IP client; see
      Section 4.5.

   -  Updated the maxptime for better clarification.  The sentence that
      previously read: "The time SHOULD be a multiple of the frame
      size." now says "The time SHOULD be an integer multiple of the
      frame size."  This should have no impact on interoperability.

   -  Updated the definition of the mode-set parameter for
      clarification.

   -  Restricted the values for mode-change-period to 1 or 2, which are
      the values used in circuit-switched AMR systems.

Top      Up      ToC       Page 54 
   -  Added a new media type parameter Mode-Change-Capability that
      defaults to 1, which is the assumed behavior of any non-updated
      implementation.  This enables the offer-answer procedures to work.

   -  Changed mode-change-neighbor to indicate a recommended behavior
      rather than a required one.

   -  Added an Offer-Answer Section, see Section 8.3.1.  This will have
      implications on the interoperability to implementations that have
      guessed how to perform offer/answer negotiation of the payload
      parameters.

   -  Clarified and aligned the unequal detection usage with the
      published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1.
      This included replacing a normative statement about packet
      handling with an informative paragraph with a reference to UDP-
      Lite.

   -  Clarified the bit order in the CRC calculation in Section 4.4.2.1.

   -  Corrected the reference in Section 5.3 for the Q and FT fields.

   -  Changed the padding bit definition in Sections 4.4.2 and 5.3 so
      that it is clear that they shall be ignored.

   -  Added a clarification that comfort noise frames with frame type 9,
      10, and 11 SHALL NOT be used in the AMR file format.

   -  Clarified in Section 4.3.2 that the rules about not sending
      NO_DATA frames do apply for all payload format configurations with
      the exception of the interleaved mode.

   -  The reference list has been updated to now published RFCs: RFC
      3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566.  A
      reference to 3GPP TS 26.101 has also been added.

   -  Added notes in storage format section and media type registration
      that AMR and AMR-WB frames can also be stored in the 3GP file
      format.

   -  Added a media type parameter "max-red" that allows the sender to
      declare a bounded usage of redundancy.  This parameter allows a
      receiver to optimize its function as it will know if redundancy
      will be used or not.  If it is used, the maximum extra delay
      introduced by the sender (that is needed to be considered by the
      receiver to fully utilize the redundancy) will be known.  The
      addition of this parameter should have no negative effects on
      older implementations as they are mandated to ignore unknown

Top      Up      ToC       Page 55 
      parameters per RFC 3267.  In addition, older implementations are
      required to operate as if the value of max-red is unknown and
      possibly infinite.

   -  Updated the media type registration to comply with the new
      registration rules.

   -  Moved section on decoding validation from Security Considerations
      to Implementation Considerations, where it makes more sense.

   -  Clarified the application of encryption, integrity protection, and
      authentication mechanism to the payload.

11.  Acknowledgements

   The authors would like to thank Petri Koskelainen, Bernhard Wimmer,
   Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for
   their significant contributions made throughout the writing and
   reviewing of RFC 3267 and this replacement.  The authors would also
   like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for
   their input on this replacement of RFC 3267.

12.  References

12.1.  Normative References

   [1]  3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding",
        version 4.0.0 (2001-03), 3rd Generation Partnership Project
        (3GPP).

   [2]  3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
        4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).

   [3]  3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
        functions", version 5.0.0 (2001-03), 3rd Generation Partnership
        Project (3GPP).

   [4]  3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure",
        version 5.0.0 (2001-03), 3rd Generation Partnership Project
        (3GPP).

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

   [6]  3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate
        operation", version 4.0.0 (2000-12), 3rd Generation Partnership
        Project (3GPP).

Top      Up      ToC       Page 56 
   [7]  3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled
        Rate operation", version 5.0.0 (2001-03), 3rd Generation
        Partnership Project (3GPP).

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

   [9]  3GPP TS 26.092, "AMR Speech Codec; Comfort noise aspects",
        version 4.0.0 (2001-03), 3rd Generation Partnership Project
        (3GPP).

   [10] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise
        aspects", version 5.0.0 (2001-03), 3rd Generation Partnership
        Project (3GPP).

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

   [12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

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

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

   [15] Casner, S., "Media Type Registration of RTP Payload Formats",
        RFC 4855, February 2007.

12.2.  Informative References

   [16] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding",
        version 8.0.1 (2000-11), European Telecommunications Standards
        Institute (ETSI).

   [17] ANSI/TIA/EIA-136-Rev.C, part 410 - "TDMA Cellular/PCS Radio
        Interface, Enhanced Full Rate Voice Codec (ACELP)".  Formerly
        IS-641.  TIA published standard, June 1 2001.

   [18] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication
        System RCR Standard", Association of Radio Industries and
        Businesses (ARIB).

   [19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
        Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
        RFC 3828, July 2004.

Top      Up      ToC       Page 57 
   [20] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols",
        version 4.2.0 (2001-09), 3rd Generation Partnership Project
        (3GPP).

   [21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
        Rate Control (TFRC): Protocol Specification", RFC 3448, January
        2003.

   [22] Li, A., et al., "An RTP Payload Format for Generic FEC with
        Uneven Level Protection", Work in Progress.

   [23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
        Generic Forward Error Correction", RFC 2733, December 1999.

   [24] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu",
        version 4.0.0 (2001-03), 3rd Generation Partnership Project
        (3GPP).

   [25] 3GPP TS 26.202, "AMR Wideband speech codec; Interface to Iu and
        Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project
        (3GPP).

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

   [27] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
        Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
        for Redundant Audio Data", RFC 2198, September 1997.

   [28] 3GPP TS 26.103, "Speech codec list for GSM and UMTS", version
        5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP).

   [29] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [30] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
        Protocol", RFC 2974, October 2000.

   [31] 3GPP TS 26.244, "3GPP file format (3GP)", version 6.1.0 (2004-
        09), 3rd Generation Partnership Project (3GPP).

   [32] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
        Generation Partnership Project (3GPP) Multimedia files", RFC
        3839, July 2004.

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

Top      Up      ToC       Page 58 
   [34] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
        Protocol Version 1.1", RFC 4346, April 2006.

   ETSI documents are available from <http://www.etsi.org/>.
   3GPP documents are available from <http://www.3gpp.org/>.
   TIA documents are available from <http://www.tiaonline.org/>.

Authors' Addresses

   Johan Sjoberg
   Ericsson AB
   SE-164 80 Stockholm, SWEDEN

   Phone: +46 8 7190000
   EMail: Johan.Sjoberg@ericsson.com


   Magnus Westerlund
   Ericsson Research
   Ericsson AB
   SE-164 80 Stockholm, SWEDEN

   Phone: +46 8 7190000
   EMail: Magnus.Westerlund@ericsson.com


   Ari Lakaniemi
   Nokia Research Center
   P.O.Box 407
   FIN-00045 Nokia Group, FINLAND

   Phone: +358-71-8008000
   EMail: ari.lakaniemi@nokia.com


   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, 2-B8
   Arlington Heights, IL 60004, USA

   Phone: +1-847-632-3028
   EMail: Qiaobing.Xie@motorola.com

Top      Up      ToC       Page 59 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   <%ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.