Date: Wed, 09 May 2007 21:04:22 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Ross Finlayson <finlayson@live555.com> Cc: freebsd-multimedia@freebsd.org Subject: Re: streaming guru needed Message-ID: <20070510040422.ABA475B50@mail.bitblocks.com> In-Reply-To: Your message of "Wed, 09 May 2007 20:24:27 EDT." <f06240801c2681654cd5a@[66.80.62.44]>
next in thread | previous in thread | raw e-mail | index | archive | help
> >This is not right. The OP seem to have misunderstood rtsp. > >It has been a while but from what I remember rtsp does not > >have acks as it was designed to work the same way over udp > >and tcp and A/V can tolerate loss of a few packets so no > >sense in having acks. > > No, you're the one who's misunderstanding. RTSP is the 'control > protocol'. It always runs over TCP. It _has_ been a while :-) I was thinking of the media delivery portion only, not the control portion. In any case rtsp does not have acks and yes technically it can be over udp and yes, you can interleave media data on the same session so it is not a pure control protocol either (though you can think of it as such). The spec says: An RTSP session is in no way tied to a transport-level connection such as a TCP connection. During an RTSP session, an RTSP client may open and close many reliable transport connections to the server to issue RTSP requests. Alternatively, it may use a connectionless transport protocol such as UDP. Though it is likely this was left over from some earlier rev. I no longer recall if (one of) the starting point(s) for RTSP was RTTP2, an internal Real Networks effort, but I assume so given Rob Lanphier is one of the RFC authors but I don't really know. In any case RTTP2 could go over either UDP or TCP and I will admit I was thinking of that!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070510040422.ABA475B50>