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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Sep 2000 16:27:06 +0200

Dear Qiaobing, everyone,

The unequal error protection/correction scheme is not designed just for
UDP-Lite. Any mechanism that can exploit the fact that the data is
sorted in sensitivity order is possible to use, e.g. a partial FEC
scheme based on the same techniques as RFC2733.

We have made some design choices that makes the payload format flexible
and bit efficient, i.e. usefull for a wide range of networks and
applications.

Best regards

Magnus Westerlund

Qiaobing Xie wrote:

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

--

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, 27 Sep 2000 12:49:23 -0500

Magnus,

Correct me if I am wrong, but I find hard to understand your reasoning.

What you are saying is basically that, in order to make the current
payload format design general enough and flexible enough to be used "for
a wide range of networks and applications" and with "any mechanism that
exploit" unequal bit sensitivity, you've chosen to compromise the
implementation efficiency and performance (and even some functionality)
for AMR over RTP/whatever-partial-checksum-UDP/IP.

I think it should be the other way around - the AMR payload design
should primarily focus on finding the optimal solution for
AMR/RTP/UDP*/IP. It doesn't sound right to me for IETF AVT WG to design
something that is meant for a wide range of networks but is
suboptimal/compromised (even functionally handicapped) for IP networks.

Regards,
-Qiaobing Xie