Subject: RE: Relationship between RTSP URL and transport

From: Eric Fleischman <[email-masked]>
Date: Mon, 23 Jun 1997 13:36:29 -0700

I am still in a fair bit of shock from Henning Schulzrinne's message of
6/17/97:

>Having a single RTSP session control several different (non-composite)
>media streams was considered early on, but it gets really messy, as it
>is hard to express the relationships between media streams without
>inventing something like RTSL, possibly SDP or the SYMM description.
>Thus, I'd expect to see a single URL, referring to a session
description
>of arbitrary complexity containing several RTSP URLs.

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!! *I would like to
provide "push back" against this concept in the general case.* Please
consider:

1) SDP provides a mechanism for associating multiple RTP sessions into
one logical presentation (e.g., see the example on page 8 of the -03
version of the spec where audio, video, and whiteboard "m" fields are
included in a single SDP announcement).

2) In the general case, RTSP users will want to "control" the various
RTP streams as a unit (i.e., as a logical presentation). Users will want
to start, stop, and pause these streams as a unit. Because this is the
"general" and "most common" case, this should be the usage for which
RTSP is optimized.

3) Thus, all that is needed is a mechanism by which to associate
SDP-like "logical presentation" definitions with a logical presentation
as well as to permit that same RTSP session to control each of the
various RTP sessions found within that "logical presentation". The
"grouping" is established by the DESCRIBE method (e.g., the SDP usage
above) and the method by which individual control can occur is defined
in RTSP section 3.2, with the needed caveate that only the streams
defined within DESCRIBE can be controlled (otherwise we would have the
same problems synchronizing between diverse multimedia streams which the
W3C Multimedia Synchronization WG is addressing (e.g., via RTSL or
similar approaches)).

4)  Limitations within the current RTSP SETUP method definition appear
to be the basis for the desire to not permit RTSP to fulfil its original
vision of being able to control an entire logical presentation by a
single RTSP session. This problem exists, I believe, because the current
SETUP method is superflous if one also uses a DESCRIBE method. Thus, I
propose that the spec be altered to state that either SETUP or DESCRIBE
must be used but it is optional (not-required) to use them both
together.

In any case, should one use the RTSP DESCRIBE method then one can obtain
all of the transport information used for the streamed media (e.g., via
using SDP). One can also continue to manipulate the individual streams
as currently stated in the spec (e.g., see example in section 9.4 of the
current version of the RTSP spec which shows how to indepently control
individual RTP streams from a single RTSP control session).

However, a DESCRIBE method containing protocol transport info (such as
all standard SDP-based usages as well as most/many proprietary
approaches) does not need a SETUP since it already contains all of the
information which SETUP will provide -- and do so in a more flexible and
useful fashion without violating the "presentation format" neutrality
goals of RTSP. And since the problem seems to be a function of
inadequacies within the definition of SETUP in the first place, this
seems to be a possible solution to the problem. (Another solution would
be to fix SETUP, but why do that when it is redundant?) Feedback??

---

From: Alagu Periyannan <[email-masked]>
Date: Mon, 23 Jun 1997 15:30:41 -0700

>provide "push back" against this concept in the general case.* Please

My understanding is that there will be 5 RTSP "sessions", but
all of them over a single "connection" to the RTSP server.
Hence, there will be no need for 5 sockets. (You could have
5 connections if you want, but 1 is sufficient.)

It turns out that when using RTP for the data stream your
calculation of the number of sockets used is in fact
close to the correct number, but for the wrong reasons.
A total of 11 sockets will be needed, 1 for RTSP, 5 for RTP
and 5 for RTCP.

---------------------------------------------------
Alagu Periyannan                   [email-masked]

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jun 1997 19:01:19 -0400

> Thus, five sockets will be needed to control five other sockets (data

To avoid further medical complications (and any legal culpability I
might incur), having 5 RTSP sessions in no way implies 5 sockets. One
will do just fine. Instead of saying

PLAY some_name_aggregate RTSP/1.0

you would/could simply say

PLAY stream1 RTSP/1.0

PLAY stream2 RTSP/1.0

...

PLAY stream5 RTSP/1.0

All sent to one TCP socket and pipelined, or sent in one or more UDP
packet(s).

This does occur a few bytes of overhead, but given the TCP header
overhead, even that is likely to be marginal.

Also, nothing prevents RTSP from controlling more than one RTP stream,
if you (as the client) have the necessary information, e.g., through
SDP, RTSL, or similar and the server knows about it. Take a fictional
SDP description in no way endorsed, vetted or coordinated with Mark:

v=0
o=mhandley ...
s=A multi-stream RTP presentation
i=Just an example
r=rtsp://example.com/presentation

(Since c for control is already taken, I use 'r' for remote.) 

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.

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.

Instead of

SETUP foo RTSP/1.0
Transport: rtp/udp; port=4588; ttl=16

we would have

SETUP foo RTSP/1.0
Content-type: application/sdp

v=0
etc.

or

SETUP foo RTSP/1.0
Content-type: application/symm

<PAR ...>

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: [email-masked] (Anup Rao)
Date: Mon, 23 Jun 1997 18:00:00 -0700

> provide "push back" against this concept in the general case.* Please

An RTSP "Session" is not related to transport connections or sessions.
ie all control messages pertaining to the 5 RTSP sessions can(and
usually will) be on the same transport connection.

> W3C Multimedia Synchronization WG is addressing (e.g., via RTSL or

We support:
- Multiple URLs and multiple RTSP sessions  to control  multiple
streams/RTP streams that may be part of the same presentation(ie bear a
sync relationship)
- Single URL and single RTSP session to control a stream/RTP streams
that may infact contain multiple interleaved data streams.

Whats seems to be the issue of debate:
"A single URL and single RTSP session to control multiple streams/RTP
streams. "
Is this something the group feels strongly for ?As pointed out(I
think),  this is possible only when tied intricately with the session
description itself - ie the interpretation of a control message
referencing the URL is tied in with the session desc. This will also
involve(as rightly pointed out by Eric and others a modified SETUP
message).

> must be used but it is optional (not-required) to use them both

Keep in mind that we want to allow the client to choose the port in most
cases for the following reasons:-It knows what is free
-User can configure port range to be used to get thru firewalls.

For these reasons, I'd say any solution that has the server returning
randomly chosen ports in reply to DESCRIBE would be a non-starter.

> be to fix SETUP, but why do that when it is redundant?) Feedback??

   I believe it is not always redundant for reasons mentioned above.
(Also, I dont really see an advantage in the server choosing the port in
the unicast case. Comments ?).

-Anup.