Subject: RTSP and SDP with container files

From: Rob Lanphier <[email-masked]>
Date: Thu, 19 Jun 1997 19:59:12 -0700

On Wednesday, I promised a strawman for how RTSP and SDP would work
together with container files (ala Quicktime, ASF, or RealMedia) for
on-demand, unicast streaming.  Here it is.  Bear in mind that Henning and
Anup have not had a reasonable opportunity to review this, so they may have
opinions of their own. 

The server would generate an SDP file on the fly (or whatever list of files
is necessary).  For instance, in the case of a Quicktime file with an audio
and a video track, we would see the following exchange:

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

  S->C: RTSP/1.0 200 1 OK
        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

For the most part, this is a standard SDP description.  One thing that is
different is that the port number is 0 rather than a valid port number for
both streams (though one could put a "suggestion" in here, but in unicast,
it's really up to the client).  This will be client-selected using SETUP.

The other thing that is different is that there is a stream id included as
an attribute of the stream in the description.  This ID will be important
in the SETUP message

  C->S: SETUP rtsp://example.com/twister.mov RTSP/1.0 2
        Stream-ID: aud
        Transport: rtp/udp;port=3056,
                   rtp/tcp

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

  S->C: RTSP/1.0 200 2 OK
        Session: 1234
        Stream-ID: aud
        Transport: rtp/udp;port=3056

  S->C: RTSP/1.0 200 3 OK
        Stream-ID: vid
        Transport: rtp/udp;port=3058
        Session: 1235

  C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 4
        Session: 1234

  C->S: PLAY rtsp://example.com/twister.mov RTSP/1.0 5
        Session: 1235

Other approaches we considered:

*  Embedding the stream id in the URL

   The disadvantage this approach has is in a modular system where the
   URL is being processed by a file system module that knows nothing
   about the specific datatype.  One could envision an RTSP server as
   a database rather than a traditional file server, where the original
   describe URL is actually a query to the server.  Coming up with a way
   of unambiguously appending a stream ID to that query is a non-trivial 
   matter (where does the query end and the stream ID begin?)

*  Having a single SETUP/PLAY for the entire presentation, mapping the 
   individual streams to RTP sessions.

   I think it was generally understood (correct me if I'm wrong) that there
   would be one RTSP session per RTP session.  The compromise that was reached
   was that if one wanted to stream a containter file as a homogenous blob, 
   one could, but the entire container would be streamed as in a single RTP
   session.  This compromise does make it difficult for a server to stream 
   container files, since barring some ungodly server hack, there would be 
   multiple filehandles open to the same file, each streaming out different 
   portions of the file, even if the file is neatly pre-interleaved.  However,
   for the sake of simplifying the protocol, this compromise was made.

Does this seem like a reasonable approach?  Comments welcome and encouraged.

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: Mark Handley <[email-masked]>
Date: Fri, 20 Jun 1997 09:39:05 -0400

>it's really up to the client).  This will be client-selected using SETUP.

I haven't kept track of RTSP details recently, so please tell me if
I've assumed anything incorrectly.

The server should probably indicate its ports - this may be a one-way
flow, but RTP still needs a destination port for its RTCP reports.  I
know you suggest putting the server's port in the SETUP response, but
putting it in the description means you could pipeline the SETUP and
PLAY commands instead of having to wait for the SETUP response before
issuing the PLAY.

Strictly speaking your example is not legal SDP as there is no "c" or
"t" field present.

The server should probably indicate its address in a "c" field as it's
possible for the data source host to be separate from the RTSP control
host and the client would need to know this.

I'm still trying to decide whether a "t" field is of any use to you
here.

Mark

---

From: Stephen Casner <[email-masked]>
Date: Fri, 20 Jun 1997 12:27:16 -0700 ()

On Fri, 20 Jun 1997, Mark Handley wrote:

> flow, but RTP still needs a destination port for its RTCP reports.

Right.  This is really a deficiency in SDP itself, too, for other
applications such as unicast conferencing.  If one wanted to set up a
unicast session using SDP, I presume that each end would be given an
SDP file with the c= address being that of the other end.
Analogously, the port on the m= line should be the port to which (RTP)
data is sent, but there is no place to specify the port on which data
is to be received.

There is a higher-level problem that both end's port selections need
to be chosen before the SDP files can be generated for each end, which
implies a previous exhange of information in the conference setup
protocol.

>  I

This is a good point.  The scenario you describe has enough places to
put port numbers, but the port number in the SDP file is not setting
the receive port (as it would for multicast) and the port number in
the SETUP request is not completely overriding the port number in the
SDP file.  So the interpretation of these port fields is different
than was the case before or in different scenarios.

If SDP were modified to carry separate send and receive ports for
unicast, then I guess we'd want to set the receive ports to 0 in this
scenario as Rob had suggested.

Would it make sense for SETUP to come before DESCRIBE (perhaps
pipelined) and then PLAY as the second exchange?

> I'm still trying to decide whether a "t" field is of any use to you

Coincidentally I have just been pondering some related questions:

If one wanted to implement a "progress indicator" in the client,
I assume one would get the duration of the media stream from the
session description, e.g., the t= field in SDP.  As SDP is used
for multicast sessions, the t= field is not always an accurate
specification of the duration of the transmission, but as used
within RSTP I guess it could be.

As the stream is playing, is it assumed that the client will
measure progress based on the media timestamps (e.g., in RTP) that
it receives?  This seems logical to me, and I don't see any
request or response to report position at the RTSP level.  Using
the local system clock would not account for drift.
							-- Steve

---

From: Stephen Casner <[email-masked]>
Date: Fri, 20 Jun 1997 19:03:59 -0700 ()

Rob,

I'm confused about how you are viewing these container files.  We've
had numerous discussions of a singled multiplexed RTP stream
vs. multiple single-medium RTP streams, and agreed that both schemes
are likely to be used in different scenarios.  Given a container file,
a server can either demultiplex the container file and send multiple
RTP streams, or send the whole container file as one pre-multiplexed
stream.

Taking pieces of your message out of order, you wrote:

>    session.  

So far, this is consistent with my understanding as stated above.

>    This compromise does make it difficult for a server to stream 

No, if the container file is being streamed as one "homogenous blob",
then there's only one filehandle open, and chunks of the interleaved
file are being streamed out in packets of the single RTP session.  A
big reason for sending a single stream is so that no manipulation of
the data is required.  If you're willing to pull out different
portions of the file, then you can send them as multiple RTP streams
to get the advantages of selectability, differential priority, etc.

A second point of confusion comes from the requirement for separate
RTSP sessions for each RTP session, but not having a requirement for
separate RTSP URLs for each RTSP session.  The definition in the -02
spec says that a presentation description contains RTSP URIs for the
individual streams as well as one for the whole presentation.

>    matter (where does the query end and the stream ID begin?)

It is not required that there be only one way to form the URL.  If the
SDP file contained RTSP URLs in place of the stream-id attributes you
added, then the binding to RTSP sessions still works.  In the case
where separate media streams are being sent from different machines,
won't you need multiple URLs in order to set up RTSP sessions with
those separate machines?
							-- Steve

---

From: Alagu Periyannan <[email-masked]>
Date: Mon, 23 Jun 1997 10:37:00 -0700

>implies a previous exhange of information in the conference setup

For the multicast case, every participant's send and receive ports
need to be the same. There is no choice here and so we have to live
with it. (I'm not sure what happens if some other process on one
of the systems is already using the port. IP_REUSEADDR partially
solves the problem, but not really.) So for multicast let's say
that the SDP file will contain the port number that MUST be used.

For the unicast case, we can solve the port assignment in a better
manner. What we really need is a way to communicate 2 port numbers.
One that is chosen by the server (to which RTCP) is sent and one
that is chosen by the client (to which the RTP data is sent).

Selection of the server port before the SDP files are generated
is not a favourable solution. Firstly, this probably means
that the SDP file needs to be generated on the fly in response
to a DESCRIBE. It also means the server needs to acquire a port
(i.e. do a partial setup) before responding to the DESCRIBE.
Then you get into the issue of each DESCRIBE request coming
back with potentially a different response. None of these issues
by themselves are bad, but it just seems like a pain to
implement.

A better solution is to have a 0 in the port number field
in the SDP file and negotiate the port number over RTSP.
To do this we may need to add "cport=" and "sport="
fields to the Transport header instead of the current
"port=" field.

On a related subject, how does the server get the client's
IP address in the current scheme? Again this is not a problem
for the multicast case since a class D address is used.
But what about for the unicast case?

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

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Philipp Hoschka <[email-masked]>
Date: Fri, 04 Jul 1997 17:25:46 +0200

>> *  Embedding the stream id in the URL
....
>added, then the binding to RTSP sessions still works.  

I'm strongly in favour of this for the 1-n-n case, i.e. one presentation 
sent over n streams and being controled by n RTSP sessions. 

This could be done by using

 a=src:rtsp://www.w3.org/audio.pcm

Example

  S->C: RTSP/1.0 200 1 OK

        v=0
        o=- 2890844526 2890842807 IN IP4 192.16.24.202
        s=RTSP Session
        m=audio 0 RTP/AVP 0
        a=src:rtsp://www.w3.org/audio.pcm
        m=video 0 RTP/AVP 31
        a=src:rtsp://www.w3.org/video.h261

  C->S: PLAY rtsp://www.w3.org/audio.pcm ...
  C->S: PLAY rtsp://www.w3.org/audio.h261

This is much better than using streamid attributes, because
- it is analogous to the way other session description files work, e.g. RTSL
- you don't have to introduce a new header-field into RTSP to solve a problem
  specific to sdp - you don't need the sessionid have when you use RTSL, since
  it already contains the URLs