Subject: Revised RTSP Methods

From: Eric Fleischman <[email-masked]>
Date: Tue, 25 Mar 1997 16:49:46 -0800

I just retrieved the March 24th version of RTSP from
http://www.cs.columbia.edu/~hgs/rtsp/draft/rtsp.txt.

First Issue:
I must confess a degree of concern over changes which have been made to
section 9 (i.e., the Methods section) from the internet-draft version
(dated Feb 22). My concern stems from the fact that with the sole
exception of the BYE command, I haven't seen any discussion on this list
as to why any of these changes are being made.

My cursory glance seems to indicate that both the BYE and GET methods
are gone.

Three new methods have been added: DESCRIBE, OPTIONS and "'".

It appears that the DESCRIBE method is very similar to the former GET
method. I discuss this in the "fourth issue" section below.

Second Issue:
In a previous message (sent on 3/5/97) I had asked for the PLAY method
to also have an optional "rate" parameter in addition to its offset and
range parameter. Discussions at the time led me to believe that there
was wide-spread agreement with this suggestion - or, at least, the lack
of push-back. However, this parameter did not appear to make it into the
document. I would therefore like to re-interate this request since the
rate parameter is needed to be able to indicate fast-forward/fast-rewind
information.

[Please recall that this rate parameter does *not* refer to the data
rate - the data rate is fixed for that session, or at least may be
"fixed" for applications such as ours. Rather, "rate" refers to the
timeline upon which the streaming "media experience" is built. The
timeline rate may be arbitrarily sped up. For fast-forward and
fast-rewind, the server therefore has to compute at what offset to "skip
to" to match that accelerated timeline. It is aided in this task by the
indexing present in certain media types - no indexing, then no
fast-forward or fast-rewind capability. What this generally means is
that only the key-frames are sent during fast-forward and fast-reverse.
And not every key-frame will necessarily be set depending on the
timeline acceleration speed selected for the timeline advancement."]

Third Issue:
Also, I thought that we had agreed to the concept that the Range
parameter for the PLAY method can also indicate an offset from which
play is to begin. According to my (faulty) memory, the offset is merely
a Range parameter lacking the "-" and the second number. Could we please
have examples giving both the offset use of Range? I ask because I think
that the offset use is much more useful than the range. (Or, at least, I
have trouble imagining how to use the Range in our implementation but I
can think of many examples of how to use the Offset.)

Fourth Issue:
Finally, I am sorry to see the absence of the GET method. I greatly
valued this method and anticipated using it to retrieve session
description information for sessions formed by streaming media file
(e.g., QuickTime, ASF, AVI, or RMFF) data.

The part of the GET method which has been retained within the DESCRIBE
method is that part which corresponds to SDP. However, SDP has not
envisioned the full gamut of session description possibilities,
especially those possibilities which may pertain to describing media
file-based content. This type of info would probably be best returned by
the second GET response type (e.g., opaque) which permits a more
flexible encoding range but which doesn't seem to exist for DESCRIBE.
Could this alternative be re-added to DESCRIBE?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Mar 1997 08:12:13 -0500

> My cursory glance seems to indicate that both the BYE and GET methods

See 'Changes' section.

GET was changed to DESCRIBE, to avoid confusion with the GET method in
HTTP (since it has a very different functionality, namely to retrieve
the object itself rather than its description). The text for DESCRIBE is
the same as before.

> method. I discuss this in the "fourth issue" section below.

No functional change has occurred here.

> rate parameter is needed to be able to indicate fast-forward/fast-rewind

Unless I'm missing some discussion, this is an oversight on my part in
translating discussion into document verbiage. My suggestion would be to
call this parameter "Scale", in accordance with DSM-CC terminology.
Also, "Speed" should probably be renamed to "Rate" or, maybe better yet,
"Datarate".

Also, I'd like comments on the following:

\motivation{HS: With 'Scale', the negative value is redundant and should
probably be removed since it only leads to possible conflicts when Scale 
is positive and Speed negative.}

The new text reads:

\subsection{Scale}
\label{sec:Scale}
 
A scale value of 1 indicates normal play or record at the normal forward
viewing rate. If not 1, the value corresponds to the rate
with respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate (``fast forward'') and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2
has    
normal play time increase at twice the wallclock rate. For every
second   
of elapsed (wallclock) time, 2 seconds of content will be delivered.
A negative value indicates reverse direction.
 
Unless requested otherwise by the {\sf Speed} parameter, the data rate
SHOULD not be changed.  Implementation of scale changes depends on the
server and media type.  For video, a server may, for example, deliver
only key frames or selected key frames.  For audio, it may time-scale
the audio while preserving pitch or, less desirably, deliver fragments
of audio.
 
The server should try to approximate the viewing rate, but may restrict 
the range of scale values that it supports.  The response MUST contain
the actual scale value chosen by the server.
 
If the request contains a {\sf Range} parameter, the new scale value
will take effect at that time.
 
\begin{verbatim}
  Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
\end{verbatim}
 
Example of reverse play at 3.5 times normal rate:
 
\begin{verbatim}
  Scale: -3.5 
\end{verbatim}
> can think of many examples of how to use the Offset.)

Not sure I understand this; as far as I can tell, this capability was
always there and hasn't been removed.

PLAY
Range: 17-

See the Range section for the example. I slso added a third example with
an open-ended range to the PLAY examples.

PLAY with start and stop time is mainly for remote editing, but it is
also very useful when assembling a program from, say, sound clips. The
type of descriptions of media instances that we saw in Cupertino
translate very naturally into this notation.

It was (and is) always possible to indicate to start at NPT 17 and keep
on going. The example in the text has this form. The only difference is
that it keeps the "-"; this is for consistency with the HTTP parameter
(and it does indicate desired behavior since playing a point doesn't
make much sense) and makes a "play from wherever you are up to X"
possible.

> Could this alternative be re-added to DESCRIBE?

I'm a bit at a loss here given that the description of DESCRIBE hasn't
changed at all from what it was when the method was called GET. You can
get any description back that the server supports (and that you,
optionally, indicate with the Accept header). This doesn't have to be
SDP; it can be any proprietary or published or standardized format.
Where does it say that only SDP is acceptable? 

The text says:

"The {\sf DESCRIBE} method retrieves the description of a presentation
or
media object identified by the request URL from a server.  It may use
the {\sf Accept} header to specify the description formats that the
client understands.  The server responds with a {\em description} of the
requested resource."

Thanks for your comments.
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs