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