[xiph-rtp] Lots of proposals

[David Barrett]

Luca Barbato wrote:
> I'm trying to separate the issues:
> 
> 1 Have the vorbis-rtp baseline approved by ietf asap with the minimal
> set of feature it will allows it to work on every scenario we are
> planning to use
> 
> 2 Make companion i-d for enhance the usage in conjunction with other
> protocols and make them accepted on a second time.

Yes, this sounds like a good plan.


> HTTP site, RTSP messaging, codebook by email or XMPP or whichever Out of
> Band system isn't a concern of baseline, I'd cosinder it allowed options
> by default and I'd like to have them regulated in other linked drafts.

Ok, so are you suggesting the baseline vorbis-rtp draft include basic 
inline codebook transmission (which is adequate for all cases, but 
non-optimal for many), but no out-of-band systems, and no 
acknowledge/retransmit RTCP profile?

If so, I think that's a good idea.


> To sum it up: you almost like Federico's/OMS group proposal about inband
> packet delivery but you prefer it asyncronous and not timed.

Correct.


> The problem with asyncronous delivery is that in the conference scenario
> you may be exposed to floods. A good compromise is to set the
> retransmission time to be related to the number of later joining clients.

Ok, that's a good point.  I've been focused on much smaller groups where 
flooding isn't an issue.  This is another good reason to separate the 
out-of-band/retransmit mechanisms from the base draft, as it's clear the 
usage scenario greatly affects which you might want to use.


> 
> Currently we have those possibilities:
> 
> + No chaining by default with optional chaining support by an in payload
> chainID (hashed)
> 
> + Chaining is band/out band using a preset flag->codebook map.
> The flag proposed is 8bit long and read as integer, timestamp and marker
> bit could have their use to mark the validity of the mappings.
> 
> + As the previous but with a longer hash
> 
> + Codebook retransmission and packet skipping, with support for
> chaining, yet to decide if is more effective which way to mark the
> codebook validity. The retransmission could be periodic, asyncronous or
> a compromise between the two.
> 
> I hope I haven't miss anything.

I'm not sure I followed those, but regardless, these are simply 
possibilities for additional drafts -- ie, you are recommending that 
none of these options are included in the base vorbis-rtp draft, correct?

-david