Subject: RTSP: SDP usage: change a=length: to a=range:

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Nov 1997 14:56:02 -0500

Proposal:

Change the current

a=length:npt=<time>

to

a=range:npt=<start>-<stop>

Motivation:

The values can be used by the client to set the playable range (slider,
scale, whatever). This makes it very easy to create a set of SDP
descriptions for a single RTSP media object. Example: a recording on a
server for a whole conference session could be turned into a web page of
talks with a set of links like

<a href="talk1.sdp">First talk</a>
<a href="talk2.sdp">Second talk</a>

where talk1.sdp would have

a=range:clock=19971105T1600-19971105T1620

and talk2.sdp

a=range:clock=19971105T1622-19971105T1650

The server doesn't need to know about "talks" at all. (Note that the t=
parameter does not cover this, as it describes the availability of the
recorded presentation, not the time when the talk was recorded.)
-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 14 Nov 1997 08:34:25 -0800

If there's any truck-sized holes in the draft, or if there are spelling
errors, you have until Nov. 18 (Tuesday) to point them out, so that we can
make a submission prior to the Nov. 21 deadline.

The only substantive changes to the doc will be about the two issues that
Henning and I mailed about:

*  Change a=length: to a=range:
*  Allow for S->C OPTIONS

See previous emails for details on these.

Thanks
Rob
---
Rob Lanphier ([email-masked])    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall

---

From: [email-masked]
Date: Sat, 15 Nov 1997 12:16:56 +0100 (MET)

> *  Change a=length: to a=range:

	Just a comment and a suggestion about a possible new header.

	I'm afraid I've been lately too busy to follow the development
of the draft so closely as I'd like, so, if you already discussed this,
forgive me.

	I think it's fine not to need the concept of 'connection' for
the RTSP protocol and to be able to control session via different
TCP connections.
	 Nevertheless, many times, the clients are implemented
to use only one TCP connection for RTSP; at least the very simple ones,
which often finish abruptly (because implementation errors when they are
still beta versions or ar being developed; because they are too simple to
recover from the lost of the TCP connection; or because the are so simple
that the user, having difficulties to exit them easily, prefers to kill
them), leaving the RTSP server with a number of open sessions which he
will have to 'abort' sometime later (using some algorithm to determine when
the sessions can be considered 'orphan').

	I had this particular problem (well, still have :-() when
developing a new client for our server, and decided to use an
extension header that I called 'Lifetime:', that can be sent with the
SETUP method as "Lifetime: connection" to inform the server that, if
the session wasn't teardowned when the connection is closed, he can
abort it.
	I know this header doesn't mean any 'big improvement' in the
protocol; but I find it quite useful, in particular for the case of
clients that are still being developed and which may 'crash' before
having teardowned their open sessions.

	I'll keep using it anyway as extension header in our server, but
I thought you might find it useful enough to include it in the draft as
RTSP header (probably with a better name and a better explanation).

	Thanks for your attention.

-------------------------------------------------------------------
Francisco Cortes		office: F2.323
University of Paderborn		Tel.:   +49 5251 60 6704
Dept. of Math. & Comp. Sci.	Fax.:   +49 5251 60 6697
Fuerstenallee 11		email:  [email-masked]
D-33102 Paderborn, Germany
http://www.uni-paderborn.de/fachbereich/AG/monien/PERSONAL/CORTES/
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96
-------------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 15 Nov 1997 11:41:32 -0500

[email-masked] wrote:

> the session wasn't teardowned when the connection is closed, he can

See the timeout parameter for the Session: header.

---

From: [email-masked]
Date: Sun, 16 Nov 1997 18:09:23 +0100 (MET)

> See the timeout parameter for the Session: header.

	The timeout parameter for Session is an other way to
cope with orphan sessions, but its has a quite different
'orientation'. It has to be sended by the Server, and forces the
client to send an 'I'm still here' periodically, what I don't like
to much (especially with a 60 sec. default).

	The timeout parameter is a nice way to deal with orphan
sessions (caused by faulty clients, or any other reason), and
given that its meaning should be something like 'After this time
I'll assume you are dead' I think that it should be used with
care.

	The kind of header I meant, the 'Lifetime:' I'm using,
is more like a "client's intentions declaration". Something like:
'If we lost contact, you must assume I'm dead', ... or you can
define other values for the header like XXXX= 'I will often close an
reopen our conntact, please, be patient and try to keep my sessions
as long as possible' ...  (which could influence the server decission about
the value given to 'timeout').

	One of the nice advantages I find from having none
TCP-connection/Session relationship, is that it allows to spare
connection resources. A user might want to see a movie, then its client
program opens a connection to the server, sends the setup messages and
a play and close the connection until the user decides to stop watching
the movie or to 'play' with the remote control. Short timeouts force
the client programm to either keep the connection open, or to reopen
it periodically, and to resend "I'm here"s for each open session;
... this can be necesary in some situations, but I would
give the client the posibility to inform the server about what kind
of behavior he has so that the server can modify that 'timeout' parameter
acordingly.

	Well, ... anyway... it is just a suggestion. You have already
experience with the protocol to judge if its useful or if your
implementations can be happy with only 'timeout'.