Subject: RE: RTSP End of Session message

From: David Oran <[email-masked]>
Date: Tue, 03 Jun 1997 15:48:24 -0400

Eric, I guess I find myself disagreeing with you again...sorry.

At 08:35 AM 6/3/97 -0700, Eric Fleischman wrote:
>> 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.
>
One job of a transport protocol is to "frame" data - i.e. indicate
boundaries in the data, to cover cases where the data are not
self-describing. Only the transport protocol knows for sure when the source
has run out of data and hence  
I in fact agree with Bruce that the transport is the appropriate place for
the functionality. In the case of RTP, BYE works just fine. For TCP, FIN
works just fine. This also allows the clear separation of the notions "end
of stream", and "end of presentation", and "end of session".

>> >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.
>
I'm of the religion that the client is always in control, so I like the
current behavior. It makes the state machines simpler and still allows a
server to punt if it needs to blow a client off in order to recover
resources. As an aside: there's few things more tooth-grinding to me as a
developer of distributed applications than a server which decides my buggy
client (which I'm currently debugging) is too impolite and disconnects me
while I'm trying to figure out if the bug is mine or (please tell me it
isn't so...) the server's!

>>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. 
>
The end-to-end argument says only the client application can tell if the
"last packet" is indeed such.

>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.
>
Well, I tend to leave the movie theater when the screen goes blank
(sometimes before, even :-) ). Where's the server supposed to get this
magic signal from in the first place? 

>> >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.
>
>
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Jun 1997 20:46:01 -0400

Server-to-client commands should be used sparingly since they won't work
in all circumstances. We have three transport mechanism to deal with:

(1) UDP
(2) TCP per command (or several), terminated by either client or server
after each command
(3) client (and server) keep TCP connection for whole RTSP session

With firewalls, only with (3) is the server likely to have a chance to
get back to the client. With (2), it's tricky even without firewalls
(which port does the server connect to on the client?).

Given this caveat, for case (3), a server-issued TEARDOWN seems simple
enough for live events. In many live events, however, RTSP will really
only be involved during the SETUP (to get a multicast address for a
URL-described event) and then drop the connection (case (2)). 

Given cases (1) and (2), data-stream level end-of-show notification (RTP
BYE) is necessary in any event. 

A paranoid client could, if it wants to, poll the server with PLAY or
GET_PARAMETER if it is not getting the data it is expecting. ("Hello,
hellooo, anybody home?") Not a good idea, in general, due to server
load.

---

From: Wieland Holfelder <[email-masked]>
Date: Wed, 4 Jun 1997 08:59:39 +0200 (MET DST)

> BYE) is necessary in any event. 

but how about a server that resends a session with multiple streams 
(say a rebroadcast of a meeting with multiple partcipants that joined
and left during the initial sesssion). The server needs to assign a
unique ssrc for each of these participants and an RTCP BYE message
only indicated that one of these participants left the session. The
client, however, does not know weather there is more from other recorded 
participants to come (maybe even after a period of silence). Only the
server knows.

My suggestion to workarround this is to have the server issue RTCP
messages with a master ssrc exclusively for status messages e.g in 
RTCP_SDES_NAME items. A client would never see any data from this ssrc 
but this "virtual session participant" would be alive for the entire
lifetime of a session. This ssrc would also be responsible to issue
receiver reports on behalf of all other recorded participants that 
come from this server/session. Other RTCP messages, however, should
still be generated for each recorded participant individually (i.e.
all SDES items and sender reports). Note that the server in this case 
is neither a mixer nor a translator in RTP notation, it simply issues
multiple streams. Therefore, it would probably be an overkill if the
server would let each recorded participant issue its own receiver
reports. In fact, they would all look alike anyway. Back to the 
end-of-session topic, once the master ssrc issues a BYE messages, the
session can considered to be over. Well, an open issue, however, is, 
how does the client know which ssrc actually is the master ssrc?
Maybe the rtsp session id could be included in one of the SDES
items for the master ssrc? All this, of course, is very much bound 
to RTP... but why not specify a draft defining some rules for sending 
RTP data streams controled by RTSP? 

Given the three scenarios Henning pointed out, an implicit "rtsp end- 
of-session-event" from a a server back to a client is indeed hard to
implement for all three cases, nevertheless I would also prefer such a
message whenever possible. The proper state of a server is in my opinion
more important than the state of a client. A "hanging" server could cause
confusion if it would depend on a teardown of a client and therefore a
server should be able to change from PLAYING to READY on its own and at
least try to send an "end-of-session-event" through rtsp if possible.

-- Wieland

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 04 Jun 1997 19:49:14 -0400

> how does the client know which ssrc actually is the master ssrc?

Wouldn't the simple rule "Shut down session when you haven't heard from
any source (virtual, real, imaginary, halluscinatory) for a while" do
the trick if you have virtual participants?

Henning