搜索结果: GY/T 322.3-2019, GY/T322.3-2019, GYT 322.3-2019, GYT322.3-2019
| 标准编号 | GY/T 322.3-2019 (GY/T322.3-2019) | | 中文名称 | 网络音频应用的开放式控制架构 第3部分：用于TCP/IP网络的协议 | | 英文名称 | Audio applications of networks-open control architecture - Part 3: Protocol for TCP/IP networks | | 行业 | 广播电影电视 行业标准 (推荐) | | 中标分类 | M60 | | 字数估计 | 23,275 | | 发布日期 | 2019 | | 实施日期 | 2019-04-28 | | 发布机构 | 国家广播电视总局 | GY/T 322.3-2019
(Open control architecture for network audio applications - Part 3: Protocols for TCP/IP networks)
GY
中 华 人 民 共 和 国 广 播 电 视 行 业 标 准
网络音频应用的开放式控制架构
第 3部分：用于 TCP/IP网络的协议
Audio applications of networks - open control architecture-
Part 3: Protocol for TCP/IP networks
2019 - 04 - 28发布
2019 - 04 - 28实施
国家广播电视总局 发 布
目次
前言...II
引言...III
0.1 概述...III
0.2 文档约定...III
1 范围...1
2 规范性引用文件...1
3 术语、定义和缩略语...1
3.1 术语和定义...1
3.2 缩略语...1
4 最小实现...1
5 协议细节...1
5.1 初始化...2
5.2 设备发现...2
5.3 设备监管...3
5.4 设备复位...4
5.5 约定...4
5.6 协议数据单元...5
5.7 协议特定数据类型...15
附录 A（资料性附录） 数据类型索引...17
附录 B（资料性附录） 协议数据单元（PDU）的 UML描述...18
参考文献...19
II
前言
GY/T 322《网络音频应用的开放式控制架构》分为以下三部分：
--第1部分：框架；
--第2部分：类结构；
--第3部分：用于TCP/IP网络的协议。
本部分为GY/T 322的第3部分。
本部分按照GB/T 1.1-2009给出的规则起草。
本部分是参照 AES70-3-2015《网络音频应用的开放式控制架构 第 3部分：用于 TCP/IP 网络的协
议》编制的。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。
本部分由全国广播电影电视标准化技术委员会(SAC/TC 239)归口。
本部分起草单位：中央广播电视总台、国家广播电视总局广播电视科学研究院、国家广播电视总局
广播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪
科技股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限
公司、北京捷成世纪科技股份有限公司、苏州大学。
本部分主要起草人：钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董
升来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆。
III
引 言
0.1 概述
本部分支持在TCP/IP网络中实现符合开放式控制架构的媒体设备的远程监控。
开放式控制架构的第1部分是参照AES70-1-2015《网络音频应用的开放式控制架构 第1部分：框架》
编制的，英文原文可从http://www.aes.org/publications/standards/search.cfm?docID=101下载。
开放式控制架构的第2部分定义了用于媒体网络监控的开放式控制架构的类结构。第2部分是参照
AES70-2-2015《网络音频应用的开放式控制架构 第2部分：类结构》编制的，英文原文可从
http://www.aes.org/publications/standards/search.cfm?docID=102下载。
开放式控制架构的第3部分是参照AES70-3-2015《网络音频应用的开放式控制架构 第3部分：用于
TCP/IP网络的协议》编制的，英文原文可从
http://www.aes.org/publications/standards/search.cfm?docID=103下载。
0.2 文档约定
本部分涉及的通用数据类型适用于所有符合开放式控制架构的协议，特定数据类型只适用于本部
分。为了便于区分，通用数据类型的名称使用“Oca”前缀，而特定数据类型的名称使用“Ocp1”前缀。
网络音频应用的开放式控制架构
第 3部分：用于 TCP/IP 网络的协议
1 范围
GY/T 322的本部分规定了用于TCP/IP网络的协议。
本部分适用于网络音频应用的监控。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GY/T 322.1-2019 网络音频应用的开放式控制架构 第1部分：框架
GY/T 322.2-2019 网络音频应用的开放式控制架构 第2部分：类结构
IETF RFC 3927 IPv4本地链路地址动态配置（Dynamic Configuration of IPv4 Link-Local Addresses）
IETF RFC 4862 IPv6无状态地址自动配置（IPv6 Stateless Address Autoconfiguration）
Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport
Protocol Port Number Registry）
IETF RFC 6762 组播DNS（Multicast DNS）
IETF RFC 6763 基于DNS的服务发现（DNS-Based Service Discovery）
3 术语、定义和缩略语
3.1 术语和定义
下列术语和定义适用于本文件。
3.1.1
开放式控制协议 open control protocol；OCP
依据开放式控制架构定义的网络协议。
3.2 缩略语
下列缩略语适用于本文件。
PDU 协议数据单元（Protocol Data Unit）
4 最小实现
每个符合开放式控制架构的设备应实现本部分的全部内容。
本部分包含的特定可选项见第5章。
5 协议细节
5.1 初始化
5.1.1 IP地址初始化
在设备初始化OcaNetwork或OcaStreamNetwork对象（见GY/T 322.2-2019）时，应进行5.1.2、5.1.3、
5.1.4所述的初始化步骤。
上述对象的ControlProtocol属性值应为“OCP01”。
5.1.2 IP地址分配方法
符合开放式控制架构的设备至少应实现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设备宜使用在 IETF RFC 3927中定义的 IPv4本地链路地址；
b) IPv6设备宜使用在 IETF RFC 4862中定义的由 IPv6自动生成的 IPv6 本地链路地址。
当设备未实现本地链路地址时，应手工设置IP地址。
5.1.3 套接字和端口
获得IP地址后，设备应建立一个TCP监听套接字接收不安全的符合本部分的会话，或一个TCP监听套接
字接收安全的符合本部分的会话，或两者同时打开。
设备应使用标准IANA动态端口范围（49152到65535，见IETF RFC 6335）内的TCP端口号。在该范围内，
设备可以把不安全的监听套接字绑定到任何可用的TCP端口，以及安全的监听套接字绑定到其他可用的TCP
端口。这些端口应公告，见5.2.2。
5.2 设备发现
5.2.1 概述
设备发现，是连接到网络的符合开放式控制架构的设备使自身被公共访问目录服务获知的机制，也是
网络中的其他设备可使用目录服务查找和寻址设备的机制。
符合开放式控制架构的设备的发现进程应具备服务发现架构，其中符合开放式控制架构的设备应到网
络服务目录中自行注册，需要获悉该设备IP地址的网络实体可通过此目录获取到。
服务发现应通过基于DNS的服务发现实现（见IETF RFC 6763）。
注： “发现”一词的另一个常见用法是指设备功能的发现。在开放式控制架构中，功能发现是由设备的根块和内部块
（如果有）枚举的方法实现。这样的枚举是正常开放式控制架构的命令响应序列,对网络类型没有特殊的依赖性。
因此，它们不在本部分的范围内。有关详细信息，见 GY/T 322.1-2019 和 GY/T 322.2-2019 的 OcaBlock 类的详
细说明。
5.2.2 服务发现
如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的不安全连接，应注册
成以下服务类型：
_oca._tcp
如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的安全连接，应注册成
以下服务类型：
_ocasec._tcp
对安全和不安全的服务，注册的服务名称应与连接所用的OcaNetwork或OcaStreamNetwork对象
NameAdvertised属性相同。如果该名称变更，设备应注销旧服务，并使用新名称注册新服务。
注册可在任何期望的域中进行，在大多数应用中，建议在本地域注册。
在本地域注册应使用组播DNS（mDNS）协议（见IETF RFC 6762）。
当在本地域注册，服务名称冲突是由DNS组播协议自动解决。当通过组播DNS改变服务名称以避免冲突
时，服务名称已更改的设备应自动更新NameAdvertised属性。
注： 在非本地域注册时，名称冲突不会自动解决。因此，如果符合开放式控制架构的设备可能在非本地域注册，宜选
择唯一的缺省服务名称。
为服务注册的端口应与该设备在5.1.3中选择的端口相一致。
遵循IETF RFC 6763第6章版本标签的建议，不安全和安全注册的TXT记录应至少包含两个键/值对。第
一个键/值对应为：
txtvers=1 [OCA service registration version]
第二键/值对包含开放式控制架构的版本，应按照以下格式：
protovers=x
x是设备OcaDeviceManager对象指定的开放式控制架构版本十进制数（见GY/T 322.2-2019）。
TXT记录可包含更多的数据，只要记录包含上面提到的两个键/值对，且数据符合在IETF RFC 6763第6
章阐述的规则。TXT记录的开始字段如图1所示。如果开放式控制架构的十进制版本大于9，第二长度字段应
为0C16。
0916 txtvers=1 0B16 protovers=x
图1 TXT记录起始字段
控制器可以在所需域内通过执行一个DNS-SD服务浏览发现网络中的符合开放式控制架构的设备，查找
“_oca._tcp”服务或“_ocasec._tcp”服务，或两者。
在本地域中浏览应使用组播DNS（见IETF RFC 6762）。
5.3 设备监管
5.3.1 概述
设备监管意味着对网络上的设备可用性进行相对持续（通常是周期性的）验证。符合本部分定义的设
备监管机制，可用来监管连接的符合开放式控制架构的设备。
5.3.2 规范
每个符合开放式控制架构的设备均应实现监管机制；按照应用要求，控制器可以启用或禁用该机制。
在设备建立安全或不安全的连接后的任何时刻，控制器可通过向设备发送KeepAlive消息（见5.6.5）
启动设备监管进程。从那一刻直到断电或设备复位，该设备和控制器应使用HeartbeatTime值以确保设备和
控制器每心跳时间（HeartbeatTime）发送一个消息。该消息可以是KeepAlive消息或其他消息。
HeartbeatTime值应在KeepAlive消息中指定，并可随时变更。设备应为不同的连接支持不同
HeartBeatTime值。
一旦监管进程启动，对已建立的连接，控制器和设备应记录收到符合本部分的消息之间的时间间隔。
如果控制器或设备未接收消息的时间长度等于三倍HeartBeatTime值，应认为连接丢失，控制器或设备应关
闭该连接。关键开放式控制架构的应用应使用KeepAlive机制，而不是靠TCP/IP检测连接丢失。
示例：
如果控制器发送的第一个KeepAlive消息中HeartBeatTime值为2秒，控制器和设备必须每两秒发送一个消息。如果6秒
没有收到消息，设备和控制器将认为连接丢失。
注： 如果控制器在建立连接后未发送 KeepAlive 消息，则该连接不启动设备监管机制。在这种情况下，除非检测到 TCP
保持激活机制，否则不会对空闲连接进行连接丢失检测（即连接没有控制流量）。典型参数设置条件下的 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类型应封装为单字节，其中值0表示的布尔值false，所有其他的值表示的布尔值true。
在GY/T 322.2-2019中定义的复合数据类型（即转化为网络字节流）的单条属性应使用GY/T 322.2-
2019中的数据类型定义进行封装。
在GY/T 322.2-2019中定义的接口适用于以下封装规则：
--类方法输入参数的数量应通过 Ocp1Command 中的 Ocp1Parameters 结构中的 parameterCount 属性
传递，见 5.6.2；
--方法的输入参数应按照 GY/T 322.2-2019规定的顺序，封装在 Ocp1Command 中的 Ocp1Parameters
结构中，见 5.6.2；
--类方法输出参数的数量应通过 Ocp1response中的 Ocp1Parameters结构中的 parameterCount属性
传递，见 5.6.3；
--方法输出参数应通过 GY/T 322.2-2019规定的顺序，封装在 Ocp1Response中的 Ocp1Parameters
结构中，见 5.6.3；
--事件参数的数量应加到 Ocp1Notification中的 Ocp1ntfparams结构中 parameterCount属性；
--事件参数应通过 GY/T 322.2-2019 规定的顺序，封装在 Ocp1Notification 中的 Ocp1NtfParams
结构中的 Ocp1EventData结构中，见 5.6.4。
注： 本部分使用的数据类型索引参见附录 A。
5.5.3 示例
ClassVersion }
OcaClassID = { OcaUint16 FieldCount, OcaUint16[] Fields }
现在考虑一个具有以下值的特定类标识实例：
ClassID = { 2,{ 1,3 } },
ClassVersion = 1 }
通过上述封装规则，在网络中实例将表示为以下字节序列（十进制值，左侧的先发送）：
0, 2, 0, 1, 0, 3, 0, 1
5.6 协议数据单元
5.6.1 消息格式
5.6.1.1 概述
每个符合本部分的消息格式如图2所示。
同步值
Sync
value
协议头
header
数据
Data
协议版本
ProtocolVersion
消息大小
MessageSize
消息类型
Message
Type
消息计数
MessageCount
图2 通用消息格式
消息协议数据单元的C语言风格定义如下：
struct {
OcaUint8 syncVal;//消息同步值
Ocp1Header header;//OCP包头
OcaUint8 data[];//消息数据
} Ocp1MessagePdu；
参数定义见表1。
表1 消息协议数据单元参数定义
参......
|