RE: Format of RTSP URLs

[Brad Hefta-Gaub <[e-mail]>]

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: [phone]
fax: [phone]
email: [e-mail]
web: http://www.real.com
-----------------------------------------