[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
INTERNET DRAFT                                                   M. Ohta
draft-ohta-ccc-video-01.txt                Tokyo Institute of Technology
                                                             T. Tsushima
                                                             T. Tsushima
                                  Victor Company of Japan, Limited (JVC)
                                                             H. FUJIWARA
                                     Graphics Communication Laboratories
                                                              March 1998

                    Camera Recorder 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 view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   This document is also a product of HSI (Home System Interface) WG of
   the multimedia standardization promotion commitee of Japanese
   national committee of IEC.

Abstract

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

   The design of CRCP is completely modular. A unit consists of several
   subunits and CRCP currently specifies units POWER, STREAM, TAPE and
   CAMERA.  However, CRCP allows arbitrary combination of subunits to
   make it useful to control any home electronics units.

1. Introduction

   CRCP (Camera Recorder Control Protocol) is a protocol to control
   audio visual units to send or receive multimedia information over the



M. Ohta              Expires on September 20, 1998              [Page 1]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   Internet.

   The model of CRCP is that there are a controller (a client) and a
   unit (a server). The controller issues commands and the unit receives
   them. Responses are generated by the unit to be reported to the
   controller. A unit may send or receive data stream to or from other
   units. The controller does not generate data streams, though a
   controller and a unit may be collocated in a host. A unit consists of
   several subunits controlled independently. The unit-subunit model is
   consistent with a model of IEEE.1394 TA and allows modular control of
   various home electronics equipments.

   The primary functions of CRCP are data transfer control, camera
   control and tape control. Data transfer control is designed after the
   existing data transfer protocol: FTP [FTP].

   The controlled unit 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 CRCP may mean UNIX filenames, names of tapes in
   automatic archive, names of input connectors, or names of TV
   channels. Even if the unit does not support the notion of file, some
   dummy filename should be supported.

   CRCP uses a ASCII text command over TCP control channel.  Thus,
   long-haul control is possible without worrying about fair-share and
   congestion avoidance algorithms. The default well known TCP port
   number of the channel is <to be assigned by IANA>.

   If the controller, such as infra-red remote controller, has a
   unidirectional interface, CRCP may also be used over UDP.  No reply
   will be given for UDP control and users are expected to confirm the
   effect of the control by themselves, which is what we are doing with
   infra-red remote controllers today.  The default well known UDP port
   number of the channel is <to be assigned by IANA>.

   If a host have multiple entities to be controlled by CRCP, 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.

   CRCP assumes a single controller for each unit. The appropriate



M. Ohta              Expires on September 20, 1998              [Page 2]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   interaction mechanisms between multiple controllers vary application
   by application and should be handled application level coordination
   entity, from which CRCP should be used to the unit. This assumption
   does not prohibit multiple controllers control a multiport VoD server
   independently port by port.

   Like FTP, a controller may not be collocated on a sender nor a
   receiver.  A single controller may, of course, control several
   senders and receivers to transmit data between them.

   CRCP is designed to define a common and simple control interface of
   camera recorders. CRCP capable controllers or units are not required
   to support HTTP, HTML nor JAVA.  CRCP commands may be issued by a
   JAVA applet running in an HTML client.

   2. Command Syntax

   Commands of CRCP are ASCII string based and have the following syntax
   with BNF-like notation (RFC2234 should be followed, here):

      <Command> = ("STAT" / "HELP") [<sp> <subunit>] CR LF /
                   [<subunit> <sp>] <subunit-command> [<sp> <arguments>]
      CR LF

      <subunit> = <subunit-type> [<subunit-no>]

      <subunit-type> = "POWER" / "CONNECTION" / "FILE" / "STREAM" /
                     "TAPE" / "CAMERA" / ...

      <subunit-no> = <digit> / <digit> <subunit-no>

      <subunit-command> = <string>

      <arguments> = <string> / <arguments> <sp> <string>

      <sp> = " " / TAB / <sp> " " / <sp> TAB

      <digit> = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
      "9"

      <string> = <character> / <string> <character>

      <character> = <An ASCII graphic character except for a space>

   If <subunit-no> field is omitted in <subunit>, the default <subunit-
   no> is "0".

   <subunit-command> is different <subunit-type> by <subunit-type>.  If



M. Ohta              Expires on September 20, 1998              [Page 3]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   <subunit> is ommitted in a command line, <subunit-command> is
   considered to be that of FTP [FTP] or its equivalent as described in
   sections 6.2, 6.3 and 6.4.

   The detailed syntax of the <arguments> are different <subunit-
   command> by <subunit-command>.

   3. Response Syntax

   The response of CRCP has the same syntax and semantics as FTP [FTP].

   Responces are listed in Appendix A.

   4. Command and Response Transport

   Commands and responses of CRCP are usually carried over a TCP
   connection as ASCII string with a default port number of <to be
   assigned by IANA>.

   If a controller can not receive IP packets or do not want to receive
   CRCP response, CRCP commands may also be carried over UDP as ASCII
   string with a default port number of <to be assigned by IANA>.
   Response is NOT returned over UDP.  In this case, it is a
   responsibility of a human user or intelligent application to judge
   the effect of each command. Note that the UDP packets carrying CRCP
   commands may not be able to reach the unit, or they may reach the
   unit in an order different from that at the controller. Multiple
   command lines may be included in a single UDP packets and executed
   sequentially, unless error condition is encountered. The error may be
   ignored and command line processing may continue or the error may
   terminate the processing of the rest of the command lines in the
   packet.

   5. Basic Command

   The basic command of CRCP is "STAT" and "HELP".  The commands MUST be
   supported by any unit.

   5.1 STAT command

   With no arguments, the command returns a list of available subunits
   and subunit numbers of the unit.

   With CRCP, four subunits, "POWER", "STREAM", "TAPE" and "CAMERA" with
   subunit numbers of 0 are defined. The response to "STAT" command will
   be:

      211-status response



M. Ohta              Expires on September 20, 1998              [Page 4]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


       POWER0
       CONNECTION0
       FILE0
       STREAM0
       TAPE0
       CAMERA0
      211 status response

   The order of subunits in the response is insignificant.

   The "STAT" command may also be used with an argument of a subunit
   name and a subunit number.

   That is, "STATUS CAMERA" and "STATUS TAPE" are the valid form of the
   STATUS command. There meanings are explained later with the related
   subunits.

   5.2 HELP command

   HELP command always successes and returns responses useful to human
   controlling the unit. With an optional subunit argument, HELP
   response will be on the subunit.  Detailed content of the response is
   outside the scope of protocol issues.  The response may be identical
   to that of STAT.

   6. Subunit Commands

   Subunit commands are different subunit by subunit.

   6.1 POWER subunit commands

   POWER subunit has two subunit commands "ON" and "OFF" corresponding
   to the functions of unit power on and off.

   A unit may be able to receive some command even if the unit is
   powered off.

   6.2 CONNECTION subunit commands

   The following subunit commands of CRCP are for connection management
   and have exactly the same semantics as FTP.

      USER NAME

      PASSWORD

      ACCOUNT




M. Ohta              Expires on September 20, 1998              [Page 5]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


      LOGOUT

   No further explanation on them is given in this memo.

   6.3 FILE subunit commands

   The following subunit commands of CRCP are for file system management
   and have exactly the same semantics as FTP.

      CHANGE WORKING DIRECTORY

      CHANGE TO PARENT DIRECTORY

      STRUCTURE MOUNT

      REINITIALIZE

      PRINT WORKING DIRECTORY

      LIST

      NAMELIST

      SYSTEM


   No further explanation on them is given in this memo.

   6.4 STREAM subunit commands

   The following subcommands of STREAM subunit are extension of the
   corresponding commands of FTP. The detail is explained in section 7.

      DATA PORT (PORT)

      PASSIVE (PASV)

      REPRESENTATION TYPE (TYPE)

      TRANSFER MODE (MODE)

      RETRIEVE (RETR)

      STORE (STOR)

      ABORT (ABOR)

   6.5 TAPE subunit commands



M. Ohta              Expires on September 20, 1998              [Page 6]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   The following commands of CRCP are unique to CCCP to be used for TAPE
   subunit control explained in section 8.

      PLAY (PLAY)

      PAUSE (PAUS)

      RECORD (RECO)

      FAST FORWARD (FF)

      STATUS TAPE (STAT TAPE)

   6.6 CAMERA subunit commands

   The following commands of CRCP are unique to CCCP to be used for
   CAMERA subunit control explained in section 9.

      IRIS (IRIS)

      SENSITIVITY (SENS)

      ROLL (ROLL)

      PAN (PAN)

      TILT (TILT)

      ZOOM (ZOOM)

      HORIZONTAL (HORI)

      VERTICAL (VERT)

      DEPTH (DEPT)

      FOCUS (FOCU)

      WHITE BALANCE (WHIT)

      STATUS CAMERA (STAT CAMERA)

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

7. Modified FTP Commands

   DATA PORT (PORT)




M. Ohta              Expires on September 20, 1998              [Page 7]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   PASSIVE (PASV)

      Unlike FTP, a port number may be one for UDP depending on TRANSFER
      MODE.  A host address may be and SHOULD be represented by a DNS
      domain name.  The address may be a multicast address.

   REPRESENTATION TYPE (TYPE)

      The types supported by CRCP are A for ASCII, and I for RTP-
      encapsulated audio/visual data.  An ASCII type may be used only
      for LIST and NAMELIST commands, and the second format parameter,
      if any, should be N.  The detailed format of Audio/visual data is
      determined by the second parameter, which is a comma separated
      list of decimal integers of well known RTP payload types [RFC1890]
      to be sent or received.

   TRANSFER MODE (MODE)

      The modes supported by CRCP 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, RTP packets must be preceded by 2 byte bigendian headers
      containing the length of the next RTP payload.  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 unit, blank image, noise or just
      silence may be sent unless PLAY command is issued.

   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 CRCP servers must be able to
      monitor multiple ports simultaneously.  When QoS is specified with
      mode, PATH or RESV messages are also stopped.



M. Ohta              Expires on September 20, 1998              [Page 8]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


8. Tape Control Commands

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

   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 unit dependent and, sometimes, totally
   ineffective.

   PLAY (PLAY)

   RECORD (REC)

      Start playing or recording from the current tape position.

      The optional second 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).

      The optional third 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.

   PAUSE (PAUS)

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

   FAST FORWARD (FF)

      An optional second 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).

      Move the current tape position forward (or backward).  An optional
      third 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.



M. Ohta              Expires on September 20, 1998              [Page 9]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


      During the operation, image or sound may or may not be sent out
      depending on the nature of the unit.

   STATUS TAPE (STAT TAPE)

      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
      tape position.  Other lines begins with the tape control command
      name supported by the unit. 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".

9. Camera Control Commands

   Viewing parameters of camera units are controlled by camera control
   commands.

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

   The argument is usually numeric and 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 argument 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 unit dependent and,
   sometimes, be totally ineffective.

   The argument may also be a special keyword "AUTO", in which case, the
   viewing parameter is controlled in a unit dependent manner.  The
   intention is to set the parameter automatically to make the view
   comfortable.

   IRIS (IRIS)

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



M. Ohta              Expires on September 20, 1998             [Page 10]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   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.

   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.

   WHITE BALANCE (WHIT)

      Controls white balance of a camera represented as a color



M. Ohta              Expires on September 20, 1998             [Page 11]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


      temperature, unit of which is Kelvin.  Positive direction makes
      color temperature higher.

   STATUS CAMERA (STAT CAMERA)

      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 supported by the unit 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. They are ordered according to the order of
      application of motions to the camera.  For example, if rotations
      are applied first to the camera and then translation is applied,
      rotation commands appear before translation commands in the reply
      of the STATUS CAMERA command,

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

10. URL

   The URL for CRCP is identical to that of FTP, except that it start
   with "cccp" and have a different default port number <to be assigned
   by IANA>.  The URL is shared both by TCP and UDP control.

11. References

   [FTP] STD9, RFC959.

   [RFC1890] RFC1890.

   12. Appendix A. List of Responces

13. Security Considerations

   CRCP is designed after FTP and, with TCP control, is just as secure
   as FTP.

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

   As the password-based security is not so secure, it is encouraged to
   deploy IPSEC security mechanisms, when they become stable enough.  An
   easy, almost configurationless, key exchange mechanism suitable for
   home electronics use should be developed.



M. Ohta              Expires on September 20, 1998             [Page 12]


INTERNET DRAFT      Camera Recorder Control Protocol          March 1998


   It is also possible to let the reply to USER command contain seeds
   for one time password, but nothing is specified in this memo, partly
   because it is a waste of effort to develop CRCP's own security
   mechanism and partly because it is not useful with one way control
   through UDP.

   For UDP-based one way control, synchronized clocks should be used to
   close the window of the replay attacks.

14. Authors' Addresses

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

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


   Takuya Tsushima
   Video System Development Laboratories
   Victor Company of Japan, Limited
   12, 3-chome, Moriya-cho, Kanagawa-ku, Yokohama,
   Kanagawa 221, Japan

   Phone : +81 45 450 2458
   Fax : +81 45 450 2469
   EMail : tsushima@krhm.jvc-victor.co.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 20, 1998             [Page 13]