[xiph-rtp] Lots of proposals

[Luca Barbato]

David Barrett wrote:

> 
> Also, I agree we *could* beat an existing round standard into our square
> peg, but it wouldn't be pretty.  A minimal, purpose-built RTCP profile
> that solves just this problem might be appropriate.  We needn't limit it
> to just Xiph codecs, but it will be used by *at least* those.
> 

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.


> Granted, when you only have a hammer, everything looks like a nail.  But
> I would vastly prefer to send a *single packet* along a RTCP stream that
> is *already established* -- even if it means creating a new RTCP profile
> -- to any of the proposed alternatives.
> 

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.


> 
> Basically, I hear all this talk about HTTP being the "safe fallback
> option", but in my experience, and for my application, it simply isn't.
>  I believe inline transmission with ack/retransmit would be superior in
> almost all cases, eliminate the need for HTTP delivery altogether, and
> thereby vastly reduce the client complexity while simultaneously
> improving performance.
> 

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

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.

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.


lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero