One document matched: draft-ohta-ccc-video-01.txt
Differences from draft-ohta-ccc-video-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 13:06:43 |