[xiph-rtp] Lots of proposals
Tor-Einar at Jarnbjo.de
Thu Sep 1 17:43:34 PDT 2005
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
> 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
> 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
- 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
- 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.
More information about the xiph-rtp