[xiph-rtp] Lots of proposals

[David Barrett]

Tor-Einar Jarnbjo wrote:
> David Barrett wrote:
> 
>> Well, I don't claim to know all the uses, but in my case I'm using 
>> Speex and Theora (and eventually Vorbis) in a P2P scenario where peers 
>> are inaccessible via TCP because they're behind NATs and firewalls.  
>> Thus:
> 
> No offense, but this sounds like a rather unusual usecase and I am not 
> sure if your requirements here should be used as an argument for how the 
> RFC should be formulated. Without proper NAT and/or firewall 
> configuration, most computers are not accessible via UDP either, but it 
> is not in the scope of the Vorbis/RTP RFC to solve all sorts of network 
> configuration issues.

None taken, but I disagre it's at all unusual: it's the classic 
VoIP/videoconferencing case.  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.


>> 2) A separate RTP stream brings no benefit as whether I send codebooks 
>> inline on the data RTP stream, or in a separate RTP stream, the 
>> broadcaster still has no idea if it ever arrives, and the receiver has 
>> no way of triggering a retransmit.  This leads to the wasted bandwidth 
>> and high setup latency that you spoke about earlier.
> 
> No. The RTP setup order could in this case look like this (assuming RTSP 
> and SDP):

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

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.

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.

-david