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

From: Phil Kerr <[email-masked]>
Date: Tue, 04 Jan 2005 15:54:02 +0000

Hi all,

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.
Simplification of SDP parameters.

Plus a number of textual changes.

Comments/feedback welcomed.

Happy New Year

Phil

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Phil Kerr <[email-masked]>
Date: Thu, 06 Jan 2005 18:16:44 +0000

All,

There was a problem with the upload of the draft, it was there when I 
checked before sending the announcement email but sometime after it went 
for a walk on the server.

Apologies if you received a 404 error, the problem has been fixed and 
it's available at the URL below.

Phil

Phil Kerr wrote:

> Removal of RTCP-based transport for configuration headers, replaced 
> with in-band transport.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Jan 2005 17:31:12 +0000

Hi,

> 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.

> 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

---

From: Phil Kerr <[email-masked]>
Date: Sun, 16 Jan 2005 18:42:33 +0000

Hi Colin,

> chance of collision, and how would that be resolved?

The CRC32 is calculated from the codebook header itself.  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.

> 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.

Will do.

>    force fragmentation when it's not otherwise needed. Could one use a 16
>    bit field instead?

The 8 bit field is a historical feature from the original Vorbis I-D.  
Changing it to 16 bits was raised on the Xiph-RTP list just after the 
latest version was submitted and if it doesn't cause any other issues, 
such as causing an inordinate number of packets to exceed path MTU, I 
think it can be altered

>    section 5 of RFC 3952 for an example.

Will do.

Cheers

Phil

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Jan 2005 18:54:37 +0000

Hi,

On 16 Jan 2005, at 18:42, Phil Kerr wrote:
> The CRC32 is calculated from the codebook header itself.

Actually, I meant what is the CRC algorithm, not which data is it 
calculated using?

> 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?

Cheers,
Colin

---

From: Phil Kerr <[email-masked]>
Date: Mon, 17 Jan 2005 11:08:09 +0000

Hi Colin,

> Actually, I meant what is the CRC algorithm, not which data is it 

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.

>> 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.
>
>

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2005 13:24:12 +0100

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

-- 

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: [email-masked]

---

From: Phil Kerr <[email-masked]>
Date: Mon, 17 Jan 2005 12:53:30 +0000

Hi Magnus,

Thanks for clarifying this point.  To avoid the problems you've 
mentioned should I include polynomial function and a C code snippet?

Cheers

Phil

Magnus Westerlund wrote:

> 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:
>>
>>
>> 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.
>>>
>>>
>>>
>>> Can you expand on why the CRC was chosen, and why a table-indexing 
>>> to onto a list of URLs wouldn't work?
>>
>>
>>
>> (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
>>>
>>>

---

From: Linus Walleij <[email-masked]>
Date: Tue, 18 Jan 2005 08:52:00 +0100 (CET)

On Mon, 17 Jan 2005, Phil Kerr wrote:

> Thanks for clarifying this point.  To avoid the problems you've mentioned 
> should I include polynomial function and a C code snippet?

Ideally, that's how it should be done. I don't know if there is an RFC for 
CRC32 that you could simply reference (after checking that it conforms to 
your implementation of course).

Another approach, which I used in the past, is to use SHA-1 hashing 
instead (160 bits), and reference RFC 3174, which already carries an 
example implementation. If you need a free-to-use BSD-like license 
implementation of SHA-1, you can find one in my SHFtool test 
implementation (http://www.df.lth.se/~triad/krad/shftool/) which you are 
more than welcome to use if you like.

Hope this helps...

Yours,
Linus Walleij

---

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Jan 2005 09:03:02 +0000

On 18 Jan 2005, at 07:52, Linus Walleij wrote:
> Ideally, that's how it should be done. I don't know if there is an RFC 
> for CRC32 that you could simply reference (after checking that it 
> conforms to your implementation of course).

If there is an RFC, that would be easiest.

Cheers,
Colin

---

From: Linus Walleij <[email-masked]>
Date: Tue, 18 Jan 2005 15:20:27 +0100 (CET)

On Tue, 18 Jan 2005, Linus Walleij wrote:

> I don't know if there is an RFC for 

Now I know that there is RFC 3385 which carries an example implementation 
in Verilog, sort of awkward unless you're devising hardware 
implementations.

I'd say that SHA-1 is better for any modern software implementation, but 
it's partly a matter of taste and opinion IMHO.

Linus Walleij

---

From: Phil Kerr <[email-masked]>
Date: Tue, 18 Jan 2005 14:23:36 +0000

Hi Linus,

Linus Walleij wrote:

> implementation (http://www.df.lth.se/~triad/krad/shftool/) which you 
> are more than welcome to use if you like.

Thanks for this info.  Because the CRC hash is in each packet, using 
SHA-1 would add 128 extra bits which does add a significant overhead.

Regards

Phil

---

From: Phil Kerr <[email-masked]>
Date: Tue, 18 Jan 2005 14:33:17 +0000

Linus Walleij wrote:

>> I don't know if there is an RFC for CRC32 that you could simply 
>> reference (after checking that it conforms to your implementation of 
>> course).
>
>
> Now I know that there is RFC 3385 which carries an example 
> implementation in Verilog, sort of awkward unless you're devising 
> hardware implementations.
>
> I'd say that SHA-1 is better for any modern software implementation, 
> but it's partly a matter of taste and opinion IMHO.

I've also found references to ISO 3309, which defines the CRC32 
polynomial used in PNG.  I think there should be sufficient pointers to 
cover this in the I-D, and it will be fully documented.

Regards

Phil