GY/T 322. 3-2019
基本信息
标准号： GY/T 322. 3-2019
中文名称：网络音频应用的开放式控制架构 第3部分:用于TCP/IP网络的协议
标准类别：广播电影电视行业标准(GY)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：1439713
相关标签： 网络 音频 应用 开放式 控制 架构 用于 协议
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GY/T 322. 3-2019.Audio applications of networks - open control architecture-Part 3: Protocol for TCP/IP networks.
GY/T 322的本部分规定了用于TCP/ IP网络的协议。
GY/T 322. 3适用于网络音频应用的监控。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GY/T 322. 1- -2019网络音 频应用的开放式控制架构第1部分: 框架
GY/T 322.2- -2019网络 音频应用的开放式控制架构第2部分: 类结构
IETF RFC 3927 IPv4 本地链路地址动态配置(Dynamic Confi guration of IPv4 Link-Local Addresses)
IETF RFC 4862 IPv6无状态地址 自动配置(IPv6 Stateless Address Autoconf igurat ion)
IETF RFC 6335互联网数字 分配机构(IANA) 为服务名称和传输协议端口号注册管理程序( Internet Ass i gned Numbers Authority (IANA) Procedures for the Management of the Serv ice Name and Transport Protocol Port Number Registry)
IETF RFC 6762组播DNS (Multicast DNS)
IETF RFC 6763基于DNS的服务 发现(DNS- Based Service Di scovery )
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。
3.1.1开放式控制协议open control protocol; OCP依据开放式控制架构定义的网络协议。
3.2缩略语
下列缩略语适用于本文件。
PDU协议数据单元 (Protocol Data Unit)
4最小实现每个符合开放式控制架构的设备应实现本部分的全部内容。
GY/T 322. 3包含的特定可选项见第5章。
5协议细节
GY/T 322的本部分规定了用于TCP/ IP网络的协议。
GY/T 322. 3适用于网络音频应用的监控。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GY/T 322. 1- -2019网络音 频应用的开放式控制架构第1部分: 框架
GY/T 322.2- -2019网络 音频应用的开放式控制架构第2部分: 类结构
IETF RFC 3927 IPv4 本地链路地址动态配置(Dynamic Confi guration of IPv4 Link-Local Addresses)
IETF RFC 4862 IPv6无状态地址 自动配置(IPv6 Stateless Address Autoconf igurat ion)
IETF RFC 6335互联网数字 分配机构(IANA) 为服务名称和传输协议端口号注册管理程序( Internet Ass i gned Numbers Authority (IANA) Procedures for the Management of the Serv ice Name and Transport Protocol Port Number Registry)
IETF RFC 6762组播DNS (Multicast DNS)
IETF RFC 6763基于DNS的服务 发现(DNS- Based Service Di scovery )
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。
3.1.1开放式控制协议open control protocol; OCP依据开放式控制架构定义的网络协议。
3.2缩略语
下列缩略语适用于本文件。
PDU协议数据单元 (Protocol Data Unit)
4最小实现每个符合开放式控制架构的设备应实现本部分的全部内容。
GY/T 322. 3包含的特定可选项见第5章。
5协议细节
标准图片预览
标准内容
中华人民共和国广播电视行业标准GY/T322.3—2019
网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议Audio applications of networks - open control architecturePart3:ProtocolforTCP/IPnetworks2019-04-28发布
国家广播电视总局
2019-04-28实施
文档约定
规范性引用文件
术语、定义和缩略语
3.1术语和定义
3.2缩略语，
最小实现
协议细节
初始化·
设备发现，
设备监管..
设备复位。
约定．.
协议数据单元，
5.7协议特定数据类型
附录A（资料性附录）
附录B（资料性附录）
参考文献
数据类型索引
协议数据单元（PDU）的UML描述GY/T322.3—2019
GY/T322.3—2019
GY/T322《网络音频应用的开放式控制架构》分为以下三部分：第1部分：框架：
第2部分：类结构：
第3部分：用于TCP/IP网络的协议。本部分为GY/T322的第3部分。wwW.bzxz.Net
本部分按照GB/T1.1一2009给出的规则起草。本部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议》编制的。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由全国广播电影电视标准化技术委员会（SAC/TC239）归口。本部分起草单位：中央广播电视总台、国家广播电视总局广播电视科学研究院、国家广播电视总局广播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪科技股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限公司、北京捷成世纪科技股份有限公司、苏州大学。本部分主要起草人：钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董升来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆。I
0.1概述
本部分支持在TCP/IP网络中实现符合开放式控制架构的媒体设备的远程监控。GY/T322.3—2019
开放式控制架构的第1部分是参照AES70-1-2015《网络音频应用的开放式控制架构第1部分：框架》编制的，英文原文可从http://aes.org/publications/standards/search.cfm?docID=101下载。开放式控制架构的第2部分定义了用于媒体网络监控的开放式控制架构的类结构。第2部分是参照AES70-2-2015《网络音频应用的开放式控制架构第2部分：类结构》编制的，英文原文可从http://aes.org/publications/standards/search.cfm?docID=102下载。开放式控制架构的第3部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议》编制的，英文原文可从http://aes.org/publications/standards/search.cfm?docID=1o3下载0.2文档约定
本部分涉及的通用数据类型适用于所有符合开放式控制架构的协议，特定数据类型只适用于本部分。为了便于区分，通用数据类型的名称使用“Oca”前缀，而特定数据类型的名称使用“Ocp1”前缀。III
网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议GY/T322的本部分规定了用于TCP/IP网络的协议。本部分适用于网络音频应用的监控。规范性引用文件
GY/T322.3—2019
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件GY/T322.1一2019网络音频应用的开放式控制架构第1部分：框架GY/T322.2一2019网络音频应用的开放式控制架构第2部分：类结构IETFRFC3927IPv4本地链路地址动态配置（DynamicConfigurationofIPv4Link-LocalAddresses）IETFRFC4862IPv6无状态地址自动配置（IPv6StatelessAddressAutoconfiguration）IETFRFC6335互联网数字分配机构（IANA）为服务名称和传输协议端口号注册管理程序（InternetAssigned Numbers Authority (IANA) Procedures for the Management of the Service Name and TransportProtocol Port Number Registry)IETFRFC6762组播DNS（MulticastDNS）IETFRFC6763基于DNS的服务发现（DNS-BasedServiceDiscovery）3
术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。3.1.1
开放式控制协议opencontrolprotocol；ocP依据开放式控制架构定义的网络协议。3.2缩略语
下列缩略语适用于本文件。
PDU协议数据单元（ProtocolDataUnit）4最小实现
每个符合开放式控制架构的设备应实现本部分的全部内容。本部分包含的特定可选项见第5章。5
协设细节
GY/T322.3—2019
5.1初始化
5.1.1IP地址初始化
在设备初始化OcaNetwork或OcaStreamNetwork对象（见GY/T322.2—2019）时，应进行5.1.2、5.1.3、5，1：4所述的初始化步骤。
上述对象的ControlProtocol属性值应为“ocPo1”。5.1.2IP地址分配方法
符合开放式控制架构的设备至少应实现IPv4或IPv6网络寻址标准。在本部分，实现IPv4网络寻址的符合开放式控制架构的设备称为IPv4设备。实现IPv6网络寻址的符合开放式控制架构的设备称为IPv6设备。设备可同时实现IPv4和IPv6，即它可同时是IPv4设备和IPv6的设备。每个IPv4设备宜实现DHCP客户端并使用DHCP服务器。每个IPv6设备宜实现DHCPv6客户端并使用DHCPv6服务器。在下文中，这些客户端和服务器将分别统称为IP地址客户端和IP地址服务器。如果设备属于多个IP子网，它宜为每个子网设置一个IP地址客户端。当设备连接一个子网时，设备宜启动对应的IP地址客户端。
如果在地址分配超时时段内IP地址客户端连接到IP地址服务器，则该设备应使用该服务器分配的地址。当在地址分配超时时段内未发现IP地址服务器，或设备未实现IP地址客户端：a）IPv4设备宜使用在IETFRFC3927中定义的IPv4本地链路地址：b）IPv6设备宜使用在IETFRFC4862中定义的由IPv6自动生成的IPv6本地链路地址。当设备未实现本地链路地址时，应手工设置IP地址。5.1.3套接字和端口
获得IP地址后，设备应建立一个TCP监听套接字接收不安全的符合本部分的会话，或一个TCP监听套接字接收安全的符合本部分的会话，或两者同时打开。设备应使用标准IANA动态端口范围（49152到65535，见IETFRFC6335）内的TCP端口号。在该范围内，设备可以把不安全的监听套接字绑定到任何可用的TCP端口，以及安全的监听套接字绑定到其他可用的TCP端口。这些端口应公告，见5.2.2。5.2设备发现
5.2.1概述
设备发现，是连接到网络的符合开放式控制架构的设备使自身被公共访问目录服务获知的机制，也是网络中的其他设备可使用自录服务查找和寻址设备的机制。符合开放式控制架构的设备的发现进程应具备服务发现架构，其中符合开放式控制架构的设备应到网络服务目录中自行注册，需要获悉该设备IP地址的网络实体可通过此目录获取到。服务发现应通过基于DNS的服务发现实现（见IETFRFC6763）注：“发现”一词的另一个常见用法是指设备功能的发现在开放式控制架构中，功能发现是由设备的根块和内部块（如果有）枚举的方法实现。这样的枚举是正常开放式控制架构的命令响应序列，对网络类型没有特殊的依赖性。因此，它们不在本部分的范围内。有关详细信息，见GY/T322.1一2019和GY/T322.2一2019的0caB1ock类的详细说明。
5.2.2服务发现
如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的不安全连接，应注册成以下服务类型：
如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的安全连接，应注册成以下服务类型：
ocasec._tcp
GY/T322.3—2019
对安全和不安全的服务，注册的服务名称应与连接所用的OcaNetwork或OcaStreamNetwork对象NameAdvertised属性相同。如果该名称变更，设备应注销旧服务，并使用新名称注册新服务。注册可在任何期望的域中进行，在大多数应用中，建议在本地域注册。在本地域注册应使用组播DNS（mDNS）协议（见IETFRFC6762）当在本地域注册，服务名称冲突是由DNS组播协议自动解决。当通过组播DNS改变服务名称以避免冲突时，服务名称已更改的设备应自动更新NameAdvertised属性。注：在非本地域注册时，名称冲突不会自动解决。因此，如果符合开放式控制架构的设备可能在非本地域注册，宜选择唯一的缺省服务名称。
为服务注册的端口应与该设备在5.1.3中选择的端口相一致。遵循IETFRFC6763第6章版本标签的建议，不安全和安全注册的TXT记录应至少包含两个键/值对。第一个键/值对应为：
txtvers=l [ocA service registration version]第二键/值对包含开放式控制架构的版本，应按照以下格式：protovers=x
x是设备0caDeviceManager对象指定的开放式控制架构版本十进制数（见GY/T322.2一2019），TXT记录可包含更多的数据，只要记录包含上面提到的两个键/值对，且数据符合在IETFRFC6763第6章阐还的规则。TT记录的开始学段如图1所示。如果开放式控制架构的十进制版本大于9，第二长度学段应为oC16。
txtvers=1
protovers=:
图1TXT记录起始字段
控制器可以在所需域内通过执行一个DNS-SD服务浏览发现网络中的符合开放式控制架构的设备，查找“_oca._tcp”服务或“_ocasec._tcp”服务，或两者。在本地域中浏览应使用组播DNS（见IETFRFC6762）。5.3设备监管
5.3.1概述
设备监管意味着对网络上的设备可用性进行相对持续（通常是周期性的）验证。符合本部分定义的设备监管机制，可用来监管连接的符合开放式控制架构的设备。5.3.2规范
每个符合开放式控制架构的设备均应实现监管机制：按照应用要求，控制器可以启用或禁用该机制。在设备建立安全或不安全的连接后的任何时刻，控制器可通过向设备发送KeepA1ive消息（见5.6.5）启动设备监管进程。从那一刻直到断电或设备复位，该设备和控制器应使用HeartbeatTime值以确保设备和控制器每心跳时间（HeartbeatTime）发送一个消息。该消息可以是KeepAlive消息或其他消息。HeartbeatTime值应在KeepAlive消息中指定，并可随时变更。设备应为不同的连接支持不同HeartBeatTime值。
一旦监管进程启动，对已建立的连接，控制器和设备应记录收到符合本部分的消息之间的时间间隔。如果控制器或设备未接收消息的时间长度等于三倍HeartBeatTime值，应认为连接丢失，控制器或设备应关闭该连接。关键开放式控制架构的应用应使用KeepA1ive机制，而不是靠TCP/IP检测连接丢失。示例：
如果控制器发送的第一个KeepAlive消息中HeartBeatTime值为2秒，控制器和设备必须每两秒发送一个消息。如果6秒没有收到消息，设备和控制器将认为连接丢失。3
GY/T322.3—2019
注：如果控制器在建立连接后未发送KeepA1ive消息，则该连接不启动设备监管机制。在这种情况下，除非检测到TCF保持激活机制，否则不会对空闲连接进行连接丢失检测（即连接没有控制流量）。典型参数设置条件下的TCP保持激活机制的检测超时时长超长，是不可接受的，往往需要数小时。此外，并非所有的TCP/IP协议栈都能正确地实现保持激活机制，
当连接丢失时，如果可能的话，控制器和设备应执行适当的终止处理。应删除连接上的锁和订阅，并清除连接信息。
5.4设备复位
5.4.1概述
符合开放式控制架构的设备可实现设备复位机制。5.4.2未实现复位
如果设备未实现复位机制，它应以NotImplemented状态响应SetResetKey消息，且不执行其他操作。否则，根据5.4.3规定的操作。
5.4.3实现复位
上电复位后，设备应禁用复位机制。若要启用复位机制，控制器应先调用设备的OcaDeviceManager对象的SetResetKey方法。当调用SetResetKey时，控制器应传递以下参数：ResetKey：一个128bit设备复位校验码；ResetAddress：设备应监听DeviceReset消息（见5.6.6）的OcaNetworkAddress（见5.7.2）。该地址应包含一个UDP端口号的数据类型，以及，可选的一个IPv4或IPv6组播地址。当收到SetResetKey的消息，该设备应配置相关机制，在ResetAddress参数指定的端口打开UDP套接字。如果ResetAddress参数同时指定一个组播地址，设备应加入指定的组播组。如果收到多个SetResetKey消息，应使用最新的SetResetKey消息给出的参数。旦复位机制配置完毕，设备应监听用于获得包含给定设备复位校验码的DeviceReset消息的UDP套接字。如果接收到这样一个复位消息，设备应执行上电复位。如果给定的ResetAddress不包含一个组播地址，复位消息将通过指定的端口直接发送到设备上。如果ResetAddress包含一个组播地址，复位消息将直接发送到该设备的指定端口或组播组的指定端口。如果收到的DeviceReset消息包含指定消息以外的复位校验码值，消息应被忽略并不执行复位操作。设备复位或关机后，设备应解除其复位机制。该机制可由上述过程重新配置。注：如果设备的复位校验码是通过不安全的开放式控制协议（OCP）连接发送，可能会被截获并被恶意使用，导致系统破坏。当需要在有破坏威胁的环境下使用设备复位机制时，SetResetKey消息只宜通过安全的OCP连接发送实现设备复位机制的设备宜提供手动方式（例如：开关、跳线或面板命令）来禁用该功能。5.5约定
5.5.1字节顺序
对于基本的符合开放式控制架构的整型数据类型和字长超过1个字节的浮点数据类型，本部分应使用网络字节顺序（即大端或高位优先）。5.5.2封装规则
OcaBoolean类型应封装为单字节，其中值o表示的布尔值false，所有其他的值表示的布尔值true。在GY/T322.2一2019中定义的复合数据类型（即转化为网络字节流）的单条属性应使用GY/T322.2-2019中的数据类型定义进行封装。在GY/T322.2一2019中定义的接口适用于以下封装规则：一类方法输入参数的数量应通过OcplCommand中的OcplParameters结构中的parameterCount属性传递，见5.6.2；
GY/T322.3—2019
方法的输入参数应按照GY/T322.2一2019规定的顺序，封装在Ocp1Command中的0cp1Parameters结构中，见5.6.2：
类方法输出参数的数量应通过Ocplresponse中的OcplParameters结构中的parameterCount属性传递，见5.6.3；
方法输出参数应通过GY/T322.2—2019规定的顺序，封装在Ocp1Response中的Ocp1Parameters结构中，见5.6.3；
事件参数的数量应加到OcplNotification中的Ocplntfparams结构中parameterCount属性：事件参数应通过GY/T322.2—2019规定的顺序，封装在Ocp1Notification中的Ocp1NtfParams结构中的Ocp1EventData结构中，见5.6.4。注：本部分使用的数据类型索引参见附录A。示例
考虑OcaclassIdentification复合数据类型，在occ定义如下：OcaclassIdentification=［OcaclassIDclassIDOcaClassVersionNumber
ClassVersion1
OcaClassID=【OcaUintl6FieldCount,OcaUint16[]Fields}OcaClassVersionNumber = {OcaUintl6Value]现在考虑一个具有以下值的特定类标识实例：OcaClassIdentification classIdentification=[ClassID={2,[1,3}],
ClassVersion = 1
通过上述封装规则，在网络中实例将表示为以下字节序列（十进制值，左侧的先发送）：0,2,0,1,0,3,0,1
5.6协议数据单元
5.6.1消息格式
5.6.1.1概述
每个符合本部分的消息格式如图2所示。同步值
协议头
header
协议版本
ProtocolVersion
消息大小
Messagesize
消息类型
Message
消息计数
MessageCount
图2通用消息格式
消息协议数据单元的C语言风格定义如下：struct{
OcaUint8
syncVal;
//消息同步值
GY/T322.3——2019
OcplHeader
OcaUint8
header
OcpMessagePdu;
参数定义见表1。
syncVal
header
//OCP包头
//消息数据
消息协议数据单元参数定义
消息同步值指示一个新符合本部分的消息的开始。同步值应为常量3B本部分包头包含通用消息字段
存放实际消息数据的数据数组
接收器应始终检查每一个以同步值开始的符合本部分的消息。如果接收到的消息不以标准同步值开始，则接收器应关闭与发送器的连接。注：连接断开之后，所涉及的控制器可以选择重启连接。开放式控制架构没有定义标准的恢复程序。协议数据单元可由GB/T28167一2011中定义的XML元数据交换（XMI）2.1格式的通用建模语言（UML）文定义。相关文件的获取途径参见附录B。5.6.1.2包头
符合本部分的数据结构的C语言风格定义如下：struct
OcaUint16
OcaUint32
OcaMessageType
OcaUint16
1Ocp1Header;
参数定义见表2。
protocolVersion
（长度为2字节）
pduSize
（长度为4字节）
pduType
（长度为1字节）
messageCount
（长度为2字节）
命令消息
5.6.2.1格式
protocolVersion;
pdusize;
pduType;
messageCount ;
//版本号
//PDU字节长度
//PDU类型
//消息数量
包头参数定义
本部分的协议版本号。开放式控制架构的类有自已的版本号，因此只有在本部分中描述的本部分的协议更新时，协议版本才更新
完整PDU的字节长度，包括包头，但不包括同步值
表示PDU的类型：即，包含的PDU消息类型。应使用下列消息类型之一（值在括号之间）：OcaCmd(o)
OcaCmdRrq(1)
OcaNtf(2)
OcaRsp(3)
OcakeepAlive (4)
命令-不需要响应
命令-需要响应
响应（对应命令或通知）
用于设备监管的保持激活消息
消息数量，显示在数据字段有多少消息（pduType类型）。此消息数量应至少为1。如果pduType等于OcaKeepAlive，消息数量应为1命令消息格式如图3所示。
命令大小
CormandSize
同步值
协议头
header
命令句柄
Handle
目标编号
Target
类树层级
TreeLevel
命令1
方法ID
MethodID
方法索引
MethodIndex
命令2
参数计数
Parameter
命令消息
命令消息协议数据单元的C语言风格定义如下：structt
OcaUint8
OcplHeader
Ocp1Command
syncval:
header:
commands [messageCountI:
Ocp1CommandPdu;
参数定义见表3。
syncVal
（长度为1字节）
header
（长度为9字节）
commands
（可变长度）
消息同步值（见5.6.1.1）
命令消息计数》
Command
Parameters
参数1
//消息同步值
//OCP包头
//命令数组
命令消息参数定义
通用消息字段。见5.6.1.2的OcplHeader定义参数2
GY/T322.3——2019
参数（参数计数》
Parameter Parameter Count
命令（messageCount）数组。命令格式由Ocp1Command类型定义，见5.6.2.25.6.2.2Ocp1Command
Ocp1Command数据结构的c语言风格定义如下：struct t
OcaUint32
OcaUint32
OcaONo
OcaMethodID
OcplParameters
1Ocp1Command;
参数定义见表4。
commandSize;
handle:
targetoNo:
methodID:
parameters;
//单条命令的长度
//命令句柄
//在控制器设备中的目的对象编号//被调用方法的ID
//被调用消息的输入参数
GY/T322.3—2019
commandSize
（长度为4字节）
handle
（长度为4字节）
targetoNo
(长度为4字节）
methodID
(长度为4字节)
parameters
(可变长度）
Ocp1Command参数定义
单条命令的长度，以字节为单位。应包含commandSize字段完整的Ocp1Command结构的长度强制使用32bit作为对于命令引用“handle”。响应应使用同样的handle值。控制器可自由地为命令分配handle值，设备应在对应的响应中匹配这些handle值。在控制器和设备之间，对于每个TCP会话应用私有handle
在控制器设备中的目的对象编号（OcaONo）。OcaONo应使用4字节（即一个OcaUint32）被调用方法的ID（OcaMethodID）（即目标对象调用的方法）：见5.6.2.3被调用消息的输入参数。如果被调用的方法没有任何参数，该结构应保留5.6.2.3
OcaMethodID
OcaMethodID数据结构的C语言风格定义如下：struct t
OcaUint16
OcaUint16
1OcaMethodID:
treeLevel;
methodIndex:
元素定义见表5。
treeLevel
(长度为2字节）
methodIndex
（长度为2字节）
//类树层级
//方法的索引
OcaMethodID元素定义
在本方法中定义的类树层级（1=root）方法的索引。定义了方法的类应决定索引值。对于每个树层级，索引应起始于1类元素分类详见GY/T322.1—2019。Ocp1Parameters
Ocp1Parameters数据结构的c语言风格定义如下：struct
OcaUint8
parameterCount;
//参数数量
OcaUint8
parameters [:
1OcpiParameters:
元素定义见表6。
//参数数组
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议Audio applications of networks - open control architecturePart3:ProtocolforTCP/IPnetworks2019-04-28发布
国家广播电视总局
2019-04-28实施
文档约定
规范性引用文件
术语、定义和缩略语
3.1术语和定义
3.2缩略语，
最小实现
协议细节
初始化·
设备发现，
设备监管..
设备复位。
约定．.
协议数据单元，
5.7协议特定数据类型
附录A（资料性附录）
附录B（资料性附录）
参考文献
数据类型索引
协议数据单元（PDU）的UML描述GY/T322.3—2019
GY/T322.3—2019
GY/T322《网络音频应用的开放式控制架构》分为以下三部分：第1部分：框架：
第2部分：类结构：
第3部分：用于TCP/IP网络的协议。本部分为GY/T322的第3部分。wwW.bzxz.Net
本部分按照GB/T1.1一2009给出的规则起草。本部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议》编制的。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由全国广播电影电视标准化技术委员会（SAC/TC239）归口。本部分起草单位：中央广播电视总台、国家广播电视总局广播电视科学研究院、国家广播电视总局广播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪科技股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限公司、北京捷成世纪科技股份有限公司、苏州大学。本部分主要起草人：钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董升来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆。I
0.1概述
本部分支持在TCP/IP网络中实现符合开放式控制架构的媒体设备的远程监控。GY/T322.3—2019
开放式控制架构的第1部分是参照AES70-1-2015《网络音频应用的开放式控制架构第1部分：框架》编制的，英文原文可从http://aes.org/publications/standards/search.cfm?docID=101下载。开放式控制架构的第2部分定义了用于媒体网络监控的开放式控制架构的类结构。第2部分是参照AES70-2-2015《网络音频应用的开放式控制架构第2部分：类结构》编制的，英文原文可从http://aes.org/publications/standards/search.cfm?docID=102下载。开放式控制架构的第3部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议》编制的，英文原文可从http://aes.org/publications/standards/search.cfm?docID=1o3下载0.2文档约定
本部分涉及的通用数据类型适用于所有符合开放式控制架构的协议，特定数据类型只适用于本部分。为了便于区分，通用数据类型的名称使用“Oca”前缀，而特定数据类型的名称使用“Ocp1”前缀。III
网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议GY/T322的本部分规定了用于TCP/IP网络的协议。本部分适用于网络音频应用的监控。规范性引用文件
GY/T322.3—2019
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件GY/T322.1一2019网络音频应用的开放式控制架构第1部分：框架GY/T322.2一2019网络音频应用的开放式控制架构第2部分：类结构IETFRFC3927IPv4本地链路地址动态配置（DynamicConfigurationofIPv4Link-LocalAddresses）IETFRFC4862IPv6无状态地址自动配置（IPv6StatelessAddressAutoconfiguration）IETFRFC6335互联网数字分配机构（IANA）为服务名称和传输协议端口号注册管理程序（InternetAssigned Numbers Authority (IANA) Procedures for the Management of the Service Name and TransportProtocol Port Number Registry)IETFRFC6762组播DNS（MulticastDNS）IETFRFC6763基于DNS的服务发现（DNS-BasedServiceDiscovery）3
术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。3.1.1
开放式控制协议opencontrolprotocol；ocP依据开放式控制架构定义的网络协议。3.2缩略语
下列缩略语适用于本文件。
PDU协议数据单元（ProtocolDataUnit）4最小实现
每个符合开放式控制架构的设备应实现本部分的全部内容。本部分包含的特定可选项见第5章。5
协设细节
GY/T322.3—2019
5.1初始化
5.1.1IP地址初始化
在设备初始化OcaNetwork或OcaStreamNetwork对象（见GY/T322.2—2019）时，应进行5.1.2、5.1.3、5，1：4所述的初始化步骤。
上述对象的ControlProtocol属性值应为“ocPo1”。5.1.2IP地址分配方法
符合开放式控制架构的设备至少应实现IPv4或IPv6网络寻址标准。在本部分，实现IPv4网络寻址的符合开放式控制架构的设备称为IPv4设备。实现IPv6网络寻址的符合开放式控制架构的设备称为IPv6设备。设备可同时实现IPv4和IPv6，即它可同时是IPv4设备和IPv6的设备。每个IPv4设备宜实现DHCP客户端并使用DHCP服务器。每个IPv6设备宜实现DHCPv6客户端并使用DHCPv6服务器。在下文中，这些客户端和服务器将分别统称为IP地址客户端和IP地址服务器。如果设备属于多个IP子网，它宜为每个子网设置一个IP地址客户端。当设备连接一个子网时，设备宜启动对应的IP地址客户端。
如果在地址分配超时时段内IP地址客户端连接到IP地址服务器，则该设备应使用该服务器分配的地址。当在地址分配超时时段内未发现IP地址服务器，或设备未实现IP地址客户端：a）IPv4设备宜使用在IETFRFC3927中定义的IPv4本地链路地址：b）IPv6设备宜使用在IETFRFC4862中定义的由IPv6自动生成的IPv6本地链路地址。当设备未实现本地链路地址时，应手工设置IP地址。5.1.3套接字和端口
获得IP地址后，设备应建立一个TCP监听套接字接收不安全的符合本部分的会话，或一个TCP监听套接字接收安全的符合本部分的会话，或两者同时打开。设备应使用标准IANA动态端口范围（49152到65535，见IETFRFC6335）内的TCP端口号。在该范围内，设备可以把不安全的监听套接字绑定到任何可用的TCP端口，以及安全的监听套接字绑定到其他可用的TCP端口。这些端口应公告，见5.2.2。5.2设备发现
5.2.1概述
设备发现，是连接到网络的符合开放式控制架构的设备使自身被公共访问目录服务获知的机制，也是网络中的其他设备可使用自录服务查找和寻址设备的机制。符合开放式控制架构的设备的发现进程应具备服务发现架构，其中符合开放式控制架构的设备应到网络服务目录中自行注册，需要获悉该设备IP地址的网络实体可通过此目录获取到。服务发现应通过基于DNS的服务发现实现（见IETFRFC6763）注：“发现”一词的另一个常见用法是指设备功能的发现在开放式控制架构中，功能发现是由设备的根块和内部块（如果有）枚举的方法实现。这样的枚举是正常开放式控制架构的命令响应序列，对网络类型没有特殊的依赖性。因此，它们不在本部分的范围内。有关详细信息，见GY/T322.1一2019和GY/T322.2一2019的0caB1ock类的详细说明。
5.2.2服务发现
如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的不安全连接，应注册成以下服务类型：
如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的安全连接，应注册成以下服务类型：
ocasec._tcp
GY/T322.3—2019
对安全和不安全的服务，注册的服务名称应与连接所用的OcaNetwork或OcaStreamNetwork对象NameAdvertised属性相同。如果该名称变更，设备应注销旧服务，并使用新名称注册新服务。注册可在任何期望的域中进行，在大多数应用中，建议在本地域注册。在本地域注册应使用组播DNS（mDNS）协议（见IETFRFC6762）当在本地域注册，服务名称冲突是由DNS组播协议自动解决。当通过组播DNS改变服务名称以避免冲突时，服务名称已更改的设备应自动更新NameAdvertised属性。注：在非本地域注册时，名称冲突不会自动解决。因此，如果符合开放式控制架构的设备可能在非本地域注册，宜选择唯一的缺省服务名称。
为服务注册的端口应与该设备在5.1.3中选择的端口相一致。遵循IETFRFC6763第6章版本标签的建议，不安全和安全注册的TXT记录应至少包含两个键/值对。第一个键/值对应为：
txtvers=l [ocA service registration version]第二键/值对包含开放式控制架构的版本，应按照以下格式：protovers=x
x是设备0caDeviceManager对象指定的开放式控制架构版本十进制数（见GY/T322.2一2019），TXT记录可包含更多的数据，只要记录包含上面提到的两个键/值对，且数据符合在IETFRFC6763第6章阐还的规则。TT记录的开始学段如图1所示。如果开放式控制架构的十进制版本大于9，第二长度学段应为oC16。
txtvers=1
protovers=:
图1TXT记录起始字段
控制器可以在所需域内通过执行一个DNS-SD服务浏览发现网络中的符合开放式控制架构的设备，查找“_oca._tcp”服务或“_ocasec._tcp”服务，或两者。在本地域中浏览应使用组播DNS（见IETFRFC6762）。5.3设备监管
5.3.1概述
设备监管意味着对网络上的设备可用性进行相对持续（通常是周期性的）验证。符合本部分定义的设备监管机制，可用来监管连接的符合开放式控制架构的设备。5.3.2规范
每个符合开放式控制架构的设备均应实现监管机制：按照应用要求，控制器可以启用或禁用该机制。在设备建立安全或不安全的连接后的任何时刻，控制器可通过向设备发送KeepA1ive消息（见5.6.5）启动设备监管进程。从那一刻直到断电或设备复位，该设备和控制器应使用HeartbeatTime值以确保设备和控制器每心跳时间（HeartbeatTime）发送一个消息。该消息可以是KeepAlive消息或其他消息。HeartbeatTime值应在KeepAlive消息中指定，并可随时变更。设备应为不同的连接支持不同HeartBeatTime值。
一旦监管进程启动，对已建立的连接，控制器和设备应记录收到符合本部分的消息之间的时间间隔。如果控制器或设备未接收消息的时间长度等于三倍HeartBeatTime值，应认为连接丢失，控制器或设备应关闭该连接。关键开放式控制架构的应用应使用KeepA1ive机制，而不是靠TCP/IP检测连接丢失。示例：
如果控制器发送的第一个KeepAlive消息中HeartBeatTime值为2秒，控制器和设备必须每两秒发送一个消息。如果6秒没有收到消息，设备和控制器将认为连接丢失。3
GY/T322.3—2019
注：如果控制器在建立连接后未发送KeepA1ive消息，则该连接不启动设备监管机制。在这种情况下，除非检测到TCF保持激活机制，否则不会对空闲连接进行连接丢失检测（即连接没有控制流量）。典型参数设置条件下的TCP保持激活机制的检测超时时长超长，是不可接受的，往往需要数小时。此外，并非所有的TCP/IP协议栈都能正确地实现保持激活机制，
当连接丢失时，如果可能的话，控制器和设备应执行适当的终止处理。应删除连接上的锁和订阅，并清除连接信息。
5.4设备复位
5.4.1概述
符合开放式控制架构的设备可实现设备复位机制。5.4.2未实现复位
如果设备未实现复位机制，它应以NotImplemented状态响应SetResetKey消息，且不执行其他操作。否则，根据5.4.3规定的操作。
5.4.3实现复位
上电复位后，设备应禁用复位机制。若要启用复位机制，控制器应先调用设备的OcaDeviceManager对象的SetResetKey方法。当调用SetResetKey时，控制器应传递以下参数：ResetKey：一个128bit设备复位校验码；ResetAddress：设备应监听DeviceReset消息（见5.6.6）的OcaNetworkAddress（见5.7.2）。该地址应包含一个UDP端口号的数据类型，以及，可选的一个IPv4或IPv6组播地址。当收到SetResetKey的消息，该设备应配置相关机制，在ResetAddress参数指定的端口打开UDP套接字。如果ResetAddress参数同时指定一个组播地址，设备应加入指定的组播组。如果收到多个SetResetKey消息，应使用最新的SetResetKey消息给出的参数。旦复位机制配置完毕，设备应监听用于获得包含给定设备复位校验码的DeviceReset消息的UDP套接字。如果接收到这样一个复位消息，设备应执行上电复位。如果给定的ResetAddress不包含一个组播地址，复位消息将通过指定的端口直接发送到设备上。如果ResetAddress包含一个组播地址，复位消息将直接发送到该设备的指定端口或组播组的指定端口。如果收到的DeviceReset消息包含指定消息以外的复位校验码值，消息应被忽略并不执行复位操作。设备复位或关机后，设备应解除其复位机制。该机制可由上述过程重新配置。注：如果设备的复位校验码是通过不安全的开放式控制协议（OCP）连接发送，可能会被截获并被恶意使用，导致系统破坏。当需要在有破坏威胁的环境下使用设备复位机制时，SetResetKey消息只宜通过安全的OCP连接发送实现设备复位机制的设备宜提供手动方式（例如：开关、跳线或面板命令）来禁用该功能。5.5约定
5.5.1字节顺序
对于基本的符合开放式控制架构的整型数据类型和字长超过1个字节的浮点数据类型，本部分应使用网络字节顺序（即大端或高位优先）。5.5.2封装规则
OcaBoolean类型应封装为单字节，其中值o表示的布尔值false，所有其他的值表示的布尔值true。在GY/T322.2一2019中定义的复合数据类型（即转化为网络字节流）的单条属性应使用GY/T322.2-2019中的数据类型定义进行封装。在GY/T322.2一2019中定义的接口适用于以下封装规则：一类方法输入参数的数量应通过OcplCommand中的OcplParameters结构中的parameterCount属性传递，见5.6.2；
GY/T322.3—2019
方法的输入参数应按照GY/T322.2一2019规定的顺序，封装在Ocp1Command中的0cp1Parameters结构中，见5.6.2：
类方法输出参数的数量应通过Ocplresponse中的OcplParameters结构中的parameterCount属性传递，见5.6.3；
方法输出参数应通过GY/T322.2—2019规定的顺序，封装在Ocp1Response中的Ocp1Parameters结构中，见5.6.3；
事件参数的数量应加到OcplNotification中的Ocplntfparams结构中parameterCount属性：事件参数应通过GY/T322.2—2019规定的顺序，封装在Ocp1Notification中的Ocp1NtfParams结构中的Ocp1EventData结构中，见5.6.4。注：本部分使用的数据类型索引参见附录A。示例
考虑OcaclassIdentification复合数据类型，在occ定义如下：OcaclassIdentification=［OcaclassIDclassIDOcaClassVersionNumber
ClassVersion1
OcaClassID=【OcaUintl6FieldCount,OcaUint16[]Fields}OcaClassVersionNumber = {OcaUintl6Value]现在考虑一个具有以下值的特定类标识实例：OcaClassIdentification classIdentification=[ClassID={2,[1,3}],
ClassVersion = 1
通过上述封装规则，在网络中实例将表示为以下字节序列（十进制值，左侧的先发送）：0,2,0,1,0,3,0,1
5.6协议数据单元
5.6.1消息格式
5.6.1.1概述
每个符合本部分的消息格式如图2所示。同步值
协议头
header
协议版本
ProtocolVersion
消息大小
Messagesize
消息类型
Message
消息计数
MessageCount
图2通用消息格式
消息协议数据单元的C语言风格定义如下：struct{
OcaUint8
syncVal;
//消息同步值
GY/T322.3——2019
OcplHeader
OcaUint8
header
OcpMessagePdu;
参数定义见表1。
syncVal
header
//OCP包头
//消息数据
消息协议数据单元参数定义
消息同步值指示一个新符合本部分的消息的开始。同步值应为常量3B本部分包头包含通用消息字段
存放实际消息数据的数据数组
接收器应始终检查每一个以同步值开始的符合本部分的消息。如果接收到的消息不以标准同步值开始，则接收器应关闭与发送器的连接。注：连接断开之后，所涉及的控制器可以选择重启连接。开放式控制架构没有定义标准的恢复程序。协议数据单元可由GB/T28167一2011中定义的XML元数据交换（XMI）2.1格式的通用建模语言（UML）文定义。相关文件的获取途径参见附录B。5.6.1.2包头
符合本部分的数据结构的C语言风格定义如下：struct
OcaUint16
OcaUint32
OcaMessageType
OcaUint16
1Ocp1Header;
参数定义见表2。
protocolVersion
（长度为2字节）
pduSize
（长度为4字节）
pduType
（长度为1字节）
messageCount
（长度为2字节）
命令消息
5.6.2.1格式
protocolVersion;
pdusize;
pduType;
messageCount ;
//版本号
//PDU字节长度
//PDU类型
//消息数量
包头参数定义
本部分的协议版本号。开放式控制架构的类有自已的版本号，因此只有在本部分中描述的本部分的协议更新时，协议版本才更新
完整PDU的字节长度，包括包头，但不包括同步值
表示PDU的类型：即，包含的PDU消息类型。应使用下列消息类型之一（值在括号之间）：OcaCmd(o)
OcaCmdRrq(1)
OcaNtf(2)
OcaRsp(3)
OcakeepAlive (4)
命令-不需要响应
命令-需要响应
响应（对应命令或通知）
用于设备监管的保持激活消息
消息数量，显示在数据字段有多少消息（pduType类型）。此消息数量应至少为1。如果pduType等于OcaKeepAlive，消息数量应为1命令消息格式如图3所示。
命令大小
CormandSize
同步值
协议头
header
命令句柄
Handle
目标编号
Target
类树层级
TreeLevel
命令1
方法ID
MethodID
方法索引
MethodIndex
命令2
参数计数
Parameter
命令消息
命令消息协议数据单元的C语言风格定义如下：structt
OcaUint8
OcplHeader
Ocp1Command
syncval:
header:
commands [messageCountI:
Ocp1CommandPdu;
参数定义见表3。
syncVal
（长度为1字节）
header
（长度为9字节）
commands
（可变长度）
消息同步值（见5.6.1.1）
命令消息计数》
Command
Parameters
参数1
//消息同步值
//OCP包头
//命令数组
命令消息参数定义
通用消息字段。见5.6.1.2的OcplHeader定义参数2
GY/T322.3——2019
参数（参数计数》
Parameter Parameter Count
命令（messageCount）数组。命令格式由Ocp1Command类型定义，见5.6.2.25.6.2.2Ocp1Command
Ocp1Command数据结构的c语言风格定义如下：struct t
OcaUint32
OcaUint32
OcaONo
OcaMethodID
OcplParameters
1Ocp1Command;
参数定义见表4。
commandSize;
handle:
targetoNo:
methodID:
parameters;
//单条命令的长度
//命令句柄
//在控制器设备中的目的对象编号//被调用方法的ID
//被调用消息的输入参数
GY/T322.3—2019
commandSize
（长度为4字节）
handle
（长度为4字节）
targetoNo
(长度为4字节）
methodID
(长度为4字节)
parameters
(可变长度）
Ocp1Command参数定义
单条命令的长度，以字节为单位。应包含commandSize字段完整的Ocp1Command结构的长度强制使用32bit作为对于命令引用“handle”。响应应使用同样的handle值。控制器可自由地为命令分配handle值，设备应在对应的响应中匹配这些handle值。在控制器和设备之间，对于每个TCP会话应用私有handle
在控制器设备中的目的对象编号（OcaONo）。OcaONo应使用4字节（即一个OcaUint32）被调用方法的ID（OcaMethodID）（即目标对象调用的方法）：见5.6.2.3被调用消息的输入参数。如果被调用的方法没有任何参数，该结构应保留5.6.2.3
OcaMethodID
OcaMethodID数据结构的C语言风格定义如下：struct t
OcaUint16
OcaUint16
1OcaMethodID:
treeLevel;
methodIndex:
元素定义见表5。
treeLevel
(长度为2字节）
methodIndex
（长度为2字节）
//类树层级
//方法的索引
OcaMethodID元素定义
在本方法中定义的类树层级（1=root）方法的索引。定义了方法的类应决定索引值。对于每个树层级，索引应起始于1类元素分类详见GY/T322.1—2019。Ocp1Parameters
Ocp1Parameters数据结构的c语言风格定义如下：struct
OcaUint8
parameterCount;
//参数数量
OcaUint8
parameters [:
1OcpiParameters:
元素定义见表6。
//参数数组
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。