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

From: Eric Fleischman <[email-masked]>
Date: Sat, 12 Jul 1997 14:12:32 -0700

The way I see things is that DESCRIBE is necessary for all environments
where a session description (whether SDP or a proprietary alternative)
exists.

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.

I see no need for ANNOUNCE. It seems to only "clutter up" the
environment. What does it add (other than complexity)?

What I think we need is to enhance the importance of DESCRIBE since I
think that session descriptions are extremely important in the general
case to making deployable systems. 

> -----Original Message-----
> From:	Rob Lanphier [SMTP:[email-masked]]
> Sent:	Friday, July 11, 1997 5:58 PM
> To:	Stephen Casner
> Cc:	[email-masked]
> Subject:	Posting descriptions via ANNOUNCE (Re: Format of RTSP
> URLs)
> 
> 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: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 1997 14:47:50 +0200

> where a session description (whether SDP or a proprietary alternative)

I don't think that is correct, in general. I can use HTTP to retrieve a
session description (SDP, MML, etc.) and never need DESCRIBE.

> environment. What does it add (other than complexity)?

DESCRIBE is 'pull', i.e., the client has to know that it wants a (new)
session description; ANNOUNCE is 'push', the server telling the client
that there's a new stream available. While I see ANNOUNCE as being
rarely needed and having the usual server-to-client communication
problems, it comes in handy on occasion, such as changes in a live or
continuous presentation. For scalability reasons, having the client poll
the server for an updated description every so often seems less
desirable, but is probably sufficient for now, given the relative number
of packets transmitted. (10-50/second, say, for audio and video and one
every few minutes for a poll.) In some cases, it may be sufficient for
the server to simply set a marker (in a response to an RTSP command or,
as a more layer-violating option, as part of the media control stream)
to tell the client "do a DESCRIBE".

Henning