Subject: Allocating state in RTSP DESCRIBE

From: "Anders Klemets (VXtreme)" <[email-masked]>
Date: Tue, 23 Sep 1997 20:55:04 -0700

I am looking for input from the group for how to solve the following
RTSP problem:

Suppose the server receives a DESCRIBE command for some presentation or
media object.  The presentation description is generated dynamically by
the server.  The description might be generated randomly, or it might
depend on the time of the day, or whatever.  Any SETUP commands for the
presentation URL that the server subsequently receives may have a
meaning that is dependent on the previously generated presentation
description.  A presentation description might have implicit state
information, and that state might be needed later, when playing the
streams in the presentation.  The problem is that the presentation was
generated dynamically, and the the DESCRIBE command is not supposed to
allocate any state on the server.

So, when the server receives the SETUP and PLAY commands, it might need
to know which randomly generated presentation description the client has
seen.  The question is, how can this be accomplished?

I can think of two ways of achieving this "association" between DESCRIBE
and SETUP/PLAY:

1.  The server allocates whatever state it needs when it generates the
presentation description, and allocates an identifier for this state,
which it encodes in the URLs that are included in the presentation
description.  This state identifier might be a random number of some
sort.  If the client never sends a SETUP command, the state is deleted
after a timeout interval.

2.  Instead of allocating a state identifier, as in the previous
example, the server allocates a session ID, which serves the same
purpose.  The session ID is returned on a "Session:" header line in the
DESCRIBE response.  (This would only be done when necessary, i.e. it
would not be done for normal, "static", presentations.)  The client
includes the session ID on a "Session:" line when it sends a SETUP
command.  If the client does not want to send a SETUP command, it should
send a TEARDOWN command to deallocate the session id and the state that
goes with it.  But if not, the session id will be automatically deleted
after a timeout interval.

Method #2 requires a modification of the RTSP spec, but it seems like a
"cleaner" solution than putting a lot of junk in the URLs.  After all,
all the normal functionality that the session ID provides can also be
accomplished by generating random URLs.  So if generating random URLs
was such a palatable solution, we would not need to have any session IDs
at all.

Comments?

Anders

---

From: [email-masked] (Anup Rao)
Date: Wed, 24 Sep 1997 09:13:55 -0700

> seen.  The question is, how can this be accomplished?

The If-Match header(Section 12.22) accomplishes this.(Also see
corresponding etag definition in Appendix C).

One might argue that such a mechanism(ie an identifier guaranteeing the
freshness of the description) and the state signified by the session id
are accomplishing the same thing - however this is not the case. One is
the actual state of the stream(s) ie playing, stopped etc., the other is
simply a freshness identifier for the presentation itself. For eg., a
freshness identifier could remain active for a day, a session id  would
not.

--
-----------------------------------------------------------------
  Anup Rao
  Member Of Technical Staff
  Netscape Communications Corp.
  email : [email-masked]         Phone : (650) 937 3129
-----------------------------------------------------------------