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 11:32:25 +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?

	P.S.: If you get 2 copies of this mail, it's my fault.
My mailing program did strange things with a first one and I'm
now resending it.

-- 
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: Rakesh Manocha <[email-masked]>
Date: Thu, 03 Jul 1997 05:40:16 -0600

Some other approaches could be :

[1] Using the "Session" id returned in the response to the DESCRIBE message.
So, in the first example when the 1st SETUP message goes to the server it
would look like

[2] To create a pipeline-able zero-th SETUP message, which exclusively
serves as a means of getting a Session id one could use a "unique" Session
ID (e.g. -1 or 0 ) which is identified by the server as a  "Session id"
request.

Rakesh Manocha
[email-masked]
Novell India Development Center
Phone : +91-80-5537856 Extn 2008
Fax : +91-80-5537892

>>> Rob Lanphier <[email-masked]> 03-Jul-97 2:38:03 AM >>>

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

         v=0

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

   S->C: RTSP/1.0 200 3 OK
         StreamID: vid

   S->C: RTSP/1.0 200 4 OK

Roundtrip #
|
v

          v=0

         

         

---

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 03 Jul 1997 23:25:45 -0700

At 10:47 AM 7/3/97 +0200, [email-masked] wrote:
>robla wrote:

Definitely a typo.  I had originally had the notion that Session: ids might
indeed be returned by DESCRIBE, but there was some resistance to tying any
sort of state to the DESCRIBE message, since the SETUP message has a
countervailing TEARDOWN message which serves to dispose of the session, and
DESCRIBE has nothing of the sort.

Sorry for the confusion.  You are correct; the first SETUP response is
where the first Session field is located.

>get new and different Session Id at the S->C response to any

Wouldn't the combination of "whole session" Session id and stream id be
sufficient for any muting functionality?  

I would think that modifying your example below would suffice for this

             Session: 1234
>            SequenceNo: streamid=aud;seq=xxxx
             (hmm, is SequenceNo useful for PAUSE?  It might be, but not
immediately obvious to me.  Different discussion, I suppose)

Is this how muting should be implemented?  

>I didn't see? Is there any proposal for a better solution?

Besides the ideas Rakesh brings up, another alternative is one monolithic
SETUP Transport field that tries to do all of the negotiation in one swell
foop.  However, distributing the complexity of the transport negotiation to
several simpler SETUP requests seems to be the way to go to me.

Rob

---

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 03 Jul 1997 23:45:42 -0700

>         Transport: rtp/udp;port=3056,

Actually, the Session: response in DESCRIBE was a typo (sorry).  However,
having DESCRIBE return a Session id did come to mind.  At this point, when
should the presumed state associated with a Session id expire?

>ID (e.g. -1 or 0 ) which is identified by the server as a  "Session id"

I'm trying to figure out how this solves the problem.  The point of the
Session id here would be to ensure that all SETUPs are issued under the
same Session id, which, short of giving all of them -1 ids, won't solve the
problem of reducing the number of roundtrips.  Perhaps an example would
make it clearer.

Thanks
Rob
---

---

From: Eric Fleischman <[email-masked]>
Date: Mon, 7 Jul 1997 08:45:52 -0700

In your example below, 1-1-1 is indeed the natural case. However, one
may prefer to use 1-1-n for playing twister.mov to MBONE audiences, say
coupled with a SDP announcement. This could result in "standard"
(perhaps "transparent" would be a better word?) MBONE content.

Another alternative for the "?" is to expand upon the text already in
Section 3.2 and state that, for example,

rtsp://media.example.com:554/twister/audiotrack 

refers to the audio of a presentation named twister.

> -----Original Message-----
> From:	Philipp Hoschka [SMTP:[email-masked]]
> Sent:	Friday, July 04, 1997 10:26 AM
> To:	[email-masked]; [email-masked]; Rob Lanphier
> Subject:	Re: Solving 1-1-n 
> 
> 
> 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: Brad Hefta-Gaub <[email-masked]>
Date: Mon, 7 Jul 1997 08:42:22 -0700

Philipp Hoschka wrote:
>   session descriptions, i.e. descriptions that are generated "on the fly" -

The proposal places no additional burden on the content
provider in the case of "physically" separate media files
being played as a single presentation. This has always been 
supported by RTSP and was not the topic of the 1-1-n etc. 
conversation. In fact, PN's RTSP implementations (the beta 
RealMedia sdk) handle this feature today.

In PN's implementation (and as we understand it, the intent
of the RTSP authors is that) such a presentation is described
by "media server indirection information" stored in a metafile,
which is hand authored and available from a standard HTTP 
server. RTSL, SDP, SYMM, or several other file formats are 
appropriate for storing this information. The client takes 
this metafile information and requests separate RTSP "requests". 
Notice of course that since RTSP allows multiplexing of multiple 
control sessions over a single TCP connection, this requires only 
one TCP connection.

Relative to the recent proposals for dealing with "streams" in 
a container file, we can assume that in this example the 
resources are in fact not container files, and therefore no 
streamID headers are required at all. (In absence of a streamID 
header the server sends all streams to that addr/port combination.)

-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: Brad Hefta-Gaub <[email-masked]>
Date: Mon, 7 Jul 1997 08:53:08 -0700

>> >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"
>> 
>> ...
>>
>> Now, my first question is: why is this a query ? Why do you need to use
>> a questionmark ?

My point is exactly that the RTSP spec should not answer these 
questions. Instead the RTSP spec should reference the standard 
URI spec, and should not place additional limitations on the 
semantics of sub-syntax of the URI.

A solution that limits the name space of the URI seems especially 
wrong when we have a perfectly reasonable pathway in the 822 headers.

In addition to our concerns about flexibility in implementing robust
file systems on the server, it seems there is also an issue with the
additional burden this will place on intermediate devices. The 
intermediate devices already implement 822 parsing and manipulation
code, but most will only look for host name and resource in the URI.
Why force all intermediate devices to implement additional URI 
parsing code to peal out stream information???

-Brad

---

From: Eric Fleischman <[email-masked]>
Date: Mon, 7 Jul 1997 09:06:32 -0700

The first method issued should establish the session, otherwise one must
worry about the context of the pre-session methods -i.e., to what do
they refer? Thus, if DESCRIBE is ever to proceed SETUP, DESCRIBE needs
to establish the sessionID for the dialog. If so, then DESCRIBE and
SETUP are peers (as I have been stating all along) in that they both
could start a session. 

> From:	Rob Lanphier [SMTP:[email-masked]]
> Sent:	Thursday, July 03, 1997 11:46 PM
> To:	Rakesh Manocha
> Cc:	[email-masked]