Subject: [AVT] Action items from IETF 52 meeting

From: Stephen Casner <[email-masked]>
Date: Fri, 14 Dec 2001 09:59:19 -0800 (PST)

This is a list of the action items from the two AVT sessions at
IETF52.  We took "hums" on these items in the meeting, but as has been
stated before, working group decisions are officially made on the
mailing list and not in the meetings.  (Also, I must say that the hums
were not very strong on Monday night, in part due to a smaller than
usual number of participatnts in a rather large room).  Therefore, we
solicit confirmations or objections on these actions -- we want to
hear both "yeas" and "nays".

The working group agreed that the following drafts should go to
working group last call for comments (pending agreement on the list).
Since there are several drafts at once, and since the holidays come up
soon, we propose that the last call period will end January 11.  All
of these are to go to Proposed Standard (except as noted):

    Comfort Noise payload format (draft-ietf-avt-rtp-cn-04.txt)
	The main question: will there be any backwards compatibility
	problems with early implementations of CN that included only
	the amplitude and not spectral information?

    Enhanced CRTP (draft-ietf-avt-crtp-enhance-03.txt)
    Tunneled CRTP (draft-ietf-avt-tcrtp-05.txt)
	These drafts comprise AVT's product for RTP multiplexing.

    Unequal Erasure Protection (draft-ietf-avt-uxp-01.txt)
    Uneven Level Protection (draft-ietf-avt-ulp-02.txt )
	These two drafts provide somewhat similar services for
	providing different levels of error protection for different
	parts of a packet stream, but for different environments or
	requirements.  In order to convince the IESG that we should
	standardize two such methods, each draft needs to have an
	applicability statement to indicate when it should be used.
	The uxp draft already has this; the ulp draft needs to add it.
	From these statements we will compose the cover letter to the
	IESG for these two drafts.

    MPEG-4 generic (draft-ietf-avt-mpeg4-multisl-03.txt)
    MPEG-4 simple (draft-ietf-avt-mpeg4-simple-00.txt)
	These drafts go together because the second is a "profile" of
	the first.  Colin Perkins has identified some additional
	changes needed to improve clarity in the generic draft, but
	these will be taken as wg last call comments along with the
	comments that other wg members may have.

    Distributed Speech Recognition (draft-ietf-avt-dsr-00.txt)

    Extended RTP Profile for RTCP-based Feedback
	An open issue was resolved for the profile specification
	(draft-ietf-avt-rtcp-feedback-01.txt) at this meeting.  When
	the draft is updated, it will be ready for wg last call.  A
	companion draft reporting on simulation studies of the timing
	algorithm (draft-burmeister-avt-rtcp-feedback-sim-00.txt) goes
	to wg last call for publication as Informational.

    Secure RTP profile (draft-ietf-avt-srtp-02.txt)
	This draft includes the description of an open issue.  A
	resolution was agreed among the authors before the meeting and
	confirmed at the meeting.  When the draft is updated, it will
	be ready for wg last call.

The working group agreed that the following drafts should be accepted
as working group tasks (pending agreement on the list):

    RTP Payload Format for EVRC, SMV and Frame-Based Vocoders
    (draft-li-avt-vocoder-00.txt)
	This draft is the generalization of the EVRC payload format
	draft on which we already did a wg last call.  However, the
	authors decided to merge with proposals for the SMV payload
	format.  At this meeting, we agreed to accept this as a wg
	item and also to issue wg last call on it after some rewording
	to make clear that this payload format may be used for future
	frame-based vocoders but that doing so is NOT preferred over
	development of an encoding-specific payload format.

    RTP Payload Format for AC-3 Streams
    (draft-flaks-avt-rtp-ac3-00.txt)

    MWPP: A resilient MIDI RTP packetization
    (draft-lazzaro-avt-mwpp-midi-nmp-00.txt)

    RTP payload format for JPEG 2000 video streams
    (draft-edwards-avt-rtp-jpeg2000-00.txt)

    RTCP Extension for SSM Sessions with Unicast feedback
    (draft-chesterfield-avt-rtcpssm-02.txt)
	The wg co-chairs were under the mistaken impression that this
	proposal had already been accepted as a wg task at a previous
	meeting, but apparently not.  So we did not hum on this one at
	this meeting, but we are asking for confirmation or objection
	on the list.

At this meeting we had a presentation of a "meta payload format" (in
the same sense as the FEC payload format) for RTP retransmission
(draft-leon-rtp-retransmission-01.txt) to be used with the extended
RTP profile for RTCP-based feedback.  This is a new proposal that uses
separate RTP sessions for the primary and retransmission traffic.  At
previous meetings, draft-ietf-avt-rtp-selret-03.txt was presented to
describe an alternative payload format that keeps all of the packets
in one RTP session but must therefore carry more information in the
payload header and must modify some of the semantics of RTP fields.
There was recently some discussion on the mailing list among the
authors of these two drafts regarding the tradeoffs.  We co-chairs are
asking for wider discussion of these tradeoffs with the goal to have
the working group agree on which of these should be published as a
Proposed Standard.

We also had a presentation at this meeting of a new payload format
proposal (draft-barany-avt-efr-00.txt) for GSM-EFR speech.  There
already is a payload format for GSM-EFR specified by ETSI and
referenced in the RTP A/V profile.  This new proposal adds one or more
bits to carry quality information that would be inserted by gateways
between a non-RTP radio link and a packet net.  Because we want to
avoid having two payload formats for the same encoding unless there is
a strong justification, the author was requested to supply supporting
evidence for claim of improved MOS scores relative to just dropping
damaged frames.

In addition to these current action items, we have an update on a
previous action item, the RTP payload format and file storage format
for AMR and AMR-WB audio (draft-ietf-avt-rtp-amr-10.txt) that has
been waiting for IESG feedback.  The (rather delayed) IESG response
was that the draft was not written clearly enough.  Qiaobing Xie
stepped up quickly with an offer to rewrite the draft and has done the
first phase of that work.  Because we want to progress this draft as
quickly as possible since the delay has already been quite long, we
agreed to the following schedule:

  - The edited draft (or a URL) will be sent directly to the avt
    mailing list to avoid the Internet Draft administrator delay.  The
    target for this is next Monday or Tuesday.

  - We ask the wg to review the revised draft and provide comments by
    early next Friday.

  - On Friday, the draft will be revised to address any comments, then
    submitted to the I-D administrator.  The AVT co-chairs will send a
    request to the IESG asking to resume the review.

Thanks for your attention and your diligence in reading through the
drafts listed above in your spare time during the holidays!  (Hint,
hint.)
						-- Steve and Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Qiaobing Xie <[email-masked]>
Date: Sun, 16 Dec 2001 22:33:08 -0600

>     request to the IESG asking to resume the review.

Please find the edited draft attached (sorry about the size of this
mail). Your comments and feedback will be greatly appreciated.

-Qiaobing

Internet Engineering Task Force                  Johan Sjoberg, Ericsson
Audio Video Transport WG                     Magnus Westerlund, Ericsson
INTERNET-DRAFT                                      Ari Lakaniemi, Nokia
December 16, 2001                               Petri Koskelainen, Nokia
Expires: June 15, 2002                          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
                    <draft-ietf-avt-rtp-amr-11.txt>

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.

Table of Contents

   1. Introduction.................................................2

Sjoberg et al.                                                  [Page 1]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   2. Conventions and Acronyms.....................................3
   3. Background on AMR/AMR-WB and Design Principles...............3
     3.1. The Adaptive Multi-Rate (AMR) Speech Codec...............3
     3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec...4
     3.3. Multi-rate Encoding and Mode Adaptation..................4
     3.4 Voice Activity Detection and Discontinuous Transmission...5
     3.5 Unequal Bit-error Detection and Protection................5
       3.5.1. Applying UEP and UED in an IP Network................6
     3.6. Robustness against Packet Loss...........................7
       3.6.1. Use of Forward Error Correction (FEC)................7
       3.6.2. Use of Frame Interleaving............................8
     3.7. Bandwidth Efficient or Octet-aligned Operation Mode......9
     3.8. AMR or AMR-WB Speech over IP scenarios...................9
   4. AMR and AMR-WB RTP Payload Formats...........................10
     4.1. Bandwidth Efficient Operation Mode.......................10
       4.1.1. The Payload Header...................................11
       4.1.2. The Payload Table of Contents........................11
       4.1.3. Speech Data..........................................12
       4.1.4. Algorithm for Forming the Payload....................13
       4.1.5 Payload Examples......................................14
         4.1.5.1. Single Frame Payload.............................14
	 4.1.5.2. Multiple Frame Payload...........................15
     4.2 Octet-aligned Operation Mode..............................16
       4.2.1. The Payload Header...................................16
       4.2.2. The Payload Table of Contents and Frame CRCs.........17
         4.2.2.1. Use of Frame CRC for UED over IP.................18
       4.2.3. Speech Data..........................................19
       4.2.4 Algorithms for Forming the Payload....................19
         4.2.4.1. Simple Payload Sorting...........................20
	 4.2.4.2. Robust Payload Sorting...........................20
       4.2.5. Payload Examples.....................................22
     4.3. RTP Header Usage.........................................22
   5. AMR and AMR-WB Storage Format................................23
   6. Congestion Control...........................................24
   7. Security Considerations......................................24
     7.1. Confidentiality..........................................25
     7.2. Authentication...........................................25
     7.3. Decoding Security........................................26
   8. MIME Type Registration.......................................26
     8.1. AMR MIME Registration....................................26
     8.2. AMR-WB MIME Registration.................................28
     8.3. Examples for Using MIME Parameters with SDP..............30
   9. IANA Considerations..........................................30
   10. References..................................................30
   11. Authors' Addresses..........................................32

1. Introduction

   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

Sjoberg et al.                                                  [Page 2]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   type registrations, one for AMR and one for AMR-WB, describing both
   RTP payload format and storage format are included.

   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.

   Even though this payload definition supports the transportation 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 RFC2119 [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

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. 

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

   The AMR codecs 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. 

   The AMR codec is a multi-mode codec that supports 8 narrow band
   speech encoding modes with bit rates between 4.75 and 12.2

Sjoberg et al.                                                  [Page 3]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   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. 

   Among the 8 AMR encoding modes, three are already separately
   adopted as standards of their own. Particularly, the 6.7 kbps mode
   is adopted 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].

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 9 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 (e.g., GSM) are allowed to
   dynamically adjust the speech encoding rate during a session so as
   to continuously adapt to the available transmission bandwidth which
   may vary from time to time. 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 piggybacked 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 limitation, etc. For this reason, at the set-up of a
   session the decoder is allowed to indicate its acceptance of a
   particular mode or a subset of the defined modes for the session.

Sjoberg et al.                                                  [Page 4]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   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 8 AMR modes or 9 AMR-WB modes. 

   If the decoder specifies such a subset of modes for a session, the
   encoder MUST abide by the request and MUST NOT use modes outside
   of the subset. If the decoder does not make such a request at the
   session set-up, then any mode available to the codec may be used. 

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

   These mode adaptation controls are signaled through MIME parameters
   at each session set-up. See Section 9 for more details.

3.4. Voice Activity Detection and Discontinuous Transmission

   Both codecs supports 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 AMR or AMR-WB frames
   containing CN parameters are called Silence Indicator (SID)
   frames. See more details about VAD and DTX functionality in [14]
   and [15]. 

3.5. 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)
   mechanism.

   The UEP/UED mechanism 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 devided into class A, B, and C, where bits in class A are most
   sensitive and bits in class C least sensitive (see Table 1 below
   for AMR and [4] for AMR-WB). A 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

Sjoberg et al.                                                  [Page 5]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

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

   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.

   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.

   There are at least two basic approaches for carrying AMR and AMR-WB
   traffic over bit error tolerant IP 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 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 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

Sjoberg et al.                                                  [Page 6]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

     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 above two approaches must be made based on
   the available bandwidth, and desired tolerance to bit
   errors. Neither solution is appropriate to all cases.

3.6. 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.6.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., 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 also a work in progress on a generic
   version of such a scheme [19] that can be applied to AMR or AMR-WB
   payload transport. 

   With AMR or AMR-WB, it is also possible to add data redundancy with
   little or no extra bandwidth by taking advantage of the multi-rate
   capability of the codec. We describe such a scheme below.

   This involves the simple retransmission of 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. 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) |
   --+--------+--------+--------+--------+--------+--------+--------+--

Sjoberg et al.                                                  [Page 7]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

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

   Figure 1: An example of redundant transmission.

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

   The use of this approach does not require signaling at the session
   setup. 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 is received, it is RECOMMENDED that the mode with the
   highest rate be used by the speech decoder. 

   A receiver MUST be prepared to receive any speech frame multiple
   times, both in exact duplicates and in different AMR rate modes. 

   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 Section 6 for more details). 

3.6.2. Use of Frame Interleaving

   To decrease protocol overhead, the payload design allows several
   speech frames be encapsulated into a single RTP packet. 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.

   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 signal its support for it at the session
   set-up.

Sjoberg et al.                                                  [Page 8]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

3.7. Bandwidth Efficient or Octet-aligned Operation Mode

   For a given session, the payload format can be either bandwidth
   efficient or octet aligned, depending on the mode of operation that
   must be signalled at the session establishment. 

   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 robust to packet loss and bit
   errors. 

   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.

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

3.8. AMR or AMR-WB Speech over IP scenarios

   One likely scenario is that the AMR or AMR-WB encoded speech will
   be transmitted from a non-IP system (e.g., GSM or 3GPP network) to
   an IP/UDP/RTP terminal, and/or vice versa, as depicted in 
   Figure 2. 

    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/3GPP network  |           IP network
                       |

   Figure 2: GW to VoIP terminal scenario

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

   A second 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

Sjoberg et al.                                                  [Page 9]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   Figure 3 below.

   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/3GPP network  |          IP network       |  GSM/3GPP network
                      |                           |

   Figure 3: GW to GW scenario

   A third likely scenario is to directly use AMR or AMR-WB codec over
   an IP connection by VoIP applications, as shown in Figure 4.

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

   Figure 4: VoIP terminal to VoIP terminal scenario

4. AMR and AMR-WB RTP Payload Formats

   The complete payload consists of a payload header, a payload table
   of contents, and speech data representing one or more speech
   frames. The following diagram shows the general payload format
   layout:

   +----------------+-------------------+----------------
   | payload header | table of contents | speech data ...
   +----------------+-------------------+----------------

   Payloads containing more than one speech frame are called compound
   payloads.

   Depending on whether the AMR session is set up to use the bandwidth 
   efficient mode or octet aligned mode, the payload format will be
   different. 

   Implementations SHOULD support both bandwidth efficient and octet 
   aligned operation to give a high possibility of interoperability. 
   The implementation of robust sorting, interleaving, and frame CRCs
   are OPTIONAL.

4.1. Bandwidth Efficient Operation Mode

Sjoberg et al.                                                 [Page 10]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

4.1.1. The Payload Header

   In this mode, the payload header simply consists of a 4 bit codec
   mode request: 

    0 1 2 3 
   +-+-+-+-+
   |  CMR  |
   +-+-+-+-+

   CMR (4 bits): Indicates a codec mode requested sent to the speech
   encoder at the site of the receiver of this payload. The value of
   CMR field is set to the frame type of the corresponding speech mode
   being requested.

   It is only allowed to request from the encoder one of the speech
   modes of the used codec, i.e., 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 ignore the request or change to a
   mode different from the one being requested.

   CMR field MUST be set to 15 for packets sent to a multicast
   group. The encoder in the speech sender SHOULD ignore mode requests
   when sending speech 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 setup. If so, the requested mode MUST be
   among the signaled mode set.

4.1.2. The Payload Table of Contents

   The table of contents (ToC) consists of a list of ToC entries and
   each ToC entry describes a speech frame carried in the payload.

   In bandwidth efficient mode, a ToC entry takes the following
   format: 

    0 1 2 3 4 5
   +-+-+-+-+-+-+
   |F|  FT   |Q|
   +-+-+-+-+-+-+

   F (1 bit): If set to 1, indicates that this frame is followed by
   another speech frame in this payload; if set to 0, indicates that
   this frame is the last frame in this payload.

Sjoberg et al.                                                 [Page 11]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   FT (4 bits): Frame type indicator, indicating either the AMR or
   AMR-WB speech coding mode or comfort noise (SID) mode of the
   corresponding frame carried in this payload. 

   The value of FT is defined in Table 1a in [2] for AMR and in Table
   1a in [4] for AMR-WB. In addition, FT=14 (SPEECH_LOST, only
   available for AMR-WB) and FT=15 (NO_DATA) are used to indicate
   frames that are either lost or not being transmitted in this
   payload, respectively.

   NO_DATA (FT=15) frame could mean either that there is no data
   produced by the speech encoder for that frame or that no data for
   that frame is transmitted in the current payload (i.e., valid data
   for that frame could be sent in either an earlier or following
   packet). 

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

   Note, the extra CN types specified in table 1a in [2] (i.e.,
   GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this 
   payload format. 

   Q (1 bit): Frame quality indicator. If set to 0, indicates the
   corresponding frame is severely damaged and the receiver should set
   the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD depending on
   the frame type (FT). 

   The frame quality indicator is included for interoperability with
   the ATM payload format described in ITU-T I.366.2, the UMTS Iu
   interface [17], as well as other transport formats. Frame quality
   indicator enables damaged frames being forwarded to the speech
   decoder for error concealment. This can improve the speech quality
   comparing to drop the damaged frames. See Section 4.2.2.1 for more
   details. 

   The following figure shows an example of a ToC of three entries
   when using bandwidth efficient operation mode.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|  FT   |Q|1|  FT   |Q|0|  FT   |Q|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.3. Speech Data

   Speech data of a payload contains one or more speech frames, as
   described in the ToC of the payload.

     Note, for ToC entries with FT=14 or 15, there will be no

Sjoberg et al.                                                 [Page 12]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

     corresponding speech frame present in the speech data.

   Each speech frame represents 20ms of speech encoded with the mode
   indicated in the FT field of the corresponding ToC entry. The
   length of the speech frame is implicitly defined by the mode
   indicated in the FT field. The bits in each speech frame SHALL
   follow the definitions in Annex B of [2] for AMR and Annex B of [4]
   for AMR-WB.

   The AMR SID frame bits SHALL be present in this order (see table
   A.2 in [2]): 

     f(n,0..38)=(s1,..,s35,t1,smi(0),..,smi(2)) 

   The AMR-WB SID frame bits SHALL be present in this order (see table
   A.2 in [4]):
   
     f(n,0..39)=(s1,..,s35,t1,mi(3),..,mi(0))

   Here, f(n,m) is bit m in speech frame n.

   In the bandwidth efficient operation mode, when multiple speech
   frames are present in the speech data (i.e., compound payload), the
   speech frames MUST be arranged in simple sorting order (see the
   algorithm in section 4.1.4 below for details).

4.1.4. Algorithm for Forming the Payload

   A payload in bandwidth efficient operation mode MUST be formed
   using the simple sorting algorithm defined in this section.

   The following definitions are used to describe the algorithm:

   b(m)    - bit m of the compound payload
   o(n,m)  - bit m of octet n in the octet description of the compound
             payload, bit 0 is MSB
   N       - number of frames to be included in the payload
   F(n)    - number of bits in speech frame n, defined by FT
   h(m)    - bit m of payload header
   t(n,m)  - bit m in the table of contents entry for speech frame n
   f(n,m)  - bit m in speech frame n

   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++){

Sjoberg et al.                                                 [Page 13]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

       b(k++) = t(j,i);
     }
   }
   /* speech 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)
   }

   The input to the algorithm MUST be a sequence of N consecutive
   speech frames, i.e., frame n is immediately preceding frame n+1. 

   If speech data is missing for one or more frames in the sequence,
   because of, for example, DTX, a ToC entry with FT set to NO_DATA
   SHALL be included in the ToC for each of the missing frames, but no
   data bits should be sent in the payload for the missing frame (see
   Section 4.1.5.2 for an example).

   At the end the compound payload, b, is mapped into a sequence of
   octets, o, where bit 0 is MSB in each octet.

4.1.5 Payload Examples

4.1.5.1. Single Frame Payload

   The following diagram shows a bandwidth efficient AMR payload
   carrying a single speech frame. 

   In the payload, no mode request is present (CMR=15), the payload
   is not damaged at the IP origin (Q=1), and the coding mode is AMR
   7.4 kbps (FT=4). The encoded speech bits, f(0) to f(147), are
   arranged in descending sensitivity order according to [2]. Finally,
   two 0s are padding to the end to make the payload octet aligned.

    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=15|0| FT=4  |1|f(0)                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sjoberg et al.                                                 [Page 14]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                     f(147)|P|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.5.2. Multiple Frame Payload

   The following diagram shows a bandwidth efficient compound AMR-WB
   payload that contains three frames, of which one has no speech
   data.

   As shown below, the payload carries a mode request for the encoder
   on the receiver's side to change its future coding mode to AMR-WB
   8.85 kbps (CMR=1). 

   The second frame has no speech data (i.e., a NO_DATA frame). The
   two remaining speech frames are not damaged at IP origin (Q=1). 

   The first frame is an AMR-WB 6.6 kbps frame (FT=0) that is composed
   of speech bits f(0) to f(131). The second frame has no speech data
   and is therefore only represented in the payload by its ToC
   entry. The third frame is an AMR-WB 8.85 kbps frame (FT=1)
   containing bits g(0) to g(176). The encoded speech bits, f(0) to
   f(131) and g(0) to g(176), are arranged in the payload in
   descending sensitivity order according to [4]. (Note, no speech
   bits are present for the second frame). Finally, five 0s are padded
   to the end to make the payload octet aligned.

    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=1 |1| FT=0  |1|1| FT=15 |1|0| FT=1  |1|f(0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                             f(131)|g(0)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               g(176)|P|P|P|P|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sjoberg et al.                                                 [Page 15]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

4.2 Octet-aligned Operation Mode

4.2.1. The Payload Header

   In octet aligned mode, the payload header consists of a 4 bit CMR,
   4 reserved bits, and optionally, an 8 bit interleaving header, as
   shown below:

    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  |
   +-+-+-+-+-+-+-+-+- - - - - - - - 

   CMR (4 bits): same as defined in section 4.1.1.

   R: is a reserved bit that MUST be set to zero. All R bits MUST be
   ignored by the receiver.

   ILL (4 bits, unsigned integer): This is an OPTIONAL field that is
   present only if interleaving is signaled out-of-band at session
   setup. The value of this field specifies the length of the
   interleave group used for speech frames carried in this payload. In
   particular, if ILL=L, then the interleave group will consist of L+1
   payload packets.

   ILP (4 bits, unsigned integer): This is an OPTIONAL field that is
   present only if interleaving is signaled. ILP MUST take a value
   between 0 to ILL, indicating the interleaving index for frames in
   this payload in the interleave group. If the value of ILP is found
   greater than ILL, the payload SHOULD be discarded.

   The following example illustrates the arrangement of speech frames
   in an interleave group during an interleave session. Here we assume
   ILL=L for the interleave group that starts at speech frame n. We
   also assume that the first payload packet of the interleave group
   is s and the number of speech frames carried in each payload is
   N. Then we will have: 

      Payload s (the first packet of this interleave group):
	ILL=L, ILP=0,
        Carry frames: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)

      Payload s+1 (the second packet of this interleave group):
	ILL=L, ILP=1,
        Frames: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)

        ...

      Payload s+L (the last packet of this interleave group):
	 ILL=L, ILP=L,
         Frames: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)

Sjoberg et al.                                                 [Page 16]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   The next interleave group will start at frame n+N*(L+1).

   It is obvious that interleaving is only meaningful when the number
   of frames per payload (N) is greater than or equal to 2. Moreover,
   the number of frame per payload (N) and the value of ILL MUST be
   unchanged inside an interleave group. In other words, all payloads
   in an interleave group MUST have the same ILL and MUST contain the
   same number of speech frames. 

   The sender of the payload MUST only apply interleaving if the
   receiver has signaled its use in the capability description. Since
   interleaving will increase buffering requirements at the
   receiver, the receiver uses MIME parameter "interleaving=I" to set
   the maximum number of frames allowed in an interleaving group to I. 

   When performing interleaving the sender MUST use a proper number of
   frames per payload (N) and ILL so that the resulting size of an
   interleave group is less or equal to I, i.e., N*(L+1)<=I.

4.2.2. The Payload Table of Contents and Frame CRCs

   The table of contents (ToC) in octet-aligned mode consists of a
   list of ToC entries where each entry cooresponds to a speech frame
   carried in the payload and, optionally, a list of speech frame
   CRCs, i.e., 

   +---------------------+
   | list of ToC entries |
   +---------------------+
   | list of frame CRCs  | (optional)
    - - - - - - - - - - - 

     Note, for ToC entries with FT=14 or 15, there will be no
     corresponding speech frame or frame CRC present in the payload. 

   A ToC entry takes the following format in octet-aligned mode:  

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |F|  FT   |Q|P|P|
   +-+-+-+-+-+-+-+-+

   F (1 bit): see definition in Section 4.1.2.

   FT (4 bits unsigned integer): see definition in Section 4.1.2.

   Q (1 bit): see definition in Section 4.1.2.

   P bits: padding bits, MUST be set to zero.

   The list of CRCs is OPTIONAL. It only exists if the use of CRC is
   signaled out-of-band at session setup. When present, each CRC on

Sjoberg et al.                                                 [Page 17]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   the list is 8 bit long and cooresponds to a speech frame carried in
   the payload.

4.2.2.1. Use of Frame CRC for UED over IP

   The general concept of UED/UEP over IP is discussed in Section
   3.5. This section provides more details on how to use the frame CRC
   in the octet-aligned payload header togather with a partial
   transport layer checksum to achieve UED.

   To achieve UED, one SHOULD use a transport layer checksum, such
   as the one defined in UDP-lite [13], to protect the RTP header,
   payload header, and table of contents bits in a payload. The frame
   CRC SHOULD be used to cover only the class A bits in the
   frame. Class B and C bits in the frame SHOULD be left out of the
   coverage of the checksum and frame CRC.

     Note, the number of class A bits for various coding mode in AMR
     codec is specified as informative in [2] and is therefore copied
     into Table 1 in Section 3.5 to make it normative for this
     payload format. The number of class A bits for various coding
     mode in AMR-WB codec is specified as normative in table 2 in
     [4]. These definitions of class A bits MUST be used for this
     payload format. 

   Packets SHOULD be discarded if the transport layer checksum detects
   errors.

   The receiver of the payload SHOULD examine the data integrity of
   the received class A bits by re-calculating the CRC over the
   received class A bits and comparing the result to the value found
   in the received payload header. If the two values mismatch, the
   receiver SHALL consider the class A bits in the receiver frame
   damaged and MUST clear the Q flag of the frame (i.e., set it to
   0). This will subsequently cause the frame to be marked as
   SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for
   AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for
   AMR-WB, before it being passed to the speech decoder, see [6] and 
   [7] more details.

   The following example shows an octet-aligned ToC with a CRC list of 
   a payload containing 3 speech frames (assmuing none of the FTs
   equals to 14 or 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|  FT#1 |Q|P|P|1|  FT#2 |Q|P|P|0|  FT#3 |Q|P|P|     CRC#1     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     CRC#2     |     CRC#3     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each of the CRC is generated by the cyclic generator polynomial: 

Sjoberg et al.                                                 [Page 18]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   g(D) = D8 + D4 + D3 + D2 + 1.

   The encoding is performed in a systematic form, which means that, in
   GF(2), the polynomial:
   - f(0)D(N+7)+f(1)D(N+6)+...+f(N-1)D8+p(0)D7+p(1)D6+...+p(6)D1+p(7);
   - p(0)-p(7): the 8 parity bits
   - f(0)-f(N-1): the N data bits to be protected by the CRC;
   when divided by g(D), yields a remainder equal to 0.

4.2.3. Speech Data

   In octet aligend mode, speech data is carried in a similar way to
   that in the bandwidth efficient mode as discussed in Section 4.1.3,
   with the following exceptions: 

    - the last octet of *each* speech frame MUST be padded with zeroes
      at the end if not all bits in the octet are used. In other
      words, *each* speech frame MUST be octet-aligned. 

    - when multiple speech frames are present in the speech data
      (i.e., compound payload), the speech frames can be arranged in
      either simple sorting order or robust sorting order (see the
      algorithms in Section 4.2.4 below for details). The use of
      robust sorting order MUST be explicitly signaled out-of-band 
      at the session setup using MIME parameters.

4.2.4. Algorithms for Forming the Payload

   Two different packatization algorithms, namely simple sorting and
   robust sorting, exist for forming a payload in octet-aligned
   operation mode. 

   The following definitions are used to describe the algorithm:

   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
   N       - number of payload frames in the payload
   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

   The input to the algorithm MUST be a sequence of N consecutive
   speech frames, i.e., frame n is immediately preceding frame n+1. 

   If speech data is missing for one or more frames in the sequence,
   because of, for example, DTX, a ToC entry with FT set to NO_DATA

Sjoberg et al.                                                 [Page 19]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   SHALL be included in the ToC for each of the missing frames, but no
   frame CRC or data bits should be sent in the payload for the
   missing frame.

   If interleaving is used, the interleaving rules defined in Section
   4.2.1 applies for frames that are contained in the payload. 

4.2.4.1. Simple Payload Sorting

   The following C-style code defines the simple payload sorting
   algorithm for octec-aligned payload:

   /* 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 */
   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)
   }

4.2.4.2. Robust Payload Sorting

Sjoberg et al.                                                 [Page 20]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   Robust payload sorting can be used to re-arrange the data inside a
   payload that carries multiple speech frames by their sensitivity
   order. This allows the application of UED (such as UDP-lite [13]) or
   UEP (such as the ULP [19]) mechanism to the payload data.

   Robust payload sorting MUST be signaled at session setup using MIME
   parameters (see Section 8 for more details). When robust sorting is
   used, the reordering of the payload data SHALL be performed on
   octet level.

   The UED and/or UEP is RECOMMENDED to cover at least the RTP header,
   payload header, table of contents, and class A bits of a sorted
   payload. Exactly how many octets need to be covered depends on the
   network and application. 

   If CRCs are used together with robust sorting, only the RTP header,
   the payload header, and the ToC should be covered by UED/UEP.

   When performing the robust sorting, the placement of the payload
   header, ToC, and frame CRCs (if present) SHALL remain unchanged in
   the beginning of the payload. Thereafter, the speech frames are
   sorted with one octet alternating from each payload frame,
   following the sorting algorithm defined in C-style below:

   /* 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++){

Sjoberg et al.                                                 [Page 21]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

       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;
           }
         }
       }
     }
   }
   /* map into octets */
   for (i = 0; i < k; i++){
     o(i/8,i%8)=b(i)
   }

4.2.5. Payload Examples

   The following diagram shows an octet aligned payload packet that
   carries two AMR frames of 7.95 kbps coding mode (FT=5). In the
   payload, a codec mode request is also sent (CMR=6), requesting the
   encoder at the receiver's side to use AMR 10.2 kbps coding mode.

   Moreover, frame CRC and interleaving are both enabled in the
   payload. The interleave group length is 2 (ILL=1) and this payload
   is the first one in an interleave group (ILP=0). The first frame in
   the payload is frame 1, consisting of bits f1(0..158), while the
   second frame in the payload is frame 3, consisting of bits
   f3(0..158), due to the interleaving. For each of the two payload
   frames a CRC is calculated as CRC1(0..7) and CRC3(0..7),
   respectively. Finally, the payload is robust sorted.

    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=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1=5 |Q|P|P|0|FT#3=5 |Q|P|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     CRC#1     |     CRC#3     |   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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note, in above example the last octet in both speech frames is
   padded with one 0 to make it octet-aligned.

4.3. RTP Header Usage

   The RTP header marker bit (M) SHALL be set to 1 in the packet that

Sjoberg et al.                                                 [Page 22]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   contains the first speech frame of a talkspurt. For all other
   packets the marker bit SHALL be set to zero (M=0). 

   The timestamp corresponds to the sampling instant of the first
   sample encoded for the first frame in the packet and the timestamp
   unit is in samples. A frame can be either encoded speech, comfort
   noise parameters, NO_DATA, or SPEECH_LOST (only for AMR-WB). The
   duration of one speech frame is 20 ms and the sampling frequency is
   8 kHz, 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 according to the interleaving rules as defined in
   Section 4.2.1. 

   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 dynamic payload type SHOULD be used.

5. AMR and AMR-WB Storage Format

   The storage format is used for storing AMR or AMR-WB speech frames
   in a file or as an e-mail attachment.

   An AMR or AMR-WB file always begins with a magic number to identify
   itself. AMR and AMR-WB files use different magic numbers. The magic
   number for AMR files consists of ASCII character string "#!AMR\n"
   (or 0x2321414d520a in hexadecimal). The magic number for AMR-WB
   files is "#!AMR-WB\n" (or 0x2321414d522d57420a in hexadecimal).

   After the magic number, the speech frames are stored in consecutive
   order separately in the octet-aligned format. This implies that
   the first octet after the last octet of frame n must be the first
   octet of frame n+1. 

   Each stored speech frame starts with a one octet frame header with
   the following format:

    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+
   |P|  FT   |Q|P|P|                                               |
   +-+-+-+-+-+-+-+-+

   The FT field and the Q bit are defined in the same way as in
   Section 4.1.2. The P bits are padding and MUST be set to 0.

Sjoberg et al.                                                 [Page 23]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   Following this one octet header come the speech bits as defined in
   4.1.3. The last octet of each frame is padded with zeroes, if
   needed, to achieve octet alignment. 

   The following example shows an AMR frame in 5.9 kbit coding mode
   (with 118 speech bits) in the storage format. Note that bits marked
   with P (padding) MUST be set to zero. 

    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=2  |Q|P|P|                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   +                Speech bits for frame n                        +
   |                                                               |
   +                                                           +-+-+
   |                                                           |P|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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. Congestion Control

   The general congestion control consideration for transporting RTP
   data applies to AMR or AMR-WB over RTP speech as well. In addition,
   the mutil-rate capability of AMR and AMR-WB speech coding may bring
   some advantage to congestion control, due to the different
   bandwidth demand by different coding mode.

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

   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 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, e.g. "Equation-Based Congestion Control for
   Unicast Applications" [18].

7. Security Considerations

Sjoberg et al.                                                 [Page 24]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   RTP packets using the payload format defined in this specification
   are subject to the general security considerations discussed 
   in [11]. 

   As this format transports encoded speech, the main security issues 
   include decoding security, confidentiality, and authentication of
   the speech itself. The payload format itself does not have any
   built-in security mechanism. External mechanism, such as SRTP [23],
   MAY be considered. 

   This payload format does not exhibit any significant non-uniformity
   in the receiver side computational complexity for packet processing
   and thus is unlikely to cause potential denial-of-service threat.

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 a need to
   encrypt the payload header or the table of contents due to 1) that
   they only carry information about the requested speech mode, frame
   type, and frame quality, and 2) that this information could be
   useful to some third party, e.g., quality monitoring. 

   As long as the AMR or AMR-WB payload is only packed and unpacked at
   either end, encryption may be performed after packet encapsulation
   so that there is no conflict between the two operations.

   Interleaving MAY affect encryption. Depending on the used encryption
   scheme there MAY be restrictions on, for example, the time when keys
   can be changed. 

   The type of encryption method used may impact the error robustness
   of the payload data. The error robustness may be severely reduced
   when the data is encrypted, unless an encryption method without 
   error-propagation is used, e.g. a stream cipher. Therefore, UED/UEP
   based on robust sorting may be difficult to applied when payload
   data is encryted. 

7.2. Authentication

   To authenticate the sender of the speech an external mechanism has
   to be used. It is RECOMMENDED that such a mechanism protects all
   the speech data bits. Note that the use of UED/UEP may be difficult
   to combine with authentication. 

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

   To prevent a man-in-the-middle attacker from tampering with the

Sjoberg et al.                                                 [Page 25]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   payload packets, some additional information besides the speech
   bits SHOULD be protected. This may include the payload header, ToC,
   frame CRCs, RTP timestamp, RTP sequence number, and the RTP marker
   bit. 

7.3. Decoding Security

   When processing a received payload packet, if the receiver finds
   that the calculated payload length, based on the information of the
   session and the values found in the payload header fields, does not
   match the size of the received packet, the receiver SHOULD discard
   the packet. This is because decoding a packet that has errors in
   its length field could severely degrade the speech quality. 

8. MIME Type Registration

   This section defines the MIME types for the AMR and AMR-WB speech
   codecs. To emphasize that siwtching from one codec to the other is
   NOT allowed during a session the MIME types of the two codecs are
   kept in separate sections although they are similarly defined. 

   The data format and parameters are specified for both real-time
   transport and for storage type applications (e.g. e-mail
   attachment, multimedia messaging). 

8.1. AMR MIME Registration

   MIME-name for the AMR codec is allocated from IETF tree since AMR is
   expected to be a widely used speech codec in general VoIP
   applications. Some parts of this section will distinguish between
   AMR 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] and
	       an example is given in Section 8.3). If not present,
	       all codec modes are allowed for the session.

    mode-change-period: Defines a number N which restricts the mode

Sjoberg et al.                                                 [Page 26]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

               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 during the session.

    mode-change-neighbor: If present, mode changes SHALL only be made
	       to the 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.

    maxptime:  The maximum amount of media which can be encapsulated in
               a payload packet, expressed as time in milliseconds. The 
	       time shall be calculated as the sum of the time the media
               present in the packet represents. The time SHOULD be a
               multiple of the frame size. When sent in SDP, "maxptime"
               MUST go in the "a=maxptime" attribute. If this
	       parameter is not present, the sender MAY encapsulate
	       any number of speech frames into one RTP packet.

    crc:       If present, frame CRCs SHALL be included in the
	       payload, otherwise not. The presence of "crc" also
	       implies automatically that octet-align operation SHALL
	       be used for the session. 

    robust-sorting: If present, the payload SHALL employ robust payload
               sorting. If not present, simple payload sorting SHALL
               be used. The presence of this parameter also implies
	       automatically that octet-align operation SHALL be used
	       for the session.

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

    ptime:     see RFC2327 [24].

   Optional parameters for storage mode:     none

   Encoding considerations for RTP mode: See Section 4 of RFC XXXX.

   Encoding considerations for storage mode: See Section 5 of 
   RFC XXXX.

   Security considerations: see Section 7 of RFC XXXX.

   Public specification: please refer to Section 10 of RFC XXXX.

   Additional information for storage mode:

Sjoberg et al.                                                 [Page 27]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

               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:
               [email-masked]
	       [email-masked]

   Intended usage: COMMON. It is expected that many VoIP applications
   (as well as mobile applications) will use this type.

   Author/Change controller:
               [email-masked]
	       [email-masked]
	       IETF Audio/Video transport working group

8.2. AMR-WB MIME Registration

   MIME-name for the AMR-WB codec is allocated from IETF tree since
   AMR-WB is expected to be a widely used speech codec in general VoIP
   applications. Some parts of this section will distinguish between
   AMR 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
               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 allowed for
	       the session.

    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 during the session.

    mode-change-neighbor: If present, mode changes SHALL only be made
	       to the 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

Sjoberg et al.                                                 [Page 28]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

	       included. 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 shall be calculated as the sum of the time the media
               present in the packet represents. The time SHOULD be a
               multiple of the frame size. When sent in SDP, "maxptime"
               MUST go in the "a=maxptime" attribute.

    crc:       If present, frame CRCs SHALL be included in the
	       payload, otherwise not. The presence of "crc" also
	       implies automatically that octet-align operation SHALL
	       be used for the session. 

    robust-sorting: If present, the payload SHALL employ robust payload
               sorting. If not present, simple payload sorting SHALL
               be used. The presence of this parameter also implies
	       automatically that octet-align operation SHALL be used
	       for the session.

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

    ptime:     see RFC2327 [24].

   Optional parameters for storage mode:     none

   Encoding considerations for RTP mode: See Section 4 of RFC XXXX.

   Encoding considerations for storage mode: See Section 5 of RFC
   XXXX.

   Security considerations: see Section 7 of RFC XXXX.

   Public specification: please refer to Section 10 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

   Person & email address to contact for further information:
               [email-masked]
	       [email-masked]

   Intended usage: COMMON. It is expected that many VoIP applications
   (as well as mobile applications) will use this type.

Sjoberg et al.                                                 [Page 29]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   Author/Change controller:
               [email-masked]
	       [email-masked]
	       IETF Audio/Video transport working group

8.3. Examples for Using MIME Parameters with SDP

   Please note that this section applies only to the real-time 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
    a=maxptime=20

   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 interleaving=15
    a=maxptime=60

9. IANA Considerations

   Two new MIME subtypes are to be registered, see Section 8. A new
   SDP attribute "maxptime", also defined in Section 8, need to be
   registered. The "maxptime" attribute is expected to be defined in
   the revision of RFC 2327 [24] and is added here with a consistant
   definition. 

10. References

   [1]  3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech
	transcoding". 

   [2]  3GPP 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".

Sjoberg et al.                                                 [Page 30]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

   [5]  IETF RFC 2119, "Key words for use in RFCs to Indicate
        Requirement Levels".

   [6]  3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate
        operation".

   [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] 3GPP 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] 3GPP 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-02.txt, "The Secure Real Time Transport

Sjoberg et al.                                                 [Page 31]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

        Protocol".

   [24] IETF RFC2327, "SDP: Session Description Protocol".

11. Authors' Addresses

   Johan Sjoberg                  Tel:   +46 8 50878230
   Ericsson Research              EMail: [email-masked]
   Ericsson Radio Systems AB
   SE-164 80 Stockholm, SWEDEN

   Magnus Westerlund              Tel:   +46 8 4048287
   Ericsson Research              EMail: [email-masked]
   Ericsson Radio Systems AB
   SE-164 80 Stockholm, SWEDEN

   Ari Lakaniemi                  Tel:   +358 50 4837698
   Nokia Research Center          EMail: [email-masked]
   P.O.Box 407
   FIN-00045 Nokia Group, FINLAND

   Petri Koskelainen
   Nokia Research Center          EMail: [email-masked]
   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: [email-masked]
   D - 81675 Munich, GERMANY

   Bernhard Wimmer                Tel:   +49 89 722 23247
   Siemens AG, ICP CD             Fax:   +49 89 722 46489
   Grillparzerstrasse 10-18       EMail: [email-masked]
   D - 81675 Munich, GERMANY

   Qiaobing Xie                   Tel:   +1-847-632-3028
   Motorola, Inc.                 EMail: [email-masked]
   1501 W. Shure Drive, 2-B8
   Arlington Heights, IL 60004, USA

   Sanjay Gupta                   Tel:   +1-847-435-0306
   Motorola, Inc.                 EMail: [email-masked]
   1501 W. Shure Drive, #3205
   Arlington Heights, IL 60004, USA

   This Internet-Draft expires in six months from December 2001.

Sjoberg et al.                                                 [Page 32]

INTERNET-DRAFT    RTP Payload Format for AMR and AMR-WB    December 2001

Sjoberg et al.                                                 [Page 33]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Dec 2001 13:08:10 +0100

Qiaobing,

Thanks for a greatly improved structure of the draft. Here are some comments:

Section 3.3 third paragraph from the end:
This paragraph contains the only MUST in the whole background. I would propose
that it is reformulated. The hard requirements should instead moved into the
MIME parameter definition.

The MIME parameter definition of mode-set is to loose in language. A sentence
like :"If present the active codec mode-set SHALL be restrited to the mode set
listed." should be added.

Section 4.1.2 Last paragraph before the definition of the Q bit:
This paragraph should be extended with a motivation why the CN types for
GSM-EFR, PDC-EFR and IS-641 shall not be used. My proposal: "The reason for
this is that the CN data of these standards is not compatibile with the
standardized AMR codec."

Section 4.2.1. Second paragraph from the end:
I would like to make the following change:

   receiver, the receiver MAY use the MIME parameter "interleaving=I" to set
                                   ^^^^^^^^^^

This will make the use of a the restricting parameter optional. The definition
of the MIME parameter "interleaving" must also be uppgraded to allow such
usage, i.e define a default behaviour of no restriction when no parameter is
present.

Section 4.3 first sentence:
The definition of when to use the marker bit is ambiguous. With multiple
frames in the packet you can't determine which of the packets that has set the
marker bit.  Therefore we suggest the following definition: The marker bit is
set when a packet as its first frame in the payload has a speech frame which
are the first in a talkspurt.

Section 8.1, definition of maxptime:
"The time SHOULD be a multiple of the frame size." First, the use of frame
size seems unappropriate as it should actually referes to the frames duration
in time. Secondly, RECOMMENDED would seem to be a requirement level more
suitable for this.

Section 8.2 definition of maxptime:
Not the same as in 8.1, missing the last sentence.

Section 8.1 and 8.2, definition of magic number for the storage format:
I belive "\n" is not ambigous, therefore the hex codes (see section 5) should
also be added to the MIME registration part.

Section 8.3 Third example,
I propose to change the limitation values for interleaving and maxptime to be
more realistic.
interleaving=30
maxptime=100
This represents a maximum of 5 frames per packet and 3/5 of a second in the
interleaving group. It also allows the usage of interleaving lengths long
enough to do any good.

Cheers

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 19 Dec 2001 16:37:18 -0600

Magnus,

Thanks for the feedback. See my comments in-line...

> MIME parameter definition.

Agreed.

> listed." should be added.

Enhanced.

> this is that the CN data of these standards is not compatibile with the

Added.

>    receiver, the receiver MAY use the MIME parameter "interleaving=I" to set

Ok.

> usage, i.e define a default behaviour of no restriction when no parameter is

How? Do you want to do "a=fmtp:99 interleaving"? What default value we
should use here. Does the syntax of "interleaving" requires an integer
be always assigned, i.e., one has to use "interleaving=<number>" and
"interleaving" alone is a syntax error?

> are the first in a talkspurt.

I think I understand what you wants here. I've changed it to the
following:

   The RTP header marker bit (M) of a payload packet SHALL be set 
   to 1 if the first frame carried in the packet is the first speech 
   frame of a talkspurt. For all other packets the marker bit SHALL 
   be set to zero (M=0).

> in time. Secondly, RECOMMENDED would seem to be a requirement level more

changed.

> Not the same as in 8.1, missing the last sentence.

Added.

> also be added to the MIME registration part.

Ok.

> interleaving group. It also allows the usage of interleaving lengths long

Good point. Changes.

thanks,
-Qiaobing

---

From: Stephen Casner <[email-masked]>
Date: Wed, 19 Dec 2001 20:08:25 -0800 (PST)

> "interleaving" alone is a syntax error?

I believe that MIME parameters are always supposed to be of the form

   param=value

This would carry over into the fmtp.

>    frame of a talkspurt. For all other packets the marker bit SHALL

This is clear enough, but why would there ever be a packet which
contained the first frame of a talkspurt in any position later than
the first frame of the packet?
							-- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Dec 2001 12:53:13 +0100

> This would carry over into the fmtp.

Okey, in that case forget my suggestions.

> the first frame of the packet?

Qiaobing, I am satisfied with that wording.

Steve, here is a case when this could happend. You are packing five frames per packet.
Your in the middle of talkspurt. The next five frames has the following modes
7,7,8,7,7, i.e. two speech frames before the VAD decieds it is silence, but the
silence is so short so the next frame is voice again. In this case the fourth frame is
the first in a new talkspurt. I see little reason to break the sequnce into two
packets, which would be necessary to have the first frame in a talkspurt first in the
packet. Also if you have even more frames per packet there exist possibilities that
multiple talkspurts is present in the same packet. Also the case of interleaving would
produce unpredictable results regarding the marker bit.

My opinion is that the marker bit is rather useless in interleaving, but also for
multiple frames per packet cases. The information the markerbit carries, the start of
a talkspurt, can also be detected by looking at the frames AMR mode. I understand that
there can exist less payload aware mechanisms that uses the marker bit. To be as
consistent as possible and avoid any unclearities the above definition is very good.

Regards

Magnus Westerlund