Subject: RTSP: Compartmentalizing RTSP

From: Rob Lanphier <[email-masked]>
Date: Fri, 22 Nov 1996 09:34:32 -0800

The primary issue at the Streams BOF II, hosted by Jeff Smith at NTT, was
whether the scope of RTSP should be limited to client-server streaming, or
whether it should be generalized enough to work in both the client-server
model, and in the peer-to-peer conferencing model. The specific implications
of this manifest themselves throughout the following items.

Compartmentalize The Protocol

We need to strike the balance between the current RTSP proposal of having
one protocol that accomplishes all necessary tasks and the proposal by
several attendees that RTSP should be modularized, breaking it up into
several components. 

Below is a straw man for breaking up RTSP into smaller pieces.
I don't necessarily agree that it should be broken up into as many
pieces as I've outlined below. However, we'll go along with a
well-reasoned consensus and allow it to evolve.

Piece 1: RTSP Framework

The RTSP Framework would provide a collection of application and
transport-level control protocols providing an extensible framework to
enable controlled, on-demand delivery of real-time data in a
client-server fashion. This document would describe how the underlying
protocols are assembled to provide a complete specification.

Our Base Requirements

     Must provide a complete set of functionality for one-to-many
     streaming of multimedia 
     Must support real-time audio/video files and live real-time feeds
     or any type of live or other paced-content information 
     Protocol must be usable over low-bandwidth connections 
     Must optionally be capable of delivering full start-to-finish
     functionality within a single TCP connection 

Piece 2: RTSP Control Protocol

The RTSP Control Protocol is the protocol that provides stream
control for the RTSP Framework. This would be similar to the work
that the MMUSIC group did with CCCP.

Piece 3: RTSP Format Descriptors

Appendix C of the current RTSP spec specifies format descriptors and
families. There has been an expressed desire from Mark Handley and
Henning Schulzrinne to separate this from the "control" part and make
them the stream description format.

Barring a full decoupling of RTSP and the format specifiers, even if the
spirit of Appendix C remains the same, splitting the document here may
be beneficial to encourage the evolution of the data types independent
of the core RTSP specification.

Piece 4: Stream Description Format 

This may be a merge of the Stream Description Protocol (SDP)
proposed by Mark Handley and the tenative RTSP format. Henning
Schulzrinne has a proposal which he has placed at
http://www.cs.columbia.edu/~hgs/rtsp/sdf.html

He proposes the name "Session Description Format", which is one
possibility. For that matter, we could come up with more reasonable
names by the pick-one-from-any-column mechanism:

      Column 1         Column 2        Column 3
      ========         ========        ========
      Session          Description     Format
      Clip             Metafile
      Presentation

Piece 5: Streaming Stream Description Format

This would provide stream description functionality in a streaming
format, such that new streams can be dynamically added and removed
within a single RTSP session, and that a single TCP connection
(authenticated once) can handle the entire experience from start to
finish. This would be similar to SIP, and perhaps could be merged with
SIP.

Piece 6: Compressed Header Format (Compressed RTP)

This would be the definintion of the RTSP version of compressed RTP.

Piece 7: SCP and Compressed SCP

We'll work with Simon Spero and the appropriate working groups to
define a format that works well for this.

Simon has a new proposal for SCP at:
http://sunsite.unc.edu/ses/scp.html 

We haven't had time to fully evaluate it, but so far, it looks pretty good.

Piece 8: Using RTSP Control over SCP

This would define how the RTSP Control protocol would work over
SCP.

Piece 9: Using RTSP Control over UDP

...yet another proposal

Those are the possible chunks.  Which parts need separate drafts, and which
are more appropriate as sections of a single draft.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com