Subject: RE: Format of RTSP URLs

From: Brad Hefta-Gaub <[email-masked]>
Date: Thu, 17 Jul 1997 02:06:07 -0700

Bill Simpson-Young wrote:
>> I don't think this example would be a common one as 
>> surely, in practice, HTTP will be used to retrieve 
>> the SDP info rather than RTSP...

As we have already discussed on the confctrl list there are 
actually two very distinct uses for "description" formats 
like SDP in the process of playing back media streams. The first 
use is for accessing "media server indirection" information. 
This is clearly best handled by an HTTP server. It seems 
to me that you are referring to this type of use of SDP.

However, there is another equally important use for "description 
formats" like SDP in the process of playing streaming media, 
specifically, "media initialization information". This is basically 
the information needed to initialize the "rendering" context of 
the media stream. This information is often not hand authored, 
because it may contain codec specific initialization goo,
and as such should not be separated from the media file itself. 
Retrieval of this information is the purpose and intended use of 
the RTSP DESCRIBE verb. The RTSP authors chose not to use GET
because this is explicitly not the same semantics of the HTTP GET.
You don't get the resource, you get a description of the resource.

For more information on this specific topic please see my post 
to the confctrl list dated Fri, 20 Jun 1997, at...

	http://www.mbone.com/lists/confctrl.1997/0339.html

>> http://foo/db/moviebase/twister          (for the bootstrapping info)
>> rtsp://foo/db/moviebase/twister/video1
>> rtsp://foo/db/moviebase/twister/audio1

Let's for the moment ignore the issue of a file system add-on that you
and Roy have dismissed as being handled by "redirection"... would 
your arguments be the same if the container media stream was being 
"generated" on the fly by a "cgi-bin" like add-on to the media server?

Imagine a cgi-bin that produces a video container file with a stream
of randomized fractal images which morph along the timeline of the 
presentation synchronized with a music audio stream. Imagine that 
such a cgi-bin actually produces a resource which is a real AVI file, 
such that if said cgi-bin was running on a web server today it would 
work exactly as one might expect. The url for such a resource might
be...

  http://foo/cgi-bin/fractalavi.exe?c1=ff00ff&c2=444400&e=0.3

Now, are you suggesting that a media server which knows the AVI file 
format, and needs to demultiplex this AVI file and send each of its 
contained streams to different ports, should inform the client of
the existence of these streams, and should be informed of the port 
selections by the client via the following urls?

  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/audio
  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/video

Are these legal URLs? Maybe I've misunderstood the uri spec, but I 
would expect a standard uri parser to barf on these. Certainly, such 
a parser would have no clue that the "/audio" and "/video" portions 
of the url are not to be sent to the cgi-bin and in fact are to be 
used in the demuxing process by the server component. Remember that 
this is a cgi-bin that runs on a web server and therefor has no idea 
of how to demux AVI. The server (not the cgi-bin add-in) will do the 
demux and routing to the correct port.

-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: "Roy T. Fielding" <[email-masked]>
Date: Thu, 17 Jul 1997 07:44:34 -0700

>"generated" on the fly by a "cgi-bin" like add-on to the media server?

Yes.  The CGI interface includes two mechanisms for passing parameters
to the script within the URL.  The first is extra path information; the
second is the query string.  If you use the former, then relative paths
are possible.  If you use the latter, then relative paths are impossible.

>  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/video

Of course not, since as I said before the query part of the base URL
is STRIPPED OFF before any relative parsing.  Try your example with
any current web server and see for yourself what the browser does.

At the same time, there is absolutely nothing preventing the CGI script
from using the URL

   rtsp://foo/fractalvid/morph/c1=ff00ff+c2=444400+e=0.3/audio

to mean the exact same thing.  The only difference is in the configuration
of the server and how the CGI parses its own input.  The same applies to
Apache API modules, NSAPI, ISAPI, and most other means of connecting a
content handler to a web server.  The argument that a database somehow
needs a query part is not relevant to the URL specification.

....Roy