[xiph-rtp] Interesting post on AVT list

[David Barrett]

Luca Barbato wrote:
> Aaron Colwell wrote:
>>This would require that all
>>codebooks be known at SDP generation time. I'm pretty sure we've
>>already agreed to that constraint though.
> 
> We can even relax that constraint allowing offband and/or inband
> retransmissions, not sure if it worth the complexity at this point since
> most of the current target implementations are covered, I do hope.

Basically someone needs to decide:

	1) Is "chaining" supported in RTP?
	2) If it is, can new codebooks be delivered on the fly?
	3) Does this decision apply only to Vorbis, or also Theora, etc.

My preference would be "yes" to all three.

Most of the complexity is on the serverside -- ensuring codebooks are 
somehow delivered before the client needs them -- and it's the 
serverside that chooses if it wants to chain.  In other words, the price 
is paid by the same developer who makes the decision; all the client 
needs to do is maintain a codebook cache and reset the decoder -- not 
trivial, but not difficult tasks.

Personally, I think the ability to change the parameters mid-stream 
without the overhead of a total stream negotiation is a nice advantage 
of the Xiph codecs.  This in fact could be a selling point for streaming 
situations where high-level adaptive encoding is valuable.

There's also perhaps a fourth question:

	4) Will Xiph codecs ever have "fixed" codebooks.

However, it's my impression this has already been decided (and the 
answer is "no"), and we're simply grappling with the consequences.


>>Comments?
> 
> I suggested that way long ago, but then somebody pointed me the 1k
> constraint to SDP, it that doesn't applies to us I'm quite happy.

While I love the idea of using SDP for codebook delivery, I've never 
heard of jamming huge base64-encoded binary chunks (ie, 5-10KB) into it 
and I'm not sure that's the intent of its designers.  For example, are 
there parser limits on field sizes that this would break?

Furthermore, the only way SIP (not sure about RTSP) can deliver >MTU 
packets is to use TCP.  If we were to mandate this we'd in effect state 
that Vorbis RTP streams can only be set up in environments where TCP is 
allowed.  To quote RFC 3261:

> 18.1.1 Sending Requests
>    ...
> 
>    If a request is within 200 bytes of the path MTU, or if it is larger
>    than 1300 bytes and the path MTU is unknown, the request MUST be sent
>    using an RFC 2914 [43] congestion controlled transport protocol, such
>    as TCP.

(Granted, just above this quote SIP states that TCP "MUST" be supported 
for precisely this reason -- to deliver >MTU packets -- but it's my 
impression that this is often ignored in the increasingly-common P2P case.)


> PS: I'll try to update the rfc having that vector as default and
> suggested and I'd let the others as discouraged.

I'm fine with stating that vorbis-rtp clients MUST support codebooks via 
SDP.  However, I'd recommend that vorbis-rtp servers only SHOULD deliver 
their codebooks in SDP.  This allows for servers to work in pure-UDP 
environments without being non-compliant.  (They might be non-compliant 
with SIP, but that's a separate matter.)

Furthermore, we could state that the inline delivery method SHOULD NOT 
be used by the server unless the SDP method is unsuitable.  Regardless, 
just as clients MUST support the SDP method (even if it's not always 
suitable), clients MUST support inline delivery.

And finally, this doesn't prevent any optional codebook delivery 
profiles (such as my favorite, inline with acknowledgment) that work on 
top of this.

-david