Subject: Posting descriptions via ANNOUNCE (Re: Format of RTSP URLs)

From: Rob Lanphier <[email-masked]>
Date: Fri, 11 Jul 1997 17:58:13 -0700

At 01:17 PM 7/11/97 -0700, Stephen Casner wrote:
>Who is in control of the file format during a record operation?  I
>would expect the presentation description to control the grouping and
>determine what kind of individual or collective files should be
>written.  Who sends the presenation description?  (From my reading of
>the protocol, presentation descriptions only go from the server to the
>client.) 

Ironically enough, we just changed that so that it is only from client to
server.  draft02 did have DESCRIBE going from server to client, and in
fact, there used to be a method called SESSION which had this function in
draft01.  We tabled the issue of replacing S->C DESCRIBE/SESSION until
after at least this conversation wound down, but now that you bring it up,
I'd like to make a proposal.

How about a new ANNOUNCE method as both a C->S and a S->C method?  This
would be the active counterpart of DESCRIBE, which would serve the
following functions:

*  Posting stream descriptions
*  Initializing an empty container with streaming information (essentially,
what normally goes in the header of a container file).

It would be very analogous to DESCRIBE, and would fit into the chain of
events thusly:

Playback      Recording
DESCRIBE      ANNOUNCE
SETUP         SETUP
PLAY          RECORD

I'll spec this out later, but I'd like to flag this as an open issue.  Now
back to the 1-1-n discussion, already in progress :)

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

---

From: Brad Hefta-Gaub <[email-masked]>
Date: Sat, 12 Jul 1997 16:16:44 -0700

>> I do not view PLAY and RECORD as being in a mutually exclusive
>> relationship. I can well imagine a PLAY and RECORD both taking place
>> simultaneously. I can imagine one chosing to record "snippets" of PLAY.

Eric, RECORD is not at all related to client side recording. I point 
this out because this message and other messages from you have seemed
to suggest that this was your understanding of RECORD.

The intent of RECORD is to tell the server to "consume" a media stream
instead of it's normal job of "producing" a stream. For example in
PN's current implementations of RTSP we use the RECORD verb 
between an encoder application and the server, where the encoder
tells the server that it should begin to consume a live feed from 
the encoder.

>> I can well imagine a PLAY and RECORD both taking place
>> simultaneously. I can imagine one chosing to record "snippets" 
>> of PLAY.

Sure, a single server may be recording and playing, and it may even 
perform these operations with the same client, but not in the same 
session.

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