Subject: Re: Changes/clarifications to RTSP

From: John Carlton <[email-masked]>
Date: Tue, 11 Apr 2000 09:46:37 -0700

Hi all,

Just a quick (late) note about the proposed RTSP Extensions set forth by
Sean Sheedy in draft-sheedy-mmusic-rtsp-ext-00.txt.

For the most part the extensions are fine but there are a couple of things
that concern us.

Specifically, Section 3.1 raises a number of questions. Specifying a
different URI in a PLAY to reuse a transport does not seem like a good
idea. This was discussed in a different context between Henning, Anup and
RNWK a few weeks back and the conclusions were that this would not be added
to RFC 2326 because of the amount of coupling involved. When exactly does
this kind of inheritance work? Don't you need to at least setup the
sub-streams you want? Is it restricted to same TCP RTSP connection? Same IP
address for UDP? It seems like this needs to be spec'ed out more fully.
Maybe a modified SESSION method would be better (and more backward
compatible)?

We are against using wildcards in URI's as proposed in 3.1. In general use
of wildcards can cause problems for intermediary devices. Its true that if
a wildcard is used only in an existing session this should not be a problem
but this should at least be an explicit requirement.

thanks

jc

---

From: Dirk Pranke <[email-masked]>
Date: Tue, 11 Apr 2000 14:33:20 -0700

Hi back,

Having worked with Sean on these extensions, I can probably comment on the
motivation ... I'm sure Sean will correct me if I get something wrong.

> For the most part the extensions are fine but there are a couple of things

I'm glad to hear that they're mostly good!

> Maybe a modified SESSION method would be better (and more backward

The motivation for this is in transports where the transport properties will
not change from stream to stream, and setting up sessions is very expensive.
A good example of this is streaming broadcast quality MPEG-2 Transport over
ATM or QAM networks for interactive VOD. The signalling requirements for new
sessions can be quite expensive (a few seconds), especially compared to the
very low latency expectations of a typical TV-biased consumer. Think of flipping
channels, for example: most of us have an expectation of near to sub-second
response times for our TV. If switching assets took 2-3 seconds to switch
QAM banks or ATM SVCs, plus the time to synchronize on the media, this would
not be a compelling solution. However, given that each MPEG-2 Transport asset
can be pretty much identical in encoding parameters and transport requirements,
there is no reason you shouldn't be able to re-use the same transport connection.

This is born out in practice by existing high speed deployments where we use
exactly this functionality today.

As to the syntax, the basic theory was that much like you can queue existing
segments of a given asset back to back using new PLAY commands, you should be
able to queue segments of different assets back to back using PLAY commands;
the fact that the assets are different shouldn't really matter as long as the
compression and transport properties are the same (which they must be, otherwise
this feature doesn't make sense).

However, I will freely agree that this feature only makes sense for some content
types and some transport types, and the spec should be more clear on this.

I would be curious to know the gist of the discussion you mention; why did you
think the coupling would be bad?

> but this should at least be an explicit requirement.

I think the intent was to be only used on an existing session. I agree that
a wildcard passed to SETUP doesn't make much sense.
 
> jc

-- Dirk

Dirk Pranke
Oracle Interactive Television Division