Re: [AVT] Working group last call: draft-ietf-avt-evrc-smv-00.txt, Comments

Magnus Westerlund <magnus.westerlund@era.ericsson.se> Fri, 15 March 2002 12:03 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26995 for <avt-archive@odin.ietf.org>; Fri, 15 Mar 2002 07:03:16 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA14755 for avt-archive@odin.ietf.org; Fri, 15 Mar 2002 07:03:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14724; Fri, 15 Mar 2002 07:02:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14697 for <avt@optimus.ietf.org>; Fri, 15 Mar 2002 07:02:31 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26982 for <avt@ietf.org>; Fri, 15 Mar 2002 07:02:28 -0500 (EST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2FC2TUw016718 for <avt@ietf.org>; Fri, 15 Mar 2002 13:02:29 +0100 (MET)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA22553; Fri, 15 Mar 2002 13:02:28 +0100
Message-ID: <3C91E2D4.3040101@era.ericsson.se>
Date: Fri, 15 Mar 2002 13:02:28 +0100
From: Magnus Westerlund <magnus.westerlund@era.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: avt@ietf.org
Subject: Re: [AVT] Working group last call: draft-ietf-avt-evrc-smv-00.txt, Comments
References: <200203010609.g2169EH30346@purple.nge.isi.edu>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
X-BeenThere: avt@ietf.org
Content-Transfer-Encoding: 7bit

Hi everyone!

I have reviewed the EVRC and SMV documents and have the following 
comments/questions:

1. section 3.2 First paragraph after table. Last sentence says that SMV 
in mode 0 has an average bit rate of  4.2 kbps should that not be 7.2 
kbps according to the table above?

2. section 4, initial paragraph: "The RTP payload data MUST be 
transmitted in packets of one of the
   following two types." I don't think it is the RTP payload that must 
be transmitted rather the speech frames.

3. What is the design rationale behind using only three bits for the LLL 
and NNN field in the payload header and then have two reserved bits? Is 
it investigated that there is no improvement of having interleaving 
using longer lengths than 8?

4. section 5.1 paragraph after table. "A ToC entry with a reserved Frame 
Type value SHOULD be considered invalid and substituted with an erasure 
frame." I don't believe this is a possible solution on the receiver 
side. If there is an error in the TOC it will be impossible to know if 
any remaining speech frames are in synch. There fore all remaining 
speech frames must be marked as erased or the whole packet discarded. I 
also recommend that a sanity check is performed on the receiver side. 
The received packet length and what the payload header size plus the 
speech frames length indicated by the TOC must match. If there are not a 
error somewhere in the TOC is probable and that can result in severe 
degrading of speech quality.

5. Section 6, sixth paragraph.  "Given a time-ordered sequence of output 
frames from the EVRC codec
   numbered 0..n, a bundling value B (in the Count field), ..." The 
parenthesis is misleading, the value B is the number of frames in a 
packet, the count field is one value lower as it is defined. Propose 
that the text in the parenthesis is change to clarify that it is the 
number of frames in a packet.

6. Section 8 first paragraph. "While an erasure frame MUST NOT be 
transmitted by an RTP sender, ..." I am a little curios about the MUST 
NOT for sending erasure frames. There exist a legal reason to send 
erasure frames in my opinion. The case with a gateway between a circuit 
switched network and a IP network. When some error in the circuit 
switched network result in a frame loss it could forward that 
information by using an erasure frame instead of a blank frame.

7. section 9.1 fourth paragraph. What is the motivation for recommending 
4 or 5 as interleaving length. Shouldn't a interleaving length of 8 be 
the most robust?

8. section 9.2, fifth and sixth paragraph. In my eyes it looks wrong to 
use a mode request with an unknown value to set the mode. Isn't it 
better to ignore such a mode request?

9. The reference [2], SMV codec. I can't find the specification on the 
3GGP2 web site's specification page, shouldn't be slightly below the 
EVRC spec?

10. section 10.1 third paragraph. "The ToC field is expanded to one 
octet by setting the left-
   most four bits of the octet to zero." Isn't it better to change the 
sentence to: "The ToC field is expanded to one octet by setting the four 
most significant bits of the octet to zero." The use of left in a bit 
pattern can be misinterpreted.

11. Section 11. This section should be expanded with more text similar 
to what can be found in section 8.3 in the AMR draft.
 

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/T/VA
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt