GY/T 322.3-2019 网络音频应用的开放式控制架构 第 3 部分：用于 TCP/IP 网络的协议

GY

中华人民共和国广播电视行业标准

GY/T322.3—2019

网络音频应用的开放式控制架构

第3部分：用于TCP/IP网络的协议

Audioapplicationsofnetworks-opencontrolarchitecture—

Part3:ProtocolforTCP/IPnetworks

2019-04-28发布2019-04-28实施

国家广播电视总局发布

GY/T322.3—2019

目次

前言................................................................................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

I

GY/T322.3—2019

前言

GY/T322《网络音频应用的开放式控制架构》分为以下三部分：

——第1部分：框架；

——第2部分：类结构；

——第3部分：用于TCP/IP网络的协议。

本部分为GY/T322的第3部分。

本部分按照GB/T1.1—2009给出的规则起草。

本部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协

议》编制的。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。

本部分由全国广播电影电视标准化技术委员会(SAC/TC239)归口。

本部分起草单位：中央广播电视总台、国家广播电视总局广播电视科学研究院、国家广播电视总局

广播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪

科技股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限

公司、北京捷成世纪科技股份有限公司、苏州大学。

本部分主要起草人：钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董

升来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆。

II

GY/T322.3—2019

引言

0.1概述

本部分支持在TCP/IP网络中实现符合开放式控制架构的媒体设备的远程监控。

开放式控制架构的第1部分是参照AES70-1-2015《网络音频应用的开放式控制架构第1部分：框架》

编制的，英文原文可从/publications/standards/search.cfm?docID=101下载。

开放式控制架构的第2部分定义了用于媒体网络监控的开放式控制架构的类结构。第2部分是参照

AES70-2-2015《网络音频应用的开放式控制架构第2部分：类结构》编制的，英文原文可从

/publications/standards/search.cfm?docID=102下载。

开放式控制架构的第3部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于

TCP/IP网络的协议》编制的，英文原文可从

/publications/standards/search.cfm?docID=103下载。

0.2文档约定

本部分涉及的通用数据类型适用于所有符合开放式控制架构的协议，特定数据类型只适用于本部

分。为了便于区分，通用数据类型的名称使用“Oca”前缀，而特定数据类型的名称使用“Ocp1”前缀。

III

GY/T322.3—2019

网络音频应用的开放式控制架构

第3部分：用于TCP/IP网络的协议

1范围

GY/T322的本部分规定了用于TCP/IP网络的协议。

本部分适用于网络音频应用的监控。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。

凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

GY/T322.1—2019网络音频应用的开放式控制架构第1部分：框架

GY/T322.2—2019网络音频应用的开放式控制架构第2部分：类结构

IETFRFC3927IPv4本地链路地址动态配置（DynamicConfigurationofIPv4Link-LocalAddresses）

IETFRFC4862IPv6无状态地址自动配置（IPv6StatelessAddressAutoconfiguration）

IETFRFC6335互联网数字分配机构（IANA）为服务名称和传输协议端口号注册管理程序（Internet

AssignedNumbersAuthority(IANA)ProceduresfortheManagementoftheServiceNameandTransport

ProtocolPortNumberRegistry）

IETFRFC6762组播DNS（MulticastDNS）

IETFRFC6763基于DNS的服务发现（DNS-BasedServiceDiscovery）

3术语、定义和缩略语

3.1术语和定义

下列术语和定义适用于本文件。

3.1.1

开放式控制协议opencontrolprotocol；OCP

依据开放式控制架构定义的网络协议。

3.2缩略语

下列缩略语适用于本文件。

PDU协议数据单元（ProtocolDataUnit）

4最小实现

每个符合开放式控制架构的设备应实现本部分的全部内容。

本部分包含的特定可选项见第5章。

5协议细节

1

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属性值应为“OCP01”。

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的OcaBlock类的详

细说明。

5.2.2服务发现

如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的不安全连接，应注册

成以下服务类型：

_oca._tcp

如果一个符合开放式控制架构的设备打开了一个监听套接字来建立符合本部分的安全连接，应注册成

以下服务类型：

2

GY/T322.3—2019

_ocasec._tcp

对安全和不安全的服务，注册的服务名称应与连接所用的OcaNetwork或OcaStreamNetwork对象

NameAdvertised属性相同。如果该名称变更，设备应注销旧服务，并使用新名称注册新服务。

注册可在任何期望的域中进行，在大多数应用中，建议在本地域注册。

在本地域注册应使用组播DNS（mDNS）协议（见IETFRFC6762）。

当在本地域注册，服务名称冲突是由DNS组播协议自动解决。当通过组播DNS改变服务名称以避免冲突

时，服务名称已更改的设备应自动更新NameAdvertised属性。

注：在非本地域注册时，名称冲突不会自动解决。因此，如果符合开放式控制架构的设备可能在非本地域注册，宜选

择唯一的缺省服务名称。

为服务注册的端口应与该设备在5.1.3中选择的端口相一致。

遵循IETFRFC6763第6章版本标签的建议，不安全和安全注册的TXT记录应至少包含两个键/值对。第

一个键/值对应为：

txtvers=1[OCAserviceregistrationversion]

第二键/值对包含开放式控制架构的版本，应按照以下格式：

protovers=x

x是设备OcaDeviceManager对象指定的开放式控制架构版本十进制数（见GY/T322.2—2019）。

TXT记录可包含更多的数据，只要记录包含上面提到的两个键/值对，且数据符合在IETFRFC6763第6

章阐述的规则。TXT记录的开始字段如图1所示。如果开放式控制架构的十进制版本大于9，第二长度字段应

为0C16。

0916txtvers=10B16protovers=x

图1TXT记录起始字段

控制器可以在所需域内通过执行一个DNS-SD服务浏览发现网络中的符合开放式控制架构的设备，查找

“_oca._tcp”服务或“_ocasec._tcp”服务，或两者。

在本地域中浏览应使用组播DNS（见IETFRFC6762）。

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秒

没有收到消息，设备和控制器将认为连接丢失。

3

GY/T322.3—2019

注：如果控制器在建立连接后未发送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