[AVT] Comments on draft-ietf-avt-rtp-uemclip-02.txt

"SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@orange-ftgroup.com> Mon, 07 January 2008 15:31 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtwS-0003Kb-Qx; Mon, 07 Jan 2008 10:31:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtwR-0003KR-48 for avt@ietf.org; Mon, 07 Jan 2008 10:31:07 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtwO-00083T-LL for avt@ietf.org; Mon, 07 Jan 2008 10:31:07 -0500
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 16:31:02 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Jan 2008 16:31:00 +0100
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD10450C98A@ftrdmel1>
In-Reply-To: <0C66FCDA-4FA4-442C-8CC2-4EAAC26661F6@csperkins.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-avt-rtp-uemclip-02.txt
Thread-Index: AchD5SXQsPZ30D+oQXa7n7/XgT2xKgNVK1Vg
References: <0C66FCDA-4FA4-442C-8CC2-4EAAC26661F6@csperkins.org>
From: SOLLAUD Aurelien RD-TECH-LAN <aurelien.sollaud@orange-ftgroup.com>
To: AVT WG <avt@ietf.org>
X-OriginalArrivalTime: 07 Jan 2008 15:31:02.0420 (UTC) FILETIME=[4F8A1540:01C85142]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Subject: [AVT] Comments on draft-ietf-avt-rtp-uemclip-02.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Hi

Here are some comments on draft-ietf-avt-rtp-uemclip-02.txt

* Section 2

It seems it is a 20-ms framed coder. You should state it.
Is there a reference to the coder spec?

* Section 3.1, the paragraph on the timestamp is not very clear.

"the RTP timestamp MUST advance based on a multiple of 8 kHz ..."
I think the word 'clock' is missing somewhere.
It would be clearer to talk about the RTP timestamp clock that is 8 or 16 kHz, and explain how it is chosen.

* Section 3.3.1

  - In figure 3, I think you could remove all the "0 1 2 3 ..." in the fields.
The classical rule is to use network byte order. If it is the case, simply state it and simplify the figure.

  - ID : For it to be useful, it should be a MUST. What is the intent of this field?

  - BS : it is not clear how it is used when multiple frames are packed. By the way, is this field really needed? It seems redundant with the payload size.

  - MX and PC : add reference to the describing sections

* Sections 3.3.1.1 and 3.3.1.2

 - It could be interesting to have informational text on the goal and the way to use these fields.
For example how is computed PW1 or PW2? How could V1 and V2 be different? ...
I think more documentation is desirable.

 - Again, I'm not sure it helps to have the "0 1 2..." in the fields on the figures.

 - R3 : reserved bit are usually set to zero

* Section 3.3.2

 - Is SB really useful? I think with CI, FI and QI and figure 3 you can deduce the sub layer size?

 - Figure 3 : CI is set to zero but the text says it should be "0x1"

* Section 5

"UEMCLIP does not have any built-in mechanism for reducing the bandwidth"
-> I don't think it is true since you can remove high level layers if you want.

* Section 6.1

 - this part should be self-contained so when referring Sections, you should add "of RFC XXXX"

* Section 6.2

I'm not sure the "Bandwidth" paragraph is needed.

* Section 6.3.2

It is a little incorrect to state "In the example below, the ptime is set to 60, and this
   means that there are 3 frames in each packet."

RFC 3264 says "If the ptime attribute is present for a stream, it indicates the
   desired packetization interval that the offerer would like to
   receive."


Regard,
Aurelien


________________________________

De : Colin Perkins [mailto:csp@csperkins.org] 
Envoyé : vendredi 21 décembre 2007 16:21
À : AVT WG
Objet : [AVT] Working group last call: draft-ietf-avt-rtp-uemclip-02.txt


This is to announce a working group last call on the RTP Payload Format for the UEMCLIP Speech Codec <draft-ietf-avt-rtp-uemclip-02.txt>. Please send any final comments on this draft to the mailing list by 18 January 2008. If no substantive issues are raised by that time, we intend to ask the IESG to publish this as a Proposed Standard RFC. 

-- 
Colin Perkins <http://csperkins.org/> 


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