Subject: [MMUSIC] Thoughts on extending RTSP

From: Rob Lanphier <[email-masked]>
Date: Thu, 21 Mar 2002 20:43:08 -0800 (Pacific Standard Time)

Hi all,

In the RTSP discussion that happened today, one thing that we discussed is
to understand how RTSP should be scoped.  Here's a very drafty draft that
starts down this path.

Please comment on this, as I intend to flesh this out much more over the
next couple of weeks.  Much of what comes out of this should probably show
up in RFC2326bis, but we can decide what the proper home for this is when
it's in a more concrete form.

Thanks
Rob
----

There are several areas that need to be addressed:

*  What are the fundemental "reusable components", and how to recognize
the shape of the hole that the square peg is being jammed into.
*  Mechanisms for extensibility
*  Guidelines for using the mechanisms for extensibility

The tension is between two extremes:
*  Discouraging sensible extensions in scope and functionality in RTSP
*  Encouraging overexpansion of the scope of RTSP

Fortunately, we don't seem to be in danger of either of these happening
now, as the proposals for extending RTSP have for the most part been very
sensible expansions to the scope of the protocol.  However, it would be
good to give the sense of where we are going with this.

= Design goals =

RTSP, broadly speaking, was designed as a means of controlling media
servers.  Media servers generally do one or both of the following:

*  Control media from disparate sources (e.g. disk, non-streaming
protocols, raw video source) and convert it to a relatively contrained set
of media data transports (usually RTP).

*  Take a relatively constrained set of media data transports (usually
RTP), and "record" them to disparate sources (e.g. disk, non-streaming
protocols, raw video sinks)

The SETUP, PLAY, PAUSE, TEARDOWN state model of timeline control is a
fundemental part of the design of RTSP.  It may be useful to control other
dimensions of media playback, such as spatial positioning, amplification,
etc.  (more needs to be discussed here).

= Proxies =

Often, the reason for wanting to leverage a particular protocol (such
as RTSP) is to leverage deployed proxies for that protocol.  In leveraging
RTSP, one must be aware of what aspects of the protocol are widely
implemented.  Proxy writers need to be aware of what applications expect,
and must not only write applications which proxy current uses of RTSP, but
gracefully handle extensions to the protocol.

= Guidelines for using RTSP =

These are not hard and fast rules, but rather guidelines for which at
least some of the checkpoints should be met:

*  Either the input or the output of the interaction should be a
relatively constrained set of media data transports, with RTP strongly
recommended as a baseline
*  Media flow should be largely asymetric (preferably one-way).  Two-way
media flow should be done with teleconferencing protocols such as SIP.

One place we should look for ideas in what to include is RFC 3205:
http://www.ietf.org/rfc/rfc3205

This is not to say that the statement for RTSP needs to be modeled after
this.  RFC 3205 was written because HTTP has argubly become a victim of
its own success, and RTSP is not currently that successful/"successful"
(depending on your point of view).  We have the luxury that RTSP has been
successful in achieving its goals without being so wildly successful as to
stir the same deep philosophical rifts.  Preemptively spelling out some
guidelines may both foster healthy growth without encouraging unwelcome
growth.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Mar 2002 20:13:21 -0500

Rob,

This seems very reasonable, in particular the recognition that RTSP is for
scenarios where media flows in a single direction only, and that multiple
directions call for a control protocol like SIP. 

More comments inline.

>etc.  (more needs to be discussed here).

Agreed, provided those aspects don't affect the timed media streaming model
that RTSP follows. We should be wary of extensions which affect the "view",
and cause the media to update, without changing the timeline.

>gracefully handle extensions to the protocol.

And how proxies handle the media flows, which will probably result in a set
of guidelines for extensions to RTSP (e.g. extensions should avoid changing
the media forwarding and caching behaviour of proxies?)

>guidelines may both foster healthy growth without encouraging unwelcome

Agreed.

Cheers,
Colin

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 25 Mar 2002 18:54:02 -0800 (Pacific Standard Time)

Changing the subject, because I think this one topic is worth a breakout
discussion:

> and cause the media to update, without changing the timeline.

This was a point of discussion at our lunch meeting on Thursday in
Minneapolis.  I agree with you on this point, but based on the
conversation, others may disagree.

We've got several different approaches to modularity when both
viewport/spatial positioning and time are concerned:

1.  RTSP is a timeline manipulation protocol.  We define a new
viewport/spatial positioning protocol
2.  RTSP is a media manipulation protocol, where timeline and viewport
manipulation are part of the mix.  RTSP sessions, as we know them today,
become "timeline sessions", and we define "viewport sessions" as an
extension to RTSP.  Perhaps a "delivery session" would need to be the base
session type from which "timeline sessions" and "viewport sessions" are
derived
3.  RTSP is a media manipulation protocol, with a unified concept of a
"session", where viewport and timeline manipulations can occur on the
associated media

There are probably other combinations of functionality here, but you get
the idea.

The distinction between the different approaches becomes clear when one
thinks about aggregate media.  For example, approach #3 seems to preclude
aggregating timeline control for several media when the viewport
positioning may be different for the individual streams.

Rob

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Mar 2002 18:40:04 -0500

>viewport/spatial positioning protocol

It's clear that we can define a protocol in the style of RTSP and HTTP that
provides viewport/spatial positioning. It may even fall out of one of the
existing protocols, although it's not clear to me that that is RTSP rather
than HTTP.

>positioning may be different for the individual streams.

I think we need to flesh out the design aims and constraints for the
different parts of the system, to make a choice on which approach to
follow. For example, panning over a still image may imply approach 1,
whereas panning over a movie (e.g. pan and scan of a 16:9 image onto
a 4:3 display) fits closer to options 2 and 3.

I'd like to hear other opinions though, since I think we're largely 
in agreement.

Colin