Subject: [MMUSIC] RTSP: eliminate queued play? (#508211)

From: Rob Lanphier <[email-masked]>
Date: Thu, 24 Jan 2002 16:03:26 -0800 (Pacific Standard Time)

Hi all,

One item that came up in the RTSP teleconference is a proposal to
eliminate the queued play feature from RTSP altogether.

Queued playing, as describe in section 10.5, is a feature that has many
problems with it (e.g. #477424) The members on the telecon felt that
support for this feature is sufficiently weak that rather than fixing this
feature, it may be more appropriate to eliminate it, and come up with a
simpler play/pause model to replace it.

What does everyone think about this?  We'd like to make a decision on this
quickly, so if there's no discussion on this list before February 6, we'd
like to call this one settled (of course, if there is discussion, we'll
let that play out first).

Rob

The writeup of the bug is at the following location:
http://rtsp.org/bug508211

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Jan 2002 16:29:13 -0500

I would like to maintain this feature. Nobody has to implement it, but
it is useful to ensure gap-less playback. The bug noted (477424) seems
to apply only to the case that explicit activation times are listed, in
which case queueing doesn't make sense. Thus, only requests without
activitation time should be queued. What other problems are there?

---

From: Jeff Ayars <[email-masked]>
Date: Fri, 25 Jan 2002 13:47:23 -0800

>activitation time should be queued. What other problems are there?

How can you have a Draft Standard document with a feature without 2 
implementations?  If nobody implements it don't we have to take it out?

JEff

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Jan 2002 17:01:58 -0500

Careless phrasing on my part: Yes, there have to be two implementations.
No, it doesn't have to be mandatory-to-implement (MUST).

---

From: Jonathan Sergent <[email-masked]>
Date: Fri, 25 Jan 2002 14:08:38 -0800

> activitation time should be queued. What other problems are there?

Right now it is a MUST for servers, but I am under the impression that
nobody uses it, and there are servers which do not implement it even
though it is a MUST.  Could it be made optional for servers?  Servers
which don't implement it can just return errors for the second and
further play requests so that the client can detect this.  A Require
tag could also be introduced for clients which absolutely need queued
play in order to operate.

-- 
Jonathan Sergent / [email-masked]

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 25 Jan 2002 17:17:53 -0800 (Pacific Standard Time)

Hi Henning,

Regarding the two implementation discussion, the issue is that we don't
feel like it's likely we'll have two clients and two servers for this
feature.  On the telecon, we tallied one server and no clients.  That's
hardly an exhaustive search, but that's also part of the point of this
thread.  If there's someone on this list who knows of client
implemenations of this feature, they need to speak up.

As I remember it, Jonathan Sergent noted on the telecon that he has a raft
of issues he plans to write up if we decide to keep queued play.  I'll let
him go into it further.  Just doing a search on "queue" in the bugs, I
find the following:

http://rtsp.org/bug477424   How to queue timed plays?
http://rtsp.org/bug477428   Priorites between aggregated & non cntrl
http://rtsp.org/bug477432   RTP info and queued plays
http://rtsp.org/bug493265   Pause - Play behaviour clarification
http://rtsp.org/bug507882   RTP timestamps when playing after pause

That's not to say that all of these speak to the issue at hand, so don't
take this as the definitive list.  In general, it seemed that most of the
people on the call would rather come up with a simplified PLAY/PAUSE
model than to work out the bugs with the current feature.

Rob

---

From: Jonathan Sergent <[email-masked]>
Date: Fri, 25 Jan 2002 18:03:32 -0800

> him go into it further.  Just doing a search on "queue" in the bugs, I

Even if we don't keep it, there are lots of issues.  I just sent the
list out this afternoon.