[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