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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 17 January 2005 12:31 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 HAA29727 for <avt-archive@ietf.org>; Mon, 17 Jan 2005 07:31:34 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWHl-0002qV-5v for avt-archive@ietf.org; Mon, 17 Jan 2005 07:47:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqW0c-000722-12; Mon, 17 Jan 2005 07:29:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqVvd-0006mo-Gr for avt@megatron.ietf.org; Mon, 17 Jan 2005 07:24:17 -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 HAA29355 for <avt@ietf.org>; Mon, 17 Jan 2005 07:24:14 -0500 (EST)
Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqWAe-0002i1-Il for avt@ietf.org; Mon, 17 Jan 2005 07:39:51 -0500
Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0HCODO6018725; Mon, 17 Jan 2005 13:24:13 +0100
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Jan 2005 13:24:13 +0100
Received: from [147.214.34.55] ([147.214.34.55]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Jan 2005 13:24:13 +0100
Message-ID: <41EBAE6C.5020603@ericsson.com>
Date: Mon, 17 Jan 2005 13:24:12 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Phil Kerr <phil@plus24.com>
Subject: Re: [AVT] draft-kerr-avt-vorbis-rtp-04
References: <41EB9C99.2080508@plus24.com>
In-Reply-To: <41EB9C99.2080508@plus24.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Jan 2005 12:24:13.0091 (UTC) FILETIME=[740F7730:01C4FC8F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
Cc: Colin Perkins <csp@csperkins.org>, 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: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit

Hi Phil,

I think the point Colin tries to make is that the CRC polynom and how it 
is calculated must be very well defined. This is an important to get 
correct to be interoperable, however history in many groups has shown 
that definitions of checksums are often not sufficiently explicit.

Cheers

Magnus

Phil Kerr wrote:
> Hi Colin,
> 
> Colin Perkins wrote:
> 
> 
>>Actually, I meant what is the CRC algorithm, not which data is it 
>>calculated using?
> 
> 
> I'm probably not the best person to discuss polynomial functions in 
> depth with, but the CRC32 routine I'm using in the implementations is a 
> basic, non-table lookup algorithm. As the CRC is fixed for the duration 
> it's only calculated once per chained file, and as the codebooks are 
> limited to 64K for RTP, it doesn't need to be highly optimised.
> 
> 
>>>The chance of collision should be quite low, MD5 would be a lot safer 
>>>in this regard but it does add quite a lot of overhead to each 
>>>packet.  There may need to be an additional identifier, possibly a 
>>>host id which ties the CRC32 value to the host, which is sent via SDP 
>>>to reduce the chance of collision further.
>>
>>
>>Host identifiers are difficult to pick too, so I'm not sure that'd help.
>>
>>Can you expand on why the CRC was chosen, and why a table-indexing to 
>>onto a list of URLs wouldn't work?
> 
> 
> The decoding codebook associated with the stream can change at the 
> boundary of a chained file, which can be at any point in the session 
> (new audio tracks or station jingles for example).  Having a CRC of the 
> associated codebook in each packet means there is a hard association 
> between the audio and decoder.
>  
> As the CRC is derived from the codebook itself we have a mechanism for 
> verifying the correct decoder is being used at any particular time 
> independent of any table.
> 
> Cheers
> 
> Phil
> 
> 
>>Cheers,
>>Colin
>>
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>avt@ietf.org
>>https://www1.ietf.org/mailman/listinfo/avt
>>
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 


-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

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