Subject: New version of RTSP draft

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 21 Feb 1997 17:58:47 -0500

A new draft of the RTSP specification is now available as PostScript at
http://www.cs.columbia.edu/~hgs/rtsp/draft/rtsp.ps

This will be submitted as an I-D in the next few days (after
ASCIIfication).

The draft raises a number of questions for discussion. The authors look
forward to discussion and comments (on the confctrl mailing list or
privately, if needed).

Henning

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

---

From: Jeff Smith <[email-masked]>
Date: Sun, 02 Mar 1997 15:27:39 -0800

A few meta-level comments and questions before I dive in deeper...

Regarding recording facilities: 
- who decides the name to be used for the stored stream in a record
request?  as written it appears that it is determined by the
requesting party.  Similar to HTTP PUT and POST it would seem
necessary to have the ability for the server or the client to specify
the abs_path or the URL.
- SETUP seams to be for "setup stream" so I'm not sure this would be
the proper place, but it is the request required before RECORD

PAUSE:
- can PAUSE indicate an SMPTE or Absolute Time stamp?

Along the same lines:
- a PLAY range will result in which? the server going to PAUSE at end
of range or CLOSE at the end of range?

js

--
 Jeffrey D. Smith
 Nippon Telegraph and Telephone Corporation   
 Multimedia Communications Laboratories
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 new-pgp-fingerprint: 2F 95 88 54 C1 FB 75 25  BB 71 FC 8A 85 49 18 C2
 old-pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Mar 1997 08:29:45 -0500

> A few meta-level comments and questions before I dive in deeper...

Thanks for the comments.

> necessary to have the ability for the server or the client to specify

I'm a bit confused by this statement, since the request URI in a RECORD
would seem to be equivalent to that in a PUT (not POST, since POST
specifies the URI that "handles" the content of the request).

> - can PAUSE indicate an SMPTE or Absolute Time stamp?

This would seem desirable for editing, right?

> of range or CLOSE at the end of range?

PAUSE would seem to make more sense.

---

From: Jeff Smith <[email-masked]>
Date: Mon, 03 Mar 1997 06:09:10 -0800

|Jeff Smith wrote: (indicated by |>)
|> 
|> A few meta-level comments and questions before I dive in deeper...
|

Hennings comments (indicated by |)

|Thanks for the comments.
|
|> 
|> Regarding recording facilities:
|> - who decides the name to be used for the stored stream in a record
|> request?  as written it appears that it is determined by the
|> requesting party.  Similar to HTTP PUT and POST it would seem
|> necessary to have the ability for the server or the client to specify
|> the abs_path or the URL.
|
|I'm a bit confused by this statement, since the request URI in a RECORD
|would seem to be equivalent to that in a PUT (not POST, since POST
|specifies the URI that "handles" the content of the request).

Exactly.  But I also want the case where the server decides the URI
similar to POST where a client would request to record streams for a
project that has a URI (known to the user/application specific to the
project) and the server would respond with the complete URI to be used
for the to-be-recorded session.

|
|
|> - SETUP seams to be for "setup stream" so I'm not sure this would be
|> the proper place, but it is the request required before RECORD
|> 

|> PAUSE:
|> - can PAUSE indicate an SMPTE or Absolute Time stamp?
|
|This would seem desirable for editing, right?

Yep.

|
|> 
|> Along the same lines:
|> - a PLAY range will result in which? the server going to PAUSE at end
|> of range or CLOSE at the end of range?
|
|PAUSE would seem to make more sense. 

So I thought, just wanted to clarify.

|
|> 
|> js
|> 
|> --
|>  Jeffrey D. Smith
|>  Nippon Telegraph and Telephone Corporation
|
|-- 
|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
|

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Mar 1997 09:31:15 -0500

> for the to-be-recorded session.

The problem is that with SETUP, you don't know yet whether you will be
recording or playing back or both.

Would it be sufficient to have the server decide whether to store this
at the request URI or at another one, to be returned via the Location:
header (as in POST)?

> |This would seem desirable for editing, right?

Added to the document.

> So I thought, just wanted to clarify.
Clarified in the document.

---

From: Jeff Smith <[email-masked]>
Date: Mon, 03 Mar 1997 06:41:18 -0800

|Jeff Smith wrote:
|
|> |I'm a bit confused by this statement, since the request URI in a RECORD
|> |would seem to be equivalent to that in a PUT (not POST, since POST
|> |specifies the URI that "handles" the content of the request).
|> 
|> Exactly.  But I also want the case where the server decides the URI
|> similar to POST where a client would request to record streams for a
|> project that has a URI (known to the user/application specific to the
|> project) and the server would respond with the complete URI to be used
|> for the to-be-recorded session.
|
|The problem is that with SETUP, you don't know yet whether you will be
|recording or playing back or both.
|
|Would it be sufficient to have the server decide whether to store this
|at the request URI or at another one, to be returned via the Location:
|header (as in POST)?

Sounds reasonable, with the default behavior of no URI submitted by
client resulting in the server generating a URI?

js

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 5 Mar 1997 16:16:52 +0200 (EET)

> This would seem desirable for editing, right?

Probably it's also useful for insuring that a subsequent request to resume
starts at the proper place even if there is considerable latency between
the client sends PAUSE and the time when the server gets to processing the
request.

> PAUSE would seem to make more sense. 

Another meta-level question from me: How about having the server remember
ranges and start the next if one exists?

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>

hes' of the kind
described above?

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>

---

From: Jeff Smith <[email-masked]>
Date: Wed, 05 Mar 1997 06:27:54 -0800

|On Mon, 3 Mar 1997, Henning Schulzrinne wrote:
|
|> > PAUSE:
|> > - can PAUSE indicate an SMPTE or Absolute Time stamp?
|> 
|> This would seem desirable for editing, right?
|
|Probably it's also useful for insuring that a subsequent request to resume
|starts at the proper place even if there is considerable latency between
|the client sends PAUSE and the time when the server gets to processing the
|request.
|
|> > Along the same lines:
|> > - a PLAY range will result in which? the server going to PAUSE at end
|> > of range or CLOSE at the end of range?
|> 
|> PAUSE would seem to make more sense. 
|
|Another meta-level question from me: How about having the server remember
|ranges and start the next if one exists?

I'm not sure what you mean here... cue up a list of ranges that you
would like to play and have the server stream them in succession?

|
|Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>
|
|

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 5 Mar 1997 17:25:52 +0200 (EET)

> would like to play and have the server stream them in succession?

Indeed. But so that even though playback may be in progress, doing a PLAY
with a certain play range would just add to the cue list. 

This is again about the network latencies. If the client wants to move to
a new point in a representation, loop a particular spot or whatever, then
just telling the server what to do would cause the network latencies to
mess up the coherence of the incoming data stream. The server wouldn't
necessarily seem to react to the requests fast enough. But if the client
knows in advance what to show, a dynamic cue can be constructed. In this
case the server instantaneously knows where to continue when a particular
PLAY range ends. If one is willing to give up the 'server liveliness'
test, then a PLAY without a range could be used to advance the cue list.
All this would fit in the protocol fairly nicely as the protocol already
has some server state. 

But remember, this is truly a meta-level question. The idea may not be
coherent enough to warrant addition to the protocol.