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

[Magnus Westerlund <magnus.westerlund@era.ericsson.se>]

Hi Jonathan,

See comments below:

Jonathan Sergent wrote:

>
>Incoming connections will not use up server-side port numbers, since
>they will all be bound to port 554 (or whatever port the RTSP server is
>listening on) on the server side.
>
>There is still obviously a resource exhaustion issue if you mandate
>that the server never close the connection.  
>
>I do not know what the right behavior should be.  My gut feeling is
>that the client SHOULD attempt to reconnect to the server if it wants
>to send an RTSP command and it discovers that its connection has been
>lost.
>
I agree that the client must try to reconnect if the connection was lost.

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

>
>This way we only have tightly-coupled session-connection binding, or
>no coupling at all, rather than a continuum of options.
>
I would rather argue for always having no coupling.

>
>The easiest thing for most typical media player clients will be to
>always request the option.
>
>But one can imagine applications where this is not desirable; for
>example, a client might send PLAY with the clock field set in the Range
>header to schedule a playout at some time in the future.  This could be
>used for a scheduled broadcast.  It would be undesirable to require
>that the TCP connection remain open until the broadcast actually
>starts, which might be several hours.  So it is worthwhile to allow
>clients to not request the 1:1 session-connection mapping.
>
The problem with the application your are describing is that it still 
requires the session to be kept alive, so traffic must regular be sent 
the server during these hours.

>
>
>P.S.  The server may also decide to drop client sessions and
>connections as a load shedding activity.  It would be helpful if this
>had well-defined meaning for the client so that the server can do this
>while still complying to the protocol.  The client could be required to
>expect that the server may want to refuse service to it after a stream
>has started playing.  I am not sure how useful it is to specify
>something like this.
>
I would recommend that load balancing is done at session setup time. 
However if the server really must move a stream it should use the 
REDIRECT method. I know that we still have problems with this in respect 
to non-persistent connections and UDP.

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