[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP: Connectionless vs. connection-based
Hi
At yesterdays telecon this issue was again brought up. I will here state
what I believe was the conclusions of the discussion. However the issue
not settled yet, and more comments are welcome.
First I would like to redefine the usage of terms here. I don't believe
the use of connectionless and connection-based is really describing what
we are discussing. So I will here define some terms that I will use in
the discussion below.
Connectionless transport: This is a transport layer that does not have a
notion of a connection, i.e. no establishment and later teardown on the
transport layer. The protocol we have today has these properties are UDP.
Connection-based transport: Transport over a protocol that has a
connection establishment. The protocol defined to be used with these
properties are TCP.
As Connection based transport can be used a bit different i would define
two use cases for TCP:
Persistent TCP: A TCP connection to a RTSP server that is maintained for
transport of several request and response messages. Ultimate the
connection can kept for all communication between the client and server,
even for the setup and teardown of several sessions.
Non-Persistent TCP: A TCP connection is only utilized for the exchange
of one request/response and then closed.
For maximum interoperability towards older clients and greatest
flexibility the servers needs to support both persistent and
non-persistent TCP. There is no need to define any as default. What
should be written in the updated specification is the pro and cons of
the two choices.
The specification should clarify how the non-persistent is working. This
involve the important fact that the network connections needs to be
decoupled from the session. A client which closes the TCP connection
shall not result in the loss of the session. The session is kept alive
until the session times out or is torn down. The time-out expires after
a given time, default 60 seconds, without activity. The server should
never close a connection unless the session times out, even not after
teardown of the session.
The session can be kept alive in several ways. Below is a list of things
that should reset the session timer:
- Any RTSP message with the sessions ID. A list in order of preference
of use should be established: Ping, Options with session header.
- RTCP messages from the client for the RTP sessions attached to the
session's media streams.
- The TCP connection if it has keep alive messages verifying that
connectivity exist. (I am a little doubting about this. This may not
show an application failure correctly)
My point is that persistent TCP is actually a special case of
non-persistent, and if a server implements non-persistent correctly it
will work fine when the client do not close the TCP connection.
And then some direct comments to the statements below.
Jonathan Sergent wrote:
>On Thu, May 16, 2002 at 04:02:22PM -0700, Rob Lanphier wrote:
>
>>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?
>>
>
>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 agree that we should preserve interoperability and require server to
implement non-persistent operations.
>
>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.
>
It would of course be possible to create a feature tag for persistent
connections, but are they really needed. With correct separation between
connections and the session it does not matter. What is important is the
session time-out and keeping it from timing out. With servers supporting
non-peristent is does not matter what the clients expect, they simple
use what they desire.
>
>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.
>
Yes, some clarifying text on this should be created. My personal view is
that it is allowed. All message related to a session will carry the
session id, otherwise it is directed to the server in general. Therefore
nothing in the protocol that I know of prevents it.
>
>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.)
>
I agree and therefore non-persistent connections need to be supported.
Regards
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic