[xiph-rtp] Lots of proposals

[David Barrett]

Tor-Einar Jarnbjo wrote:
> For a 100kbps stream, it will take roughly 5 
> secs to transmit the header this way, add some packet loss and 
> prebuffering of audio data and you'll soon end up with an inacceptable 
> delay before the client is able to start playing.

This is exactly what I experienced, forcing me to drop inline 
transmission.  Personally, I've come to the conclusion that it's just 
not a good idea to make a profile of an unreliable protocol (RTP) depend 
on reliable delivery (inline codebook transmission) without providing 
some kind of reliability feature.  Otherwise at best you're wasting 
bandwidth, and at worst you're creating unacceptable delays.

With this in mind, has anyone proposed a matching RTCP profile that adds 
a "codebook acknowledged" packet?  If this existed, clients MUST send it 
when they get a codebook, but the server only SHOULD pay attention to it.

Thus unidirectional broadcasters would need to do some kind of 
exponential retransmission backoff or something (at cost in delay and 
bandwidth), while bidirectional broadcasters/receivers could reliably 
deliver codebooks before the server ever sends video data.

(And I believe this is entirely orthogonoal to the chaining discussion.)

-david