Subject: RE: RTSP End of Session message

From: Eric Fleischman <[email-masked]>
Date: Mon, 2 Jun 1997 13:57:07 -0700

I can't see this as a transport issue. Even if it were, since
RTSP-controlled multimedia data can purposefully be carried over
numerous transports in addition to RTP, extensions to RTP would not
address the problem.

As things stand with the current RTSP spec version for this scenario,
the client doesn't know when the last packet has been received. The only
thing the client knows is that it is no longer receiving data -- not why
that is so. There is no mechanism (e.g., STATUS method) for the client
to inquire as to why the server isn't sending data. There is no
mechanism for the server to tell the client (e.g., a Server initiated
PAUSE method with a Status Code of End of Session) that the session is
over. There is no indication in the RTSP state machine as to what the
proper state for this possibility should be (logically one should expect
the server to enter the Ready state once the session ends since it is no
longer in the Playing state -- but the state machine does not address
this possibility). Nor can one even assume that a TEARDOWN should be the
next logical method, especially if we're talking about a "channel" of an
Internet TV station in which a new broadcast session (perhaps with
different DESCRIBE values) may be about to start momentarily. Or maybe
there was a technical problem at the broadcaster which will be
momentarily fixed...

This is what I'd like to suggest we do:
1) more complete error code info to cover these types of possibilities
(non-sequence number alignment, end of session, etc)
2) recognition that the Server will need to end some sessions should
communications with the client get hopelessly out-of-what. Thus a
client-control-only approach is not "real life".
3) recognition that certain events can only be known to the server
(e.g., end of session) and thus the server needs a mechanism to convey
this status information to the client -- and the state machine should
account for such eventualities. I would prefer that this occurs either
via the server initiating a TEARDOWN (e.g., in the "communication is
hopeless state) or else initiating a PAUSE (e.g., end of session). 

> -----Original Message-----
> From:	Bruce Butterfield [SMTP:[email-masked]]
> Sent:	Monday, June 02, 1997 1:22 PM
> To:	Eric Fleischman
> Cc:	[email-masked]
> Subject:	Re: RTSP End of Session message
> 
> I believe this is a transport issue, not a control issue. Each stream
> in a
> presentation can indicate 'last packet' (in the stream data, perhaps,
> or
> as an RTP extension). When the last stream has completed, the client
> sends
> a TEARDOWN request, or starts up another presentation. 
> 
> Typically I think it should be up to the client to end a session
> because
> only it knows when the last packet has been received. Out-of-band
> control
> can only serve as a hint. 
> 
> Bruce Butterfield <[email-masked]>  	Phone: (206) 674-2467
> Progressive Networks			Fax:   (206) 674-3580
> Software Development Engineer - Platform Group
> 
> On Mon, 2 Jun 1997, Eric Fleischman wrote:
> 
> > Unless I've missed something, there seems to be a need to have a
> > mechanism available for the Server to inform the client that a data
> > stream has ended for certain "live" events. That is, the DESCRIBE
> method
> > would usually carry this type of information for "on-demand"
> sessions
> > and live events with known ending times. However, not all "live"
> events
> > have a pre-known duration to them. In this case we need a mechanism
> to
> > have the server inform the client(s) that the session is over. How
> do we
> > do this in RTSP?
> > 
> > On another topic, I am embarassed that my last Email message got
> > involved in a mail loop. (I only sent it to the list once. Honest!)
> Do
> > we have a solution for the two questions I asked in that message?
> >

---

From: Bruce Butterfield <[email-masked]>
Date: Mon, 2 Jun 1997 14:22:42 -0700 (PDT)

> numerous transports in addition to RTP, extensions to RTP would not

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.
 
> hopeless state) or else initiating a PAUSE (e.g., end of session). 

The server is always able to initate a TEARDOWN for whatever reason, as is
the client. 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?

If you mean that the spec needs to enhance the state machine to include
exception handling, I don't disagree. Any proposals?