Subject: [MMUSIC] RTSP: Connectionless vs. connection-based

From: Rob Lanphier <[email-masked]>
Date: Thu, 16 May 2002 16:02:22 -0700 (Pacific Daylight Time)

Hi all,

Currently, the RTSP specification says this about the RTSP connection:

   There is no notion of an RTSP connection; instead, a server maintains
   a session labeled by an identifier. An RTSP session is in no way tied
   to a transport-level connection such as a TCP connection. During an
   RTSP session, an RTSP client may open and close many reliable
   transport connections to the server to issue RTSP requests.
   Alternatively, it may use a connectionless transport protocol such as
   UDP.

Many operational RTSP clients and servers do treat the underlying TCP
connection as a significant factor.  We've had several conversations to
date about this, mostly on the RTSP telecon:

http://rtsp.org/2002/telecon/minutes23Jan.html#line90
http://rtsp.org/2002/telecon/minutes17Apr.html#section3.9

...and it's currently listed as issue 477427 on SourceForge:
http://rtsp.org/bug477427

Here's the proposed resolution:
    Define header and response for non-persistent connections.
    Default is connection-oriented, and connectionless MAY be implemented.
    Look into SIP "supported" header (defining a feature tag for
    connectionless operation)

In the recent telecons, we've decided that this is an important issue to
highlight to the group.  So, any additional thought on this?

Rob
-- 
Rob Lanphier, Program Manager -- Interoperability, RealNetworks
http://realnetworks.com http://rtsp.org http://interop.real.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Sergent <[email-masked]>
Date: Thu, 16 May 2002 18:12:22 -0700

> highlight to the group.  So, any additional thought on this?

Some thoughts (no claims on these being anything more than thoughts):

We should be sure to not go down any slippery slopes with respect to
the importance of the Session header on connection-oriented RTSP, so
that servers which currently implement "connectionless" RTSP and do not
attach significance to connections do not suddenly fall out of
compliance.

I do agree that it would be nice for the server to get explicit
information as to its expectations for connection lifetime.  Right now
the Sun server has various heuristics to keep the connection alive so
that clients which expect connection-oriented behavior are not
disappointed by the loss of the connection while streams are playing.

We should also address the issue of multiple sessions on one
connection.  I don't know what the right way to do this is.  The two
issues are somewhat related.

I also wonder if the default should be connectionless to preserve
compatibility with RFC 2326... we wouldn't want a client which thinks
it can drop the connection safely due to RFC 2326 breaking with a "new
RTSP" server which assumes by default that when the client closes the
TCP connection that it can tear down the playing stream.  (But maybe
this isn't an issue if we signal things right; I'm not sure.)

--jss.