INTERNET DRAFT                                                   M. Ohta
draft-ohta-ccc-video-00.txt                Tokyo Institute of Technology
                                                            K. Nishimura
                                                    Hiroshima University
                                                                 H. Kago
                                                       Waseda University
                                                               K OKAMURA
                                                         Kobe University
                                                                A. AMANO
                                               Hiroshima City University
                                                              S. Shimojo
                                                        Osaka University
                                                             H. FUJIWARA
                                     Graphics Communication Laboratories
                                                            January 1997

                       CamCoder Control Protocol

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   CCCP (CamCoder Control Protocol) is designed after FTP to be useful
   to operate realtime/batch analog/digital video cameras and
   video/audio recorders over the Internet.

1. Introduction

   CCCP (CamCoder Control Protocol) is a protocol to control audio
   visual devices to send or receive multimedia information over the
   Internet.




M. Ohta              Expires on September 17, 1997              [Page 1]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


   As its primary function is data transfer, the protocol is designed
   based on FTP [FTP].

   The controlled device may be just a plain file server for non-
   realtime transfer, a VoD server with a realtime file system, a video
   camera connected to realtime MPEG encoder, a virtual camera in VRML
   space or an analog audio tape recorder connected to a PC sound board.

   Filenames of CCCP may mean UNIX filenames, names of tapes in
   automatic archive, name of input connectors, or names of TV channels.
   Even if the device does not support the notion of file, some dummy
   filename should be supported.

   CCCP uses a TCP control channel. The default well known port number
   of the channel is <to be assigned by IANA>.

   If a host have multiple entities to be controlled by CCCP, different
   port numbers should be used for the control channels.

   Control commands and responses are exchanged over the control channel
   with TELNET style ASCII.

   Unlike FTP, it is required that server and client must support
   monitor the control and data connections simultaneously.

   CCCP assumes a single controller for each device. The appropriate
   interaction mechanisms between multiple controllers vary application
   by application and should be handled application level coordination
   entity, from which CCCP should be used to the device. This assumption
   does not prohibit multiple controllers control a multiport VoD server
   independently.

   Like FTP, a single controller may, of course, control several
   devices.

   2. Commands

   The following commands of CCCP have exactly the same semantics as
   FTP.

      USER NAME

      PASSWORD

      ACCOUNT

      CHANGE WORKING DIRECTORY




M. Ohta              Expires on September 17, 1997              [Page 2]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


      CHANGE TO PARENT DIRECTORY

      STRUCTURE MOUNT

      REINITIALIZE

      LOGOUT

      PRINT WORKING DIRECTORY

      LIST

      NAMELIST

      SYSTEM

      STATUS

      HELP

      NOOP

   No further explanation on them are given in this memo.

   The following commands of CCCP are subset or extension of the
   commands of FTP with the same name. The modifications are explained
   in section 3.

      DATA PORT (PORT)

      PASSIVE (PASV)

      PRESENTATION TYPE (TYPE)

      TRANSFER MODE (MODE)

      RETRIEVE (RETR)

      STORE (STOR)

      ABORT (ABOR)

   The following commands of CCCP are unique to CCCP to be used for tape
   control explained in section 4.

      PLAY (PLAY)

      PAUSE (PAUS)



M. Ohta              Expires on September 17, 1997              [Page 3]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


      RECORD (RECO)

      FAST FORWARD (FF)

      TAPE STATUS (TSTA)

   The following commands of CCCP are unique to CCCP to be used for
   camera control explained in section 5.

      IRIS (IRIS)

      SENSITIVITY (SENS)

      ROLL (ROLL)

      PAN (PAN)

      TILT (TILT)

      ZOOM (ZOOM)

      HORIZONTAL (HORI)

      VERTICAL (VERT)

      DEPTH (DEPT)

      FOCUS (FOCU)

      CAMERA STATUS (CSTA)

   FTP commands not mentioned in this section do not exist in CCCP.

3. Modified FTP Commands

   DATA PORT (PORT)

   PASSIVE (PASV)

      Unlike FTP, a port number may be one for UDP depending on TRANSFER
      MODE.  A host address may be a multicast address.

   PRESENTATION TYPE (TYPE)

      The types supported by CCCP are A for ASCII, and I for
      audio/visual data.  ASCII type may be used only for LIST and
      NAMELIST commands, and the second format parameter, if any, should
      be N.  The format of Audio/visual data is determined by the second



M. Ohta              Expires on September 17, 1997              [Page 4]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


      parameter, 'M' for MPEG2-TS and 'R' for RTP. The third parameter
      may supply additional information.  The format of the paramter for
      RTP is a comma separated list of decimal integers of well known
      RTP payload types in RFC1890 [RFC1890] to be sent or received.
      For MPEG2, it is one of the following strings: "MP@ML", "SP@ML".

   TRANSFER MODE (MODE)

      The modes supported by CCCP are S for Stream (TCP), P for Packet
      (UDP).  Packet mode uses UDP. Packet mode has a space separated
      second unsigned decimal numeric parameter to indicated the number
      of MPEG2-TS or RTP payloads included in a single UDP packet.  Only
      a single RTP payload may be included in a UDP packet.  In a TCP
      stream, MPEG2-TS packets, having fixed (188 bytes) size, are
      packed continuously with no additional headers while RTP packets
      must be preceded by 2 byte bigendian headers containing the length
      of the next RTP frame.  The optional second (for Stream mode) or
      third (for Packet mode) argument is an ASCII string specifying QoS
      requirement to be used with RSVP [RSVP]. The format of the string
      is, <to be determined>.  If no QoS is specified, transfer mode is
      best effort.

   RETRIEVE (RETR)

      These command initiate the transfer of data.  When QoS is
      specified with mode, PATH messages are also sent along with the
      data.  Note that, with tape device, blank image or just silence
      may be sent unless PLAY command is used.

   STORE (STOR)

      This command initiate the acceptance of data.  When QoS is
      specified with mode, RESV messages are also sent upstream.

   ABORT (ABOR)

      This command terminates the acceptance of data.  Unlike FTP, no
      special action is required, because CCCP servers can monitor
      multiple ports simultaneously.  When QoS is specified with mode,
      PATH or RESV messages are also stopped.

4. Tape Control Commands

   Tape devices, such as audio or video tape recorder, have a notion of
   current tape position.

   Some of the commands may be applicable to non-tape devices.
   Especially, TAPE STATUS command is always supported.



M. Ohta              Expires on September 17, 1997              [Page 5]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


   Some tape control commands have an argument to specify a tape
   position. The position is represented in seconds with decimal
   notation with optional fractional part.  The integral part should be
   between 2147483647 and -2147483648, that is, can be represented by a
   32 bit signed integer.  When '+' or '-' sign precedes the number, it
   means a position relative to the current tape position.

   Arguments are separated by a single space character. The precision
   and range of the arguments are device dependent and, sometimes,
   totally ineffective.

   PLAY (PLAY)

   RECORD (REC)

      Start playing or recording from the current tape position. An
      optional second argument may designate the position to stop
      playing or recording.  If the stop position is already behind the
      current tape position (depending on the direction of the movement)
      at the beginning of the command, the command terminates.  An
      optional third signed integer argument represented in decimal
      notation with optional fractional part may designate the play or
      record speed (e.g. 1 for normal play speed, -1 for reverse play or
      record with the normal speed).

   PAUSE (PAUS)

      Stop playing, recording or fast forwarding at the current
      position.

   FAST FORWARD (FF)

      Move the current tape position forward (or backward).  An optional
      second argument may designate the position to stop operation.  If
      the stop position is already behind the current tape position
      (depending on the direction of the movement) at the beginning of
      the command, the command terminates.  An optional third signed
      integer argument represented in decimal notation with optional
      fractional part may designate the forwarding speed (e.g. 5 for
      fast forward, -5 for rewind).  During the operation, image or
      sound may or may not be sent out depending on the nature of the
      device.

   TAPE STATUS (TSTA)

      Will cause multiline response.  The first line begins with the
      name of the command in operation (PAUS if nothing) followed by a
      decimal integer with optional fractional part to show the current



M. Ohta              Expires on September 17, 1997              [Page 6]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


      tape position.  Other lines begins with the tape control command
      name (other than TSTA itself) supported by the device. If the
      command has numeric arguments, two numbers separated by a comma
      will be returned which designate the minimum and the maximum
      meaningful value of the corresponding command parameter.

   Reply code of tape control commands will be "200 Command okay", "501
   Syntax error" in parameters or arguments" or "502 Command not
   implemented".

5. Camera Control Commands

   Camera devices may be controlled its viewing parameters.

   Some of the commands may be applicable to non-camera devices.
   Especially, CAMERA STATUS command is always supported.

   Camera control commands other than CAMERA STATUS have a numeric
   argument to specify the view.

   The number is represented with decimal notation with optional
   fractional part.  The integral part should be between 2147483647 and
   -2147483648, that is, can be represented by a 32 bit signed integer.
   When '+' or '-' sign precedes the number, it means a value relative
   to the current value.

   The number may be a single character '+' or '-' with no decimal
   characters, in which case, the view changes some meaningful small
   amount toward the direction of the sign.

   The precision and range of the argument is device dependent and,
   sometimes, be totally ineffective.

   IRIS (IRIS)

      Controls iris of a camera. Positive direction makes iris more
      open.

   SENSITIVITY (SENS)

      Controls sensitivity of a (CCD) camera. Positive direction makes
      image brighter.

   ROLL (ROLL)

      Controls roll angle of a camera. Positive direction turns the
      camera clockwise viewed behind the camera.




M. Ohta              Expires on September 17, 1997              [Page 7]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


   PAN (PAN)

      Controls pan angle of a camera. Positive direction makes view move
      right.

   TILT (TILT)

      Controls tilt angle of a camera. Positive direction makes view
      move up.

   ZOOM (ZOOM)

      Controls viewing angle of a camera. Positive direction makes view
      angle narrower (more zoom).

   HORIZONTAL (HORI)

      Moves a camera horizontally. Positive HORIZONTAL movement moves
      the camera right viewed behind the camera.

   VERTICAL (VERT)

      Moves a camera vertically. Positive VERTICAL movement moves the
      camera to the upward direction..

   DEPTH (DEPT)

      Moves a camera along the viewing direction. Positive DEPTH
      movement moves the camera forward.

   FOCUS (FOCU)

      Controls focal point of a camera. Positive direction makes the
      focal point farther.

   CAMERA STATUS (CSTA)

      Will cause multiline response.  The first line contain some string
      such as "OK", which is ignored.  Other lines begin with the camera
      control command name (other than CSTA itself) supported by the
      device followed by three numbers separated by a comma which
      designates the minimum meaningful, the current and maximum
      meaningful values of the corresponding viewing parameter.  For the
      non-commutative commands of camera motion control, the order of
      them in the reply is significant. The order of Such commands are
      the order of application of motions to the camera.  For example,
      usually, rotations are applied first to the camera and then
      translation is applied. Thus, in the reply of the CSTAT command,



M. Ohta              Expires on September 17, 1997              [Page 8]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


      rotation commands appear before translation commands.

   Reply code of camera control commands will be "200 Command okay",
   "501 Syntax error in parameters or arguments" or "502 Command not
   implemented".

6. URL

   The URL for CCCP is identical to that of FTP, except that it start
   with "cccp" and have a different default port number.

7. References

   [FTP] STD9, RFC959.

   [RFC1890] RFC1890.

8. Security Considerations

   CCCP is designed after FTP and is just as secure as FTP.

   That is, CCCP control connection to servers can be protected by
   password.

   Though it is possible to let the reply to USER command contain seeds
   for one time password, nothing is specified in this memo.

9. Authors' Addresses

   Masataka Ohta
   Computer Center
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku
   Tokyo 152, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3415
   EMail: mohta@necom830.hpcl.titech.ac.jp

   Kouji Nishimura
   Information Processing Center
   Hiroshima University
   1-4-2, Kagamiyama
   Higashi-Hiroshima 739, JAPAN

   Phone: +81-824-24-6262
   Fax: +81-824-22-7043
   EMail: kouji@hiroshima-u.ac.jp



M. Ohta              Expires on September 17, 1997              [Page 9]


INTERNET DRAFT         CamCoder Control Protocol            January 1997


   Hiroaki Kago
   Waseda University
   3-4-1, Okubo Shinjuku-ku
   Tokyo 169, JAPAN

   Phone: +81-3-5286-3116
   Fax: +81-3-3209-3173
   EMail: kago@olu.info.waseda.ac.jp

   Koji OKAMURA
   Information Processing Center
   Kobe University
   1-1 Rokkodai, Nada, Kobe 657, JAPAN

   Email: oka@kobe-u.ac.jp
   Phone: +81 78 803 0189
   Fax:   +81 78 803 0193

   Akira AMANO
   Faculty of Information Sciences
   Hiroshima City University
   151-5 Ozuka, Numata, Asaminami
   Hiroshima 731-31, JAPAN

   Phone: +81 82 830 1766
   Fax:   +81 82 830 1792
   Email: a-amano@its.hiroshima-cu.ac.jp

   Shinji Shimojo
   Computer Center
   Osaka University
   5-1 Mihogaoka, Ibaraki
   Osaka 567, JAPAN

   Phone: +81 (6) 879-8793
   Fax: 06-879-8814
   EMail: shimojo@center.osaka-u.ac.jp

   Hiroshi FUJIWARA
   Graphics Communication Laboratories
   6F Annex Tohshin Bldg,
   4-36-19, Yoyogi, Shibuya-ku
   TOKYO 151, JAPAN

   Phone:          +81 3 5351 0181
   Fax:            +81 3 5351 0184
   EMail:          fujiwara@gctech.co.jp




M. Ohta              Expires on September 17, 1997             [Page 10]