Subject: Sessions, presentations and URLs in RTSP

From: [email-masked] (Anup Rao)
Date: Fri, 11 Jul 1997 17:18:08 -0700

The message is pretty long, but I feel this  is justified by the amount
of discussion that has gone on, and  to try and reach some agreement.

There has been a lot of discussion on streaming of container files using

RTSP  using 1-1-1, 1-1-n, 1-n-n. There is also a proposed way of doing
it using 1-1-n by having a single URL, and referencing (via a header) a
"StreamID" within that URL.

In the container discussion, and in particular of server/client
implementation issues regarding  container file handles and
synchronization,  it seems that seperate issues might have gotten
interleaved here. While they are not 100% seperate, I contend that there

are 3 seperate issues here:-

a) Need for 1-1-n.
b) Standard means for referencing a part within a container, for example

audio track 1 within a  Quicktime file.
c) Aggregate control(sending a single control message that affects more
than one stream).

c) is fairly self-explanatory, there is the also the need for a means to

convey whether the aggregate operation is allowed or not.(Or
alternatively, whether a non-aggregate operation is allowed or not).

Lets take b) first. There seem to be two ways to do this :
1) The "StreamID" proposal
2) Using URLs with ?/# identifiers.

Pros for URLs(Credits to Phillip Hoschka, Stephen Casner and others) :
-Standard, well regulated and understood
-Embedable in html in a  standard way.
-From RTSP point of view, really no difference between a presentation
composed of seperate files, and that composed from parts of a container.

-Reuse : you can say rtsp://foo/movie?track=1, to simply use the audio
track out of a file standalone.

Cons of URLs
-Efficiency and resolution issues in component server architecture(see
mails from Brad Hefta-Gaub and Rob Lanphier)
- URLs may get long and untenable.
- URLs may be used for passing other parameters to server modules, and
there may be possible confusion as to which URL segment references part
of the container vs. which one is meant for other reasons.
(I will try and answer these later on in this message).

Now lets take a)(ie need for 1-1-n):
When a presentation is composed of 2 or more streams(coming from the
same server, regardless of whether it is the same file), it is (very)
handy to have a common session identifier for those streams. This
allows:
-Convenient context for maintaining a single container file handle if
necessary.(Admittedly, this can also be done without having the same
Session: identifer, but that is a tad more difficult to do right)..
-It gives a server implementor some means to actually tie together n
streams that are really a part of the same presentation.(Admittedly,
client side synchronization is a seperate issue. However this is still
great to have, for stream prioritization kind of  issues at the server
end. At worst, having this does no harm).

That said, I would argue that 1-1-n is a special case of 1-n-n, and not
the other way around. Therefore 1-n-n must *always* be possible. It is
the most general way - and the way things are done if two streams come
from different servers.

Besides the issues a), b), there is something I would like to add :
- It is desirable to have RTSP as a control protocol treat presentations

uniformly regardless of whether they come from  a container file or
seperate files. (The purist in me believes that if we special case a
container file, we will lose much of the elegance and abstraction that
we have strived for).
-Need to maintain maximal independance between  RTSP and the session
description.

Being a supporter of the URL way, here is a proposal to:
- Control a presentation using 1-1-n using URLs and not "StreamID"
- Provide aggregate control using URLs and not "StreamID"

Note that in this proposal 1 URL != 1 session. A RTSP session(signified
by Session: )  may involve control messages for more than one URL. In
the current RTSP draft, Session: has one use - it identifes the requests

coming for the same URL for multiple clients. This proposal increases
its purpose somewhat.
The following URL scheme is used to denote a part of the container:
rtsp://foo.com/movie?track=1
The interpretation of stuff after the "?" is upto the server. In this
case, it means Track 1 of the movie presentation - could be the audio
track out of a AVI file or such.
(Note that this URL syntax is just an example for the purposes of this
proposal. We
are looking at  the details)
The session description contains one URL per stream at minimum. In
addition, it may contain a "aggregate" or "presentation" URL. The
interpretation of these URLs is upto the server.

Lets assume that the following session description was obtained by the
client(off a web page or in reply to a DESCRIBE on the container URL):

********
s= sample rtsp presentation
r = rtsp://foo/twister   /* aggregate URL*/
m= audio 0 RTP/AVP 0
r = rtsp://foo/twister?track=1 /* URL to control audio*/
m=video 0 RTP?AVP 26
r = rtsp://foo/twister?track=2 /* URL to control video*/
********

In addition,
-We maintain that there will be one SETUP message per stream. This is
desirable because combining transport parameters for multiple streams
within one message leads to a fair deal of tangled syntax, and the
ability to convey back. (from server to client) which of the streams'
transport params were not correct isn't there. The resulting cost of
round-trips should be acceptable, since these messages may be
pipelined(atleast all after the first one).
-We introduce 2 additional error messages 4xx(Aggregate control not
allowed), 4xx(Only aggregate control allowed)

Here is how things would proceed:

setup rtsp://foo/twister?track=1 rtsp/1.0 33
Transport: rtp/udp;port=8000

200 rtsp/1.0 OK 33
Transport: rtp/udp;port=8000
Session: 4234

setup rtsp://foo/twister?track=2 rtsp/1.0 34
Transport: rtp/udp;port=8002
Session: 4234

200 rtsp/1.0 OK 34
Transport: rtp/udp;port=8000
Session: 4234

play rtsp://foo/twister
Session: 4234

would   start up both the streams.

play rtsp://foo/twister?track=1
Session: 4234

would start up only the audio stream.

The presentation author and the server may decide not to allow this for
artisic reasons. In that case:

play rtsp://foo/twister?track=1
Session: 4234

would result in :
4xx rtsp/1.0  Only aggregate control allowed

means that the client is applying a method on a URL that is not allowed
since it is not an aggregate URL.

The aggregate URL is not "setupable".
setup rtsp://foo/twister

would result in

4xx rtsp/1.0 Aggregate control not allowed.

teardown  rtsp://foo/twister
Session: 4234

would get rid of the session 4234.

teardown  rtsp://foo/twister?track=1
Session: 4234

would get rid of the Session 4234 only if all other streams within that
Session were already  torndown.

I believe the above example would work for RECORD too.

What does this achieve ?
- You can have a single file handle open. The Session: allows you to.
Some part of the server maintains a session context,and parses the URL
to check if it has the file open. There is nothing to preclude a
arbitrary filesystem.
- The client is oblivious to "track=1". The server can choose anything
of its liking(ie rtsp://foo/twister/audio). If we agree on using URLs as

the only controllable entities, having a common URL  syntax atleast for
some basic containers should be possible to do in interest of
interoperability.
-It allows aggregate control for those who want it.
-It provides a way for the client to know whether the URL
is aggregate or not and if the method is allowed.
I think this concept is important - we *have* to introduce this
knowledge
into the protocol in a minimal way. (This proposal does it in the form
of error messages, and it seems
adequate). This allows presentation authors to decide that
"playing only video will never be allowed", as well as allow aggregate
control.
-The session description needs to do nothing but  provide one or more
URL(s). In this way, RTSP is independant of it.
- Multifile, Multiserver, singlefile, singleserver presentations are
treated consistently by RTSP.(ie all are based on URLs as the
controllable entity).
A Multiserver presentation would be necessarily 1-n-n.
- 1-1-n and 1-n-n are transparent to servers. If you do 1-1-n, 1-n-n
would simply work in the cases where the presentation author allows it.
This is important. Again, I stress that 1-n-n should not go away.

What it does not achieve:
-Save roundtrips(If we need n SETUPs, this is difficult to do anyway).
-Whatever else you can think of.

Finally, addressing the cons of  URLs(ideas taken  from message by
Stephen Casner).

- Problems with arbitrary file systems in component based server :
Efficiency wise, it should not be any different whether this "StreamID"
is the first header in the message or part of the URL.
Agreed that if one wants content to be interoperable between servers(not

always true in the web world) or use parts of the URL for other needs
(aka HTTP) , the URL syntax or atleast the order of
segments  has to regulated. This is something one might want to take up
seperately.

If one uses the rule :" A url segment not understood by one component
goes on to the next", it might help in the component architecture.
The arbitrary filesystem issue is something I do not understand. In
fact, I  would say that one of  URL's  major purposes is to abstract a
uniquely identifiable  resource. They do not have a relation to any
filesystem - this relationship is *created*  by the server.  Putting
?audio or ?track=1 does not change anything with respect to the
filesystem.
Also, URLs have been used for a while by the HTTP world, and they get
and put data out of arbitrary filesystems all the time.

- URLs getting too long or untenable:
The danger is significantly less here than HTTP. If one absolutely needs

to pass a long list of parameters, then one should do it using HTTP, or
look into doing that with an extension header. Having this fear preclude

the use of URLs to reference parts of containers seems unreasonable.

Thanks for your patience.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : [email-masked]         Phone : (415) 937 3129
-----------------------------------------------------------------