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

[Jeremy Worley <jworley@real.com>]

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.

>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.

Regards,
         Jeremy


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic