Subject: RTSP 1b & e. 1-1-n & Use of SDP within RTSP

From: Rob Lanphier <[email-masked]>
Date: Wed, 27 Aug 1997 16:46:51 -0700

Issue 1b. & 1e. from Munich:

1-1-n refers to a single RTSP resource (i.e. a container file), which is
controlled by a single RTSP session (and thus has a single NPT and session
id), that contains multiple (n) RTP streams. Here's where things landed:

  1. Client retrieves description of the container
     file through a single DESCRIBE (though may
     retrieve this through other means if those means
     are sufficiently synchronized with the media
     server). This single description contains
     multiple streams.
  2. The client issues a SETUP command per stream (n
     SETUP commands) to the server. Each of the SETUP
     messages has the same session id, and are
     distinguished by their URLs.
  3. The client issues a single PLAY, which starts
     all streams in the session along a common NPT.

To see how this translates to the actual session descriptions, look at the
following SDP:

NOTE: The examples below are slightly different than those in the
draft03. This came from hallway discussions with various parties about how
SDP and RTSP could be better integrated. The next draft will resolve this
issue.

For single-stream presentations, the DESCRIBE
response should look like this:

   DESCRIBE rtsp://foo.com/boo/bar.wav/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: 22 Jul 1997 00:16:41 GMT
   Content-type: application/sdp
   Content-Length: 242

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info>
   t=0 0
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.wav

For multi-stream presentations:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info>
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL trackID=48

The media urls in the request are relative to the request url. One could
just as easily have had:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info>
   c=IN IP4 0.0.0.0/15/1
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=48

There were no major concerns expressed about this in Munich. When an
arbitrary stream URL is specified in a DESCRIBE response (perhaps to an
entirely different server), the client is expected to still send the SETUP
message corresponding to that URL to the server that the DESCRIBE response
came from. This behavior will be specified in the next revision of the
specification.

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Thu, 28 Aug 1997 09:11:48 -0400

Rob Lanphier wrote:

> came from. 

I disagree with the last statement (assuming I understand it correctly).
If there's an absolute URL with different servers, I have to assume that
the servers somehow coordinate in the background. Why not just send the
SETUP to the absolute URL specified? I can always use relative URLs if I
want the requests to go to the origin of the DESCRIBE response.

Sending
SETUP rtsp://foo.com/movie

to the (non-virtual) host rtsp://bar.com seems strange.

(Because of that, it is probably a good idea to make Session id's
globally unique. It certainly can't hurt.)
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 28 Aug 1997 10:46:48 -0700

>to the (non-virtual) host rtsp://bar.com seems strange.

It does, but I think I like it.  My thinking was more in line with yours
prior to the Munich meeting.  However, two or three people came up to the
microphone in Munich espousing the virtues of this approach.  I thought
about raising a fuss at that time, but restrained myself until thinking
about it further, and no one else complained.

What this approach allows is the clean creation of a coordinator proxy.  By
returning this presentation description, the RTSP server is volunteering to
make the coordination happen, and thus isn't imposing it on the client.
The client can then treat the URLs as opaque stream identifiers.

This actually falls in line with PNs assertion that the DESCRIBE response
should only be for media initialization, and not for media indirection, so
this makes me a pretty happy camper.

One thing that we could do is have a separate syntax for when media
indirection is actually desired.  For instance:

   DESCRIBE rtsp://foo.com/something/other.sdp

   RTSP/1.0 200 1 OK

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL rtsp://oneplace.com/blah/trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://theother.com/blech/trackID=48

...would mean media initialization, and thus all SETUPs are issued to
foo.com, whereas:

   DESCRIBE rtsp://foo.com/something/other.sdp

   RTSP/1.0 200 1 OK

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=video 8002 RTP/AVP 31
   a=murl:rtsp://oneplace.com/blah/trackID=47
   m=audio 8004 RTP/AVP 3
   a=murl:rtsp://theother.com/blech/trackID=48

...would mean that indirection is in order, and thus one should issue the
SETUPs to oneplace.com and theother.com.

I would leave the definition of an indirection field for SDP to someone who
actually needs it, though.  Right now, the necessary portion is the "c=IN
URL" definition.

>globally unique. It certainly can't hurt.)

It's necessary, actually, now that we have 1-1-n.  If the server is
expected to treat two distinct URLs with a common session id as one
session, then the session id has to be globally unique.

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/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Thu, 28 Aug 1997 17:04:55 -0400

Note that we also need a description format (RTSL, SDP) to be retrieved
via HTTP, to find out the component sessions and since directly
including an rtsp:// URL in a web page is not going to be very useful. I
thought that using SDP was one option for simple scenarios; what's the
syntax for that? (In that case, the URL should point to the SETUP
location, at least).

I also don't see the need for the 'fake' URL and proxies. If you have a
proxy that serves the other 'back-end' servers, it can easily create its
own namespace, as in

rtsp://proxy.com/oneplace.com/blah/trackID=47

The proxy server must be informed about how to do the coordination in
any event. Why expose the identity of the back-end servers to the client
at all since they don't receive any RTSP commands?

Thus, in summary, I'm not sure breaking the standard URL assumption (a
request URL refers to the host or its virtual aliases) is such a great
idea:

- it doesn't add any real functionality that couldn't be had otherwise;

- it creates a mess for SDP, as you now need two similar-looking, but
radically different rtsp URL mechanisms, one to get the basic session
description (container or not) and one for DESCRIBE.
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 28 Aug 1997 15:10:29 -0700

>rtsp://proxy.com/oneplace.com/blah/trackID=47

Assuming we go this route (I'm not convinced we should, but I'd like some
others to weigh in), it really should use the standard proxy convention:
rtsp://proxy.com/rtsp://oneplace.com/blah/trackID=47

...since that's the way it's done in HTTP.

<a href="http://proxy.com/http://foo.com/bar.html">Use the proxy</a>

However, if you were to look at what happens on the wire, you would see, in
the connection to proxy.com:

GET http://foo.com/bar.html HTTP/1.1
...

So, in the case of RTSP, when it makes the connection, should it say:

SETUP rtsp://oneplace.com/blah/trackID=47 RTSP/1.0 2

... or should it say:

SETUP rtsp://proxy.com/rtsp://oneplace.com/blah/trackID=47 RTSP/1.0 2

Rob

---