Subject: RE: RTSP End of Session message

From: Eric Fleischman <[email-masked]>
Date: Tue, 3 Jun 1997 08:35:05 -0700

> Bruce Butterfield wrote:
> 
> >Any transport I could conceive of would have a mechanism to pass
> >information about the data it contains as well as the data itself. I
> only
> >mention RTP because it is the baseline transport supported by RTSP.
>  
The job of a transport protocol is to convey user data, not interpret
that data.

> >The server is always able to initate a TEARDOWN for whatever reason,
> as is
> >the client. 
> 
The RTSP spec currently does not permit the Server to teardown a session
or take any initiative (except for the REDIRECT method), no matter how
great the provocation or confusing the miscommunication. (Please see
Table 2 in Section 9.0.) At a minimum the spec should be enhanced to
permit the Server to be given the ability to initiate a session
TEARDOWN.

>My point is that the client is the only participant that has
> >enough information to handle 'last packet' notification which is (of
> >course) sent by the server. It is certainly welcome to timeout, for
> >example. My point is that the control channel is inappropriate for
> flow
> >control mechanisms. Why muck up the spec with transport-dependent
> >idiosyncracies?
> 
There seems to be some confusion here: Nobody has been talking about
flow control. 

I also haven't been talking about "last packet notification".  I have
solely been talking about "end of data transmission notification" for
events where there was no previously announced end time or the
previously announced end time was modified for some reason.

> >If you mean that the spec needs to enhance the state machine to
> include
> >exception handling, I don't disagree. Any proposals?
> 
My proposal is that certain events (i.e., end of data transmission,
initial miscommunication between client & server) should be permitted to
cause the server's State machine to switch from "Playing" to "Ready". 

Specifically:
Should the presentation data stream end in an unanticipated manner, the
Server's state should switch from "Playing" to "Ready" and the server
should send the client a Status method informing it of the transition.
Should the client wish to inquire after the Server's current state, then
the client can send the server an Status method. Thus, the proposed
Status method has two different meanings, depending on who sends the
message: if Server, it's a notification of current Server state. If
Client, it's an inquiry concerning the current Server state.

Admittedly this adds extra complexity into RTSP. Thus perhaps the group
would favor the alternative to continue to let the session "hang" once
the data transmission has ended or else define some timeout mechanism??
But in any case, the Server needs to be given the ability to do a
TEARDOWN should the communication become hopelessly muddled.