Subject: More RTSP suggestions

From: Sean Sheedy <[email-masked]>
Date: Wed, 13 Sep 2000 10:29:11 -0700

A few more suggestions for the RTSP draft:

   * Clients often want to know the location in a presentation at which
     a PAUSE occurred.  The spec should recommend that servers return
     the paused location with a Range header in the PAUSE reply.  (I
     vaguely recall that this may have been brought up earlier.  My
     apologies if this one has already been covered.)

   * Large installations with customized servers and clients often want
     to use some deployment specific error codes.  The spec should
     reserve some error codes (for example, 490-499 and 590-599) for
     deployment specific errors.

   * Response code 100 is included in the spec, but no details are
     provided about how it should be used.  Should clients and servers
     use it in a manner analogous to that defined for HTTP/1.1?  If so,
     this should be explicitly called out.  Personally, I would prefer
     it be removed entirely.  I don't think HTTP/1.1 type behavior is
     required for RTSP, and would complicate implementations.

   * Sometimes authorization data (such as encryption keys) for pieces
     of content needs to be exchanged between client and server during
     SETUP.  I've seen several approaches to doing this:
        o In separate headers
        o As part of the Transport header
        o In a message body on SETUP
     Recommendations about the preferred approach would be helpful.  I'm
     not sure that this belongs in the RTSP spec, however.  Maybe a
     separate document?

Sean

--
Sean Sheedy                                         [email-masked]
(503) 531-6427

---

From: [email-masked] (Ron Frederick)
Date: Wed, 13 Sep 2000 11:35:32 -0700

>      apologies if this one has already been covered.)
This could be done in the PAUSE reply, but I'd actually rather see this
done as a general "stream done" message of some kind that gets sent whenever
the server transitions from the Playing state to the Ready state, or when
it transitions from playing one segment to another during queued PLAY. This
message could be used to deliver not only the URL and range that just finished
playing but also RTP-Info for RTP streams saying where the boundary was
in sequence number and timestamp between this data and the next (if any).
This seems much cleaner to me that what clients typically have to do now,
where they just assume the server has stopped playing after the amount of
time a play request corresponded to has elapsed.
--
Ron Frederick
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2000 19:42:11 -0400

> time a play request corresponded to has elapsed.

My major concern is that server-to-client messages should be used very
sparingly, since they may not work in firewalled networks. Another
problem is to make sure this is somehow synchronized with the playout.
How useful is it to know that 30 seconds ago, a transition happened,
after RTP packets for the new segment have started to arrive?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: [email-masked] (Ron Frederick)
Date: Wed, 13 Sep 2000 17:43:58 -0700

> after RTP packets for the new segment have started to arrive?
I'm not sure I see the firewall issue here, unless you are using UDP for
the RTSP messages (in which case getting _any_ replies back might be hard,
not just server to client messages). With TCP, as long as the client keeps
the connection open, it should be able to receive these messages even if
it is behind a firewall.

As for synchronization, there's no reason to believe that there would be
any significant delay in the delivery of the message in the typical case.
We already rely on this in the reply to "PLAY" messages -- some clients
need the "RTP-Info" information contained there and depend on having that
before the data packets start arriving (at least ideally). Given that this
stream done message isn't present now, it's likely clients will have to
treat it as a hint, meaning they'll still work if it doesn't arrive.
However, if it does arrive, they'll be able to do things like update their
UI to show that the stream has stopped playing (or which segment is playing)
without having to estimate based on total playout time.

In the specific case of queued PLAY, I still haven't gotten back a good
answer to how one is expected to return proper "RTP-Info" with the way the
spec is written right now. However, with the approach I described here, a
server and client can do the same thing for queued PLAY that they do right
now for playing the initial play spurt. The data will be delivered to the
client just before the server begins sending the packets from a new play
spurt (either in the initial PLAY reply or in one of these new messages),
and the client code can treat the two cases similarly.
--
Ron Frederick
[email-masked]

---

From: Dirk Pranke <[email-masked]>
Date: Wed, 13 Sep 2000 18:40:20 -0700

> the connection open, it should be able to receive these messages even if

The problem is the "as long as the client keeps the connection open" part ...
right now, RTSP will work just fine with the server allowed to drop the
connection at any time it's idle. Requiring the server to keep the connnection
open may increase the burden on servers and firewalls in an undesirable way,
but I don't claim to be an expert to know if this is an issue for sure.

> without having to estimate based on total playout time.

I would agree that as long as you not trying to replace in-band, synchronized
notificant, then the delay is probably acceptable. But, this could be done
through a liveness ping to the server as well ... "hmm, I haven't gotten any
data in a while, let's see what's going on". I should point out that Oracle's
RTSP extensions do include callbacks for these situations, so I'm not really
arguing against them.

> and the client code can treat the two cases similarly.

Hmm, I'm not sure if I agree with this, because this sounds like it gets
dangerously close to needing in band notification to me ...

-- Dirk

Dirk Pranke
Oracle Interactive Television Division