[xiph-rtp] Lots of proposals

[Tor-Einar Jarnbjo]

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.

> 1) HTTP is cumbersome because I'd need to have clients post their 
> codebooks to a TCP-accessible server/peer, which undermines the value 
> of a decentralized system and introduces greater points of failure.

Fair enough here, but your arguments againts the second variant are 
completely wrong.

> 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):

- the client issues an RTSP describe request for the main URL and gets 
an SDP response from the server containing another RTSP url (and 
potentially a chechsum/hash) for the codebook stream

- the client issues an RTSP setup request followed by a play request for 
the codebook stream, the codebook data is repeated endlessly at appr. 
the audio stream bitrate

- as soon as the client has a complete codebook (probably within a 
couple of seconds), the codebook stream is closed with an RTSP teardown 
request

- the client can now continue session initialization (RTSP setup and 
play) with the main URL

In your case, including a codebook checksum or hash in the SDP would 
probably make much sense, as I suppose the servers use the same codebook 
most of the time and the client may decide without server knowledge to 
cache the codebook and skip codebook retrieval completely.In any case, 
no bandwidth is wasted during media streaming for codebook 
retransmissions and  the server does not have to care about if the 
client is having the codebook data or not, as the client is either 
clearly stating "start audio streming now" or "send codebook now".

> So in my case, neither of the two methods work well for me.  Yes, I 
> can force them to work if they're the only options, but I'd prefer 
> more options -- such as a "codebook ACK" packet sent via RTCP -- and 
> I'd prefer to do it without breaking the standard.

It's not breaking any standard to refer to other resources in the SDP 
using an URI. It is even mentioned as a usecase in the SDP standard 
(RFC2327, section 5.4).

> Hm, I think you might be right -- Speex can make due with just what's
> defined out of band, such as with SDP (which needs to be delivered 
> reliably, but that's a separate concern).  Regardless, if the problem 
> only exists for Vorbis and Theora (and possibly also Flac), and if the 
> problem is identical for both, that seems sufficient justification for 
> standardizing the solution between the two.

Makes sense, but the common standard does not have to be inband RTP.

Tor