Subject: RE: Relationship between RTSP URL and transport

From: Rob Lanphier <[email-masked]>
Date: Mon, 23 Jun 1997 16:52:09 -0700

At 01:36 PM 6/23/97 -0700, Eric Fleischman wrote:
>As I read this message and subsequent postings, I (hopefully
>incorrectly) see a desire to migrate the current version of the RTSP
>spec into a version where one RTSP session will be needed manage each
>RTP stream. If so, a logical presentation with 5 media types each with
>their own RTP session will be "managed" by 5 separate RTSP sessions!
>Thus, five sockets will be needed to control five other sockets (data
>streams) -- a most ineffectual use of resources!! 

Whoa, wait a sec.  5 RTSP Sessions != 5 TCP Sockets.  

A single TCP connection is capable of handling 5 RTSP Session, since the
requests are made ala HTTP keep-alive, and the multiplexing is handled via
the "Session:" header field.

We can discuss the rest of your points later, but I want to make sure that
this assumption is not at the foundation of your concern, and how you feel
about your other points based on modifying this assumption.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Eric Fleischman <[email-masked]>
Date: Mon, 23 Jun 1997 16:57:38 -0700

Henning Schulzrinne wrote (on June 23, 1997)
>I would argue (and this was the original problem) that having both
>per-stream and aggregate control for the same presentation is probably
>not such a great idea, although nothing in the RTSP syntax prevents you
>from doing this.

I disagree. I believe that the flexibility of being able to have both
per-stream and aggregate control by the same RTSP session is A Good
Thing. It is my personal belief that most usages will be "aggregate
control" uses: The client will want to start a presentation, pause it,
fast forward, etc -- all aggregate control actions. However, the client
may also want to "mute" the audio and record the whiteboard at times
within the session. These latter are per stream control actions. Thus, I
would argue that in the general case it is preferable to
permit/encourageboth aggregate and per stream control by the same RTSP
session and that supporting both is the "more natural" way to control
multimedia content.

>The only limitation is that SETUP cannot be used to set up more than
one
>port number (say). In principle, we could decide that SETUP could use
>any of the session description methods (SDP, RTSL, SYMM, etc.). The
>SETUP transport parameters were taken as the minimal subset necessary
to
>ensure that all RTSP-compliant implementations could communicate. I
have
>no problem with the transport header. It can express a few things (like
>interleaving, mode and appending) which SDP would have to "learn" or
>which would have to remain in the transport header.

The main point of my posting was that SETUP is a feeble method which
should be replaced or supplemented by the DESCRIBE method. This is why I
wanted to make SETUP and DESCRIBE to be peers as far as which is
required (i.e., one is required to use either one or the other with
using both being also permitted). 

However, since you apparently want to continue to keep SETUP as being
required and DESCRIBE as being optional as the spec currently states,
then I would like to suggest that you consider specifying a unique port
value within SETUP (e.g., a "?" as in "port=?") which would be defined
as meaning that the port information must be subsequently specified in
the DESCRIBE method and thus is not being specified by SETUP. In that
way we can cleanly indicate within SETUP that subsequent (e.g., SDP)
information is being carried by DESCRIBE, thus eliminating potential
confusion as to how to identify aggregate control (due to current SETUP
limitations). 

On another topic, your latest posting used language which made me think
that the RTSP authors have expanded the RTSP text -- or at least their
understanding of the text -- considerably beyond the -02 version of the
spec which is available to the list. Would you mind issuing an -03
version of the spec soon so that non-authors and authors can synch up
and verify that we are indeed "on the same page" together?

---

From: Eric Fleischman <[email-masked]>
Date: Mon, 23 Jun 1997 17:18:57 -0700

Thanks, Rob, for checking.

I am indeed concerned about the fortuitously incorrect equation but
multiplexing multiple RTSP sessions on the same TCP session does not
really address my concern. These concerns are: 
*	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.
*	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.
*	Dislike of the "gutless" SETUP method which I believe confuses
important aggregate control issues with self-imposed limitations.
*	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. (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.)

> -----Original Message-----
> From:	Rob Lanphier [SMTP:[email-masked]]
> Sent:	Monday, June 23, 1997 4:52 PM
> To:	Eric Fleischman; 'Henning Schulzrinne'; Alagu Periyannan
> Cc:	[email-masked]
> Subject:	RE: Relationship between RTSP URL and transport
>