[xiph-rtp] header ident

[Ralph Giles]

Hey, everyone,

I'd like to get things going again with the RTP spec. I remember us 
being stalled on derf's objection that the CRC32 mapping between the 
Payload Header's codec setup field and the two (or three) setup packets 
themselves had too high a risk of collision.

Seems to me we have the following options:

We cannot make the the ident field larger because of overhead. We must 
therefore break the general mapping between the ident field and the 
decoder setup. So in general it is the problem of the stream description 
protocol to establish this mapping.

Now, we can retain the 32 bit ident, so that applications that find the 
CRC "good enough" can still use it.

If we do not do that, and it is a general feature of xiph designs to 
avoid optional features, then I would argue 32 bits is too much. 
Personally, I think 8 bits is plenty, since you have to establish the 
mapping in the session description anyway, and 256 chain segment 
variations should be enough for anybody. :) But I don't think chaining 
is that important to support. We could be a committee and compromise on 
16 bits.

So, 8, 16, or 32? That's one question. I notice that 24 would let 
us word-align the packet data, which has advantages for embedded 
implementations. And another general feature of xiph designs is 
excessive room for future expansion. Therefore I'd propose the 
following payload header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Setup Ident         |   Reserved    |C|F|R| # pkts. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What do you think? I don't have good intuition on how a one byte 
overhead of dubious future usefulness weighs against simplicity
of packet construction.

 -r