Subject: RE: RTSP End of Session message

From: Eric Fleischman <[email-masked]>
Date: Wed, 4 Jun 1997 08:30:16 -0700

RTSP, as currently defined, is a client-oriented protocol. I'm not
arguing against that orientation. I am merely saying that the current
definition has some pretty significant problems which could be
alleviated by a number of mechanisms. The mechanism I personally prefer
is to give the Server an ability to notify the client about "Events".
Such a use would be consistent with your "used sparingly" advice.

Concerning other points mentioned within this thread: If the data
channel is unreliable then you're probably not going to get a 'FIN' or
'last packet marker' any better than you'd get it on an unreliable
control channel.  

Another important point concerns what happens when you have multiple
unreliable data streams managed by one RTSP session.  Data could
arbitrarily stop coming from any of the streams for any number of
reasons (which need not have anything to do with network problems) and
since the client could not be guaranteed to have reliably received the
'last packet marker' on those streams, we have an opportunity for
confusion. Did the stream temporarily stop (e.g. there is currently no
audio data because no one is talking)?? Is there a problem with the
connection?? Should the user just "time out" and assume the stream has
completed erroneously??  Easily panicked individuals may react in many
undesirable ways to such a scenario -- how much better to be able to
provide an alert from server to client to "clue them in". Even so, the
case which scares me much more is to continually waste server resources
because an automated client which was writing the session to a disk did
not have the intelligence to issue a TEARDOWN when the session actually
ended.

Regardless, this discussion points out the need to have reliable control
protocol that can inform the client when the session is completed. While
RTSP can indeed be carried unreliably as per the spec, it seems most
unwise to forego the advantages of building in reliable functionality
for the large number of implementations which can use reliable
transports for RTSP controls.

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Tuesday, June 03, 1997 5:46 PM
> To:	[email-masked]
> Subject:	Re: RTSP End of Session message
> 
> 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 23:01:50 +0200 (MET DST)

Eric,

I agree, if we had the choice between a reliable control protocol with the
possibility of server-client-events and an unreliable protocol that might
or might not have this possibility I would definitely vote for the
reliable solution. Your points are very correct but I'm asking myself
weather this is not an issue that would have a rather strong influence on
the current specification and would lead to quite a different application
scenario. 

We actually implemented such a protocol to control an RTP DataPump 
that can record and playback RTP data streams. I thought about using 
RTSP as control protocol but soon realised that it won't give me the
functionality I wanted. We even have two connections for our control
protocol, one for stream control commands and return messages and one
for events from the server back to the client. We use two connection
because the events can happen totally asynchronous and therefore only 
one connection would make the event handling much more complicated.

Again, I'd prefer a reliable solution with server-client-events but
I'm not sure if this wouldn't drift to far away from the original
target scenario of RTSP.

-- wieland

---

From: Anders Klemets <[email-masked]>
Date: Mon, 11 Aug 1997 13:12:43 -0700

I am catching up with some unread mail and came across this old thread.
There have been at least three different proposals for how the end of
the stream can be indicated to the client.

1) A timestamp in the presentation description
2) Reliance on the RTCP BYE message
3) Use of the RTSP TEARDOWN message

Unfortunately, I don't think any of these solutions are good enough.  I
will explain why.  I would like to rephrase the problem as follows: "The
client needs to know when the last _packet_ of a stream has been
received."

The word "packet" is very important here.  Somebody suggested that a
special end-of-stream indication was only needed for live streams, and
not for pre-recorded streams.  The presentation description of a
pre-recorded stream could contain the NPT (timestamp) of the last
frame.  (Proposoal #1.)  A problem with this is in some cases a frame
may span multiple RTP packets, and those packets would all have the same
RTP timestamp.  (Large video I-frames, for example, may have to be split
into multiple RTP packets.)

For some applications, a rough end-of-stream estimate may be
sufficient.  A couple of packets more or less may not matter.  But other
applications may have more stringent requirements.

Thus, I don't think we can say that the timestamp of the last frame is a
sufficiently precise end-of-stream indication.  The sequence number of
the last packet cannot be specified in the presentation description,
because the exact packetization may not be known ahead of time.

It has been suggested to use the RTCP BYE packet to indicate the
end-of-stream condition.  (Proposal #2.)  I don't think this is
appropriate to overload the semantics of the BYE message in this
manner.  BYE is supposed to mean that an RTP source has left the RTP
session.  The client may still want to rewind the stream or seek to the
beginning and play the stream again.  Thus, it would be wrong for the
server to leave the RTP session just because the end of the stream has
been reached.  In addition, the RTCP BYE message does not include the
sequence number of the last RTP packet.

Yet another proposed solution is to have the server send a TEARDOWN
message to the client when the end-of-stream has been reached.
(Proposal #3.)  Again, this has the same problems as the RTCP BYE
message.  The original semantics of TEARDOWN is that the RTSP Session ID
is no longer valid.  I does not seem right that the Session ID should
become invalid when the end-of-stream is reached.  Because then the
client would be forced to issue a new SETUP command in order to rewind
the stream, or to play it again.

So, we need to come up with a better solution.  I don't claim to have
the right answer, but something that would certainly work for me is to
have the server send a new EOF method.  Like this:

EOF rtsp://server.com/foo RTSP/1.0 123
Transport-Info: lastseq=3453545

Anders
--------
[email-masked]        VXtreme, Inc.        "Expect Motion ..."

---

From: Anders Klemets <[email-masked]>
Date: Mon, 11 Aug 1997 15:42:30 -0700

The RTSP draft says that if a PLAY command does not have a Range header,
it means that the server should start playing from the beginning of the
stream or resume playing if it was previously paused.  But there is a
scenario where the behavior of the PLAY command is not at all obvious
without a Range header.

Consider the case of a live event that is also being stored on the
server and is being unicasted to the clients.

When a client joins such a live session, it must send a PLAY command in
order to receive data, because data is sent point-to-point to the
clients.  Sometimes a client may want to play the live stream all the
way from the beginning.  This is not a problem, because the server is
recording the live stream.  

More often, however, the client may want to start playing from the "live
offset", or "time t=Now".  This is essentially the same as sending a
PLAY command with the Range header giving the timestamp of the end of
the stream that the server has recorded.  The problem is that this
timestamp is constantly changing, as new data is being added to the
stream all the time.  Thus, since this timestamp is not constant, it
would be better to represent it with a logical name, rather than a
numerical value.

One way of doing it would be to reserve the word "now" (or "eof") for
this timestamp.  Here is how the client would tell the server to send it
the newest and freshest data it has:

PLAY rtsp://live.com/video RTSP/1.0 123
Range: npt=now-

As usual, the response to the PLAY command will contain a Range header
with the timestamp that the server is actually using.

Another way around the problem would be for the client to use its
current UTC time as the starting point, e.g.:

Range: clock=19970811T223015.25Z-

But this is not really a desirable solution.  We know there is no
guarantee for clock synchronization and the RTT between the client and
server may not be neglible.

Yet another way around the problem is to say that for live streams, a
PLAY command without a Range header is equivalent to "npt=now-".  We
assume, I suppose, that the client knows that it is dealing with a live
stream through the presentation description.  Otherwise, it would not
know when to include the Range header and when not to.

By the way, for pre-recorded streams, clients will typically need to
know the total "Range" of a stream expressed in NPT units.  This is
needed in order to display a seek bar or "progress indicator".  The
client will also need to know whether the stream is seekable, and
whether Rewind and Fast-Forward is supported, etc, _before_ it actually
tries any of those commands.  I really want the client GUI to properly
reflect which actions are available right from the beginning.  I suppose
this information has to be part of the presentation description, since
RTSP has no intrinsic support for it.  Please correct me if I am wrong.

Anders
--------

---

From: David Oran <[email-masked]>
Date: Tue, 12 Aug 1997 20:56:57 -0400

I may be completely off in left field, but it strikes me as wierd and a bit
unnatural to treat the live event and the recorded version as the same stream.

What's wrong with treating these as separate RTSP sessions?

>[email-masked]        VXtreme, Inc.        "Expect Motion ..."
-----------------
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]