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]