Subject: Control of Recording and Playback Media Streams

From: Jeff Smith <[email-masked]>
Date: Fri, 21 Jun 1996 14:14:59 -0700

The following is the beginnings of my thoughts for the 15 minutes I
have the end of the second day...

This is more of a position paper and an attempt to encourage
discussion and ensure completeness of the requirements for protocols
to initiate and control recording and playback of mbone media streams.

Unfortunately, I didn't get as far with the details of how I would
like to see the protocols actually specified and used.  I figured it
was more valuable to give anyone checking their mail before leaving
for Montreal a chance to see this before I stood up in front of
everyone.

Cheers,

js

--
 Jeffrey D. Smith     【ジェフリー・スミス】
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: [email-masked]

---------------------

  Protocols for managing storage and retrieval of media streams
  Jeffrey D. Smith [email-masked]
  $Id: position-paper.sgml,v 1.1 1996/06/19 03:36:36 sumisu Exp sumisu $

  A complete solution to storing and retrieving multimedia streams on
  the Internet is necessary.  The scope of this proposed solution is
  limited to current MBONE usage of multimedia streams (1:1, 1:n, or
  n:n) which are transmitted via multicast (RTPv2) over the Internet.
  The goal of this paper is to introduce the domain in order to create
  discussion.  The issues surrounding storage and retrieval of media
  streams on the Internet are discussed.  Proposals for addressing
  server discovery, resource and facility reservation, and VCR-like con-
  trols of the streams is introduced.  It is the assumption of this pro-
  posal that no single protocol will be able to provide a solution, but
  rather a suite of protocols (relying largely on existing protocols)
  will be necessary.

  1.  Background

  The Internet multicast experiment called the MBONE has been largely
  successful as a proof of concept.  The MBONE has provided a testbed
  for protocols and shown that the Internet can be used for realtime
  multimedia communication.  The MBONE is being used to transmit
  conferences, broadcast concerts, for distance-learning, and for
  general collaboration.  It has become the medium of choice for
  distributed collaboration in many cases.  The ability to record and
  playback streams has been included in several tools sdr,nv and "media
  servers" media kit,mbone vcr have been developed.  To support the
  fundamental distributed nature of the MBONE it is necessary to provide
  distributed recording and playback where (given security and resource
  constraints) any user can request to any server to record a stream and
  likewise find a server with a desired stream and request playback and
  then be able to control that playback.

  2.  Scenario

  To explain further a simple usage scenario would be helpful.	Note --
  the sketch below does not address multiple requests to record the same
  session, nor does it address collaborative playback.

  2.1.	Recording

  A researcher in Japan wants to record a session being broadcast from
  the upcoming IETF.

  He (requesting party) sends a request for a server that is available
  to record, indicating the session he would like to record.  He can
  also indicate the "domain" of the requested server (request a server
  in his own company or within Japan, etc.)

  This request is sent to many (all) servers within the scope defined by
  the requesting party.

  A server that has the capacity to record the requested session will
  create a "reservation" and respond with an acknowledgement that it
  will be able to record that session.	The acknowledgement contains a
  URL (rtp://...)  that can be used to retrieve the recording stream(s).

  The reservation will include the session information and the
  requesting party information.

  Using the URL returned from the server, during the session the
  requesting party may stop the recording and restart if necessary.
  (Similar to pausing during commercials on a VCR.)
  2.2.	Playback

  Based on the policy of the recording server, the policy/encryption of
  the original session stream(s), or the settings made by the requesting
  party, playback will be available through similar means as record
  requests.

  A user can send a request for a server that has an archive of a
  desired stream(s) or session, or use the URL to request the stream(s)
  directly.

  The response from a server that has the requested stream is a URL for
  the stream.

  Several streams, possibly from different servers, can be combined for
  playback and defined as a session.

  A user can request the playback in multicast (with a different ttl
  than original) or unicast.

  A user can request a specific stream encoding (conversion from
  original encoding to requested encoding if different).

  Playback "viewers" would most likely be standard MBONE tools.

  A playback control tool would allow the requesting user to manipulate
  the playback of the streams (using VCR-like controls).

  During playback one or more of the streams may be muted.

  Streams may be added to or subtracted from the playback "session."

  3.  Issues

  Based on the above scenario/requirements and some brainstorming, the
  issues for providing distributed storage and retrieval of MBONE media
  streams can be identified as:

  o  Finding a server (``psuedo-anycast'')

  o  Requesting services  (QoS and server capabilities)

  o  Identifying a stream  (RTP URL)

  o  Controlling a stream (VCR-like controls)

  o  Dealing with encrypted streams

  o  Conversion of stream encoding  (nv to H.261)

  o  (Re)Mixing of streams  (audio channels in different languages, also
     video from server A and audio from server B)

  o  Formats for storage to disk (including security and session
     information)

  4.  Proposal for protocols

  Roughly, the above issues can be divided into the following areas:
  server discovery, resource and facility reservation, stream
  identification and control, and server internals.  The last, server
  internals, which would include storage formats and stream conversion,
  is beyond the scope of this document.
  4.1.	Server discovery

  There are two possible approaches that come to mind: searching and
  then binding to a server, or using a "global naming" to provide a
  persistent name for a server (actually a name for a service).

  My first impression is that the latter is prefered.  Persistent names
  would provide portability and could be used to provide a psuedo
  anycast and allow use of a "most available" server.

  By using CCCP, send (video.record) query to get
  "instantiation" of available server.

  4.2.	Resource and facility reservation

  This area is concerned with reserving resources on a server for record
  or playback.

  SIP may be a candidate.

  4.3.	Stream identification and control

  UDP based, realtime control May be unicast or multicast

  Commands

  o  Record

     Record_Cue Record_Start Pause Stop

  o  Play

     Play_Cue Play_Start Pause Stop FF Rew Rew_to_Start FF_to_End
     Slow_Forward Slow_Rewind

  o  Index

     Make_Index (timestamp) Next_Index n Prev_Index n

  o  Archive

     Show_Archive Show_Sessions Show_Space

---

From: Wieland Holfelder <[email-masked]>
Date: Wed, 26 Jun 1996 17:12:52 +0200 (MET DST)

> for Montreal a chance to see this before I stood up in front of

Jeff, ConfCtrlers,

unfortunately I will not be able to follow Johns presentation 
at the IETF meeting in Monterey today, neither in person, nor 
via MBone. However, I'd like to make some comments (last minute 
I know, but this discussion will probably go on for a while) 
since I believe that you started a very important thread. In 
fact this is something that is probably not only of interest 
for the mmusic group but also for the avt people and others.

A while ago I implemented one of the recording and playback 
applications on the MBone, the MBone-VCR, but unfortunately 
it is a little outdated since I didn't have enouguh time to 
look after it after I left ICSI (where I developed it). 
Anyhow, some ideas were still in my mind and together with 
two students in Mannheim we now could start a new project a 
couple of weeks ago that we called: "MBone-VCR on demand Service"

Well, we just started, so there are lots of things we have to 
investigate further, but since John brought the issue up, I 
thought this might be a good point to throw our ideas in the 
pot as well...

A brief overview of our project goals so far:

o  develop a distributed client-server architecture where 
   MBone-VCR clients request recordings and playbacks from 
   MBone-VCR server.

o  clients will be java-applets so they can be viewed and run
   with any java-capable browser on any platform. The clients
   take care to launch the appropriae applications to view the
   recordings. The information which the aproriate appplication
   is comes from the server. The interaction between clients 
   and servers will be via remote objects.

o  server will be partially implemented as java-applications 
   (not applets!) and partially using C++. The interface to 
   the client will be implemented in java (so we can use the 
   same RO-stack), time critical issues like retrieving RTP-
   packets from the net and storing them on a vcr-file will 
   be implemented in C++ and bound to the java application as
   shared library. The server will implement an interface to
   sdap in order to be able to receive session announcments
   (which the server will offer the clients as possible candidates
   that they can record) and to announce playbacks requested 
   from clients.

o  define a protocol between clients and servers that will provide:
   - session control and management e.g.:
     + listing of available session announcments
     + listing of available recordings
     + scheduling of recordings
     + scheduling of playbacks
     + change parameters of a session (e.g. lower the ttl)
     
   - stream control and managment e.g. 
     + play, stop, pause, record, ff, rew, set index,
       jump to next index, ...
     + events like "end of recording", "sync"  or "update timing"

   - floor control 
     + allow only one client to control the session 
       while multiple clients may receive it.
     + allow passing of the floor control token
 
o  define a standardized rtp-file format to store rtp-packets:
   The file format should be:
   - media independant
   - self describing
   - interchangable
   - efficient
   and optionally support
   - fast random access
   - indexing
   - editing
   
There are a lot more things to mention but I think you get the idea
and we have enough to talk and discuss about. We are at the very
beginning of the project and would be happy to have lively discussion
and new ideas that we may include in the architecture.

Again, it's too bad that I can't participate in the Monterey Meeting 
but I hope we will keep in touch and will have further discussion.

Thanks, so long,
-- Wieland 
-------------------------------------------------------------------------------
Wieland Holfelder
University of Mannheim
Praktische Informatik IV 	      Email: [email-masked]
L 15,16 			                        Fax  : +49-621-292-5745
68131 Mannheim				                Phone: +49-621-292-3300
Germany                     	     http://www.informatik.uni-mannheim.de/~whd
-------------------------------------------------------------------------------

---

From: Bob Olson <[email-masked]>
Date: Wed, 26 Jun 1996 13:24:54 -0500

Given this has come up :-) I should stop lurking and mention a project
we've been working on for some time ... dubbed the Voyager project,
we're building an RTP-based media server. I'm hacking on getting it
ready for a public release in the next week or two.

The Voyager system has a distributed client-server architecture, where
the server side consists of a set of cgi-scripts for session browsing,
recording, and playback; a pair of lowlevel daemons for record and
playback; a Perl-based architecture for gluing the layers together
(using nPerl for interdaemon communication (1)), and a relational
database to act as a central repository of informationfor the system
as a whole. The design goal is to serve large numbers of
high-bandwidth streams (nominal 5Mbps or more) both in record and
playback mode.

We use the IBM TigerShark multimedia filesystem on the server machine,
in order to do striping across multiple disk server nodes in the SP2
we're using as a server. 

On the client side we just use the mbone tools -- vic/vat or the
Precept tools.

We demonstrated an earlier version of Voyager at Supercomputing '95 --
see http://www.iway.org/video/index.html for a little info;
information on the current version is available at
http://voyager.mcs.anl.gov/Voyager/. 

(1) Nexus/Perl -- see http://www.mcs.anl.gov/nexus/nperl/

--bob

PS. Please note the server is in rough shape currently ... am working
out the kinks for public use of it... please be kind to it as it's
only a single-node server now, multinode operation should be up soon
as well.

---

From: Wieland Holfelder <[email-masked]>
Date: Thu, 27 Jun 1996 01:31:58 +0200 (MET DST)

Hi Bob, 

very interesting piece of work! Thanks for the coming out :-)
Competition  always makes things getting better faster, right!
However, despite the fact that you (almost?) have a running system 
already, I think there is still room for further discussion. Some of the 
ideas that Jeff mentioned and some of the ideas that we want to 
implement are - as far as I could see it with a first look at your web 
pages - not included in the current voyager architecture. I'm sure that 
you have a lot more in the backhand that the things you list on the ToDos 
page but I think we would all benefit from further coorperation and 
discussions. One of the things, e.g. would be an rtp file format that 
would be interchangable between the various systems, a control protocol 
would be another issue and I could think of many more.

Whow, this field is moving real fast! 
Looking forward to more discussions.

Thanks,
-- Wieland

-- Wieland

---

From: Jeff Smith <[email-masked]>
Date: Wed, 26 Jun 1996 23:15:31 -0700

We just finished (literally) the BOF that was a follow-up to the
MMUSIC mtg. today.  I will be finalizing the summary of what we agreed
(and disagreed) upon in the next week or so and submitting this for
comment among those of us who attended the BOF and then sending this
to the list.  We would, of course, be interested in your comments.

More later,

js