Subject: Streams-control BOF notes - update

From: Jeff Smith <[email-masked]>
Date: Tue, 06 Aug 1996 20:45:21 -0700

Sorry, it seems I sent an older version of the notes to the list... I
had updated the sgml version but had not made the current ascii
version before dumping it into mail.

js

==
  BOF - Managing storage and retrieval of media streams
  Jeffrey D. Smith [email-masked]
  $Id: BOF-notes.sgml,v 1.2 1996/08/07 03:35:16 sumisu Exp $

  These are the notes summarizing the BOF held at the June IETF on 27
  June, 1996.  The BOF was called to discuss the issues surrounding
  recording and playback of media streams on the Internet.  These issues
  were also discussed as possibly being applicable to remote device con-
  trol, voice mail, and interactive voice response systems among others.
  The BOF was able to address issues of location services (orthagonal),
  invitation (extensions to SIP), session descriptions to accomodate
  recording and playback control channels (SDP), and some ideas for
  record and playback negotiation.  The actual control protocol for
  streams was not addressed - we need to define our requirements and
  research a number of possible solutions.

  1.  Background and Definitions

  1.1.	Goal statement

  Support recording and playback of media streams on the Internet for
  distributed clients and distributed servers.

  A footnote to this goal is to keep in mind the possibility of this
  mechanism also being useful for other applications involving other
  non-human participants in a conference (i.e. device control).

  A comment on scope - it was decided to define the "simple" case of
  media recording and playback and then evaluate what was necessary for
  the other applications.

  1.2.	Defining terms

  o  Conference - a multiparty, multimedia session (multi >= 1)

  o  Session - a set of related streams.  A session is defined by an SDP
     "packet."

  o  Stream - "realtime" media being transmitted over the Internet
     (including audio, video, whiteboard, shared applications).  In our
     specific case a stream is a pair of RTP+RTCP.

  o  Entity - a participant in a conference.  This participant may be
     non-human.  In our specific case an entity may be a media record or
     playback server.

  1.3.	Applications

  o  VOD

  o  Distance learning

  o  Home VCR-like scheduled recording, and playback on demand
     (archiving)

  o  Voice/video-mail

  o  Telephony

  2.  Components

  2.1.	Server location

  It was decided that this problem was orthogonal to the issue of
  recording and playback.

  Options:

  o  Directly use SIP, submitting the information (SDP) of what session
     an entity (server) is to be invited to attend, and relying on the
     SIP + proxy mechanism to locate the entity.

  o  First query a location service with the requirements for a entity
     and use the results of the query to direct a SIP request to invite
     the entity.

  2.2.	Invitation

  SIP will need to add SDP information that describes the control
  channel that will be used to control the entity which is being
  invited.

  It was decided that it may be helpful to develop profiles for SIP as
  seperate documents to define case-specific behavior.	We will define a
  profile for inviting record and playback servers with a control
  channel request.

  Assumptions:

  o  More than one server may be available for a given request.

  o  More than one server may be invited into a session.

  o  A server may be invited by more than one entity.

  2.3.	Negotiation and Control

  There are two levels, or stages of negotiation.  The first stage could
  use the facilities described in the SIP draft, Category 4: NEGOTIATE.
  This negotiation is in regards to the "contents" of the SDP
  description for a session.

  Upon accepting the invitation, the server will use a control channel
  protocol for further negotiation and subsequent control (including
  record_start, play_start, etc.)

  Not specified, see below "Issues of the Control Protocol"

  3.  Issues for Recording

  o  Query for facilities (enough disk space, CPU load, etc.)

  o  Negotiate for facilities

  o  In the case of an invitation to record, at some time the server
     will provide a unique identifier for each stream in the session
     that may be used to retrieve the stream.  This identifier may be
     provided by the inviting entity and confirmed by the server, or
     generated independently by the server.
  o  In the general case, an invitation to a record server will result
     in the server being set to "record cue" mode.  The actual command
     to record will be sent on the control channel.

  4.  Issues for Playback

  o  Initiation of playback may be a SIP request sent to 1 or more
     entities containing the component stream information and the
     control channel information.  Indication of address, port, ttl for
     the media streams may be included in this message. It is mandatory
     to indicate address, port, ttl for the control channel.

  o  Same as Record - the general case will put the server in "play cue"
     mode and wait for "play" on the control channel.

  o  Finding a stream or reconstruction a session.

  5.  Issues of the Control Protocol

  Functionality:

  o  Need to manage assignment of address and port for control channel.

  o  Asynchronous notification

  o  Acks

  o  Timing

  o  1:1 control

  o  1:n control

  o  n:n control

  o  Need stream id (possibly SSRC + dest address)

  o  Need to quote RTP timestamps

  Objects of control:

  o  record server

  o  playback server

  o  RTP mixer

  o  POTS gateway

  o  Camera

  o  Video equipment (VCR, LaserDisc)

  o  Remote Phone Application

  Protocols to look at:

  o  RTP

  o  RTCP

  o  SNMP

  o  T.120

  o  DTMF (for phone applications)

  6.  Attendees

  Andrew Hally, [email-masked]

  Dave Thaler, [email-masked]

  Francois Menard, [email-masked]

  Mark Handley, [email-masked]

  Steven Magnell, [email-masked]

  Steve Casner, [email-masked]

  Scott Petrack, [email-masked]

  Joerg Ott, [email-masked]

  Jeff Smith, [email-masked]

  Ross Finlayson, [email-masked]

  Keith Johnson, [email-masked]

  Bob Webber, [email-masked]

--
 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]