[xiph-rtp] Lots of proposals
dbarrett at quinthar.com
Thu Sep 1 19:12:48 PDT 2005
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.
> 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.
More information about the xiph-rtp