home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ohta-ccc-video-00.txt < prev    next >
Text File  |  1997-01-16  |  17KB  |  562 lines
  1.  
  2.  
  3.  
  4.  
  5. INTERNET DRAFT                                                   M. Ohta
  6. draft-ohta-ccc-video-00.txt                Tokyo Institute of Technology
  7.                                                             K. Nishimura
  8.                                                     Hiroshima University
  9.                                                                  H. Kago
  10.                                                        Waseda University
  11.                                                                K OKAMURA
  12.                                                          Kobe University
  13.                                                                 A. AMANO
  14.                                                Hiroshima City University
  15.                                                               S. Shimojo
  16.                                                         Osaka University
  17.                                                              H. FUJIWARA
  18.                                      Graphics Communication Laboratories
  19.                                                             January 1997
  20.  
  21.                        CamCoder Control Protocol
  22.  
  23. Status of this Memo
  24.  
  25.    This document is an Internet-Draft.  Internet-Drafts are working
  26.    documents of the Internet Engineering Task Force (IETF), its areas,
  27.    and its working groups.  Note that other groups may also distribute
  28.    working documents as Internet-Drafts.
  29.  
  30.    Internet-Drafts are draft documents valid for a maximum of six months
  31.    and may be updated, replaced, or obsoleted by other documents at any
  32.    time.  It is inappropriate to use Internet- Drafts as reference
  33.    material or to cite them other than as ``work in progress.''
  34.  
  35.    To learn the current status of any Internet-Draft, please check the
  36.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  37.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  38.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  39.    ftp.isi.edu (US West Coast).
  40.  
  41. Abstract
  42.  
  43.    CCCP (CamCoder Control Protocol) is designed after FTP to be useful
  44.    to operate realtime/batch analog/digital video cameras and
  45.    video/audio recorders over the Internet.
  46.  
  47. 1. Introduction
  48.  
  49.    CCCP (CamCoder Control Protocol) is a protocol to control audio
  50.    visual devices to send or receive multimedia information over the
  51.    Internet.
  52.  
  53.  
  54.  
  55.  
  56. M. Ohta              Expires on September 17, 1997              [Page 1]
  57.  
  58. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  59.  
  60.  
  61.    As its primary function is data transfer, the protocol is designed
  62.    based on FTP [FTP].
  63.  
  64.    The controlled device may be just a plain file server for non-
  65.    realtime transfer, a VoD server with a realtime file system, a video
  66.    camera connected to realtime MPEG encoder, a virtual camera in VRML
  67.    space or an analog audio tape recorder connected to a PC sound board.
  68.  
  69.    Filenames of CCCP may mean UNIX filenames, names of tapes in
  70.    automatic archive, name of input connectors, or names of TV channels.
  71.    Even if the device does not support the notion of file, some dummy
  72.    filename should be supported.
  73.  
  74.    CCCP uses a TCP control channel. The default well known port number
  75.    of the channel is <to be assigned by IANA>.
  76.  
  77.    If a host have multiple entities to be controlled by CCCP, different
  78.    port numbers should be used for the control channels.
  79.  
  80.    Control commands and responses are exchanged over the control channel
  81.    with TELNET style ASCII.
  82.  
  83.    Unlike FTP, it is required that server and client must support
  84.    monitor the control and data connections simultaneously.
  85.  
  86.    CCCP assumes a single controller for each device. The appropriate
  87.    interaction mechanisms between multiple controllers vary application
  88.    by application and should be handled application level coordination
  89.    entity, from which CCCP should be used to the device. This assumption
  90.    does not prohibit multiple controllers control a multiport VoD server
  91.    independently.
  92.  
  93.    Like FTP, a single controller may, of course, control several
  94.    devices.
  95.  
  96.    2. Commands
  97.  
  98.    The following commands of CCCP have exactly the same semantics as
  99.    FTP.
  100.  
  101.       USER NAME
  102.  
  103.       PASSWORD
  104.  
  105.       ACCOUNT
  106.  
  107.       CHANGE WORKING DIRECTORY
  108.  
  109.  
  110.  
  111.  
  112. M. Ohta              Expires on September 17, 1997              [Page 2]
  113.  
  114. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  115.  
  116.  
  117.       CHANGE TO PARENT DIRECTORY
  118.  
  119.       STRUCTURE MOUNT
  120.  
  121.       REINITIALIZE
  122.  
  123.       LOGOUT
  124.  
  125.       PRINT WORKING DIRECTORY
  126.  
  127.       LIST
  128.  
  129.       NAMELIST
  130.  
  131.       SYSTEM
  132.  
  133.       STATUS
  134.  
  135.       HELP
  136.  
  137.       NOOP
  138.  
  139.    No further explanation on them are given in this memo.
  140.  
  141.    The following commands of CCCP are subset or extension of the
  142.    commands of FTP with the same name. The modifications are explained
  143.    in section 3.
  144.  
  145.       DATA PORT (PORT)
  146.  
  147.       PASSIVE (PASV)
  148.  
  149.       PRESENTATION TYPE (TYPE)
  150.  
  151.       TRANSFER MODE (MODE)
  152.  
  153.       RETRIEVE (RETR)
  154.  
  155.       STORE (STOR)
  156.  
  157.       ABORT (ABOR)
  158.  
  159.    The following commands of CCCP are unique to CCCP to be used for tape
  160.    control explained in section 4.
  161.  
  162.       PLAY (PLAY)
  163.  
  164.       PAUSE (PAUS)
  165.  
  166.  
  167.  
  168. M. Ohta              Expires on September 17, 1997              [Page 3]
  169.  
  170. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  171.  
  172.  
  173.       RECORD (RECO)
  174.  
  175.       FAST FORWARD (FF)
  176.  
  177.       TAPE STATUS (TSTA)
  178.  
  179.    The following commands of CCCP are unique to CCCP to be used for
  180.    camera control explained in section 5.
  181.  
  182.       IRIS (IRIS)
  183.  
  184.       SENSITIVITY (SENS)
  185.  
  186.       ROLL (ROLL)
  187.  
  188.       PAN (PAN)
  189.  
  190.       TILT (TILT)
  191.  
  192.       ZOOM (ZOOM)
  193.  
  194.       HORIZONTAL (HORI)
  195.  
  196.       VERTICAL (VERT)
  197.  
  198.       DEPTH (DEPT)
  199.  
  200.       FOCUS (FOCU)
  201.  
  202.       CAMERA STATUS (CSTA)
  203.  
  204.    FTP commands not mentioned in this section do not exist in CCCP.
  205.  
  206. 3. Modified FTP Commands
  207.  
  208.    DATA PORT (PORT)
  209.  
  210.    PASSIVE (PASV)
  211.  
  212.       Unlike FTP, a port number may be one for UDP depending on TRANSFER
  213.       MODE.  A host address may be a multicast address.
  214.  
  215.    PRESENTATION TYPE (TYPE)
  216.  
  217.       The types supported by CCCP are A for ASCII, and I for
  218.       audio/visual data.  ASCII type may be used only for LIST and
  219.       NAMELIST commands, and the second format parameter, if any, should
  220.       be N.  The format of Audio/visual data is determined by the second
  221.  
  222.  
  223.  
  224. M. Ohta              Expires on September 17, 1997              [Page 4]
  225.  
  226. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  227.  
  228.  
  229.       parameter, 'M' for MPEG2-TS and 'R' for RTP. The third parameter
  230.       may supply additional information.  The format of the paramter for
  231.       RTP is a comma separated list of decimal integers of well known
  232.       RTP payload types in RFC1890 [RFC1890] to be sent or received.
  233.       For MPEG2, it is one of the following strings: "MP@ML", "SP@ML".
  234.  
  235.    TRANSFER MODE (MODE)
  236.  
  237.       The modes supported by CCCP are S for Stream (TCP), P for Packet
  238.       (UDP).  Packet mode uses UDP. Packet mode has a space separated
  239.       second unsigned decimal numeric parameter to indicated the number
  240.       of MPEG2-TS or RTP payloads included in a single UDP packet.  Only
  241.       a single RTP payload may be included in a UDP packet.  In a TCP
  242.       stream, MPEG2-TS packets, having fixed (188 bytes) size, are
  243.       packed continuously with no additional headers while RTP packets
  244.       must be preceded by 2 byte bigendian headers containing the length
  245.       of the next RTP frame.  The optional second (for Stream mode) or
  246.       third (for Packet mode) argument is an ASCII string specifying QoS
  247.       requirement to be used with RSVP [RSVP]. The format of the string
  248.       is, <to be determined>.  If no QoS is specified, transfer mode is
  249.       best effort.
  250.  
  251.    RETRIEVE (RETR)
  252.  
  253.       These command initiate the transfer of data.  When QoS is
  254.       specified with mode, PATH messages are also sent along with the
  255.       data.  Note that, with tape device, blank image or just silence
  256.       may be sent unless PLAY command is used.
  257.  
  258.    STORE (STOR)
  259.  
  260.       This command initiate the acceptance of data.  When QoS is
  261.       specified with mode, RESV messages are also sent upstream.
  262.  
  263.    ABORT (ABOR)
  264.  
  265.       This command terminates the acceptance of data.  Unlike FTP, no
  266.       special action is required, because CCCP servers can monitor
  267.       multiple ports simultaneously.  When QoS is specified with mode,
  268.       PATH or RESV messages are also stopped.
  269.  
  270. 4. Tape Control Commands
  271.  
  272.    Tape devices, such as audio or video tape recorder, have a notion of
  273.    current tape position.
  274.  
  275.    Some of the commands may be applicable to non-tape devices.
  276.    Especially, TAPE STATUS command is always supported.
  277.  
  278.  
  279.  
  280. M. Ohta              Expires on September 17, 1997              [Page 5]
  281.  
  282. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  283.  
  284.  
  285.    Some tape control commands have an argument to specify a tape
  286.    position. The position is represented in seconds with decimal
  287.    notation with optional fractional part.  The integral part should be
  288.    between 2147483647 and -2147483648, that is, can be represented by a
  289.    32 bit signed integer.  When '+' or '-' sign precedes the number, it
  290.    means a position relative to the current tape position.
  291.  
  292.    Arguments are separated by a single space character. The precision
  293.    and range of the arguments are device dependent and, sometimes,
  294.    totally ineffective.
  295.  
  296.    PLAY (PLAY)
  297.  
  298.    RECORD (REC)
  299.  
  300.       Start playing or recording from the current tape position. An
  301.       optional second argument may designate the position to stop
  302.       playing or recording.  If the stop position is already behind the
  303.       current tape position (depending on the direction of the movement)
  304.       at the beginning of the command, the command terminates.  An
  305.       optional third signed integer argument represented in decimal
  306.       notation with optional fractional part may designate the play or
  307.       record speed (e.g. 1 for normal play speed, -1 for reverse play or
  308.       record with the normal speed).
  309.  
  310.    PAUSE (PAUS)
  311.  
  312.       Stop playing, recording or fast forwarding at the current
  313.       position.
  314.  
  315.    FAST FORWARD (FF)
  316.  
  317.       Move the current tape position forward (or backward).  An optional
  318.       second argument may designate the position to stop operation.  If
  319.       the stop position is already behind the current tape position
  320.       (depending on the direction of the movement) at the beginning of
  321.       the command, the command terminates.  An optional third signed
  322.       integer argument represented in decimal notation with optional
  323.       fractional part may designate the forwarding speed (e.g. 5 for
  324.       fast forward, -5 for rewind).  During the operation, image or
  325.       sound may or may not be sent out depending on the nature of the
  326.       device.
  327.  
  328.    TAPE STATUS (TSTA)
  329.  
  330.       Will cause multiline response.  The first line begins with the
  331.       name of the command in operation (PAUS if nothing) followed by a
  332.       decimal integer with optional fractional part to show the current
  333.  
  334.  
  335.  
  336. M. Ohta              Expires on September 17, 1997              [Page 6]
  337.  
  338. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  339.  
  340.  
  341.       tape position.  Other lines begins with the tape control command
  342.       name (other than TSTA itself) supported by the device. If the
  343.       command has numeric arguments, two numbers separated by a comma
  344.       will be returned which designate the minimum and the maximum
  345.       meaningful value of the corresponding command parameter.
  346.  
  347.    Reply code of tape control commands will be "200 Command okay", "501
  348.    Syntax error" in parameters or arguments" or "502 Command not
  349.    implemented".
  350.  
  351. 5. Camera Control Commands
  352.  
  353.    Camera devices may be controlled its viewing parameters.
  354.  
  355.    Some of the commands may be applicable to non-camera devices.
  356.    Especially, CAMERA STATUS command is always supported.
  357.  
  358.    Camera control commands other than CAMERA STATUS have a numeric
  359.    argument to specify the view.
  360.  
  361.    The number is represented with decimal notation with optional
  362.    fractional part.  The integral part should be between 2147483647 and
  363.    -2147483648, that is, can be represented by a 32 bit signed integer.
  364.    When '+' or '-' sign precedes the number, it means a value relative
  365.    to the current value.
  366.  
  367.    The number may be a single character '+' or '-' with no decimal
  368.    characters, in which case, the view changes some meaningful small
  369.    amount toward the direction of the sign.
  370.  
  371.    The precision and range of the argument is device dependent and,
  372.    sometimes, be totally ineffective.
  373.  
  374.    IRIS (IRIS)
  375.  
  376.       Controls iris of a camera. Positive direction makes iris more
  377.       open.
  378.  
  379.    SENSITIVITY (SENS)
  380.  
  381.       Controls sensitivity of a (CCD) camera. Positive direction makes
  382.       image brighter.
  383.  
  384.    ROLL (ROLL)
  385.  
  386.       Controls roll angle of a camera. Positive direction turns the
  387.       camera clockwise viewed behind the camera.
  388.  
  389.  
  390.  
  391.  
  392. M. Ohta              Expires on September 17, 1997              [Page 7]
  393.  
  394. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  395.  
  396.  
  397.    PAN (PAN)
  398.  
  399.       Controls pan angle of a camera. Positive direction makes view move
  400.       right.
  401.  
  402.    TILT (TILT)
  403.  
  404.       Controls tilt angle of a camera. Positive direction makes view
  405.       move up.
  406.  
  407.    ZOOM (ZOOM)
  408.  
  409.       Controls viewing angle of a camera. Positive direction makes view
  410.       angle narrower (more zoom).
  411.  
  412.    HORIZONTAL (HORI)
  413.  
  414.       Moves a camera horizontally. Positive HORIZONTAL movement moves
  415.       the camera right viewed behind the camera.
  416.  
  417.    VERTICAL (VERT)
  418.  
  419.       Moves a camera vertically. Positive VERTICAL movement moves the
  420.       camera to the upward direction..
  421.  
  422.    DEPTH (DEPT)
  423.  
  424.       Moves a camera along the viewing direction. Positive DEPTH
  425.       movement moves the camera forward.
  426.  
  427.    FOCUS (FOCU)
  428.  
  429.       Controls focal point of a camera. Positive direction makes the
  430.       focal point farther.
  431.  
  432.    CAMERA STATUS (CSTA)
  433.  
  434.       Will cause multiline response.  The first line contain some string
  435.       such as "OK", which is ignored.  Other lines begin with the camera
  436.       control command name (other than CSTA itself) supported by the
  437.       device followed by three numbers separated by a comma which
  438.       designates the minimum meaningful, the current and maximum
  439.       meaningful values of the corresponding viewing parameter.  For the
  440.       non-commutative commands of camera motion control, the order of
  441.       them in the reply is significant. The order of Such commands are
  442.       the order of application of motions to the camera.  For example,
  443.       usually, rotations are applied first to the camera and then
  444.       translation is applied. Thus, in the reply of the CSTAT command,
  445.  
  446.  
  447.  
  448. M. Ohta              Expires on September 17, 1997              [Page 8]
  449.  
  450. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  451.  
  452.  
  453.       rotation commands appear before translation commands.
  454.  
  455.    Reply code of camera control commands will be "200 Command okay",
  456.    "501 Syntax error in parameters or arguments" or "502 Command not
  457.    implemented".
  458.  
  459. 6. URL
  460.  
  461.    The URL for CCCP is identical to that of FTP, except that it start
  462.    with "cccp" and have a different default port number.
  463.  
  464. 7. References
  465.  
  466.    [FTP] STD9, RFC959.
  467.  
  468.    [RFC1890] RFC1890.
  469.  
  470. 8. Security Considerations
  471.  
  472.    CCCP is designed after FTP and is just as secure as FTP.
  473.  
  474.    That is, CCCP control connection to servers can be protected by
  475.    password.
  476.  
  477.    Though it is possible to let the reply to USER command contain seeds
  478.    for one time password, nothing is specified in this memo.
  479.  
  480. 9. Authors' Addresses
  481.  
  482.    Masataka Ohta
  483.    Computer Center
  484.    Tokyo Institute of Technology
  485.    2-12-1, O-okayama, Meguro-ku
  486.    Tokyo 152, JAPAN
  487.  
  488.    Phone: +81-3-5734-3299
  489.    Fax: +81-3-5734-3415
  490.    EMail: mohta@necom830.hpcl.titech.ac.jp
  491.  
  492.    Kouji Nishimura
  493.    Information Processing Center
  494.    Hiroshima University
  495.    1-4-2, Kagamiyama
  496.    Higashi-Hiroshima 739, JAPAN
  497.  
  498.    Phone: +81-824-24-6262
  499.    Fax: +81-824-22-7043
  500.    EMail: kouji@hiroshima-u.ac.jp
  501.  
  502.  
  503.  
  504. M. Ohta              Expires on September 17, 1997              [Page 9]
  505.  
  506. INTERNET DRAFT         CamCoder Control Protocol            January 1997
  507.  
  508.  
  509.    Hiroaki Kago
  510.    Waseda University
  511.    3-4-1, Okubo Shinjuku-ku
  512.    Tokyo 169, JAPAN
  513.  
  514.    Phone: +81-3-5286-3116
  515.    Fax: +81-3-3209-3173
  516.    EMail: kago@olu.info.waseda.ac.jp
  517.  
  518.    Koji OKAMURA
  519.    Information Processing Center
  520.    Kobe University
  521.    1-1 Rokkodai, Nada, Kobe 657, JAPAN
  522.  
  523.    Email: oka@kobe-u.ac.jp
  524.    Phone: +81 78 803 0189
  525.    Fax:   +81 78 803 0193
  526.  
  527.    Akira AMANO
  528.    Faculty of Information Sciences
  529.    Hiroshima City University
  530.    151-5 Ozuka, Numata, Asaminami
  531.    Hiroshima 731-31, JAPAN
  532.  
  533.    Phone: +81 82 830 1766
  534.    Fax:   +81 82 830 1792
  535.    Email: a-amano@its.hiroshima-cu.ac.jp
  536.  
  537.    Shinji Shimojo
  538.    Computer Center
  539.    Osaka University
  540.    5-1 Mihogaoka, Ibaraki
  541.    Osaka 567, JAPAN
  542.  
  543.    Phone: +81 (6) 879-8793
  544.    Fax: 06-879-8814
  545.    EMail: shimojo@center.osaka-u.ac.jp
  546.  
  547.    Hiroshi FUJIWARA
  548.    Graphics Communication Laboratories
  549.    6F Annex Tohshin Bldg,
  550.    4-36-19, Yoyogi, Shibuya-ku
  551.    TOKYO 151, JAPAN
  552.  
  553.    Phone:          +81 3 5351 0181
  554.    Fax:            +81 3 5351 0184
  555.    EMail:          fujiwara@gctech.co.jp
  556.  
  557.  
  558.  
  559.  
  560. M. Ohta              Expires on September 17, 1997             [Page 10]
  561.  
  562.