Subject: RE: Pause, Fast-Forward, Fast-rewind in RTSP

From: Eric Fleischman <[email-masked]>
Date: Fri, 7 Mar 1997 09:38:43 -0800

There seems to have been some confusion over my inadvertent use of the term 
"STOP". Our stop is your "pause" in that its total effect is to stop the 
data stream. It does not tear down the data stream session. It does not 
need "timers" since the events are user-controlled and no resources are 
consumed via our version of pause.

I am afraid that this type of misunderstanding is due to us not working 
from the same model with a consistent state machine. I can not imagine a 
simpler state machine than that which drives our implementation.

-----Original Message-----
From:	Rob Lanphier [SMTP:[email-masked]]
Sent:	Friday, March 07, 1997 9:22 AM
To:	Eric Fleischman; 'Sampo Syreeni'; 'Jeff Smith'
Cc:	'Henning Schulzrinne'; [email-masked]'
Subject:	Re: Pause, Fast-Forward, Fast-rewind in RTSP

At 05:51 PM 3/5/97 -0800, you wrote:
>[speaking of implementing "pause" by treating it like a stop/close]
>This is all very clean and has permitted our streaming servers to scale to 
>a thousand (or more) simultaneous sessions. This would not have been
>possible had we been using the algorithm this discussion seems to be
>assuming.

We've also been able to implement servers that scale to a thousand (or
more) simultaneous sessions, and we've actually maintained PAUSE as a
state.  The reason is very straightforward why this works:  when someone
hits "pause", they often do want to do a small, momentary pause.  In our
current implementation, there is a timeout when the pause is very long (I
can't remember the number, but this is easily verified using our client).

Momentary pausing is more scalable than stopping, since only allowing stop
would actually result in having to go through a potentially expensive 
setup
when playback resumes.

>Related user controls which seems to have been overlooked by the RTSP 
draft
>are "fast forward" and "fast rewind". These are very important controls
>which are quite popular with users. Unfortunately, they are only possible 
>for certain media types such as video. The way these commands work is very 
>similar to the "pause", so I mention it here for completeness' sake.
>
[explanation of "rate" as a parameter for the PLAY method]

I agree that we need these.  However, in early discussion we compromised
with the notion these are media-specific methods, since they don't
necessarily apply to all streams, as noted.  I think we can come up with a
core RTSP document without this method.  At that point, it would be simple
enough to standardize these as parameters in SET_PARAM and GET_PARAM, or 
as
an extension field to PLAY, as you described.

As long as we can stipulate that these belong as optional extensions 
rather
than core requirements, I'm sure there will be no problem placing these in
an appropriate document (which is probably the core document, though I'd
want to make sure we don't lose focus on the core framework before adding
this extra feature).

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.realaudio.com

---

From: Anup Rao <[email-masked]>
Date: Fri, 07 Mar 1997 12:47:24 -0800

> simpler state machine than that which drives our implementation.

Looking closely, your simple state machine is really the same as the one
currently in the draft. The only difference is that the RTSP one
considers that you might have allocated (possibly transport) resources
*before* the state "not sending" or the actual PLAY. This accounts for
"INIT".  Basically you get into the state "not sending" only *after*:-
a) server knows that it can associate transport resources for the
client.
b) anything else it might need to allocate based on information in
SETUP.

Clearly, an implementation might just want to do all the
allocation(transport, timers etc.) on receipt of the PLAY - that is
fine, the INIT state is null in this case. On the other hand, one may
want to differentiate clearly between failure to associate transport
resources and that to associate timing resources(particularly for
requests at n times normal rate etc.)
In the user scenario, it may be desirable to connect to the server, know
that the server will serve you(atleast normal rate) and activate the
play button, rather than having the user press the play button only to
be refused, or having to necessarily send a PLAY on connection just to
see if you will be served.

The rationale *for and against* having transport headers in SETUP *only*
is explained in the draft - let us try and answer this, I believe the
issue of 2 versus 3 or more  states should follow. I completely agree
that we should strive for simplicity.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------