[xiph-rtp] header caching and chaining

Ralph Giles giles at xiph.org
Sat Feb 5 14:54:40 PST 2005


Derf raised the question of CRC32 cache collisions on irc today and I'm 
afraid he as a point.

The idea was to CRC32 hash the info+setup headers, and include that in 
every packet to identify the associated decoder setup. Since this ident 
is generated in a well defined way from the stream headers, clients 
could cache the results and avoid having to do an out-of-band retrieval 
for headers it's already seen. It also makes it easy to verify correct 
retrieval of the headers before use.

The problem is that the risk of a collision causing the decoder to use 
the wrong set of headers. If you believe in deterministically correct 
software, that's bad, and even if you don't the probability with a 32 
bit value is high enough to occur occasionally in practice.

So, the only way around this is to not cache the headers. We could just 
say that, but doing so breaks the broadcast use case where play-time 
retrieval isn't an option.

The other thing we can do is just make it an arbitrary number and say 
that the sender and receiver MUST negotiate a mapping between the ident 
and the decoder setup out of band, and just leave it out of the scope of 
the RTP mapping (beyond the in-band transmission option anyway.) This 
should work fine for the SDP uri and so on.

Thoughts?

 -r


More information about the xiph-rtp mailing list