Subject: Solving 1-1-n

From: Rob Lanphier <[email-masked]>
Date: Wed, 02 Jul 1997 14:38:03 -0700

Here's how we would like to solve the 1-1-n streaming issue.  This proposal
involves the following changes to RTSP:

*  Sending "Session" fields from client to server in SETUP messages
*  Association of multiple SETUP requests to a single PLAY request via
   "Session" field.

Given a single URL pointing to a container with n streams, there would be 1
DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.

Here's what a 1-1-n exchange looks like:

   C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
         Accept: application/sdp

   S->C: RTSP/1.0 200 1 OK
         Session: 1234
         Content-Type: application/sdp

         v=0
         o=- 2890844526 2890842807 IN IP4 192.16.24.202
         s=RTSP Session
         m=audio 0 RTP/AVP 0
         a=streamid:aud
         m=video 0 RTP/AVP 31
         a=streamid:vid
 
   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
         StreamID: aud
         Transport: rtp/udp;port=3056,
                    rtp/tcp
         
   S->C: RTSP/1.0 200 2 OK
         Session: 1234
         StreamID: aud
         Transport: rtp/udp;port=3056

   C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
         Session: 1234
         StreamID: vid
         Transport: rtp/udp;port=3058,
                    rtp/tcp

   S->C: RTSP/1.0 200 3 OK
         StreamID: vid
         Transport: rtp/udp;port=3058
         
   C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 4
         Session: 1234

   S->C: RTSP/1.0 200 4 OK
         SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
  (note: "SequenceNo" is a new field which I will explain in a separate
         email.  The quick explanation is that it provides the initial RTP
         sequence number for each stream)

Now, for those of you counting roundtrips, you may notice that the
dependencies here necessitate 4 roundtrips (assuming the only piece of info
one starts with is an URL), since the DESCRIBE is necessary to get the
stream ids, the first SETUP is necessary to get the "Session:" id that is
sent with the next SETUP.  The SETUP and PLAY *may* be pipelined, but
that's pretty unwise, since if there are multiple transports, it may be
hard knowing which transport will be selected.

The "unnecessary" roundtrip comes from not being able to pipeline the first
SETUP with the 2nd through n SETUP messages.  A solution to this problem is
to create a pipeline-able zero-th SETUP message, which exclusively serves
as a means of getting a Session id, as follows:

Roundtrip #
|
v
0.5 C->S: DESCRIBE rtsp://example.com/twister.mov RTSP/1.0 1
          Accept: application/sdp
 
0.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2

1   S->C: RTSP/1.0 200 1 OK
          Session: 1234
          Content-Type: application/sdp

          v=0
          o=- 2890844526 2890842807 IN IP4 192.16.24.202
          s=RTSP Session
          m=audio 0 RTP/AVP 0
          a=streamid:aud
          m=video 0 RTP/AVP 31
          a=streamid:vid

1   S->C: RTSP/1.0 200 2 OK
          Session: 1234

1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 3
          Session: 1234
          StreamID: aud
          Transport: rtp/udp;port=3056,
                     rtp/tcp
         
1.5 C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 4
          Session: 1234
          StreamID: vid
          Transport: rtp/udp;port=3058,
                     rtp/tcp

2   S->C: RTSP/1.0 200 3 OK
          StreamID: aud
          Transport: rtp/udp;port=3056

2   S->C: RTSP/1.0 200 4 OK
          StreamID: vid
          Transport: rtp/udp;port=3058
         
2.5 C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
          Session: 1234

3   S->C: RTSP/1.0 200 5 OK
          SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678
         
Both techniques would be acceptable, with the latter provided as a better
roundtrip performer.  The pipelineable "Transport"-less SETUP message could
even be sent prior to the DESCRIBE to ensure the integrity of the DESCRIBE.
(Clients want to be sure the file that was DESCRIBEd is the same file they
issue a SETUP on, and since DESCRIBE is stateless, there is normally no way
to be sure.  Sending a SETUP prior to the DESCRIBE implies the server will
keep track of the media file for the duration of the Session).

---
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: <[email-masked]>
Date: Thu, 3 Jul 1997 10:47:20 +0200 (MET DST)

A couple of comments about the proposal.
I hope they make sense for you. (Sorry if I misunderstand something
and they don't)

> [...] 
           ^^^^^^^^^^^^^

	Is that a typo, or the Session Id. can be sent as early as
to the answer to a DESCRIBE?

> [...]
  
>          Transport: rtp/udp;port=3056,
           ^^^^^^^^^^^^^

	I suposse that THIS ONE is the first time the server sends
a Session Id to the client.

> [...]

	How can I have control over the individual streams that
are part of the Session 1234?

	Wouldn't be better to use a "whole session" setup like
the pipeline-able zero-th SETUP message described bellow to get
the Session Id that you'll send with the following SETUP
messages for the 'n' streams of the 1-1-n session; but to
get new and different Session Id at the S->C response to any
of those SETUPs?

> 1   S->C: RTSP/1.0 200 1 OK
            [ deleted ]
> 1   S->C: RTSP/1.0 200 2 OK
            ^^^^^^^^^^^^^

	This would be the global session Id. used to control the
bunch of streams as a whole, and sent as a field of the following
SETUP messages.

> 2   S->C: RTSP/1.0 200 3 OK
	    Session: 2001
> 2   S->C: RTSP/1.0 200 4 OK
	    Session: 2002
>           SequenceNo: streamid=vid;seq=1234,streamid=aud;seq=5678

	....
allows a potential:

      C->S: PAUSE rtsp://example.com/twister.mov RTSP/1.0 23
            Session: 2001
            StreamID: aud

      S->C: RTSP/1.0 200 23 OK
            SequenceNo: streamid=aud;seq=xxxx

to mute the audio.

	Do you think it would work? Is there any implied problem
I didn't see? Is there any proposal for a better solution?

-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
[email-masked]			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96

---

From: Philipp Hoschka <[email-masked]>
Date: Fri, 04 Jul 1997 19:26:11 +0200

>DESCRIBE (potentially) followed by n SETUP messages and 1 PLAY message.

All this 1-1-1 .. 1-n-n discussion is about a presentation that is stored in 
a single file, right ? E.g. a flattened Quicktime file, say twister.mov.

In this case
1) 1-1-1 seems to be the "natural" choice
2) 1-n-n is the same as if the media was stored in several files,
  at least from the point of view of RTSP/RTP - conceptually, the 
  server splits up the container file into several seperate files
  before data is sent out
3) 1-1-n is also the same as if the media was stored in several files -
  since there are n streams

Now, the problem with 2) and 3) is that there's only one filename - twister.mov,
and you need to generate several identifiers for it, one for each of 
the "files" contained in twister.mov.

There are two ways to do this
1) create a namespace within the container file that can be 
   addressed via URLs
2) create an additional attribute that must be contained in every
   session description format, and mapped onto an RTSP header field

You chose option 2) by introducing the sessionid.

I'd like to convince you that putting it into the URL is feasible,
and does not have the problems you describe.

I suggest to use the "?" notation, since the files are extracted
at the server. That means, if you want to control the audio track
of "twister.mov" stored in track 1 of the Quicktime file, you write:

rtsp://www.w3.org/twister.mov?1

From Brad's message, it seems that you fear that there may be a conflict
with some future use of a the question mark, e.g. like this:

rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"

(btw, I just showed this to one of my colleages, and he said you should use ";" 
rather than "&" (which is "old stuff" as he said) - the "&" created problems
with some browsers, because it's also used for defining SGML entities)

Now, my first question is: why is this a query ? Why do you need to use
a questionmark ?

There's a single album by Nirvana called "Nevermind" (what happens if 
you put in "Greatest hits", and there are several, btw ?), so you
might as well write

rtsp://server/db/query/Nirvana/Nevermind/Polly

And now you can easily write

rtsp://server/db/query/Nirvana/Nevermind/Polly?1

meaning the first track in the Quicktime file, which corresponds to an audio track.

Also, you can have more than one questionmark in a URL, e.g. you could write

rtsp://server/db/query?artist="Nirvana"&album="Nevermind&;track="Polly"?1

In both cases (sing URL or using sessionid), it would be good to have to 
have a standard way to describe how to map components in a composite file 
into identifiers such as "1". 

In your scheme the server generates the mapping "on the fly",
But what if people want to write sdp files by hand,
i.e. they're not automatically generated ? To write such an sdp file, the 
author would have to know how the particular server used generateS sessionids -
not very nice.

So I guess you need a standard way to generate ids for components of media
files even if you use sessionids. 

If you use URLs instead of session ids, the same standard would help you to use 
only the audio source of a quicktime file in a presentation, which is a nice extra 
functionality.

This standard mapping would have to be done for each composite file format, 
e.g. ASF, Quicktime etc.

It's a common thing to do, similar to defining what "#" means for html 
or for CGI (a vector graphics format, see http://www.w3.org/TR/NOTE-cgm#Refer)

To sum up, problems with sessionid that are resolved when using URLs are:

- The "sessionid" complicates things, because it requires that each format
  ever returned by the "describe" method has this attribute in one form or
  another. Using URLs factors out this functionality into a single place.

  Using URLs also provides a natural way to decompose composite files, which
  is generally useful, not only in the case of 1-*-n - it allows to reuse
  a single track of a composite file in a completely different presentation.

- The current proposal is incomplete, as the server is free to choose whatever
  sessionid he wants - not great for handwriting of session descriptions.
  Say you have handwritten session descriptions, and you want to move from server
  A to server B, which use different conventions for generating session ids - 
  bummer !
  A standard mapping between composite file components and session ids (or better:
  URL queries) seems to be needed, which probably is specific to the format of 
  the composite file (ASF, Quicktime, MPEG, ...)
  The proposal seems to be too slanted to automatically generated
  session descriptions, i.e. descriptions that are generated "on the fly" -
  there is still a need to write them manually as well.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 07 Jul 1997 17:29:03 +0200

> a single file, right ? E.g. a flattened Quicktime file, say twister.mov.

Yes, but this is somewhat invisible at the RTSP level, since there's
only an issue if there's more than one RTP stream involved or if you
want to control the pieces of a composite stream (basically dynamically
creating a composite stream, in which case separate streams are also an
option). If all you ever want to do is play a single composite stream,
none of this discussion is needed.

> You chose option 2) by introducing the sessionid.

Allowing 2) does not provent a server from offering 1), I might add.

>   the composite file (ASF, Quicktime, MPEG, ...)

I would invite experts in these formats to offer such a mapping. Maybe
this could be put into an appendix.

-- 
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