Subject: Changes/clarifications to RTSP

From: Anup Rao <[email-masked]>
Date: Fri, 24 Mar 2000 16:38:23 -0800

Hi everyone,

Seems like it is a good time to work on  a RTSP spec  revision with:

a) Clarifications based on  implementation experience
b) Enhancements, possibly related to caching or other work.
c) Removing parts that have not been implemented and will not be, should such
parts exist.

I'll go through what I have for a) below. Input for all of the categories is
solicited.  Note that some  enhancements are proposed in
draft-sheedy-mmusic-rtsp-ext-00.txt and
draft-periyannan-rtsp-caching-00.txt.

Thanks
Anup.

a1) Use of destination parameter in Transport header, raised by Ed Lau

Draft seems to be unduly restrictive in terms of using this parameter for
unicast, ie to direct a stream at an address other than the one
control requests are being recd from.  Henning posted a change,  reproduced
here:

\begin{changebar}
\item[\header{destination}:] The address to which a stream will be
sent.
The client may specify the destination address with the \header{destination}
parameter.  To avoid becoming the unwitting perpetrator of a remote-controlled
denial-of-service attack, a
server {\SHOULD} authenticate the client and {\SHOULD} log such attempts
before allowing the client to direct a media stream to an address not
chosen  by the server.  This is particularly important if RTSP commands are
issued via UDP, but implementations cannot rely on TCP as reliable means of
client identification by itself.
\end{changebar}

a2) Description of error code 451 is not consistent. It is "Invalid parameter"
in 7.1.1 and "Parameter not understood" everywhere else.

a3) Clarification of  response code if some value within a header is not
supported. I've add quite a few people ask me this : what is the response code
if  a server gets a PLAY with absolute time,  and  does not support it.

Propose to use a new 5xx code. In addition, the reponse should include parts of
the header that were not supported.

For example:

PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z

RTSP/1.0 451 Parameter not understood
Range: time=19970123T153600Z

meaning that the absolute time specification was not understood.

This should be backwards compatible.

a4) Also,  the use of OPTIONS to query the support of such abilities(ie types of
ranges supported)  in addition to querying extension and method support.

Currently OPTIONS can be used only to query method support. It is useful to have
it query
the supported  range types(smpte/absolute/npt) as well.

A possible way to do this is to include the headers in the request whose
supported possibilities are desired. For example

OPTIONS *  RTSP/1.0
Range: * (or empty)

RTSP/1.0 200 OK
Range: npt, clock, smpte

For querying of server supported extensions, it is possible to use OPTIONS and
the "Supported" header specified for SIP.

a5)  More a question: Any SET/GET_PARAMETERS requiring to be standarized ?

-Anup.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 02 Apr 2000 15:07:18 -0400

Anup Rao wrote:

> in 7.1.1 and "Parameter not understood" everywhere else.

I edited this to 'Parameter Not Understood'.

> This should be backwards compatible.

I don't like this idea, as it doesn't conform with standard HTTP/SIP
practice. Why not simply have the status message include more detail? I
don't think it is likely that the application will want to display the
headers nor be able to recover automatically from this. In other words,

RTSP/1.0 451 Absolute time range header not understood

is much clearer to the user. An Accept-Ranges header (see below) can be
added for the benefit of software.

> the "Supported" header specified for SIP.

Should probably be something like Accept-Range header, to be consistent
with the other Accept mechanisms. This would be automatically returned
by OPTIONS, just like the other Accept-* headers.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Anup Rao <[email-masked]>
Date: Mon, 03 Apr 2000 18:36:48 -0700

> RTSP/1.0 451 Absolute time range header not understood

Just realized that my earlier  message was erroneous.. I proposed a new 5xx code, and
promptly followed it with a 4xx example. (I also neglected to mention that the
behavior speced in RFC2326  is to send a 501 - this is usually used for unsupported
*methods* and therefore somewhat ambiguous). I  am fine  with your comment about
simply having more detail in the message  instead of  my proposal though.

Comment on Accept-Ranges below...

> by OPTIONS, just like the other Accept-* headers.

I thought of this, but shied away from it simply because the notion of Accept-*
headers in HTTP seems very tied in  to the content (ie message body) in the response
rather than a parameter to a header to a subsequent request.

Still, what you propose  seems to be a reasonable progression in the usage of
Accept-*.

-Anup.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Apr 2000 22:04:52 -0400

Anup Rao wrote:

> Still, what you propose  seems to be a reasonable progression in the usage of

Actually, HTTP/1.1 has the Accept-Ranges header, so this seems in line
with the (re)use of the Ranges header. In HTTP, a server that doesn't
implement Ranges simply returns the whole object, which isn't what we
want. 

Any opinions as to whether to reuse 501 or create a new 55x status code?

---

From: Dirk Pranke <[email-masked]>
Date: Mon, 03 Apr 2000 21:46:06 -0700

There are also two problems that are related to the 'range type not implemented'
problem:

(1) what if only a subset of requestable values are permanently available?
(2) what if only a subset of requestable values are temporarily available?

In the first case, suppose I issue "Speed: 5.3" and only "Speed: 2.0" and "Speed: 8.0"
are available? Is this an error, or does the server round to an available value?
If it rounds, what is the acceptable precision of rounding, and does it round up or
down?

In the second, case, what if the different speed is temporarily unavailable?
(for example, suppose handling trick mode streams was more CPU intensive on the
server, and the resources are temporarily unavailable). Is this an error? Is it
acceptable for the server to return "Scale: 1.0" in this case (which is not trick
mode at all)?

Both these questions clearly apply to at least the Range:, Speed:, and Scale: 
headers, but may apply to others that aren't occuring to me at the moment ...
I believe the second case is addressed somewhat by Sean Sheedy's proposed RTSP
extensions, but the more general is still unclear.

-- Dirk

Dirk Pranke
Oracle Interactive Television

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Apr 2000 09:55:04 -0400

> If it rounds, what is the acceptable precision of rounding, and does it round up or

I'm a bit worried that this could get infinitely complicated, as the
server may have to indicate sets of values and somehow the client has to
make sense of this. If we want to go there, we should take a serious
look at the HTTP content negotiation work which addresses such parameter
constraints, particularly since it may well be possible that
combinations of parameters are restricted.

A simple approach is to say "the server proposes, the client disposes",
i.e., the server decides whether it can deliver something that is "close
enough" and indicates its choice. If the client doesn't like the choice,
it can terminate the PLAY or prompt the user with something like "You
requested speed 5.3, the server can only do 8.0. Abort/Retry/Continue?"

In a consumer application, the client might be happy with anything even
reasonably close, given that the alternative is no streaming content at
all. In a pro-editing application, the client would probably at least
ask. 

One possibility is to add a Require: precisescale, preciserange, 

where the server would then return a 551 or whatever if it can't exactly
do as told (or 420 if it doesn't know the feature).

---

From: Kundan Singh <[email-masked]>
Date: Tue, 4 Apr 2000 11:55:24 -0400 (EDT)

Will it be a good idea to include some provision 
in RTSP to delete a resource/recorded media on the server.

Henning and I had a discussion on this and we see following
possibilities:
 - define another RTSP method, say "DELETE".
 - Use SETUP(mode=record)-TEARDOWN sequence. If you want to delete
   the resource/file then you send RTSP messages as if
   you are recoding the file, but without sending an actual
   RECORD message. The server interprets SETUP for recording,
   followed by TEARDOWN (without RECORD) as a command to
   delete the file. (Any way the recorded file will be empty otherwise).

The first approach is a more straight forward, formal approach
while the second is a hack.

Obviously, proper authentication needs to be done for
deletion. 

Regards
Kundan
--
Kundan Singh     http://www.cs.columbia.edu/~kns10

---

From: Dirk Pranke <[email-masked]>
Date: Tue, 04 Apr 2000 20:19:12 -0700

> combinations of parameters are restricted.

I share your concerns, but we still need to address the problem. I would be
in favor of the simplest possible approach ...
 
> requested speed 5.3, the server can only do 8.0. Abort/Retry/Continue?"

This is certainly a simple approach, and has occurred to us. The one real
drawback is that the command may have side effects that are undesirable.
For example, if I'm writing a consumer application, and the consumer pressed
fast-forward, and the server decided to play the 8x stream at 1x instead,
then do to the race between control information (RTSP) and data information (RTP)
the client may well get 1-2 seconds of 1x stream that it didn't want. In
some situations, this may be uncontrollably thrown up on screen with 
distracting results ...

> do as told (or 420 if it doesn't know the feature).

Yeah, this might be a start, but I, like you, am not sure where to draw
the line.

-- Dirk

Dirk Pranke
Oracle Interactive Television Division

---

From: Dirk Pranke <[email-masked]>
Date: Tue, 04 Apr 2000 20:21:34 -0700

> Obviously, proper authentication needs to be done for

I might be open to adding a DELETE method, but am hesitant given that
HTTP has not found it necessary to add a DELETE method.

The second approach is too far out of the realm of what TEARDOWN
is supposed to do, in my opinion.

-- Dirk

Dirk Pranke

---

From: Philipp Hoschka <[email-masked]>
Date: Wed, 05 Apr 2000 09:45:11 +0800

Dirk Pranke a écrit :
...
> HTTP has not found it necessary to add a DELETE method.

there is actually a DELETE method in HTTP/1.1

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 05 Apr 2000 08:40:02 -0400

> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

Are you suggesting RTSP doesn't need one or that there's precedent for
doing it?

---

From: Philipp Hoschka <[email-masked]>
Date: Wed, 05 Apr 2000 14:41:19 +0800

> Are you suggesting RTSP doesn't need one or that there's precedent for

I was just responding to the statement that "HTTP has not found it
necessary to add a DELETE method", which is incorrect.

I have no immediate opinion on whether RTSP needs a DELETE method
at all, and if so, whether it should reuse the HTTP method; or
design its own

---

From: Dirk Pranke <[email-masked]>
Date: Wed, 05 Apr 2000 13:25:10 -0700

> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

Sigh. I knew I should have checked my references before making this 
statement ...

-- Dirk

---

From: Sean Sheedy <[email-masked]>
Date: Mon, 10 Apr 2000 15:26:31 -0700

> Obviously, proper authentication needs to be done for

I don't think that content management (of which deletion is only a very
small part) belongs in RTSP.  Other protocols such at HTTP are more
appropriate.  RTSP should stick to controlling delivery of
presentations.

Sean

-- 
Sean Sheedy                                         [email-masked]
(503) 531-6427

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Apr 2000 12:35:08 -0400

> appropriate.  RTSP should stick to controlling delivery of

The problem is that this doesn't work well in practice. In many cases,
an RTSP server won't have an HTTP server or, if it does, the namespaces
will be very different. I agree that most servers don't need to
implement this, but for some applications (such as voice mail) this
pretty much covers content management.

---

From: Rob Lanphier <[email-masked]>
Date: Tue, 11 Apr 2000 11:49:07 -0700

>pretty much covers content management.

Let me just throw out a half-baked idea as a possibility:  could we present 
some way of probing for permissions on a URL?  For instance:

OPTIONS rtsp://foo.com/bar/blat.rm RTSP/1.0
CSeq: 1
HTTP-management-options: please

RTSP/1.0 200 OK
HTTP-Management-URL: http://foo.com/rtspserver/bar/blat.rm
HTTP-Public:  PUT, DELETE, PROPFIND, PROPPATCH, COPY

This would make it possible to do whatever file-management that HTTP 
offers, such as DELETE in the simple case, and WebDAV (rfc2518) in a more 
complex scenario.

Other than noting that the RTSP->HTTP crossover problem is a solvable 
problem, I'm not going to offer an opinion (yet) as to whether it's the 
best thing to do.

Rob

---

From: Anthony Baxter <[email-masked]>
Date: Wed, 12 Apr 2000 11:02:00 +1000

>>> Henning Schulzrinne wrote
> > 

The problem is that this is a really slippery slope - you end up trying
to encapsulate a whole lot of stuff into RTSP, and it's really quite 
unpleasant. This is not just hypothetical - I've been there, and done 
this. It _really_ does not work. Sure, delete might be ok - but what 
about (in the voicemail case) reply? annotate? If you want to do delete
via RTSP, do it by something like 

DESCRIBE /deleteMessage/msgid=343556432 

which can send back an audio stream saying 'message deleted'. Adding it as
a new command seems way overkill.

ObSuggestedImprovementToRFC: cleaning up the words about destination and
source, in particular when dealing with record and play. Actually, unicast
record (the voicemail, again) could do with some more docs.

Anthony

---

From: Sonia Gomez Garcia <[email-masked]>
Date: Wed, 12 Apr 2000 08:16:04 +0200

I'd like not to receive more mails from this list.

Thank you,
    Sonia

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Apr 2000 03:32:30 -0400

> to encapsulate a whole lot of stuff into RTSP, and it's really quite

The slippery slope argument can be made about anything, so I'm not sure
how to respond.

> via RTSP, do it by something like

In our voice mail model, there is no need for replies in the traditional
sense.

> a new command seems way overkill.

This seems even uglier. At least with an explicit command, the client
can find out which methods are supported (via OPTIONS), rather than
somehow magically guessing that some strange DESCRIBE URL also happens
to delete the message.

---

From: Anthony Baxter <[email-masked]>
Date: Wed, 12 Apr 2000 18:52:16 +1000

> The slippery slope argument can be made about anything, so I'm not sure

If you're going to add DELETE, why not RENAME as well? And then you might
get into versioning, so maybe you need locks, and the like. 

> In our voice mail model, there is no need for replies in the traditional

? In the model I'm familiar with, it's one of the more frequent operations.
RTSP is fine for setting up streams and working with them - but I'm not sure
that extending it to modifying the resources on the original servers is such 
a great idea. It's surely such an incredibly site-specific copnfiguration, 
and it seems like it would be far far better implemented via HTTP or some 
other protocol. For the argument 'but not all RTSP servers will run HTTP' - 
well, they'd have to be modified to add DELETE &c, so why not modify them 
to do it via HTTP, instead?

> This seems even uglier. 

Sure, it is - but the point is that this isn't a protocol that's really
designed to do the data manipulation tasks. It should be noted that I 
don't advocate the above - but if you must do it via RTSP, you can.

> At least with an explicit command, the client

But how would a client determine if it had access rights to delete a 
message? So you'd need to extend DESCRIBE to work out what access you 
had for a particular resource. And then you might need to add stuff to 
allow you to change access control for a particular resource.

It seems to me like the line between what RTSP does now (record/play -
setting up streams) and things like delete/rename/modify operations on 
resources on the server is a pretty clear one. 

Anthony
-- 
Anthony Baxter     <[email-masked]>   
It's never too late to have a happy childhood.

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 13 Apr 2000 12:29:14 -0700

I think I have to side with Henning on the concept of DELETE.  We already 
have slid down the slippery slope of file management by creating the 
ANNOUNCE/SETUP/RECORD functionality.  If one has file creation in a 
protocol, I think it's necessary to have file deletion in the 
protocol.  I'm not dug in on this position, but it seems sensible to me 
(though I haven't done a lot of asking around with our RTSP implementors here).

That said, your concerns can be addressed by the proposal I made a couple 
of days ago.  Basically, RTSP can and probably should provide the bare 
minimum necessary to clean up after itself, and punt to HTTP to do anything 
beyond the basics.  Maybe my proposal wasn't so half-baked after all  :)

I firmly second Hennings distaste of "DESCRIBE 
/deleteMessage/msgid=343556432".  The protocol should say what it means, 
and mean what it says.  "DESCRIBE"ing and deletion have nothing to do with 
one another.

Rob

---

From: Anthony Baxter <[email-masked]>
Date: Fri, 14 Apr 2000 15:52:24 +1000

>>> Rob Lanphier wrote
> (though I haven't done a lot of asking around with our RTSP implementors here)

But what do ANNOUNCE/SETUP/RECORD have to do with file creation? As far
as I can see (and this is also going from the existing wording) RTSP is
for setting up streams. ANNOUCE/RECORD is for setting up a stream or streams
from the client to the server. I don't see anything about it specifically
addressing creation of a file. 

> beyond the basics.  Maybe my proposal wasn't so half-baked after all  :)

Ok, so what's wanted is a way to say 'actually, no, that Record operation
I just did was a mistake, please undo whatever permanent changes were made'?
In that case, couldn't a similar operation apply for DESCRIBE/PLAY?

As far as your "half-baked" idea - it's not too bad as a general idea.
This would be a way of saying 'hey, give me the HTTP reference for this
thing'. Could/should this be passed back in the 201 reply to a RECORD? 
That seems like the neatest solution.

> and mean what it says.  "DESCRIBE"ing and deletion have nothing to do with 

Oh, absolutely - I don't advocate it at all. I was trying to make a point,
(obviously, I made it badly). Using RTSP for control of resources on the end
systems just seems like taking it in a new direction. 

Anthony

---

From: Dave Singer <[email-masked]>
Date: Fri, 14 Apr 2000 12:32:20 -0700

>That seems like the neatest solution.

This issue also comes up with caches;  please tell me a reliable 
(e.g. HTTP) way to get to this content, and its type (i.e. now a file 
type, rather than stream types).
-- 
David Singer
Apple Computer/QuickTime

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 17 Apr 2000 11:12:01 -0700

>addressing creation of a file.

I urge you to go back and read the spec.  There's all sorts of discussion 
of RECORD as a file creation method.  RealNetworks' primary use of 
ANNOUNCE/SETUP/RECORD happens to not have much to do with actually putting 
bits to disk (it's used for hooking up a live encoder, though if the live 
archiving feature is turned on, a file is created).  However, there's a lot 
of language in the spec that assumes that file creation is going on (the 
presence of a "250 Low on Storage Space" response, the VCR analogies 
throughout, the fact that the method is called "RECORD" and not "LISTEN" or 
"RELAY").

I'm going to let the people who really want this method argue for it from 
here on out, since I'm not particularly wedded to it.

Rob