Subject: Advertisements over RTSP

From: "Kirk Shoop" <[email-masked]>
Date: Wed, 10 Jun 1998 15:15:44 -0700

Hi, I have another thread to start.. :)

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.

So a DESCRIBE is sent, in the response we are told that this 
URL has Video and Audio, then we send SETUP.  However this 
time it resolves to content that streams Audio only.  
Now what?

One way to allow this is to move the SessionID response to 
the DESCRIBE and thereby include DESCRIBE in a Session.  
This way the SessionID received from the DESCRIBE can be 
sent with a subsequent SETUP where it is used to maintain 
the state.  If the SETUP method is sent without a SessionID 
then a new one is allocated.  This would require that 
DESCRIBE's be followed by TEARDOWN's.

Thanks,
Kirk

---

From: Alagu Periyannan <[email-masked]>
Date: Wed, 10 Jun 1998 16:10:54 -0700

>time it resolves to content that streams Audio only.

How about using the REDIRECT mechanism that came
over to RTSP from HTTP.

Everytime you do a DESCRIBE on the advertisement URL
the server will look up the database and redirect you
to a specific ad's URL. From then on the current behavour
supported by RTSP should suffice.

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

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Jun 1998 19:42:57 -0400

> DESCRIBE's be followed by TEARDOWN's.

I would prefer that the URLs in the DESCRIBE contain an actual URL of
the advertising clip. This seems cleaner.

-- 
Henning Schulzrinne   [email-masked]
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

---

From: Anup Rao <[email-masked]>
Date: Wed, 10 Jun 1998 17:08:17 -0700

> DESCRIBE's be followed by TEARDOWN's.

After some  arguments either way, it was decided to keep DESCRIBE
stateless - ie. not allocate session ids on a DESCRIBE. The primary
argument is that DESCRIBE does not need to result in any resource
allocation - for that matter it is optional in RTSP. 

Here is another way to accomplish what you need - use HTTP GET to your
adserver to get a .sdp file, do SETUP etc. and take it from there. The
.sdp file gives you the right RTSP URL ie. every HTTP GET would give you
different RTSP URLs in random fashion(This, I believe is the current web
model).  You would never need to pass a RTSP url to your "random
resolver".  If you absolutely do not want to use HTTP, then a RTSP
DESCRIBE may return you a different RTSP URL(not highly recommended)
than the one the DESCRIBE was done on and then you would do SETUP etc.
on it. But then you would have to resolve URLS differently depending on
whether they are coming by DESCRIBE or some other message i.e "describe"
urls get resolved randomly, others do not.

What you have suggested will work for your case, but here are my
thoughts on the subject: 
The sessionID is meant to  denote/specify  the client instance of a
particular URL, not identify a piece of content(which is what is
happening, I think in what you are suggesting - the sessionID is
transgressing into the functionality space of the URL). 

Regards
Anup.