[xiph-rtp] Lots of proposals

[David Barrett]

Ok, I think we've covered all the bases we're going to cover.  I'm going 
to attempt a summary of my position -- Tor, will you please do the same? 
(ie, please don't respond point-by-point to my position, just summarize 
yours)

1) For the P2P architecture I am currently developing with Speex and 
Theora, neither HTTP nor inline unacknowledged codebook delivery are 
ideal options.  Thus I propose a new option, inline with codebook ACK 
(which, incidentally, works well with chaining to support seamless 
adaptive encoding).

2) I intend to use Vorbis in the same architecture, and would like to 
use the same solution (inline with codebook ACK).

3) I believe my use case (the common P2P case) is fundamentally 
different than today's common web radio case and tomorrow's 
theoretically-common multicast case.  Indeed, I supect there are more 
cases, some of which might warrant yet more codebook delivery options.

4) Given all these delivery options, I don't want to build them all, and 
I expect others won't want to either.  Thus I propose we make *all* 
codebook delivery options into optional extensions, with some 
suggestions about which options are recommended for which type of 
application (P2P, client/server, multicast, TCP, etc.).

5) As a compromise, I'd be open to picking one option as a "baseline" 
that all decoders support.  If we do this, I recommend picking the 
easiest one (unacknowledged inline codeboks) so as to minimize time 
spent developing unused features.

6) Finally, I believe the IETF would accept the above proposals just 
fine.


Anywhere, that's where I stand.  And I'll note that for me, this is not 
some abstract thought experiment.  My recommendations are based on 
solving today's problems using today's internet, intended for 
integration with an architecture and application that exists today.

-david

On Fri, 2 Sep 2005 3:17 am, Tor-Einar Jarnbjo wrote:
> David Barrett wrote:
>
>> None taken, but I disagre it's at all unusual: it's the classic 
>> VoIP/videoconferencing case.
>
>
> It is, but as I already pointed out: Vorbis _is not_ suitable for low 
> latency use cases like VoIP or video conferencing, so there is no point 
> in considering this when writing the RFC. The Vorbis codec itself has a 
> realtively high latency, it is not coping very well with packet loss - 
> enforcing a longer receive buffer to compensate for transmission jitter 
> and it is tuned for music and not for speech compression. For the same 
> reasons, noone is seriously using MP3, WMA or similar for telephony or 
> conferencing. I'm not sure about this, but I expect Theora to have many 
> of the same limitations and I'm not really convinced if it's suitable 
> for video conferencing either.
>
>> All if it is going P2P (think Skype) using the same NAT/firewall 
>> penetration techniques I'm using.  The primary standards are SIP and 
>> RTP (not RTSP), and all the networking is UDP.  If Theora and Speex 
>> are to be considered for this entire industry, this problem needs 
>> solving in one way or another, and the two options you present are 
>> cumbersome.
>
>
> You already realized this yourself, but my suggestions would work 
> perfectly with SIP as well as with RTSP. The only requirement for the 
> extra RTP stream to work is that the client is able to setup an RTP 
> stream and the server is able to transmit one. If they weren't, they 
> wouldn't be able to setup the audio stream either, so I can't think of 
> any situation where it won't work. In a SIP situation, the client would 
> "dial" the main audio stream, getting a reference to the codebook 
> stream in the SDP. It could then dial the codebook address and get the 
> codebook while e.g. letting the main address ring.
>
>> (I'm not using RTSP, but an equilvalent method would work with SIP.) 
>> Yes, that would work.  But consider the two options:
>>
>> 1) Establish two RTP streams, deliver codebooks over one, media over 
>> another, kill codebook stream when received.
>> 2) Establish one RTP stream, deliver codebooks and media on it, send 
>> codebook ACK in RTCP profile when received.
>>
>> Both "work" in the sense that you can write a program to do it in each 
>> way.  Both have comparable performance characteristics.  But neither 
>> is plainly superior.  I assume #1 fits your architecture better.  I 
>> can guarantee, #2 fits mine.
>
>
> As I already pointed out, I'm not having any architecture to target and 
> I am trying to speak generally and not about a specific use case. OTOH, 
> if you see for which purposes music streaming is actually being used at 
> the moment, you are mainly limited to real time radio broadcasts and 
> specific songs on demand. At least I assume that multicast will become 
> more popular in the future, at the moment it is simply not supported by 
> most IPs or in the internet backbone. The difference I see between the 
> two options you describe are that 1 will work for both multicast, 
> unicast and without client feedback (and is the only really scalable 
> solution yet being discussed) and 2 will only for for unicast with 
> client feedback. Especially for multicast scenarios, it is important 
> that the mechanism should work without client feedback.
>
>> I'm merely advocating that we are not smart enough to pick the 
>> end-all-be-all solution for codebook delivery.  This discussion alone 
>> (not to mention the many similar discussions that have proceeded this) 
>> is proof enough for me that there are strong opinions and reasonable 
>> arguments in favor of competing options.
>
>
> Yes, if we could just spend time being constructive instead of wasting 
> time on discussing completely off the edge problems, we might have been 
> much further. As long as people are making definite statements based on 
> "random values" and ends up with a conclusion containing results far 
> off any realistic values (Luca Barbato: 0,4 vs >8s for codebook 
> delivery) and you are trying to make the mandatory part of the RFC fit 
> a use case, for which Vorbis was never designed, we won't get anywhere.
>
>> Whether we mandate supporting all, mandate supporting some, or leave 
>> everything optional to the developer -- somebody will be dissatisfied. 
>> And at the end of the day, I vastly prefer a RFC that errs on the side 
>> mandating too little, than mandating too much.
>
>
> Yes I may agree on that, but we obviously disagree on exactly what. 
> Mandating only inband RTP delivery of the codebook makes it an IMHO 
> completley unusable RFC and I expect IETF to share that opinion.
>
> Tor
>
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp