Subject: Comments on draft-ietf-avt-rtp-amr-00.txt

From: Qiaobing Xie <[email-masked]>
Date: Tue, 26 Sep 2000 18:51:29 -0500

Hello, everyone:

I have some serious concerns on the design of the AMR payload format as
defined in <draft-ietf-avt-rtp-amr-00.txt>. In brief, the design seems
very limiting in terms of taking advantage of the error tolerant
features built into the AMR codec algorithm. Also, it seems that not
enough consideration has been given to implemenation efficiency and
performance.

Since my concerns are rather fundamental to the design, the email is a
little long, please bear with me..

1) Basic idea

The basic idea of the draft is to transport AMR frames over IP in an RTP
payload, i.e., AMR-frame/RTP/UDP/IP. I have no problem with that. 

Therefore, the packet *passed to the UDP layer* will contain three types
of bits:

   +--------------+
   | header bits  |
   +--------------+
   | Class A bits |
   |    and/or    |
   |  other bits  |
   +--------------+

Here, the "header bits" will include all the AMR speech frame control
bits (ie., frame header), the RTP payload header bits, and the RTP
header bits.

"Class A bits" is the most sensitive coded speech data bits, as defined
by the AMR codec. The "other bits" (also called Class B and C bits in
AMR terminology) are less sensitive coded speech data bits. 

2) Problems with the current AMR payload format design

The design in the current draft apparently was guided under the
misconception that the "Class A bits" of an AMR speech frame need to be
delivered error-free, and if that part of the frame is corrupted the
whole frame should be tossed. This is not correct.

What the AMR codec really wants from the transport is: "if Class A bits
is found corrupted in a frame, raise a Bad Frame flag but still pass the
whole frame to the decoder since the decoder still may want to use Class
B and C bits to help error concealment." The purpose of the flag is to
tell the decoder that Class A bits are bad and do not use them.

However, the draft seems to suggest on the use of a partial checksum
(such as the one provided by the proposed UDP-lite) to protect the
"header bits" AND the "Class A bits" at the transport leverl. This means
if Class A bits have any error, the whole packet will be tossed by the
transport. Even worse, if the packet is a compound payload, you will
have all the AMR frames tossed by the transport if a bit error occurs in
the Class A bits of any one of the enclosed frames.

It becomes more problematic when, in order to support multiple AMR
frames in a compound RTP payload and to use 
the partial checksum, a *very ugly* bit-wise shuffling scheme is
proposed to copy (bit by bit) all the "Class A bits" of each enclosed
AMR speech frame to the front of the packet!! The hugely computational
intensive operation is required no each RTP packet on both ends of the
RTP session.

3) A better way to do it:

To get what AMR codec wants, we should only checksum the "header bits",
and carry an 8-bit CRC in the AMR frame header to cover the "Class A
bits" of the frame. This CRC is for the RTP receiver (that is above the
transport) to verify the integrity of the Class A bits and to raise the
Bad Frame flag before passing the AMR frame to the decoder. 

In other words,

 1. Partial checksum at the transport level to cover all the "header
    bits" -- if checksum fails, toss the whole packet.
 2. CRC in AMR frame header to cover the "Class A bits" -- if CRC fails,
    raise the bad frame flag.
 3. No error checking on the "other bits".

When bundling multiple AMR frames in one RTP packet (the compound
payload), we should use a table of contents (TOC) structure to avoid
bit-wise copying (AMR frames are bit-stuffed to byte boundary). and then
use the transport level checksum to cover the header bits and TOC bits
only (the Class A CRC of each AMR frame is in the TOC). 

   +------------------+
   | RTP header bits  |  -- RTP and payload headers
   +------------------+
   | Table of Contents|  -- list of frame headers of the 
   +==================+ \   included AMR frames
   | Fmr1 Cls A bits  |  \
   +------------------+  |
   | Fmr1 Cls B bits  |  |
   +------------------+  |
   | Fmr1 Cls C bits  |  |
   +==================+  |
   | Fmr2 Cls A bits  |   > not covered by transport level chksum
   +------------------+  |
   | Fmr2 Cls B bits  |  |
   +------------------+  |
   | Fmr2 Cls C bits  |  |
   +==================+  |
   | Fmr3 Cls A bits  |  /
   +------------------+ /
         .....
         .....

This way, you get what the AMR codec asks for and yet avoid bit-wise
copying.

===============================================================
  Qiaobing Xie, Ph.D
  Principal Staff Engineer
  Network Architecture & Technology
  Motorola, Inc.
  TEL: (847) 632-3028 
===============================================================