Subject: RE: Advertisements over RTSP

From: "Anders Klemets (Exchange)" <[email-masked]>
Date: Wed, 10 Jun 1998 19:20:50 -0700

> Say you have an Ad server that randomly picks content from a 
> database when asked for a particular URL.  So each time the 
> URL is resolved, different content is returned.
> [...]

I brought up exactly the same problem on this list in September last year.
I am including two e-mail messages from our previous discussion as MIME
attachments.

If the confctrl list is archived somewhere you may want look in that
archive, too.
In short, the solution to the problem is to use the Etag feature in SDP and
the If-Match field in RTSP.

Anders

Subject: Re: Allocating state in RTSP DESCRIBE
From: [email-masked]
To: Anders Klemets (VXtreme)
Cc: "[email-masked]'" <[email-masked]>
Date: Wed, 24 Sep 1997 09:13:55 -0700

Anders Klemets (VXtreme) wrote:

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

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

Subject: Re: Allocating state in RTSP DESCRIBE
From: [email-masked]
To: Anders Klemets (VXtreme)
Cc: "[email-masked]'" <[email-masked]>
Date: Wed, 24 Sep 1997 09:13:55 -0700

Anders Klemets (VXtreme) wrote:

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

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

---

From: Anup Rao <[email-masked]>
Date: Wed, 10 Jun 1998 22:27:12 -0700

> the If-Match field in RTSP.

Yes, it is a very similar problem, but I did not understand it to be the
same as that mentioned below. Unless I missed something, Kirk seems to
be referring to the case where URL resolution itself is randomized. 
What either of us said or some combination should do the trick.

Thanks
Anup.
 
>                                                   ------------------------------------------------------------------------
> 
> CC: "[email-masked]'" <[email-masked]>
>

---

From: "Kirk Shoop" <[email-masked]>
Date: Thu, 11 Jun 1998 18:18:57 -0700

Thank you all for the quick replies to this.  The several answers 
caused me to realize that we had not researched the problem 
sufficiently.

I agree that SessionID should not be overloaded for this purpose.  
I agree that redirection or cgi over http can circumvent this 
issue, but they do not really solve our problem.  

After looking through the HTTP spec, I think that ETag and If-Match 
are the best fit for us (Thank you Anders).  The only thing missing 
from this is the ability to control the lifetime of the state on 
the server.  We foresee situations where many DESCRIBE's are done, 
but never a SETUP, and therefore never a TEARDOWN.  We could just 
timeout the resources allocated in the DESCRIBE, but would rather 
add a header to DESCRIBE that would allow the client to _request_ 
an ETag in the response rather than always returning one.  If the 
client does not request an ETag then the server can discard the 
state immediately after the DESCRIBE is finished.

Thoughts?

Thanks,
Kirk

---

From: Alagu Periyannan <[email-masked]>
Date: Fri, 12 Jun 1998 10:34:02 -0700

>issue, but they do not really solve our problem.

Redirection is possible in RTSP also. An RTSP server can
do a redirect in response to a DESCRIBE. This redirect will
give the specific ad's URL to the client.

---------------------------------------------------
Alagu Periyannan                   [email-masked]

Interactive Multimedia Group
Apple Computer, Inc.

---

From: "Kirk Shoop" <[email-masked]>
Date: Fri, 12 Jun 1998 17:30:06 -0700

After some more research, we think we can solve the state-timeout problem in
our server with the Require header.

Our client and server would do this..

C->S:	DESCRIBE rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 260
	Require: retain-entity-for-setup

S->C:	RTSP/1.0 OK
	CSeq: 260
	ETag: EEE..

C->S:	SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 261
	If-Match: EEE..

S->C:	RTSP/1.0 200 OK
	CSeq: 261

Our client and a non-compatible server would do this..

C->S:	DESCRIBE rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 302
	Require: retain-entity-for-setup

S->C:	RTSP/1.0 551 Option not supported
	CSeq: 302
	Unsupported: retain-entity-for-setup

C->S:	DESCRIBE rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 303

S->C:	RTSP/1.0 200 OK
	CSeq: 303

C->S:	SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
	CSeq: 304

S->C:	RTSP/1.0 200 OK
	CSeq: 304

A non-compatible client and our server would work normally. If
retain-entity-for-setup is not specified, then our server will
free the resources used by the DESCRIBE.

This means that our server can serve dynamic content to compatible
clients and still inter-operate with other client and server
implementations.

Thank you all for your help,

Kirk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kirk Shoop
> Sent: Thursday, June 11, 1998 6:19 PM
> To: Confctrl
> Subject: RE: Advertisements over RTSP
>
>