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

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