Subject: Re: Format of RTSP URLs

From: Rob Lanphier <[email-masked]>
Date: Tue, 15 Jul 1997 09:50:28 -0700

At 01:44 PM 7/15/97 +1000, Bill Simpson-Young wrote:
>robla wrote:
>> ...
>> The URL scheme, taken from Roy Fielding's draft on the subject
>> (draft-fielding-url-syntax-05.txt) is something we'll have to consider very
>> seriously in all of this.  The URL syntax there is:
>> <scheme>://<site>/<path>?<query>#<fragmentid>
>> 
>> The problem with that scheme is that "fragmentid" is really "client-side
>> fragment id".  What we really need is a server side fragment id as well.
>> 
>> <scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>
>
>In RFC 1808, the URL syntax is 
>
><scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
>
>where "params   ::= object parameters (e.g., ";type=a" as in
>                       Section 3.2.2 of RFC 1738 [2])."
>
>Why not use params which is intended for this purpose?  I know the 
>"params" isn't used in the HTTP scheme but the disadvantages of using ? 
>and # are great enough that it's better to use params than stay close to 
>the HTTP scheme.

I think this may be acceptable, but there's one other possible requirement
I'd like to mention.  It would be nice to have the ability to have relative
URLs, so that, for example, the following scenario can play out (using ":"
as a server side fragment identifier for the time being)

C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1

S->C  RTSP/1.0 200 1 OK
      Content-length: 178
      Content-type: application/sdp

      s= sample rtsp presentation
      r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = :track=audio1                           /* URL to control audio*/
      m=video 0 RTP?AVP 26
      r = :track=video1                           /* URL to control video*/

At this point, the client can easily discern that the audio track and the
video track are indeed merely fragments of the same object on the server,
and not separately controlled entities.  I'm not sure how this would work
with ";" parameters, since the relative behavior defined in 1808 is
different than what I'd expect above (which is more akin to "#").

One way to route around this is to always use absolute URLs, but I think
that would be slightly more prone to error.

---
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: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Jul 1997 11:03:09 -0700

>different than what I'd expect above (which is more akin to "#").

Those relative URLs would resolve to

      rtsp://foo/db/:track=audio1
      rtsp://foo/db/:track=video1

which is obviously not what you would want.  Query info and relative
references do not mix in practice.  In any case, using query info to
select a resource, as opposed to redirecting to the real resource URL,
is poor namespace management.

....Roy

---

From: Bill Simpson-Young <[email-masked]>
Date: Thu, 17 Jul 1997 13:09:39 +1000

>       r = :track=video1                           /* URL to control video*/

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.  There are a 
load of advantages to using HTTP (eg access to the SDP data by existing 
robots, use of streaming control protocols other than rtsp, etc) and there 
would be even more advantages if later there is an XML DTD corresponding 
to SDP (eg human readability of the metadata).

I realise that the idea is to allow applications to use either protocol to 
do the bootstrapping but I still can't really see the point in using RTSP 
for this. I guess the advantage of using RTSP for the SDP data is that you 
can run just the RTSP server on the media server without the need for a 
separate HTTP server and without the need for the RTSP server to support 
HTTP but I would have thought that you'd usually want the SDP info to come 
from a different box anyhow which is running the metadata database and can 
run just an HTTP server.  I would have thought the use of RTSP for getting 
discrete data would be the exception rather than the rule and the 
incorporation of HTTP support in any RTSP servers that want to support 
this would be a better approach.

If I'm right, then this will have an impact on relative URLs specified in 
SDP (or some XML version of it) as they would be HTTP URLs not RTSP ones 
unless some form of base tag is used in the SDP data. Either way I agree 
with Roy about the specification of tracks using the path itself (using 
"/").  So, regardless of whether we're using container file formats or 
separate tracks in separate files, the respective URLs could be:

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

and we could have the following (using an imaginary XML DTD for the 
bootstrapping info):

C->S  GET http://foo/db/moviebase/twister HTTP/1.1

(if this was from a query you would have had a redirect stage before this 
as suggested by Roy)

S->C  HTTP/1.1 200 1 OK
      Content-length: 178
      Content-type: text/foo

      <?XML version="1.0"?>
      <!DOCTYPE foo SYSTEM "http://foo/foo.dtd">
      <session base="rtsp://foo/db/moviebase/twister"/>
      <summary>Sample RTSP Presentation</summary>
      <media type="audio" location="audio1" ... />
      <media type="video" location="video1" ... />
      </session>

Bill