Subject: RE: RTSP: 6. Destination for data that is not the source of control messages

From: David Oran <[email-masked]>
Date: Fri, 18 Apr 1997 13:15:03 -0400

At 09:51 AM 4/18/97 -0700, Eric Fleischman wrote:
>RTCP use is great. However, one of the underlying concepts of RTSP was
>that it was to be "neutral" about the data delivery protocol. 
Eric, I can't tell from this whether you're arguing in favor of, or
against, my idea of using RTCP to protect unicast sinks from being
bombarded with unwanted data. :-) See below...

>RTCP just
>doesn't care whether the data -- and RTSP "control messages" themselves
>-- is carried by UDP, TCP, UPD/RTP, TCP/RTP or Joe's recent transport
>invention. Thus, binding RTSP to RTP represents a change in thinking as
>to what RTSP actually is.
>
I don't think of this at all as "binding" RTP and RTSP together. Clearly
the RTCP method would only work for streams delivered to unicast sinks
through RTP.

>There is power in limiting RTSP to its original constraints and relying
>on other protocols, in partnership with RTSP, to fill in those holes
>which are purposefully "out of scope" to RTSP itself.
>
I agree with this. In fact, let me take this one step further. Your logic
argues that RTSP cannot safely interpret *any* particular delivery address
to decide if that address is co-located with the RTSP client. Let's say we
want RTSP to deliver a stream straight on top of an ATM VC, using Q.2931
addresses. How would the RTSP server figure out whether that ATM address
isn't some poor sucker who will accept an incoming VC and get spammed? The
only way to deal with this in general is for the server to learn directly
from the stream sink whether it wants the data.

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]