Subject: mapping of RTSP sessions onto TCP connections

From: [email-masked]
Date: Wed, 19 Nov 1997 00:11:20 -0500 (EST)

since the deadline for comments is ending shortly, here are my last-minute
thoughts on this issue.

suggestion: make server support for interupting TCP connection during RTSP
session optional

i think it would be a good idea to allow a server implementation that maps a
single rtps session onto a single TCP connection. The advantages allowing
that the client can interupt the TCP connection for a session (don't keep a
TCP connection while user watches a two hour video-clip, allow to "pass the
control" between different users) are valid. 

However, i think that there are quite a few applications that don't require
re-opening a session, and that there will be quite a few clients that will
never do this (since is an additional thing you have to implement, which does
not really increase the functionality of the protocol). Also, given the
http-likeness suggested by the draft, i'm pretty sure that many initial
server implementations won't implement "session-reset" (although this isn't
what the standard says, of course)

I would therefore suggest to make support for interupting/re-opening an rtsp
session at the server side optional, if TCP is used as the transport
protocol.

This could be achieved by adding a header sent by the server to the client,
in which the server tells the client that it should never interupt the TCP
connection during the session, e.g. the header "no-interupt". This header
should be added to the first message that establishes a session, e.g. the
response to the SETUP message.

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 20 Nov 1997 00:06:54 -0800

>what the standard says, of course)

My initial reaction was to actually support this (and thus reflected in my
private mail to you shortly after I got this).  However, after a few
conversations with some folks, it becomes clear that this doesn't make
complexity disappear for minimal implementations, but rather shifts the
burden from server to client, so we'll have to consider this pretty carefully.

So, let's weigh the complexity here:

If we don't change things:
  Server:  inetd-based approaches must maintain a separate "session
manager" daemon or must maintain disk-based state.

  Client:  minimal implementation must support either model.

If we do change things:

  Server:  inetd-based approaches work fine

  Client:  client MUST support persistant model, must parse new field, and
may support non-persistant model.

I think it's a wash, and given the late state of affairs, I'm inclined to
go with the status quo.  If we *must* support this, the way to do this
would probably be something like:

   SETUP rtsp://foo/bar RTSP/1.0

   RTSP/1.0 200 OK
   Session:  1234;tcpclose=teardown

...or perhaps:

   SETUP rtsp://foo/bar RTSP/1.0

   RTSP/1.0 200 OK
   Session:  1234;session-tcp-reconnect-interval=0
                   ^^^wordy as all getout (something else would be better)

...but like I said, frankly, I'd prefer to leave things unchanged.

Rob

----------------
>response to the SETUP message.
---
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Nov 1997 10:19:43 -0500

> burden from server to client, so we'll have to consider this pretty carefully.
Agreed. To amplify in more general terms:

One of the problems with creating too many overlapping subsets of
functionality is that we'll drag everybody's expectations to the lowest
common denominator (and we'll be dragged into the
X.400/H.323/name-your-ITU-standard profile and interoperability
agreement game). Supporting multiple sources of requests may underlie
many novel applications of RTSP servers (e.g., in conferencing), and
removing that ability for a slight gain in server simplicity just
hinders server interoperability in the long run. Since server
development is never going to be an afternoon's affair, I think the
traditional Internet trade-off of putting slightly more burden on the
server is the correct one.

Henning