`
`US. Patent No. 9,716,853
`
`Roku EX1032
`U.S. Patent No. 9,716,853
`
`0001
`
`

`

`NOTICE
`
`Consumer Electronics Association (CEA®) Standards, Bulletins and other technical publications
`are designed to serve the public interest
`through eliminating misunderstandings between
`manufacturers and purchasers, facilitating interchangeability and improvement of products, and
`assisting the purchaser in selecting and obtaining with minimum delay the proper product for his
`particular need. Existence of such Standards, Bulletins and other technical publications shall not in
`any respect preclude any member or nonmember of CEA from manufacturing or selling products
`not conforming to such Standards, Bulletins or other technical publications, nor shall the existence
`of such Standards, Bulletins and other technical publications preclude their voluntary use by those
`other than CEA members, whether the standard is to be used either domestically or internationally.
`
`Standards, Bulletins and other technical publications are adopted by CEA in accordance with the
`American National Standards Institute (ANSI) patent policy. By such action, CEA does not
`assume any liability to any patent owner, nor does it assume any obligation whatever to parties
`adopting the Standard, Bulletin or other technical publication.
`
`Note: The user’s attention is called to the possibility that compliance with this standard may
`require use ofan invention covered by patent rights.
`
`By publication of this standard, no position is taken with respect to the validity of this claim or of
`any patent rights in connection therewith. The patent holder has, however, filed a statement of
`willingness to grant a license under these rights on reasonable and nondiscriminatory terms and
`conditions to applicants desiring to obtain such a license. Details may be obtained from the
`publisher.
`
`This document does not purport to address all safety problems associated with its use or all
`applicable regulatory requirements.
`It is the responsibility of the user of this document to establish
`appropriate safety and health practices and to determine the applicability of regulatory limitations
`before its use.
`
`This document is copyrighted by the Consumer Electronics Association (CEA®) and may not be
`reproduced,
`in whole or part, without written permission. Federal copyright
`law prohibits
`unauthorized reproduction of this document by any means. Organizations may obtain permission
`to reproduce a limited number of copies by entering into a license agreement. Requests to
`reproduce text, data, charts, figures or other material should be made to CEA.
`
`(Formulated under the cognizance of the CEA R7 Home Networks Committee.)
`
`Published by
`©CONSUMER ELECTRONICS ASSOCIATION 2012
`Technology & Standards Department
`wwaEcrg
`
`All rights reserved
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0002
`
`0002
`
`

`

`CEA—931-C
`
`FOREWORD
`
`Users of this standard should be aware that ongoing standardization work in the 1394 Trade
`Association may have a future impact on this standard. The CEA has stated its intention to
`harmonize its standards with those developed within the 1394 Trade Association, and likewise
`the TA has indicated its willingness to coordinate standards development with CEA.
`
`This standard was developed under the auspices of the CEA R7 Home Network Committee.
`
`CEA-931—C supersedes CEA—931—B
`
`Users of this standard should note that in Section 4.2.1 CEA—931 Predefined URl, Page 9, 3rd
`Paragraph,
`the following typo [ path_segemnts ] should read as [ path_segments ]. See
`corrected example below.
`
`path_segments
`[
`hostport
`"http:/l"
`=
`CEA_931_UR|
`[?connlD=Connection|D]] ["?" [ "query" "?" ] operation ]
`
`]
`
`"ICEA931"
`
`[proctype
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0003
`
`0003
`
`

`

`CEA—931—C
`
`Contents
`
`INTRODUCTION ............................................................................................................. 1
`
`OVERVIEW AND SCOPE ............................................................................................... 1
`Example Scenarios .................................................................................................... 3
`Revision History ......................................................................................................... 4
`
`2.1
`2.2
`
`3.1
`3.1.1
`3.1.2
`3.2
`3.2.1
`3.2.2
`3.3
`3.4
`3.5
`
`GENERAL ........................................................................................................................ 5
`Normative References ............................................................................................... 5
`Normative Reference List ................................................................................... 5
`Normative Reference Acquisition ....................................................................... 5
`Informative References .............................................................................................. 5
`Informative Reference List .................................................................................. 5
`Informative Reference Acquisition ...................................................................... 6
`Definitions .................................................................................................................. 6
`Symbols and Abbreviations ....................................................................................... 6
`Compliance Notation ................................................................................................. 7
`SPECIFICATION ............................................................................................................. 7
`Pass—through Commands for Devices Supporting IEEE 1394 and ANC Protocols ..7
`All Devices .......................................................................................................... 7
`Target Devices ................................................................................................... 7
`Controller Devices .............................................................................................. 8
`Manufacturer—specific commands ....................................................................... 8
`Pass—through Commands for Devices Supporting HTTP .......................................... 8
`CEA-931 Predefined URI ................................................................................... 9
`Query for Support of CEA—931 URI Syntax ...................................................... 10
`Query for Support of a Specified Operation ..................................................... 10
`HTTP Status Responses .................................................................................. 11
`CEA—931 URI Examples ................................................................................... 11
`Additional CEA—931 URI Examples .................................................................. 12
`Deterministic Functions (Informative) ...................................................................... 13
`Open Issues (Informative) ........................................................................................ 13
`AV/C PASS-THROUGH CONTROL COMMAND ................................................ 14
`
`1.
`
`2.
`
`3.
`
`4.
`
`4.1
`4.1.1
`4.1.2
`4.1.3
`4.1.4
`4.2
`4.2.1
`4.2.2
`4.2.3
`4.2.4
`4.2.5
`4.2.6
`4.3
`4.4
`ANNEX A
`
`A.1.
`A11
`A.1.2
`A.1.2.1
`A.1.2.2
`A123
`A.1.2.4
`A.1.2.5
`A13
`A.1.4
`A.1 5
`A.1 6
`A2.
`
`PASS-THROUGH control command ........................................................................... 14
`Key Pass—Through Functions .................................................................................. 16
`Deterministic Functions ........................................................................................... 17
`Play function ..................................................................................................... 18
`Tune function .................................................................................................... 19
`Select disk function .......................................................................................... 20
`Select A/V input function .................................................................................. 20
`Select audio input function ............................................................................... 21
`Function keys ........................................................................................................... 21
`Vendor unique ......................................................................................................... 21
`Operation data field length ....................................................................................... 22
`Command and response frame ............................................................................... 22
`Controller implementation guideline for PASS-THROUGH command ................... 22
`
`ANNEX B
`
`APPLICATION SCENARIOS ............................................................................... 24
`
`Il
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0004
`
`0004
`
`

`

`B.1.
`8.1.1
`8.1.2
`
`IR Blaster Functionality ............................................................................................... 24
`Analog setup using lR Blasters ................................................................................ 24
`Networked PVR Example ........................................................................................ 25
`
`B.2.
`
`B.3.
`
`RCU Key Pass-through ............................................................................................... 27
`
`EXAMPLE KEY PASS-THROUGH USING HTTP ........................................................ 28
`
`CEA—93‘l-C
`
`iii
`
`Licensed to LiMin Fields. ANSI order X~589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0005
`
`0005
`
`

`

`Table of Figures
`
`Figure 1 Example Operational Scenario
`Figure 2 Example Navigation using GUI in Video
`Figure A.1 — PASS-THROUGH command format
`Figure A.2 — Field format for “play function” subcommand
`Figure A.3 — Field format for “tune function” subcommand
`Figure A.4 —— Field format for “select disk function” subcommand
`Figure A.5 — Field format for “select A/V input function” subcommand
`Figure A.6 — Field format for “select audio input function” subcommand
`Figure A.7 — Operation_data (operation_id = 7E15) field format
`Figure 8.1 IR Blaster Scenario with Analog interconnects
`Figure 8.2 Networked PVR Example
`Figure 8.3 RCU Key Pass—through
`Figure 8.4 Device connectivity diagram
`Figure 8.5 Home Page on PDA
`Figure 8.6 Highlighted icon
`Figure 8.? DTV powered on
`Figure 8.8 DTV and Cable tuner powered up
`
`Table of Tables
`
`Table 1, HTTP Response Headers
`Table A1 — Operation id List
`Table A2 — Cursor navigation and Menu operations
`Table A3 -— Numerical input operations
`Table A4 — Other operations
`Table A.5 — Deterministic functions
`Table A6 — Playback Speed
`Table A] — Function key operations
`Table A.8 — Vendor unique operation
`Table A.9 — Command and response frame for PASS-THROUGH control command
`
`CEA—931—C
`
`3
`4
`14
`18
`20
`20
`21
`21
`22
`24
`26
`27
`28
`29
`29
`30
`30
`
`11
`15
`16
`16
`17
`18
`19
`21
`21
`22
`
`iv
`
`Licensed to LiMin Fields. ANSI order X_5898351 Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0006
`
`0006
`
`

`

`CEA—931—C
`
`Remote Control Command Pass-through
`Standard for Home Networking
`
`1.
`INTRODUCTION
`This specification defines a standardized method for communication of certain basic operational
`functions between devices in a home network‘. The functions are those typically associated with
`a device’s front panel controls or remote commander. Functions associated with the operation of
`“IR blaster”2 arrangements are also accommodated by this method.
`Normative requirements are specified here for two distinct types of interfaces and their associated
`lower-layer protocols. One set is based on lEEE 1394 and A/VC commands and the other on
`devices supporting HTTP 1.1 over lP.
`
`2. OVERVIEW AND SCOPE
`Machine—to-machine control usually involves modeling the behavior of various elements
`(sometimes called sub—functions or subunits) within audio/video devices. For this discussion, we
`use the term “unit” to refer to an audio/video component such as a DVD player or satellite set-top
`receiver. Any given unit may include within it one or more different subunits. For example, an A/V
`Receiver may include audio processing subunits (such as amplifiers and filters), audio/video
`switching subunits, as well as a tuner subunit.
`A unit may include DVD playback functionality for example. A fully—featured machine-machine
`interface (MMl) to the DVD playback unit would involve a device control model (DCM) of the DVD
`disk player subunit. Device control models typically support control of all aspects of the device
`and monitoring of the status of all aspects of operation. Full DOM—based device control protocols
`are often very complex because many devices are themselves complex.
`Although it does involve commands sent from one machine to another in the home network, this
`standard takes a simpler approach to solve a simpler problem. This standard may be used to
`build a remote control unit that is capable of operating any device in the home network that is
`compliant with the standard. Traditionally, a so—called “universal remote” is a device that emulates
`the lR pulses needed to control various devices.
`it must be configured to emit the appropriate
`codes, or learn them by sampling the output of a remote one wishes to emulate. With the present
`standard,
`the function of the universal remote is accomplished by translating,
`in a controller
`device such as a DTV,
`iR codes received from that device’s native remote into standard
`commands on the network bus. The operations defined here apply equally well to devices in the
`same room as to devices in other rooms accessible via the network.
`We consider a home network to be made up of various types of interconnected AudioNideo
`devices. Some are sources of AN data; others take in AN data and process it for output or
`
`
`
`1 While the commands are specified here in terms of protocols built on the lEEE-1394 standard and on
`HTTP over lP, the commands could be transported via other standards including other physical
`layer
`protocols as they travel from source device to receiving device in the network.
`2 lR Blasters involve infrared emitters on or connected to one device that are programmed to emit infrared
`pulses emulating the remote control codes recognized by another device. The emitter is placed in proximity
`of the device to be controlled. Functions such as tuning and operation of a recording device can be
`performed using an IR Blaster approach.
`
`Licensed to LiMin Fields. ANSl order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0007
`
`0007
`
`

`

`CEA—931—C
`
`display (visual or audio). Some devices in the network may function only to control different
`devices in the network.
`
`The current standard specifies certain commands sent from one A/V device to another in the
`home network that represents the kinds of functions that are so basic they are often associated
`with dedicated keys on the remote control unit. The kinds of functions considered here include
`such things as power on/off, channel up/down, volume up/down, direct entry of channel numbers,
`and media playback and record controls (play, pause, stop, fast forward and rewind, record).
`Operations considered for inclusion here communicate simple user intent across the network,
`ideally in response to a single, simple user action. The operation is one of a set of operations that
`enable a remote control associated with any device on the network with video display capability to
`perform basic functions on any device in the network.
`in the protocols described in this standard, the controller device (the one issuing the command)
`can know whether the target device has implemented the particular function, and whether it was
`able to perform the indicated action.
`in some situations, it is up to the user to know whether the
`action that was performed was actually the desired action, for example, by visual or audio
`feedback.
`
`is defined by the
`The functions specified here have an effect on the target device that
`manufacturer of that device. As an example, the “POWER” control function corresponds to the
`behavior that would occur if the user hit the Power key on the target device’s native remote. A
`particular target device may use the Power key as “enter low-power standby” or it may be a power
`toggle. These functions are used in conjunction with visual feedback to the user, for example via
`an on—screen display or front panel.
`A source device can create on-screen displays by
`embedding text and graphics into its video output. Or,
`if CEA—775-A [6] graphics are used, the
`on—screen display can be created from bitmaps delivered across the 1394 bus.
`This standard does not specify the method a controller device might use to determine which
`target device on the network should be the recipient of a given command. Typically for example,
`controllers would send video playback—related command to the networked device currently
`selected as the video source and audio—related commands (mute, volume control) to the device
`designated as the audio subsystem associated with that source device.
`As several different a/v devices in the room may receive infrared pulses from a given remote
`control unit, and a controller device may translate these pulses into a network command, a given
`device may receive both a network—delivered command and that same command in the form of
`infrared pulses. This standard does not specify design requirements to avoid command
`duplication in such casesa.
`
`In summary, this standard
`
`.
`
`.
`
`involves network-communicated remote control unit (RCU) commands that convey a
`simple user intent, usually in response to a single, simple user action;
`does not specify specific behavior required of the target device in response to any given
`function, although guidance on expected behavior is provided (exact behavior is at the
`discretion of the device manufacturer); and
`
`- may be used to build a remote control unit that is capable of operating any compliant
`device in the home network.
`
`
`3 it is recommended that in the case a target device determines that the same command has been received
`both via infrared pulses and via the network, it should reply to the PASS-THROUGH command with the
`ACCEPTED response (even if the infrared pulses arrived first).
`
`2
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0008
`
`0008
`
`

`

`CEA-931—C
`
`2. 1 Example Scenarios
`In this simple
`Figure 1 shows an example network where the DTV acts as the “controller” device.
`scenario, the user has selected the Personal Video Recorder (PVR) on the right as the input
`source. Using the protocol specified in this standard, a PLAY key on the DTV remote is
`interpreted by the DTV as indicating a desire on the part of the user to start playback of the
`recorded or paused video content. The DTV recognizes the IR pulses, which may be emitted
`using a proprietary format, as being the PLAY key. The DTV then creates a command delivered
`on the Home Network backbone to the PVR, indicating “perform your PLAY operation.”
`
`DTV
`
`Room to Room
`Network
`Interface (opt)
`Interconnect
`
`
`
`IR pulses
`(proprietary
`format)
`
`"PLAY"
`command
`
`PVR
`
`
`
`Figure 1 Example Operational Scenario
`
`The figure shows that the PVR may or may not be in the same room as the DTV receiver—
`optionally, a room—to-room network interface may separate the two.
`If the DTV and PVR are in
`the same room, the protocol defined in this standard offers the features of a “universal remote” in
`that an RCU from one manufacturer can control a device made by another manufacturer. The
`conversion between proprietary IR pulse formats and a standard command on the bus makes this
`possible.
`Figure 2 illustrates commands used to interact with and control a source device via a Graphical
`User Interface the source provides over video or via bitmaps per CEA—775—A [6]. A GUI generated
`within the source device could be MPEG-2 encoded and delivered across the network bus as
`compressed video, or CEA—775—A bitmaps could be supplied for the DTV to mix with video. The
`user can interact with the source device’s GUI using the DTV’s RCU as long as the GUI uses only
`the basic navigational keys:
`the numeric keys (0—9), the arrow keys (up, down, left, right), Enter
`(or “OK”), and Cancel, and those keys are provided on the DTV remote.
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0009
`
`0009
`
`

`

`CEA—931—C
`
`PTV
`
`
`
`
`
`GUI in Video
`(or ElA-775A bitmaps)
`my ,
`, ~>Wmagmwxm, c
`,Wpfiwmw
`, swank
`>
`Wang.a .i.
`
`R pUlseS
`(proprietary
`format)
`
`commands
`0-9, «um Enter, Cancel
`
`Control
`
`
`
`RCU
`
`Figure 2 Example Navigation using GUI in Video
`
`2.2 Revision History
`Revision A incorporates Version 1.21 of the AV/C Panel Subunit specification, which added the
`operation_id values corresponding to “deterministic functions,” values 6015 through 6A16. Annex A
`includes this update of the AV/C document.
`Informative Section 4.5 in the present revision
`discusses deterministic functions. Section 4 was expanded to describe requirements for both
`target and controller devices. Support of the AV/C POWER control commands is now mandatory.
`Informative Annex B was added to describe an IR Blaster scenario and an example application of
`CEA-931 in a digital networked environment.
`
`Revision B defines the CEA-931 URI and specifies normative requirements for devices
`supporting HTTP 1.1 over lP. This fully backward—compatible extension to CEA-931-A is designed
`to allow devices networked via lP protocols to communicate the same set of RCU key codes and
`deterministic functions as those defined for the AV/C—based method. Section 8.3 in Annex B was
`added to illustrate an example usage scenario for this option.
`
`Revision C adds references to L3 Bridged 1394/COAX and FCP over in4 [2], AV/C Panel
`Subunit specification 1.23 [3].
`In addition Hostport and path_segments was added to the HTTP
`command sequence to allow for addressing logical units as defined in CEA—2027—B [9]. Added
`optional allowance for the procedure extension type and the connection ID to appear in the HTTP
`command sequence (additional examples were added in Section 4.2.6).
`
`Licensed to LiMin Fields. ANSI order Xw589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0010
`
`0010
`
`

`

`CEA—931—C
`
`3. GENERAL
`
`3.1 Normative References
`
`through reference in this text, constitute
`The following standards contain provisions that,
`normative provisions of the appropriate sections of this standard. At the time of publication, the
`editions indicated were valid. All standards are subject to revision, and parties to agreements
`based on this standard are encouraged to investigate the possibility of applying for the most
`recent editions of the standards listed in Section 3.1.1.
`
`3.1.1 Normative Reference List
`
`1. AV/C Digital interface Command Set General Specification, Version 4.1, TA Document
`2002012, 1394 Trade Association, December 11, 2001.
`
`2.
`
`lEEE 1394 Bridged over Coaxial Cable — Part 3: FCP and CMP over IPv4, TA Document
`2006021, Revision d0.5, 1394 Trade Association, March 19, 2007.
`
`3. AV/C Panel Subunit Specification 123, TA Document 2007001, 1394Trade Association,
`January 2007.
`
`4. RFC 2616, Hypertext Transfer Protocol — HTTP 1.1, The Internet Society, June 1999.
`
`5. RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, The Internet Society,
`August 1998.
`
`3.1.2 Normative Reference Acquisition
`
`1394 Trade Association Documents
`
`- Contact the 1394 Trade Association, 1111 South Main Street, Suite 100, Grapevine, TX, USA;
`Phone: 817—410-5750; Fax: 817-410—5752; Internet: http://www1394taorg.
`
`RFC Documents
`
`the World Wide Web Consortia (W30), 32 Vassar Street, Room 32—G515,
`. Contact
`Cambridge, MA 02139 USA; Phone: 617-253-2613; Fax: 617.258.5999; Internet www.w3.org.
`
`. Contact the Internet Society (ISOC), 1775 Wiehle Ave., Suite 102, Reston, VA 20190 USA;
`Phone: 703—326—9880; Fax: 703—326—9881; internet: www.isoc@isoc.org.
`
`3.2
`
`Informative References
`
`3.2.1
`
`Informative Reference List
`
`6. CEA—775—A, DTV 1394 Interface Specification, April 2000.
`
`7. CEA—775.1, Web-Enhanced DTV 1394 Interface Specification, March 2000.
`
`8. ECMAScript Language Specification, Standard ECMA—262, 3ml Edition, December 1999.
`
`9. CEA—2027-B, A User Interface Specification for Home Networks Using Web—Based
`Protocols, July 2007.
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0011
`
`0011
`
`

`

`CEA—931—C
`
`3.2.2
`
`Informative Reference Acquisition
`
`CEA Standards:
`
`. Global Engineering Documents, World Headquarters, 15 Inverness Way East, Englewood,
`CO USA 80112-5776; Phone: 800-854—7179; Fax: 303-397—2740; Internet: http://globatihscom;
`E—mail: global@ihs.com.
`
`ECMA Standards:
`
`.
`
`ECMA International, 114 Rue du Rhéne - CH-1204 Geneva —— Switzerland;
`httg://www.ecma~international.org.
`
`Internet:
`
`3.3 Definitions
`
`For the purposes of this document, the following definitions apply.
`
`Controller
`
`direct mode
`
`indirect mode
`
`Subunit
`
`target
`
`Unit
`
`As defined in [1], a device at a serial bus node that sends AV/C
`commands to control a remote AV/C target device.
`
`In direct mode,
`A data transfer mode of the Panel Subunit defined in [3].
`the Panel Subunit is responsible for creating the on—screen user interface
`based on information provided by the target device. User operations are
`processed in the controller device, and when a UI object (such as a
`button) is activated, that fact is communicated across the network bus to
`the target. For details, refer to Section 4.4 of [3].
`
`A data transfer mode of the Panel Subunit defined in [3]. Allows the Panel
`Subunit to receive user manipulations but the Panel Subunit is not
`responsible for display of Ul data on the controller screen. The GUI image
`might be transmitted to the display device as part of the video data
`transmitted from the target device (eg. using EIA—799 bitmaps). The Panel
`Subunit controller conveys user operations to the target by only AV/C
`PASS-THROUGH commands, and works simply like a remote commander
`of the target device. For details, refer to Section 4.5 of [3].
`
`A uniquely identifiable and addressable entity contained within a unit. The
`Panel Subunit is a type of subunit defined in [3].
`
`As defined in [1], a device at a serial bus node that receives and responds
`to AV/C commands from a remote controller device.
`
`The instantiation of an AV/C device. A unit is addressable in a specific way
`using AV/C commands. A unit may contain zero or more subunits.
`
`3.4 Symbols and Abbreviations
`ANSI
`American National Standards Institute
`AN
`Audio/Video
`AVIC
`AudioNideo Control
`CEA
`Consumer Electronics Association
`DTV
`Digital Television
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0012
`
`0012
`
`

`

`CEA—931-C
`
`DV
`DVCR
`EIA
`
`GUI
`HTTP
`IEC
`lEEE
`IP
`ISO
`PVR
`RCU
`
`RFC
`TA
`UI
`URI
`
`Digital Video
`Digital Video Cassette Recorder
`Electronic Industries Alliance
`
`graphical user interface
`HyperText Transfer Protocol
`International Electrotechnical Commission
`Institute of Electrical and Electronics Engineers
`Internet Protocol
`International Organization for Standardization
`personal video recorder
`remote control unit
`
`Request for Comments
`Trade Association
`user interface
`Universal Resource Identifier
`
`3.5 Compliance Notation
`As used in this document, "shall” denotes a mandatory provision of the standard. “Should”
`denotes a provision that is recommended but not mandatory. ”May” denotes a feature whose
`presence does not preclude compliance that may or may not be present at the option of the
`implementer.
`”Optional” denotes items that may or may not be present
`in a compliant
`implementation.
`
`4.
`SPECIFICATION
`The following sections describe requirements for compliance with this standard. Devices
`originating commands issued for the purpose of controlling other devices are called “controllers.”
`Devices accepting and responding to the control commands defined here are called “targets.”
`Normative requirements are specified for two distinct types of interfaces and their associated
`lower-layer protocols. One set
`is based on IEEE 1394 and ANC commands or Bridged
`1394/COAX using A/VC commands with FCP/IPv4 and the other on devices supporting HTTP 1.1
`over IP.
`
`4.1 Pass-through Commands for Devices Supporting IEEE 1394 and A/VC Protocols
`The requirements in this section apply normatively to audio/video devices supporting lEEE 1394
`and AV/C protocols.
`
`All Devices
`4.1.1
`the minimum requirements of the AV/C Digital
`Target and controller devices shall support
`Interface Command Set General Specification [1].
`In addition, for 1394 devices that support L3
`Bridging then the PCP and CMP over IPv4 Specification [2] shall be supported.
`
`4.1.2 Target Devices
`Target devices shall support the SUBUNIT INFO status command defined in Section 11.3 of the
`AV/C Digital Interface Command Set General Specification [1] and shall include in the SUBUNIT
`INFO command status response a subunit_type value 0916 indicating the presence of a Panel
`Subunit.
`
`Licensed to LiMin Fields. ANSI order X_589835. Downloaded 7/26/2019. Single user license only. Copying and networking prohibited.
`0013
`
`0013
`
`

`

`CEA-931—C
`
`lndirect Mode, defined and described in
`implement the Panel Subunit,
`Target devices shall
`Sections 4.3 and 4.5 of AV/C Panel Subunit Specification [3]. A target device may return a
`response of “NOT IMPLEMENTED” to the GUI UPDATE status command. Target devices shall
`respond with “IMPLEMENTED” to the GENERAL INQUIRY command for PASS—THROUGH command.
`
`implement the PASS-THROUGH control command specified in Section 9
`Target devices shall
`(introduction) and Section 9.4 of AV/C Panel Subunit Specification [3].
`
`Target devices should respond to PASS-THROUGH control commands with operation_id values
`corresponding to user operations or deterministic functions applicable to that device.
`If a given
`operation_id value corresponds to an operation or function that is not applicable to the device,
`that device should respond to the PASS—THROUGH control command with a NOT IMPLEMENTED
`response.
`
`Target devices shall implement the POWER control command defined in Section 11.1 of [1], and
`shall support both the Control and Status forms of that command.
`
`4.1.3 Controller Devices
`
`Controller devices shall use the AV/C Panel Subunit PASS-THROUGH control command.
`Controllers may verify that a particular target device supports this specification by:
`
`1.
`
`issuing a SUBUNIT INFO AV/C command in accordance with Section 11.3 of [1];
`
`2. verifying the presence of a Panel Subunit (subunit_type value 0916) in the response;
`
`3.
`
`issuing a GENERAL INQUIRY command for PASS-THROUGH command;
`
`4. verifying the response is “IMPLEMENTED.”
`Implementation guidelines for controllers described in Section 9.4.7 of [3] should be followed.
`
`4.1.4 Manufacturer—specific commands
`One form of the PASS-THROUGH command provides a mechanism whereby a manufacturer may
`deliver nonstandard data related to the remote control key function. The format of the Vendor
`Unique PASS-THROUGH command includes a 24—bit Organizationally Unique Identifier (OUI) code
`so that any given target device can ensure that the manufacturer-specific bytes contained in the
`command are understood and supported before processing them. The AV/C specification calls
`the OUI field company ID. The syntax and semantics of bytes following the company ID are
`defined in whatever way the given manufacturer wishes.
`
`A target device shall disregard a Vendor Unique PASS-THROUGH command containing an
`unrecognized value for company ID. The Vendor Unique PASS—THROUGH command shall not be
`used to convey RCU key commands that can be represented by one of the standard values for
`operation_id listed in this standard“.
`
`4.2 Pass-through Commands for Devices Supporting HTTP
`The requirements in this section apply normatively to audio/video devices supporting the HTTP
`method of remote control pass—through. Such compliant devices shall support HTTP version 1.1
`(as defined in RFC 2616 [4]).
`
`
`4 If the operation_id list is expanded in a future version of this standard to include new RCU keys, a vendor
`may conti