[xiph-rtp] Lots of proposals

[David Barrett]

Tor-Einar Jarnbjo wrote:
> David Barrett wrote:
> 
>> - The only codebook mechanism supported by the baseline spec is inline 
>> delivery, without ack/retransmit.
> 
> How do you expect the client to handle transmission loss of parts of the 
> codebook header?

Well to start, if you're delivering RTP via a lossless channel (over 
TCP, or in a file) then the baseline works just fine and I'd stick with 
that.

However, generally you are using UDP which is unreliable, and so I 
agree, that's the problem.  Whether loss of part or the whole thing, the 
baseline isn't that great.  If I were writing a plain vanilla baseline 
broadcaster, I'd use some kind of exponential backoff of the codebook. 
For example I'd send at:

0ms
1000ms
2000ms
4000ms
8000ms and every 8s thereafter

Unfortunately it's never *guaranteed* to arrive, but it's highly 
probable.  Frankly that's not reassuring to me, which is why I probably 
wouldn't write a baseline broadcaster.  Rather, I'd pick whichever 
codebook delivery mechanism made the most sense for my situation:

- If I'm broadcasting to a small group using UDP, I'd use an optional 
extension where the client sends a "codebook acknowledged" whenever it 
receives the codebook.  Then the broadcaster would just keep sending the 
codebook every second until it receives a "codebook acknowledged" before 
sending any audio/video.

- If I were broadcasting over multicast, I might use an optional 
extension where codebooks are just sent periodically over a separate 
channel.  Then clients subscribe to this channel long enough to get the 
codebook, and then unsubscribe after they've got it.

- If I'm broadcasting from a webserver, I might use an optional 
extension where codebooks are delivered over HTTP via URLs embedded in 
the SDP.

I'm sure there are other strategies that are appropriate for other 
situations.  The key thing is, however, the baseline RTP packet format 
remains the same for all these situations, and it's only the codebook 
delivery mechanism that changes.

Does this make sense?

-david