Re: Format of RTSP URLs

Rob Lanphier <> Thu, 17 July 1997 05:38 UTC

Received: from cnri by id aa01119; 17 Jul 97 1:38 EDT
Received: from (services.Bunyip.Com []) by (8.8.5/8.7.3) with ESMTPid BAA10608; Thu, 17 Jul 1997 01:36:41 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id BAA15485 for uri-out; Thu, 17 Jul 1997 01:18:31 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id BAA15479 for <>; Thu, 17 Jul 1997 01:18:26 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id BAA03982 for uri@services; Thu, 17 Jul 1997 01:18:25 -0400 (EDT)
Received: from ( []) by (8.8.5/8.8.5) with SMTP id BAA03979 for <>; Thu, 17 Jul 1997 01:18:21 -0400 (EDT)
Received: from ( by with SMTP id AA26546 (5.67b/IDA-1.5 for <>); Wed, 16 Jul 1997 22:23:00 -0700
Message-Id: <>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 16 Jul 1997 22:16:06 -0700
To: Bill Simpson-Young <>
From: Rob Lanphier <>
Subject: Re: Format of RTSP URLs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

At 01:09 PM 7/17/97 +1000, Bill Simpson-Young wrote:
>robla wrote:
>> 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*/
>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.  

I very sincerely beg to differ.  In practice, there are a lot of datatypes
that need more initialization information than you would expect a content
author to get right in their hand-authored portion.  This is bound pretty
intricately to the media file itself, and therefore should be served by the
media server.  This is in fact how we are implementing this (and have
implemented it in our RealMedia developer betas).

This idea was brought up once before on confctrl, in a message from Brad
Hefta-Gaub, one of our RealMedia development leads:

>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)
>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>

There is a lot of work going on in this area.  We have an SGML-based
metafile language that looks very similar to this actually called RTSL
which is included in the RealMedia SDK (see for
more details).  However, we don't require content authors to place all of
the media initialization information into their presentations, which leads
us to rely on DESCRIBE to get the bulk of the parameters.  We instead use
this metafile as a means of providing high-level sequencing, selection, and
synchronization, and for mapping stream components onto layout components.