Subject: RTSP URL issues

From: Rob Lanphier <[email-masked]>
Date: Wed, 23 Jul 1997 14:53:47 -0700

Sorry for the duplicate if you receive this twice...
----------
Date: Tue, 22 Jul 1997 01:07:35 -0700
To: [email-masked]
From: Rob Lanphier <[email-masked]>
Subject: RTSP URL issues
Cc: [email-masked], "Roy T. Fielding" <[email-masked]>

I'm going to take another stab at explaining why we at PN are so adament
about wanting the StreamID in a method header field rather than in the
URL.

(i.e.  we'd like:
SETUP rtsp://foo.com/bar.rm RTSP/1.0 1
StreamID: audio
)

Below I'm going to discuss RTSL/RTSP integration.  RTSL, for those of
you who aren't aware, is the Real Time Session Language, which we are
shipping with the RealMedia SDK as the glue for presentations from
disparate files and file formats, and map them onto layout elements in a
web browser or in a standalone media player.

I realize that RTSL currently isn't being standardized within the MMUSIC
group (and since it's a file format, it probably doesn't belong here),
but I think the authoring scenarios are important here to understanding
why we at PN seem so dug in on this issue.

We are using RTSL as the media indirection half of the media
indirection/media initialization process that needs to happen prior to
playing a stream (see http://www.mbone.com/lists/confctrl.1997/0339.html
for the distinction).  So the idea is the following:

Client                                Server

http link
http request --------------------->  
             <---------------------  Media indirection (RTSL)
rtsp DESCRIBE -------------------->  
             <---------------------  Media initialization (SDP)
initialization complete

We would like to deal with container files in the following way in RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

This would instruct the client to fetch rtsp://foo.com/movie.rm and map
the text to the screen element "window1", and map the video to screen
element "window2" (in rough terms).  Note that there are no media
initialization parameters, because we think that content authors should
only be burdened with sequencing, grouping and layout information, and
not necessarily with getting every initialization parameter of the media
file will need.

Current Thinking on URLs
========================
Here's my understanding of how all of this URL talk maps into RTSL.  I
want to be clear: *the examples immediately below aren't what PN
believes should be the case, but rather what others may believe should
be the case*.

Every stream has an URL.  For instance, the way that this could map onto
what I have above is the following:

<source url="rtsp://foo.com/movie.rm">
  <stream url="rtsp://foo.com/movie.rm/audio">
  <stream url="rtsp://foo.com/movie.rm/video" playto="window1">
  <stream url="rtsp://foo.com/movie.rm/text" playto="window2">
</source>

Or it could be:
<source url="rtsp://foo.com/movie.rm?musicvideo=chiquitita">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=audio">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=video"
          playto="window1">
  <stream url="rtsp://foo.com/movie.rm?musicvideo=chiquitita&track=text" 
          playto="window2">
</source>

The point behind the URL discussion on the URI list is that the URL is and
should be an opaque, unique identifier.  Taken to an extreme:

<source url="rtsp://foo.com/uuid=abcd00000000000000000000">
  <stream url="rtsp://foo.com/uuid=1234cccccccccccccccccccc">
  <stream url="rtsp://foo.com/uuid=5678cccccccccccccccccccc"
          playto="window1">
  <stream url="rtsp://foo.com/uuid=9012cccccccccccccccccccc" 
          playto="window2">
</source>

The client would know to handle this as a 1-1-n presentation (one RTSP
session, multiple RTP streams) not by parsing any of the URLs, but by
noting the presense of the "ueber" url as an attribute of the source
tag.  The server could then accept or reject the 1-1-n behavior based on
what it knows of the requests coming in.  Let's take what would happen,
given the last example (and that this actually did describe a valid
1-1-n setup):

C->S: DESCRIBE rtsp://foo.com/uuid=abcd00000000000000000000
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/uuid=abcd00000000000000000000 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/uuid=1234cccccccccccccccccccc 
                                               /* URL to control audio*/
      m=video 0 RTP/AVP 26
      r = rtsp://foo.com/uuid=5678cccccccccccccccccccc 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/uuid=9012cccccccccccccccccccc 
                                               /* URL to control text */

C->S: SETUP rtsp://foo.com/uuid=1234cccccccccccccccccccc
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/uuid=5678cccccccccccccccccccc
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/uuid=abcd00000000000000000000
      Session: 1234
S->C: OK
      (Both streams play).

Let's take an example, now, where we want to use relative URLs in the
"stream" tags instead of absolute URLs.  According to RFC 1808, this is
fine, so long as one uses "/" and not "?"  for queries (though standard
behavior from a web browser is to use "?"  when using <FORM method=GET
action="/cgi-bin/query">, so it would be difficult to have similar
behavior adding cgi behavior to RTSP)

Here's an example of how this would work:
<source url="rtsp://foo.com/movie.rm/musicvideo=chiquitita/index">
  <stream url="audio"
          playto="window1">
  <stream url="video" 
          playto="window2">
</source>

C->S: DESCRIBE rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
S->C: OK
      s= sample rtsp presentation
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/index 
                                               /* aggregate URL*/
      m= audio 0 RTP/AVP 0
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio 
                                               /* URL to control audio*/
      m=video 0 RTP?AVP 26
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/video 
                                               /* URL to control video*/
      m=video 0 RTP/AVP 101
      r = rtsp://foo.com/movie.rm/musicvideo=chiquitita/text 
                                               /* URL to control text*/

C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/audio
S->C: OK
      Session: 1234
C->S: SETUP rtsp://foo.com/movie.rm/musicvideo=chiquitita/video
      Session: 1234
S->C: OK
C->S: PLAY rtsp://foo.com/movie.rm/musicvideo=chiquitita/index
      Session: 1234
S->C: OK
      (Both streams play).

Problems with current thinking on URLs
======================================

*  The relative URLs are prone to authoring errors
   
   Let's apply this now to a simple container file situation:

   <source url="rtsp://foo.com/chiquitita.rm/">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   Notice the trailing slash at the end of chiquitita.rm.  This would be
   necessary in order to keep "audio" and "video from resolving without
   the chiquitita.rm part.  Let me explain:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="audio">
      <stream url="video" playto="window1">
      <stream url="text" playto="window2">
   </source>

   ...is incorrect, because translating the relative urls "audio" and
   "video" into absolute URLs results in "rtsp://foo.com/audio" and
   "rtsp://foo.com/video".  Would it be acceptable for a client to
   always assume an implicit traling slash on all source urls with
   substreams?  If so, this is less of an issue.  However, my reading of
   RFC 1808 says that this wouldn't be strictly complient, and thus may
   create some confusion.

*  Absolute URLs are prone to authoring errors:

   Let's assume we can live without relative URLs.  Let's do absolute,
   then:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquitita.rm/audio">
      <stream url="rtsp://foo.com/chiquitita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquitita.rm/text" playto="window2">
   </source>

   This would actually work, since now the urls can be treated as opaque
   strings by the client.  However, this means that one slip in any of
   the urls causes problems.  Not a big deal, but that's a lot more that
   can go wrong than in the case of relative URLs.  Consider the
   following:

   <source url="rtsp://foo.com/chiquitita.rm">
      <stream url="rtsp://foo.com/chiquatita.rm/audio">
      <stream url="rtsp://foo.com/chiquatita.rm/video" playto="window1">
      <stream url="rtsp://foo.com/chiquatita.rm/text" playto="window2">
   </source>

   It's pretty difficult to catch the error in the RTSL above, because
   there is just way more verbiage than there should be.

*  All URLs are ambiguous to the server

   Wouldn't it be nice to have a *standard* way of dealing with
   container files that didn't rely on making the container appear to be
   directory on the server?  This makes a little extra work for the
   server to really figure out what is going on.  Not a lot, mind you,
   but it just seems sloppy.

Now, the nice thing about making these things into IDs that are sent in
portions of the protocol other than the URL is that it gets the client
out of the URL construction/decryption business, and allows the client
to have multiprotocol support without imposing lots of authoring
scenarios on content authors.

Consider, for instance, the top piece of RTSL:

<source url="rtsp://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

If we have the ids sent in the 822 headers, then it's very clear how the
client should deal with this piece of RTSL with the server.

Also, notice that if we change the source URL to http, we still can have
reasonably network-friendly behavior from the client:

<source url="http://foo.com/movie.rm">
  <stream id="audio">
  <stream id="video" playto="window1">
  <stream id="text" playto="window2">
</source>

In this case, the client can engage in HTTP psuedo-streaming, and split
each of the fragments off at the client side.  From an authoring
perspective, nothing has changed, other than the source of the stream.

Now, I'm not going to make the claim that it's impossible to come up
with an URL format that will address the issues that I have above.
I just hope that we can resolve this in a timely manner.

Thanks
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