Subject: RTSP Feature Tags RE: [MMUSIC] RTSP: Connectionless vs. connectio n-based

From: Thomas Zeng <[email-masked]>
Date: Wed, 10 Jul 2002 14:18:24 -0700

Dear MMUSIC:

During the discussion of persistent-connection vs connection-less operating
modes of RTSP,  
it has become clear that  some relevant feature tags in support of
capability probing should be defined 
(see attached email for background). Here are draft definitions of  two of
them. Your comments are quite welcome.

ping-b4-session-timeout
ping-b4-connection-timeout

1. Option Tag For RTSP:   "Ping Before Timing Out RTSP Session"

- RTSP Feature Tag Name:
   ping-b4-session-timeout

- Summary of the RTSP Features Indicated By This Feature Tag:
   
     This feature tag is intended as part of the RTSP base specification.
This feature tag is only to be used by an RTSP server, 
   and only when operating in "persistent-connection" mode (see [RFC2326
sec. 9]).

     Normally RTSP clients are responsible for "keep-alive" RTSP requests in
order to prevent server from removing the RTSP session
   due to RTSP timeout (see [RFC2326 12.37]). An RTSP server may use this
feature tag to tell its client that it will always ping the 
   client with an RTSP message before removing the session. Conversely, an
RTSP client can use this tag to query whether 
   the server support this feature.

      If an RTSP server agrees to suport this feature, then the client does
NOT have to periodically send "keep-alive" RTSP messages
    to server, as long as the client answers to the server ping message
within the RTSP timeout as defined in  [RFC2326 12.37]. The 
    server ping message must contain the proper session ID (GET_MESSAGE RTSP
request can satisfy this requirement). This is 
    necessary when there are more than one sessions carried over one
connection. In this way the client implementation may be 
    simplified. It is then up to  the discretion of the server to decide
when to ping the client.  If the server is 
    very careful about  Denial of Server Attacks (DSAs), it may 
    ping inmediately after RTSP timeout so as to remove an inactive session
as soon as possible to free up resources.

      In any event, after the ping RTSP message, the server MUST NOT remove
the client session earlier than RTSP timeout, because the protocol is      
    that the client has up to RTSP timeout to respond to ping message.

      Note that  any client wanting to exploit this  feature MUST use a
persistent connection to the server. Otherwise the server 
    cannot reach the client.

2. Option Tag For RTSP:   "Ping Before Timing Out RTSP Connection"

- RTSP Feature tag name:
   ping-b4-connection-timeout

- Summary of the RTSP features indicated by this feature tag:
   
    This feature tag is intended as part of the RTSP base specification.
This feature tag may be used either by client or server.

       During RTSP communications, either the server or the client can drop
the connection due to lack of activity. An RTSP protocol 
    engine (either server or client) may use this feature tag to tell its
peer that it will always ping the other party with 
    an RTSP message before dropping  the RTSP connection.

       If one side agree to this feature tag,  then the other side does NOT
have to periodically send "keep-alive" RTSP messages 
    to maintain the RTSP connection. If an RTSP protocol engine  detects no
activity on the connection after CONNECTION TIMEOUT, 
    it can send a ping RTSP message such as OPTION request (which does not
need a session ID) to probe the other party, if the peer 
    answers to the ping RTSP message quickly, the connection is deemed
alive, but if no response is received within RTSP timeout (
    see [RFC2326 12.37]), then the connection can be removed. Furthurmore,
if the mode of RTSP operation happens to be the 
    persistent-connection mode, then any RTSP sessions  carried over it will
be removed as well. Magnus:

- Thomas Zeng

PacketVideo Corp,
10350 Science Center Drive, Suite 210,
San Diego, CA92121
858 731 5465

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Friday, June 28, 2002 12:04 AM
To: [email-masked]
Cc: Thomas Zeng; [email-masked]
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based

Hi Vivek and Thomas,

See my comments to both your mails inline.

Vivek Mudgil wrote:

> It has been an interesting reading this discussion on connectionless 
> vs connection-based. Logically
> it would make more sense if clients send the "I am alive" signal to 
> the server. This philosophically is in line with the concept of load 
> distribution.

Yes, I agree with you that it is a responsibility of the client to keep 
the connection alive. This would be in line with that it also is the 
clients responsibility to keep the RTSP session alive. However the 
server may of course try to ping the client before closing the 
connection. We can't mandate such a mechanism but it be a may or 
recommended. Also I do believe that  an options tag for this could be 
beneficial. That way the client will know how the server will behave.

>
> Secondly I was just wondering why can't the "persistent connection" be 
> made a default option for
> RTSP connection with a time out on server side. This passes the onus 
> of keeping the connection alive to the clients. Clients may have a 
> configurable parameter which will allow the user to decide whether it 
> wishes to work in persistent mode by periodically sending the 
> "connection alive" signal or wishes to run in connectionless mode by 
> closing the connection after each transaction. This is turn will be 
> based on delay performance observed by the user in re-establishment of 
> connection.
>
I don't want to make it default because that may result in loss of 
backwards compatibility towards non-persistent connections. To my 
understanding persistent connections is a special case of 
non-persistent. My goal is to write the specification so that makes no 
difference for the server to support both modes. The client has the 
choice to use what suits it. I do believe we are aiming for the same 
goal, let the client choose. 

> Thomas Zeng wrote:
>
>>Hi Magnus:
>>
>>In the message below you suggest that  "the server shall not 
>>close the a connection unless at least the RTSP session time-out  has 
>>passed without traffic."
>>
>>Later on you seem to imply that the onus is on the client to make sure 
>>that it sends a message (could be some keep alive message such as
>>OPTIONS) at least every 60 seconds (or according to RTSP  timeout
interval).
>>(Or did you mean
>>the server is to ensure one message every 60 seconds? It was not clear to
>>me... hence this email...)
>>
It is the client that needs to send regular keep alive messages.

>>
>>How about putting the onus on the server to ping the client when RTSP
>>session time-out
>>expires, and only kick out the client if no ping-response is receive after
a
>>"RTSP response
>>timeout" (again a negotiable value, perhaps a few seconds)?
>>
I can see the usefulness of this, but the default behavior must remain 
that it is the responsibility of the client. An options tag could be 
used by the server in a supported header to tell the client that it has 
this capability. Such a mechanism can be used for both the RTSP timeout 
and the connection timeout. Should both be included in the same tag or 
could they be separately implemented?

Thomas, could you draft a paragraph defining this for the connection to 
be included in the proposed section 9.3. I would like it to also define 
the options tag to use.

>>
>>I say because I may have thin clients that I'd like to keep as simple as
>>possible. Servers on the other hand 
>>have more leeway. 
>>

Implementing a keep alive mechanism is still required for the client. 
Otherwise it will lose the RTSP session, it can of course rely on RTCP. 
But if the code to implement a timer that sends regular connection and 
session keep alive is to much, I would recommend that this client use 
non-persistent connections. 

Best regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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