Re: [AVT] draft-kerr-avt-vorbis-rtp-04

Colin Perkins <csp@csperkins.org> Sun, 16 January 2005 18:38 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08531 for <avt-archive@ietf.org>; Sun, 16 Jan 2005 13:38:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqFXA-0008Su-2Y for avt-archive@ietf.org; Sun, 16 Jan 2005 13:53:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqFFE-0006DD-T8; Sun, 16 Jan 2005 13:35:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqF8B-0005DU-Jn for avt@megatron.ietf.org; Sun, 16 Jan 2005 13:28:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05832 for <avt@ietf.org>; Sun, 16 Jan 2005 13:28:04 -0500 (EST)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqFKW-0007gN-BA for avt@ietf.org; Sun, 16 Jan 2005 13:40:52 -0500
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CqEFX-0007Yv-4K for avt@ietf.org; Sun, 16 Jan 2005 12:31:39 -0500
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62688 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CqEFB-00074d-Jg; Sun, 16 Jan 2005 17:31:17 +0000
In-Reply-To: <41DABC1A.90505@plus24.com>
References: <41DABC1A.90505@plus24.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <6AFFD5C9-67E4-11D9-B484-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] draft-kerr-avt-vorbis-rtp-04
Date: Sun, 16 Jan 2005 17:31:12 +0000
To: Phil Kerr <phil@plus24.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: AVT List <avt@ietf.org>
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>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit

Hi,

On 4 Jan 2005, at 15:54, Phil Kerr wrote:
> An -04 update of the Vorbis-RTP draft was submitted a few days ago.
>
> http://www.ietf.org/internet-drafts/draft-kerr-avt-vorbis-rtp-04.txt
>
> Major changes include:
>
> Removal of RTCP-based transport for configuration headers, replaced 
> with in-band transport.
> Inclusion of a CRC32 header field used to tie the stream to the 
> associated decoding codebook.

This is an interesting idea. How is the CRC32 calculated? What is the 
chance of collision, and how would that be resolved?

> Simplification of SDP parameters.

These certainly look reasonable. However, we try to avoid mandating SDP 
(since there may be other session description formats). Can you move 
the description of the parameters into the MIME registration, and make 
this section describe how they can be mapped onto SDP (for those 
applications which use SDP). Section 5 of RFC 3557 is a good example of 
what is needed.

> Plus a number of textual changes.
>
> Comments/feedback welcomed.

A few issues to consider:

  - Why is the payload length only an 8 bit field? It seems that this 
might
    force fragmentation when it's not otherwise needed. Could one use a 
16
    bit field instead?

  - Providing a URI for the configuration header is appropriate, but the
    draft needs to define the syntax of that URI (e.g. by referencing an
    appropriate specification, perhaps RFC 2396). It also needs to define
    the legal MIME types for the data referenced, so the format is known.
    Is there an existing MIME type for this?

  - Need to discussion offer/answer considerations when using SDP. See
    section 5 of RFC 3952 for an example.

Cheers,
Colin



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