Subject: Miscellanous RTSP comments

From: Anders Klemets <[email-masked]>
Date: Wed, 13 Aug 1997 19:20:09 -0700

I have a number of miscellanous comments on the RTSP draft.

Section 12.6.  There is a "Bandwidth" parameter that is sent from
the server to the client.  How is this suposed to be used?  Is the
idea that the client might use the bandwidth value as a parameter in
an RSVP reservation?  I would like it to be possible for the client
to send the "Bandwidth" parameter to the server as well.  This
would be used by the client to tell the server what its bandwidth
constraints are.  The server can use this information to select a
version of the stream that suits the client.

Section 12.36.  The "Transport-Info" field contains a "stream-id"
parameter.  I am a little bit confused here.  What exactly is this?
Is it the same thing as the "channel identifier" that is used when
interleaving RTP over the RTSP connection?  Or does it have something
to do with the session id?  

I think if you are sending an "aggregate" PLAY command, you will
receive multiple "Transport-Info" headers, one for each stream.
There needs to be a way to know which stream a particular 
"Transport-Info" header refers to.  The spec says that the response 
to the SETUP command may return an "ssrc" parameter.  This parameter
could be used in lieu of the "stream-id" in "Transport-Info" in order
to associate it with a particular stream.

Section 12.35.  The BNF syntax for the "Transport" field does not
include the "interleaved" parameter, and the text does not explain
the usage of the "channel" parameter.

Section 12.34.  The "Session" header.  The text should mention that
there is a "Session Not Found" error message.

Section 12.11.  "Conference" header.  The spec should probably
specify a "Conference Not Found" error message.

Section 10.4 & 10.5.  SETUP and PLAY commands.  The examples given
in these sections do not include the "Session-Id" parameter.  This
is confusing.  What does it mean if "Session-Id" is left unspecified?
I think it should be a protocol error.

Section 10.10, Appendix 1 & Appendix 2.  REDIRECT command.  Does the
REDIRECT command cause a state change in either the client or the
server?  The tables in the appendix do not show anything.  Should
the client send a TEARDOWN command after having received a REDIRECT?
I guess the answer is Yes, but the spec ought to be more specific
here.

Section 14.5.  RECORD command example.  This example uses the
DESCRIBE command in a strange way.  I think it should use ANNOUNCE
instead.  The spec does not make clear in which ways ANNOUNCE and
RECORD may fail.  I see that an error code "409 Conflict" has been
defined.  But the spec does not elaborate on its usage.  For instance,
Table 1 says that error 409 is only supposed to be returned by the
RECORD command.  But what about the ANNOUNCE command?  If the RECORD
command returns 409, ANNOUNCE must do so too, otherwise the data 
stored on the server will be left in an inconsistent state.

In addition, it might be useful to have a "2xx Low on disk space"
return code.  The server can estimate how much disk space it needs
for a recording, if the RECORD command contains a "Range" parameter
and a "Bandwidth" parameter.  It can save the user a lot of grief
if he can be warned that there might not be enough disk space.

Anders

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 15 Aug 1997 20:31:21 -0400

> I have a number of miscellanous comments on the RTSP draft.

Thanks for your careful reading.

> version of the stream that suits the client.

The bandwidth header is a "R" (Request) header and thus sent from client
to server. I'm not sure the opposite direction makes a lot of sense.

> to do with the session id?

This is last-minute editing, left-over from the stream-id discussion.
Please ignore for now.

> the usage of the "channel" parameter.

Fixed. Now interleaved=channel

> there is a "Session Not Found" error message.

Added.

> specify a "Conference Not Found" error message.

Was there: 452; pointer added.

> I think it should be a protocol error.

I added the Session: header. However, omission is not a protocol error;
I added:

A server does not have to set up a session identifier if it has other 
means of identifying a session, such as dynamically generated URLs.

> I guess the answer is Yes, but the spec ought to be more specific

The current text says: " Receiving a {\sf REDIRECT} from the server is
equivalent
to receiving a 3xx redirect status from the server." (goes to Init) All
other state changes are initiated by client action, so this doesn't
quite fit the table.

> stored on the server will be left in an inconsistent state.

It is not quite clear to me yet what the appropriate model is for
recording a group of streams. How, it at all, should stream groups be
expressed when recording? Since ANNOUNCE doesn't create/change state, it
seems inappropriate to attach semantics to it.

SETUP rtsp://foo/audio
Transport: RTP/AVP/UDP;destination=224.2.0.1;???port=3456

SETUP rtsp://foo/video
Transport: RTP/AVP/UDP;destination=224.2.1.1;???port=38385

(The parameter name "destination" seems be ill-chosen, unfortunately.)

What should a server do with an ANNOUNCE? One possibility: Attach it as
meta-information to the recorded file. In that case, it should probably
be issued after the SETUP.

> if he can be warned that there might not be enough disk space.

If the RECORD request contains a Range parameter, the server could
simply compute the amount of time it can record, put that in the Range
header in the normal fashion. I added 250 Low On Storage Space.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs