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...) 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 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. Regards, thomas zeng, packetvideo corp. 10350 Science Center Dr., Suite 210 San Diego, CA92121 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Thursday, June 27, 2002 12:21 AM To: Jeremy Worley Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based Hi Jeremy, See my comments below. Jeremy Worley wrote:Magnus, Jonathan, At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:It's probably worthwhile to allow either the client or the server to request a "persistent connection" on a session with a feature tag that tells the other end to not shut down. This feature tag, in addition to what has been proposed before, could also enforce a 1:1 session-connection binding for the session and connection in question. If the client sent it to the server, it would tell the server to make the session and connection timeouts the same, and to always shut down the session if the connection goes away. It would also tell the client not to shut down the connection during the middle of the session. The server should be able to ask this of the client independently of whether the client has asked it of the server. The server might want to request this if a clustering system was in use where the client might be reconnected to a different server. So it should be able to tell the client "if you hang up the connection, I am going to terminate your session.I'm inclined to agree with Jonathan that a feature tag is desirable. If a server can choose to terminate the RTSP session, forcing the client to reconnect to send a message, then there are cases where the cost of reconnect may be too high. For example, a general purpose RTSP server on the internet and a client on a high-latency network. The server on the internet may be configured to not maintain persistent sessions by default, assuming most sessions will be over low latency links. The client, being on a high latency network, would prefer a persistent session. In this case, signalling a preference for a persistent RTSP session could be beneficial.There may also be cases where the server would want to signal this.Yes, I agree with the motivations you give above. However I don't see how a feature tag will help. The problem of when the server shall close the connection and recover the resources related to the connection still remains. If the client sends a feature tag saying it want to have a persistent connection and then the server receives no messages. When are the server going to close the connection, 1 min, 30 min, 1 hour, 1 day, or never? To solve this problem I suggest that the server shall not close the a connection unless at least the RTSP session time-out has passed without traffic. See text proposal for a section 9.3 in mmusic message: http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00681.htm l If the server does not close unless a RTSP time-out time has passed the client has the choice to keep a persistent connection. It simply has to maintain it by sending a message normally at least every 60 seconds, these messages can also be used to keep the RTSP session alive. Otherwise I don't see a reason to make a tight binding between the transport connection and the RTSP session.I don't know that having a feature tag for this will be useful. As far as I understand it neither side can really commit to having the connection open. Therefore it feels much more robust to assume that a client is free in its usage of persistent and non-persistent connections, and can at any point close a connection.I don't understand why neither side can commit to having the connection open. I think that if both sides agree to a persistent connection, then defining rules for coupling of RTSP and RTP sessions should be OK.As I point out above a server can never trust its clients to never foul up. Therefore a mechanism must exist that allows the server to reclaim the resources dedicated to the client. This mechanism must give the client flexibility to in a simple fashion choose between persistent and non persistent connections. Also we are not discussing coupling of a RTSP session to RTP sessions, which are coupled after setup of media transport over RTP. What we are discussing is how the transport protocol transporting RTSP requests, especially TCP, relate to the RTSP session. 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: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic