Subject: RE: Relationship between RTSP URL and transport

From: Brad Hefta-Gaub <[email-masked]>
Date: Tue, 24 Jun 1997 03:15:39 -0700

Eric,

you wrote...

>> *	The belief that the spec should cleanly identify a way to have a
>> single RTSP session control a single logical presentation being carried
>> via multiple RTP sessions.

I think we need to be very clear about what we mean by "RTP session" in
this phrase. As I understand it, the phrase "RTP Session" as per the RTP
spec refers to an RTP stream targeting a single address/port combination.
Eric, is it actually your desire to have a single RTSP session control the
RTP streams flowing to multiple address/ports?

It seems to me that you are probably asking for a single RTSP session to
control the playback of multiple RTP streams that are targeting a single
address/port combination, much like a single NetShow control channel
can control a set of multiple streams targeting a single UDP address/port
combination.

Can you clarify?

>> *	The belief that that that single RTSP session should cleanly be
>> able to have both aggregate and per-RTP-session control of that logical
>> presentation.

You've given a couple vague examples of this per-RTP-session control, but
I'm not quite convinced a change to the spec is needed for you to implement
those features. For example you mention:

	>> to "mute" the audio 

	This feature should be primarily implemented on the client side as 
	part of the audio device integration. In general an end user will 
	be confused and disappointed if they don't get instantaneous response
	from the mute/un-mute feature. Our usability tests have shown that
	the latency introduced by actually turning on and off the stream
	produces more confusion than any additional value added by actually
	"stopping" a single stream of a multi-stream presentation.

	>> record the whiteboard at times
	
	Again, this is a client feature unrelated to the actual streaming of
	the bits. Whether or not you are recording the whiteboard feed, you
	probably still want to view it.

In general I think this is a reasonable "feature" to _not_ implement in v.1.0 
of the RTSP spec. (Let's avoid feature creep for something which can be 
implemented on the client side independent of the protocol.) When we do begin
to entertain the v.2.0 spec we should be able to easily add this as a PEP 
extension to the SETUP or other methods.

>> *	Dislike of the "gutless" SETUP method which I believe confuses
>> important aggregate control issues with self-imposed limitations.

Again, I don't think you've actually demonstrate to the group that SETUP
is deficient. If you reconsider your view on what it means to stream a 
multimedia file (like ASF or QuickTime or RealMedia) using RTSP, you will
see that the spec _does_ support the same level of support that both NetShow 
and the RealPlayer support for streaming multiple data streams to a single 
client side port as controlled by a single control session. Isn't this the
real issue?

>> *	Desire to supplement  (or replace) SETUP by the more-robust
>> DESCRIBE method which more cleanly integrates SDP-based setup
>> information and thereby establishes both the aggregate and the
>> per-RTP-session identities which can subsequently be controlled by the
>> same RTSP session. 

I'm a bit surprised by this position. Is it not clear that DESCRIBE's role 
in RTSP is to provide media stream initialization information? I don't think
anyone has ever suggested that protocol initialization related information 
should appear in the response to the DESCRIBE message, this is clearly the
job of the SETUP message. Again, as I tried to point out in my mail to the
group yesterday, I think we may have read too much into the suggestion that 
SDP be used as the "format" for the describe response. Let's not lose sight 
of what DESCRIBE's role in the protocol is.

Remember that the bulk of the DESCRIBE message's value comes from the
server telling the client about the characteristics of the media. In contrast 
the bulk of the SETUP message's value comes from the client telling the 
server about the characteristics of its network setup. These are clearly 
different tasks that are rightfully separate.

>> (If the spec wants to continue to be "presentation
>> agnostic" then you can substitute "proprietary or SDP-based" for
>> "SDP-based" in the previous sentence if such is its wish.)

Clearly we need to agree on formats we will all use in order to be 
interoperable, I think this language was intended to point out that since 
the C->S DESCRIBE method allows the specification of a "accept" header, 
the client and server can negotiate a format which is most useful for them 
both. This is not at all unreasonable and the concept has a strong foundation 
in HTTP. I don't think the "spirit" of the spec needs to be changed relative 
to this statement. Of course, there is always room for improvement in the 
"letter" of the spec.

On this note, it would probably be more useful for the group to expend
its efforts in defining the interoperable manner in which multiple streams
can be streamed to a single address/port.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: [email-masked]
web:   http://www.real.com
-----------------------------------------

---

From: Philipp Hoschka <[email-masked]>
Date: Fri, 04 Jul 1997 17:05:28 +0200

>	"stopping" a single stream of a multi-stream presentation.

No !!
one of the reasons to switch of one of the media types is that you
don't have enough bandwidth to support all of them - this is like
web browsing with images switched off.

While this is crude, it's quite useful - Europeans often do this when
browsing the web, and I remember vividly following a recorded MBone seminar
where I had to switch of the video to be able to follow it.

Please consider this as another factor of "usability" - otherwise, why
would you switch off anything in the first place ?

Having one RTSP session controling one RTP stream allows to do this.

(maybe you should do usability tests in Europe as well, with a server
in the US :-))