GY/T 304-2016 高性能流化音频在IP网络上的互操作性规范

GY

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

GY/T304—2016

高性能流化音频在IP网络上的

互操作性规范

High-performancestreamingaudio-over-IPinteroperability

2017-01-04发布2017-01-04实施

国家新闻出版广电总局发布

GY/T304—2016

目次

前言................................................................................II

引言...............................................................................III

1范围..............................................................................1

2规范性引用文件....................................................................1

3术语、定义和缩略语................................................................2

4同步..............................................................................6

5媒体时钟..........................................................................6

6传输..............................................................................7

7编码与成流........................................................................9

8会话描述.........................................................................12

9发现服务.........................................................................14

10连接管理........................................................................14

附录A（规范性附录）媒体类别.......................................................16

附录B（资料性附录）IEEE802.1AS时钟域接口........................................19

附录C（资料性附录）网络QoS配置建议...............................................21

附录D（资料性附录）AVB网络传输...................................................23

附录E（资料性附录）发现系统.......................................................26

参考文献............................................................................28

I

GY/T304—2016

前言

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

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

本标准由全国广播电影电视标准化技术委员会（SAC/TC239）归口。

本标准起草单位：中央人民广播电台、中央电视台、国家新闻出版广电总局广播科学研究院、国家

新闻出版广电总局广播电视规划院、北京英夫美迪科技股份有限公司、苏州市福川科技有限公司、北京

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

本标准主要起草人：钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、张伟、邓向冬、韦安明、

何晶、董晓坡、陈武、陈沁、唐卫平、练文杰。

II

GY/T304—2016

引言

高性能媒体网络支持以低延迟（小于10ms）传输专业质量的音频信号（采用线性PCM编码，采样率

不低于44.1kHz，量化精度不低于16位），并适用于现场扩声。局域网及企业级网络的性能都可以满足

作为高性能媒体网络的要求，但广域网或公共互联网的性能通常无法满足要求。

尽管截至本标准颁布前出现的使用各种专有和标准协议的此类媒体网络都基于IP协议，但它们之间

无法互操作。

本标准是参照AES67—2015《High-performancestreamingaudio-over-IPinteroperability》编

制的。

本标准提出了高性能媒体网络互操作性的具体规定。本标准重点规定如何使用现有的协议来创建可

互操作的系统。基于这一点，并未开发其他新的协议。

III

GY/T304—2016

高性能流化音频在IP网络上的互操作性规范

1范围

本标准规定了在IP网络上传输全频带和低噪声的高性能音频的互操作模式。

本标准适用于广播、音乐制作和影视后期制作设备间信号的交换，也可用于商业音频应用，如固

定和流动的现场扩声。

2规范性引用文件

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

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

GB/T25931—2010网络测量和控制系统的精确时钟同步协议（IEC61588—2009，IDT）

IETFRFC768用户数据报协议（UserDatagramProtocol）

IETFRFC791互联网协议（InternetProtocol)

IETFRFC1112IP组播的主机扩展（HostExtensionsforIPMulticasting）

IETFRFC2236互联网组管理协议，第二版（InternetGroupManagementProtocol,Version

2）

IETFRFC2474IPv4和IPv6包头中的区分服务字段（DS字段）的定义（Definitionofthe

DifferentiatedServicesField（DSField）intheIPv4andIPv6Headers）

IETFRFC2616超文本传输协议-HTTP/1.1（HypertextTransferProtocol-HTTP/1.1）

IETFRFC2974会话公告协议（SessionAnnouncementProtocol）

IETFRFC319012位DAT音频和20位、24位线性采样音频的RTP有效载荷格式（RTPPayloadFormat

for12-bitDATAudioand20-and24-bitLinearSampledAudio）

IETFRFC3261SIP:会话发起协议（SIP:SessionInitiationProtocol）

IETFRFC3264使用会话描述协议（SDP）实现会话提议/应答的模型（AnOffer/AnswerModel

withtheSessionDescriptionProtocol（SDP））

IETFRFC3376互联网组管理协议，第三版（InternetGroupManagementProtocol,Version

3）

IETFRFC3550RTP：实时传输协议（RTP:ATransportProtocolforReal-TimeApplications）

IETFRFC3551使用最小控制的音视频会议RTP类别（RTPProfileforAudioandVideo

ConferenceswithMinimalControl）

IETFRFC4566会话描述协议（SessionDescriptionProtocol）

IETFRFC7273RTP时钟源信令（RTPClockSourceSignalling）

AES5—2008脉冲编码调制采用的优先采样频率（AESrecommendedpracticeforprofessional

digitalaudio—Preferredsamplingfrequenciesforapplicationsemployingpulse-code

modulation）

AES11—2009(R2014)演播室数字音频系统同步（AESrecommendedpracticefordigitalaudio

engineering—Synchronizationofdigitalaudioequipmentinstudiooperations）

EBUTech3326音频在IP网络上的互操作要求（AudiocontributionoverIP-Requirementsfor

Interoperability）

1

GY/T304—2016

IEEE1588—2002网络测量和控制系统的精确时钟同步协议（IEEEStandardforaPrecision

ClockSychronizationProtocolforNetworkedMeasurementandControlSystems）

IEEE802.1AS—2011桥接局域网中时间敏感应用的定时与同步（TimingandSynchronization

forTime-SensitiveApplicationsinBridgedLocalAreaNetworks）

IEEE802.1Q—2011媒体接入控制桥和虚拟桥局域网（MediaAccessControl(MAC)Bridgesand

VirtualBridgedLocalAreaNetworks）

3术语、定义和缩略语

3.1术语和定义

下列术语和定义适用于本标准。

3.1.1

精确时间协议precisiontimeprotocol；PTP

由IEEE1588—2002、GB/T25931—2010和IEEE802.1AS—2011定义的通用时钟分发协议。

3.1.2

边界时钟boundaryclock

在一个域中具有多个精确时间协议（PTP）端口，并维护该域中所用时标的时钟。它可作为时间

源，即为主时钟；也可与另一个时钟同步，即为从时钟。

[GB/T25931—2010，定义3.1.3]

3.1.3

数字音频参考信号digitalaudioreferencesignal；DARS

AES11—2009(R2014)中定义的音频时钟信号。

3.1.4

汇入源contributingsource；CSRC

为RTP混合器生成组合流起到贡献作用的RTP流输入源。

3.1.5

区分服务differentiatedservices

对IP网络流量分级并提供不同QoS保障的系统。

3.1.6

区分服务代码点differentiatedservicescodepoint；DSCP

位于IP包头中用于分级的一个6位字段，是区分服务架构中的一部分。

3.1.7

64位扩展的唯一标识符64bitextendeduniqueidentifier；EUI-64

由一个24位或36位的公司注册标识符和一个公司唯一设备标识符组合构成的64位全球唯一标识

符。

3.1.8

最高级时钟grandmaster

2

GY/T304—2016

通过PTP进行时钟分发所需的同步主时钟源。最高级时钟是用64位扩展的唯一标识符（EUI-64）

标识的一种网络设备。

3.1.9

最高级时钟标识符grandmasteridentifier；GMID

一种EUI-64唯一标识符，用于标识为同步域提供服务的最高级时钟，在GB/T25931—2010和IEEE

802.1AS—2011同步标准中规定。

3.1.10

互联网组管理协议internetgroupmanagementprotocol；IGMP

主机用来向IPv4路由器报告其组播组成员的通信协议。

3.1.11

链路偏移量linkoffset

媒体消耗在网络、发送器的缓存和接收器的缓存中的总时间。

3.1.12

媒体时钟mediaclock

发送器用于采样和接收器用于播放数字媒体流的时钟。音频流的媒体时钟以音频样值数标注。

3.1.13

媒体包mediapacket

媒体流的一部分，承载媒体数据的数据包。每个媒体包包含一个或多个音频通道的一个或多个样

值。

3.1.14

最大传输单元maximumtransmissionunit；MTU

特定数据链接中能传输的最大IP数据包大小，以字节为单位。以太网数据链路的MTU为1500字节。

3.1.15

网络时钟networkclock

由第4章定义的网络同步机制提供的时间，以秒为单位。

3.1.16

开放式系统互联模型opensystemsinterconnectionmodel；OSImodel

以抽象层的方式描述和规范了通信系统的功能。

3.1.17

网络层networklayer

OSImodel的第3层，负责将可变长度数据序列从源转发和路由到目的地。

3.1.18

包时间packettime

媒体包中的媒体数据的实际持续时长。

3

GY/T304—2016

3.1.19

服务质量qualityofservice；QoS

描述依据性能要求，在网络中对流量分级、标记和传输的系统。

3.1.20

接收器receiver

一种可以从网络接收媒体流的网络设备。

3.1.21

请求注释requestforcomment；RFC

由IETF发布的、与Internet及Internet互联系统的操作相关的规范文档，以编号作为索引。

3.1.22

实时传输协议real-timetransportprotocol；RTP

一种由RFC3550定义并为应用通过UDP/IP网络构建、标记和传输媒体数据包的协议。

3.1.23

实时传输控制协议real-timetransportcontrolprotocol；RTCP

实时传输协议（RTP）的伴生协议，为RTP媒体数据包提供统计分析和控制信息。

3.1.24

RTP时钟RTPclock

在包含流数据的RTP包中携带的时间戳。每个流都有自己的RTP时钟。

3.1.25

RTP会话RTPsession

一种发送器与接收器之间的、基于RTP协议的媒体连接。RTP会话可以是单播或组播形式。

3.1.26

RTP流RTPstream

由已规定的时间间隔发送的媒体数据组成的RTP包串。一个流可以包含多个通道。每个RTP会话可

以由多个媒体流构成。

3.1.27

音频流audiostream

媒体数据为音频的RTP流。

3.1.28

会话描述协议sessiondescriptionprotocol；SDP

一种用于描述RTP会话和操作属性的格式，包括网络寻址、编码格式和其他元数据属性。

3.1.29

发送器sender

一种可以将媒体流发送到网络上的网络设备。

4

GY/T304—2016

3.1.30

SIPURI

一种在SIP协议中用于识别用户代理URI的字段。SIPURI采用sip:<user>@<domain>或

sips:<user>@<domain>的描述形式，见10.2.1。

3.1.31

从时钟slaveclock

一种使用精确时间协议（PTP）与主时钟（即时钟提供者）保持同步的时钟。从时钟可以作为其

他时钟的主时钟，也可以作为边界时钟。

3.1.32

传输层安全协议transportlayersecurity；TLS

一种IP网络安全通信加密协议。

3.1.33

透明时钟transparentclock

测量精确时间协议（PTP）事件报文通过该设备的时间，并向接收该PTP事件报文的时钟提供该信

息的设备。

3.1.34

传输层transportlayer

OSImodel的第4层，为网络应用提供端到端的通信服务。

3.1.35

用户代理useragent

一种SIP终端设备，例如VoIP电话机。

3.1.36

历元epoch

时标的原点。

[GB/T25931—2010，定义3.1.9]

3.1.37

快速转发expeditedforwarding

区分服务的其中一种分级，具有低延时、低丢包率和低抖动的特点，适用于语音、视频和其他实

时服务。快速转发流量相较于别的流量，通常拥有严格优先级队列。

3.1.38

普通时钟ordinaryclock

在一个域中具有单个精确时间协议（PTP）端口，并维护该域中所用时标的时钟。它可作为时间

源，即为主时钟；或与另一个时钟同步，即为从时钟。

[GB/T25931—2010，定义3.1.23]

3.2缩略语

下列缩略语适用于本标准。

ARB任意（Arbitrary）

5

GY/T304—2016

AVB音视频桥接（AudioVideoBridging）

BE尽力转发（BestEffort）

DNS域名服务系统（DomainNameSystem）

IEEE电气和电子工程师协会（InstituteofElectricalandElectronicsEngineers）

IETF互联网工程任务组（InternetEngineeringTaskForce）

IP互联网协议（InternetProtocol）

IPv4互联网协议版本4（InternetProtocolversion4）

IPv6互联网协议版本6（InternetProtocolversion6）

SAP会话公告协议（SessionAnnouncementProtocol）

SIP会话发起协议（SessionInitiationProtocol）

UDP用户数据报协议（UserDatagramProtocol）

URI统一资源标识符（UniformResourceIdentifier）

4同步

4.1概述

高性能流化音频区别于低性能流化音频（如互联网广播和IP电话）之处是运行前者的设备或应用

可共用一套精确的统一时钟。通过时钟的统一，网络中的任何一台接收器都能与其他的接收器同步回

放。通过时钟的统一，发送器和接收器之间的延时固定并可测量。统一时钟确保所有流的采样速率和

还原速率相同。接收器更易于合成具有相同采样率的音频数据流。这一特性对网络音频设备的高效运

行特别关键，如数字调音台。

时钟的同步应通过GB/T25931—2010中规定的精确时间协议（PTP）来实现。

GB/T25931—2010定义了各种同步传输应用类别（profile）。这些类别描述了协议的属性、可

选项和设备的性能需求。GB/T25931—2010为延时请求-响应机制（GB/T25931—2010附录J中J.3）

和点到点延时机制（GB/T25931—2010中J.4）定义了缺省的类别。

除了部分AVB设备（见下段）外，其他设备均应支持GB/T25931—2010缺省的类别。支持缺省类

别的设备应使用GB/T25931—2010附录D规定的IPv4封装。

唯一的例外是，两种设备不需要实现GB/T25931—2010缺省的类别，一种是4.4中描述的使用AVB

同步机制的设备，另一种是为完成媒体流传输而连接到AVB网络的设备。

4.2IP网络同步

标准IP网络中的设备宜使用附录A中定义的媒体类别，以确保为各种应用提供所需的性能，也可

使用缺省类别，但锁定时间会延长、精度会降低。

4.3GB/T25931—2010网络同步

在GB/T25931—2010（边界时钟或透明时钟）交换机构建的网络上恰当地使用缺省类别，可满足

音频传输所需的性能。

注：由于性能的限制，一些GB/T25931—2010网络设备可能不支持媒体类别。

4.4AVB网络同步

IEEE802.1Q—2011中定义的增强型以太网（即音视频桥接，AVB）按照IEEE802.1AS—2011的规

定分发同步信息。IEEE802.1AS—2011定义了一个GB/T25931—2010的类别。相对于缺省类别或媒体

类别，AVB网络可优先使用自有的IEEE802.1AS—2011同步类别。使用GB/T25931—2010和IEEE

802.1AS—2011搭建异构同步网络的方法参见附录B。

5媒体时钟

6

GY/T304—2016

发送器使用媒体时钟进行采样，接收器使用媒体时钟播放数字媒体流。媒体时钟与网络时钟存在

确定的对应关系。媒体时钟与网络时钟应共用GB/T25931—2010中7.2.2定义的历元，即1970年1月1

日00:00:00TAI。通过网络传输的数字音频应根据媒体时钟进行采样，或者根据媒体时钟转换采样

频率。

注：由于1972年伊始引入了闰秒，1972年及之后的TAI和UTC时间戳的偏移量变成了整数秒，而1971年及之前该值

为非整数秒。这导致出现了另一个可用的历元--1969年12月31日23:59:51.999918UTC，见GB/T25931—2010

中7.2.2。这种非整秒的UTC时间偏移量仅在1972年之前的网络时钟时间中存在。

与网络时钟相比，媒体时钟拥有更精准的速率，此速率应与音频采样率相同。

本标准支持三种采样率：44.1kHz、48kHz和96kHz（见7.2）。在一秒网络时钟中，如果音频流的

采样率为48kHz，则媒体时钟前进48000个采样时间。在GB/T25931—2010中7.2.2定义的历元，媒体

时钟的值应为0，每一个采样周期过后自动加1。

RTP时钟相对媒体时钟有恒定的偏移量，此偏移量应在每个流的会话描述（见8.4）中表示。

在网络协议和管理接口中，RTP和媒体时钟通常以32位整数表示。48kHz流的媒体时钟大约每24.86

小时会产生溢出。为了确保与网络时钟同步，以32位整数表示的媒体时钟应准确地处理所有发生在历

元与当前时间之间的溢出（反转）。

6传输

6.1概述

本章介绍编码和封包的媒体数据如何在网络中传输。基于开放式系统互联模型（OSImodel），

本章定义第3层（网络层）和第4层（传输层）上的操作方式。本标准并未规定如何在OSImodel的更

低层实现互操作。

本标准是基于理想的IP网络传输技术。

注：IP报文在以太网上的传输标准见RFC894。

6.2网络层

媒体数据包应使用RFC791中定义的IPv4传输。

注1：本标准暂不支持IPv6。

尽管RFC791中要求支持分片数据包重组，但本标准对接收器不作此要求。不支持分片数据包重

组的接收器应忽略IP分片数据包。

发送器可在传出的媒体数据包的IP包头中设置禁止拆分标记（DF）位。如果网络要对标记为DF的

数据包进行分片，此数据包将被丢弃，发送器将收到ICMP“TooBig”消息。发送器在收到此消息后，

宜终止传输该流。

组播消息，例如同步消息，应使用RFC1112中描述的IP组播实现。

注2：有关IP组播的更多信息见RFC3170。

所有设备应支持RFC2236中定义的IGMPv2，也可支持RFC3376中定义的IGMPv3。

注3：上文提出支持IGMPv2的要求是因为运行于IGMPv2网络中的IGMPv3设备需两分钟启动延时来查找网络中的

IGMPv3服务。

注4：RFC2236和RFC3376提出了向下兼容的要求。支持IGMPv2的设备可以在IGMPv1或IGMPv2的网络中正常

运行。支持IGMPv3的设备可以在IGMPv1、IGMPv2或IGMPv3的网络中正常运行。

设备应使用互联网组管理协议（IGMP）来请求接收所需的组播，包括接收同步信息（见GB/T25931

—2010附录D中D.3）、使用组播寻址的媒体流（见7.7）以及设备上可能使用的其他应用协议信息（例

如第9章的发现服务）。

注5：在某些路由重新配置的情况下，IGMP注册数据可能会被网络清除，这可能会导致流数据中断。重传IGMP

成员报告，是一种有效的快速恢复服务的方法，可通过关闭并立即重启受影响的组播网络套接字来实现。

在发送组播媒体数据包之前，发送器应使用IGMP协议向接收器发送查询并收到确认报文。

注6：通过发送IGMP请求，发送器实际上不会接收到它发送的数据包，而是为了阻止不必要的组播媒体数据泛滥。

有些IGMP探测的实现可能会造成无注册成员的组播组数据包泛滥。

7

GY/T304—2016

注7：这种需求通常以发送器接收实时传输控制协议（RTCP）消息的方式实现。在RFC3550中，虽然建议但不强

求设备发送或接收RTCP数据包。

6.3服务质量

若网络中同时存在无管理的非实时流量和时间敏感的媒体流量时，后者通常具备优先处理权，即

QoS。为了在网络中有效实施适当的QoS策略，设备应使用RFC2474中所述的区分服务方法。区分服务

会根据流量分级，通过IP包头中的DSCP字段来标记数据包，这样网络就能轻易识别需要优先处理的数

据包。

所支持的流量等级划分最少应包含表1中所示的三种。设备应使用合适的DSCP值标记输出的流量。

对于设备，DSCP字段宜使用表1所示的缺省值，但网络管理员或用户也可以通过管理接口，以其他的

DSCP值标记流量。发送器可对多个等级使用同一DSCP值，以达到等级合并的效果。本标准不要求设备

具有管理接口，设备可仅使用缺省值。

当有极低传输延时需求的媒体流与使用较长包时间的媒体流以同一QoS等级传输时，前者可能无

法在网络中得到低延时的传输保障。为了区别对待有不同需求的媒体流，发送器可配置使用表1规定

之外的服务等级。

表1QoS等级与区分服务的对应关系