[xiph-rtp] Lots of proposals

[Aaron Colwell]

On Mon, Aug 29, 2005 at 04:17:33PM -0700, David Barrett wrote:
> 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.

Inline delivery is mainly for forward link only and multicast scenarios.
The periodic transmission of the codebooks is added to the cost of delivering
the stream and is a necessesary component for cases where you have no way to
insure reliable transmission.

> 
> 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.

I go back and forth about whether it is appropriate to create our own
"codebook ACK" or whether we should use existing IETF standards and drafts that
have similar purposes. There are several options mainly RTCP XR 
(RFC 3611), AVPF (AVT Internet Draft), and perhaps the retransmission draft.
The conflict I have about using the existing stuff is that it seems to apply to
the whole session. We really only want to reliably transmit part of the
session. It's not clear to me whether this is justification enough to create
our own reliability mechanism or not.

I think this conflict is mainly the reason why I've leaned towards HTTP for
codebook retrieval. It allows you to use a seperate reliable transport for the 
only data that needs to be transmitted in a reliable fashion.

I suppose one other possibility could be to put the codebooks in their own RTP
session. A client could then listen to that session for as long as it took to
receive the codebooks and then close down that session. I'm not really a huge
fan of this particular idea since it has a much higher overhead then a simple
HTTP transfer.

Aaron