AES67标准

合集下载

AoIP技术的发展及其在广电领域的应用

164
2021.07
②数据的交换与调度。AoIP 网络数据流有单播、多播、广播、组播等多种传输方式。相关设备通过交换机组网后，任意音频节点都可以与网内的其他节点完成数据传输、通信与交互，通过设置路由和切换软件可以轻松地实现音频的矩阵化调度，同时信号传输无延时、质量好，即使软件关闭及网络故障都不会影响已建立的音频传输路由；可以实现对实体矩阵的冗余备份。
之一。广播播控系统在传统音频技术的基础上，有效融入 AoIP 技术，可以构建更加简洁化、清晰化的系统，同时实现多元化的数据采集、数据交换、数据监测等功能。
①数据的采集与监测。通过 AoIP 技术，将各种音频信号统一转化为 IP 数据流信号，在连接层、协议层和音频层进行全面的实时分析及监测，再将相应节点采集及分析到的各类监测数据，通过系统中的各类控制软件，可以实现各种应用：将电平、相位、频谱信息通过监看软件以图形等的形式作直观的呈现；将采集到的音频信号通过监听软件实施监听；通过报警软件实现信号过载、反相、静音等各项报警；通过流程图实现故障点排查定位及预案提示等。利用 AoIP 技术搭建的播控系统，可以实现对整个播控网络关键节点的全方位监测，缩短了播出事故发现周期，提高了排障的效率，整体系统安全性大大增强。
三、结语
当下 IP 网络技术、5G 通信技术正在飞速发展，AoIP 技术也必然会伴随这股浪潮，以比现在更快的速度发展与进步。未来其一定会为专业音频领域系统的构造与搭建提供更加完善的技术指向与方案，带来更大的变革与创新。■
（作者单位：沈阳广播电视台）【参考文献】 [1]朱超 . 基于 AOIP 技术广播播控系统搭建展望[J]. 科技传播,2017,9(11):25-26+59. [2]经广瑞 .AOIP 技术在广播监测中的应用[J]. 通讯世界,2019,26(08):190-191.

aes 标准

AES（Advanced Encryption Standard）是一种广泛使用的对称加密标准，它是由美国国家标准和技术研究院（NIST）于2001年公布的。

AES有多种密钥长度版本，包括128位、192位和256位。

最常用的是128位版本，因为它的加密和解密速度较快，同时提供了足够的安全性。

AES加密算法是一种块加密算法，它将明文分成固定大小的块（在AES中为128位），然后对每个块进行加密。

加密过程中，密钥与明文块进行多次迭代运算（在AES中为10次），每次运算都会生成一个新的密文块。

最后一次迭代生成的密文块与之前的密文块进行连接，形成最终的密文。

AES加密算法具有较高的安全性，它采用了复杂的数学运算和混淆操作，使得即使攻击者能够获取到密文和密钥的一部分信息，也很难破解整个加密过程。

此外，AES加密算法还具有良好的性能和可扩展性，可以适用于不同的应用场景。

由于AES加密算法的普及程度高、安全性好、性能优良，因此它已经成为许多领域中首选的加密标准之一。

许多软件和硬件厂商都提供了对AES加密的支持，包括各种编程语言、操作系统、网络协议等。

AoIP和AES67及其对未来音频系统的影响

AoIP和AES67及其对未来音频系统的影响作者：寸垒来源：《中国传媒科技》2018年第02期摘要：由于数字音频技术的快速发展，其音频信号的传输效率得到了明显改善。

如今，网络化传输是当今社会最流行的传输手段，得到了广大人们的任何，接受程度很高。

本文主要介绍了网络音频AoIP的优势，并对AES67也进行了介绍，阐述了AES67标准内容，在此基础上，对音频系统的未来影响与发展趋势进行了分析。

关键词：AES67；AoIP；传输协议；数字音频；网络音频中图分类号：TN931.2 文献标识码：A文章编号：1671-0134（2018）02-051-02 DOI：10.19483/ki.11-4653/n.2018.02.0171.网络音频AoIP由于网络技术的发展，对信息进行处理时，处理效率得到了明显提升。

在AoIP技术中，数字音频有效结合了信息网络技术等，并且，还具有如下诸多的优势：（1）以TCP/ IP网络为基础，对专业的音频进行传输时，既可以应用网线，也可以选择光纤，以及网络交换机；（2）利用同一根线缆，就能够对音频、视频，以及控制信号进行传送，有利于设备的远程控制。

不仅如此，在某些最新的协议格式中，通过PTP时钟，能够设备入网，也就是实现了同步；（3）利用数据流的途径，对音频进行传输时，只用一根线缆，就能够双向地传输诸多的数据流，对于传输带宽，主要取决于交换机；（4）对数据包进行复制、分配时，利用交换机，实现了一点对多点，不仅简化了传输，也提高了传输效率。

2.AES67简介2.1 AES67的目标近些年来，在网络化音频方面，其传输协议不断地推出，具有不同的特点，不过，大多数的协议都属于专利协议，兼容性不理想，底层也缺少开放性，通常，自己负责自己的领域，建设属于自己的支持队伍。

根据音频行业的整体情况来分析，在这种环境的影响下，因为这些协议的存在，特别是新研发出来的协议，严重阻碍了AoIP的发展。

目前，依然具有很大的调整空间，站在理论角度来说，如果能够制定出一个通用的标准，并且，可以兼容全部的协议，那么，在此之前，各执己见的设备生产厂商也就能够避免推翻性调整，进而实现相互兼容的目标，在此基础上，一起促进IP音频技术的进程。

AES67网络关键概念介绍及构建要点

本文详细介绍了组建AES67音频网络的几个基础及其需要注意的地方，对PTP 同步和组播数据的分发进行了深入分析，同时提出了构建该类AoIP 网络时需要注意的地方。

AES67 AoIP PTP 组播一关键概念介绍AES67旨在采用COTS 通用交换机为基础架构，构建通用的音频数据交换网络。

假如网络配置正确，音频数据流和其他数据流可以共享在一个网络中，同时不会影响用户的整体使用体验。

AES67音频网络主要依靠以下四个基础来建立： z 同步； z 组播数据包传输； z 服务质量； z 会话信息。

1. 同步AES67网络实现同步的关键是在该网络的所有节点中传输精度足够高的参考时间（wall clock time ，指以PTP 纪元时间1970年1月1日零时为时基计算的参考时间数值），同时AES67标准规定了使用IEEE 1588-2008标准（亦称作PTP v2）传输同步时间。

这里要注意的是，PTP v2与PTP v1（IEEE 1588-2002）并不兼容。

PTP v2中包含最佳主时钟算法，它确保了最优时钟被选为网络中所有节点的主时钟。

当某节点与由主时钟衍生的参考时间同步后，任何地方所需的媒体时钟都可以由此节点生成。

如果网络同步的精度足够高，所有本地生成的媒体时钟将具有相同的采样频率，甚至它们还可以准确地相互锁定。

使用PTP 同步可以达到亚微秒级别范围内的精度（指的是本地时钟对于主时钟来说的偏差值），然而在大多数情况下这需要部署PTP 感知交换机来实现。

所幸的是，大多2. 组播数据包传输PTP 同步是基于组播数据包传输的，AES67标准要求组播流支持音频数据的传输。

一般通用交换机都支持组播流传输，但只有管理型交换机（Managed Switches ）可以提供组播管理并有效避免网络风暴。

非管理型交换机（或配置不当的管理型交换机）会将组播流当成广播流进行处理，将所有输入的组播数据包转发到交换机的所有端口。

AES67拥抱网络音频的未来

AES67拥抱网络音频的未来今天，所有的集成商（制造商）都希望为客户提供所安装设施之间的平台互操作性。

遗憾的是，现在业内流行的系统看上去都是“专有的”对其他协议与技术的互操作性关上了大门。

从风光一时的Cobranet到现在风头正劲的Dante，网络音频协议技术不断发展进步，选择也足够丰富，但每个系统都是硬币的两面，没有一个系统是完美的。

虽然很多系统已经在开发支持高性能媒体的网络，但是到现在为止还没有以互操作方式运行这些系统的推荐规范。

专家预测，总有一天每个设备都将成为一个IP分配系统上的终端，可以运行在任何网络上，而AES67就是其中关键。

AES67在同步、媒体时钟识别、网络传输、编码和流媒体，会议描述和连接管理方面，提供全面的互操作性推荐规范。

核心功能AES67是一个在IP网络上传输高性能音频的标准。

AES67 对于高性能的定义是至少有44.1kHz的采样率，至少有16bit 的分辨率，以及延时少于10ms。

AES67瞄准专业音频的应用领域包括：广播、制作、现场音频以及商业和家居应用。

AES67并不是发明了新技术，而是说明了如何使用其他已经制定的标准，实现音频网络的协作。

与那些为音频网络提供全功能用户体验的系统和产品不同，AES67主要是提供互操作性的基本条件。

AES67的核心功能主要包括以下三个方面：同步和媒体时钟：音频设备作为一个系统运行时首先必须确保彼此间的精确同步。

从而才能够保证网络上所有设备以完全一样的速率和时间创建和复制音频采样。

同步性能使AES67 （和其他专业媒体网络）有别于互联网广播、VoIP和Airplay，在最好的情况下，它能使设备与所选数字音频信号源的起源同步。

传输、编码和流媒体：音频网络是通过在网络数据包里传输音频采样来工作的。

数据包以有规律的间隔进行传送。

在AES67中，数据包是根据实时传输协议（斯「）格式化的IP数据包。

RTP标准为众多类型的音频和视频定义了数据包格式。

aes67协议研究

1 引言广播电台播控系统是电台节目播出、传送、监控和运行的核心技术平台，它主要起着调度音频节目信号、质量监控和安全播出保障等作用。

实时音频节目传输技术是电台播控系统的核心。

实时音频节目传输技术发展经历模拟传输技术、数字音频技术以及最新的以太网音频传输技术。

早期使用的是模拟传输技术采用P2P 方式，即点到点的传输模式，存在传输损耗大、指标低、灵活性差的缺点。

目前，模拟传输技术在电台内的传输能够兼容现有的以太网络，系统架构将变得简单化，机房布线也将变得更加简洁，同时以太网的交换特性，也有利于改变传统数字音频只能依靠点对点传输的局限，从而实现数字音频传输的软交换和软路由。

2 相关技术研究2.1 DanteDante技术是Audinate公司于2003年提出的，基于网络层的IP网2.2 LivewireLivewire音频传输网络由美国Axia Audio公司开发，是世界上第一套基于通用以太网协议，专用于广播电台数字音频的传输、路由、矩阵、监测、同步的专业音频系统。

Livewire音频传输网络是一个综合性、全功能的广播音频网络。

除了音频，Livewire网络中还传输Livewire网络同步信号、控制信号、状态监测信号等。

整个Livewire音频传输网络摘要：音频传输技术作为电台传输高质量音频的关键技术，近年来发展迅速。

本文在介绍了目前主流基于以太网的数字音频传输技术的基础上，对AES67协议进行了深入的研究分析，最后展望了AES67协议未来的发展前景。

关键词：数字音频传输实时 AoIP AES6719. 20. 可容纳32767个音频、控制信号通道，配合丰富的控制监测设备，可满足广播音频系统中的各种复杂需求。

Livewire 音频传输网络中，音频以44.1kHz 或48kHz 数字音频形式无压缩地在CAT-5e、CAT-6或光缆中传输，每条网线中传输的音频通道数量只受带宽限制。

在100Base-T 线缆中可容纳25个立体声音频通道，1000Base-T线缆中可容纳250个立体声音频通道。

AES67高性能网络音频标准介绍

AES67 实现高性能网络音频IP网络是进行设备间互操作的最优途径，目前的技术和设备只有与IP网络实现互联才有生命力。

现今已有许多建立在IP基础上的网络音频，如互联网广播，IP电话等。

这类技术将音频信号压缩编码，封装成IP包进行传输，其特点是压缩和传输过程耗时较长，进行两点间对话有明显的延迟。

为克服时间延迟，实现高性能网络音频，办法是在网络上直接传送采样率44.1kHz，16bit量化的线性PCM音频，以及更高采样和量化的音频数据，时间延迟在10ms之内，达到不可察觉之性能。

市场中已出现多个上述高性能网络音频技术，实现10ms之内时延。

但这类专有网络设备，相互间不能互联及互操作，缺乏标准化规定。

2011年，AVB（audio video bridging）首次有IEEE进行开放型标准化，是增强的音频以太网，由IEEE802.1BA，IEEE802.1Q和IEEE802.1AS定义。

然而，AVB网络在标准发布后的数年内并未取得明显进展，原因在于AVB网络连接必须采用AVB专用交换机。

CISCO表面宣称将大力支持AVB，但始终无所作为，缺少业界大佬支持，AVB一直处于停滞状态。

2012年，音频工程协会AES开始着手整合高性能网络音频技术。

AES和EBU联合开发实现网络音频互通的目标，在现有技术基础上定义可互通的系统。

2013年AES发布标准AES67-2013，完成高性能网络音频的第一个里程碑。

AES67并未提供新技术，而是充分采纳目前网络中广泛使用的协议和交换规则，构造音频互联世界。

作为高性能网络音频标准，基础的标准化是指定满足不被察觉条件下的最大延迟时间。

同样，封装包长度和地址内容的定义必须保证最优的音频性能。

AES67提供综合性交互，在同步，媒体时钟，网络传输，流和编码，会话描述和连接管理等方面进行规定。

其目标在于建立高性能媒体网络，支持专业质量的音频（44.1kHz 采样，16bit量化及更高的采样率和分辨率），低延迟时间（小于10ms），适用于局域网和企业网。

AES67-2013

STANDARDS ANDAES67-2013The AES Standards Committee is the organization responsiblefor the standards programme of the Audio Engineering Society.It publishes a number of technical standards, information docu-ments and technical reports.Working groups and task groups with a fully international mem-bership are engaged in writing standards covering fields thatinclude topics of specific relevance to professional audio.Membership of any AES standards working group is open to all individuals who are materially and directly affected by the documents that may be issued under the scope of that working group.Complete information, including scopes of working groups and project status is avai lable at /standards. Enquiries may be addressed to standards@AES67-20132014-03-24 printingAES standard foraudio applications of networks - High-performance streaming audio-over-IP interoperabilityPublished byAudio Engineering Society, Inc.Copyright ©2013 by the Audio Engineering SocietyAbstractHigh-performance media networks support professional quality audio (16 bit, 44,1 kHz and higher) with low latencies (less than 10 milliseconds) compatible with live sound reinforcement. The level of network performance required to meet these requirements is available on local-area networks and is achievable on enterprise-scale networks. A number of networked audio systems have been developed to support high-performance media networking but until now there were no recommendations for operating these systems in an interoperable manner. This standard provides comprehensive interoperability recommendations in the areas of synchronization, media clock identification, network transport, encoding and streaming, session description and connection management.An AES standard implies a consensus of those directly and materially affected by its scope and provisions and is intended as a guide to aid the manufacturer, the consumer, and the general public. The existence of an AES standard does not in any respect preclude anyone, whether or not he or she has approved the document, from manufacturing, marketing, purchasing, or using products, processes, or procedures not in agreement with the standard. Prior to approval, all parties were provided opportunities to comment or object to any provision. Attention is drawn to the possibility that some of the elements of this AES standard or information document may be the subject of patent rights. AES shall not be held responsible for identifying any or all such patents. Approval does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the standards document. This document is subject to periodic review and users are cautioned to obtain the latest edition. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.Audio Engineering Society Inc. 60 East 42ndStreet, New York, NY., US./standards standards@2014-03-24 printingContents0 Introduction ....................................................................................................................................... 5 0.1 General ........................................................................................................................................ 5 0.2 Patents ......................................................................................................................................... 5 1 Scope ................................................................................................................................................. 6 2 Normative references ...................................................................................................................... 6 3 Definitions and abbreviations ......................................................................................................... 7 4 Synchronization .............................................................................................................................. 12 4.0 General ...................................................................................................................................... 12 4.1 IP network synchronization ........................................................................................................ 12 4.2 IEEE 1588 network synchronization .......................................................................................... 13 4.3 AVB network synchronization .................................................................................................... 13 5 Media clocks ................................................................................................................................... 13 6 Transport ......................................................................................................................................... 13 6.0 General ...................................................................................................................................... 13 6.1 Network layer ............................................................................................................................. 14 6.2 Quality of service ....................................................................................................................... 15 6.3 Transport layer ........................................................................................................................... 16 7 Encoding and streaming ............................................................................................................... 16 7.0 Introduction ................................................................................................................................ 16 7.1 Payload format and sampling rate ............................................................................................. 16 7.2 Packet time ................................................................................................................................ 17 7.2.0 General ................................................................................................................................ 17 7.2.1 Required packet time .......................................................................................................... 17 7.2.2 Recommended packet times ............................................................................................... 18 7.3 Stream channel count ................................................................................................................ 18 7.4 Link offset ................................................................................................................................... 19 7.5 Sender timing and receiver buffering ......................................................................................... 20 7.6 Multicasting ................................................................................................................................ 20 8 Session description ....................................................................................................................... 21 8.0 General ...................................................................................................................................... 21 8.1 Packet time ................................................................................................................................ 21 8.2 Clock source .............................................................................................................................. 22 8.3 RTP and media clock ................................................................................................................. 22 8.4 Payload types ............................................................................................................................ 23 8.5 Example descriptions ................................................................................................................. 23 8.5.1 Multicast session description example ................................................................................ 23 8.5.2 Unicast session description example .................................................................................. 23 9 Discovery ........................................................................................................................................ 24 10 Connection management ............................................................................................................ 24 10.0 General .................................................................................................................................... 24 10.1 Unicast connections ................................................................................................................. 24 10.1.1 SIP URI ............................................................................................................................. 24 10.1.2 Server and serverless modes ............................................................................................ 24 10.1.3 User-Agent (25)10.1.4 Format negotiation (25)10.1.5 Packet time negotiation (25)10.2 Multicast connections (25)Annex A (Normative) - Media profile (26)A.0 General (26)A.1 Media profile description (26)A.2 Media profile (26)A.2.1 Identification (26)A.2.2 PTP attribute values (26)A.2.3 PTP options (29)A.2.4 Clock physical requirements (29)Annex B (Informative) - Network QoS configuration recommendations (30)B.0 General (30)B.1 DiffServ network configuration (30)B.1.1 Clock (30)B.1.2 Media (31)B.1.3 Best effort (32)Annex C (Informative) – AVB network transport (33)C.0 General (33)C.1 AVB network transport (33)C.1.1 Interoperable media as AVB time-sensitive streams (33)C.1.2 Interoperable media as other traffic (34)Annex D (Informative) - Interfacing to IEEE 802.1AS clock domains (36)D.0 General (36)D.1 Boundary clock interface (36)D.2 Ordinary clock interface (36)D.3 Traceable reference (36)D.4 AVB network as a boundary clock (37)Annex E (Informative) – Discovery systems (38)E.0 General (38)E.1 Bonjour (38)E.2 SAP (38)E.3 Axia Discovery Protocol (38)E.4 Wheatstone WheatnetIP Discovery Protocol (38)Annex F (Informative) - Informative references (39)Annex G (Informative) - Glossary (40)2014-03-24 printingForewordThis foreword is not part of the AES67-2013 AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperabilityThis document was developed in project AES-X192, in the SC-02-12-H task group on high-performance streaming audio-over-IP interoperability, under the leadership of Kevin Gross.Members of the writing group that contributed to this document in draft are: R. Abraham, J. Amate, M. Barbour, C. Becker-Foss, J. Berryman, M. Bishop, H. Blum, J. Boqvist, T. Borland, N. Borthwick, L. Bradshaw, P. Briscoe, L. Brito, J. Britton, C. Broad, N. Brunsgaard, D. Brutzman, E. Bukont Jr., A. Calvanese, R. Camprodon, M. Carter, A. Cedronius, A. Clark, H. Clarke, M. Coinchon, P. Cyrta, S. de Jaham, P. Demuytere, J. Dibley, A. Dickens, P. Dietrich, C. Dodds, S. Dove, A. Eales, E. Echols, R. Economaki, T. Edwards, A. Elder, L. Ellison, K. Fitzke, J. Fletcher, S. Flock, R. Foss, P. Foulkes, F. Gierlinger, R. Goforth, J. Grant, M. Graubner, D. Gravereaux, S. Gray, H. Hansen, B. Harshbarger, S. Heinzmann, A. Hildebrand, D. Hoch, M. Holtmann, Os. Igumbor, H. Jahne, T. Johansson, M. J. Teener, S. Johnson, L. Jonsson, A. Karamustafaoglu, K. Kearney, P. Keller, J. Koftinoff, P. Koftinoff, D. Koss, S. Langhans, M. Lave, D. Lazecko, S. Ledergerber, C. Lefebvre, J. Lindsay, G. Linis, S. Loehberg, A. Louko, A. Makivirta, J. A. Martinez, A. Mayo, W. McQuay, C. Merienne, A. Metz, J. Meunier, J. Meyer, R. Michl, S. Millan, D. O'Gwynn, N. O'Neill, H. Okai-Tettey, K. Parker, J. Passaniti, J. Peavey, J. Perez, W. Peters, S. Price, S. Pro, M. Quaix, F. Ragenard, R. Rayburn, D. Rice, T. Rohwedder, G. Rosenboom, M. Saito, M. S. Carreres, J. Sauter, R. Schoonbroodt, V. Schueppel, P. Schwizer, S. Scott, G. Shay, T.Shuttleworth, D. Silver, J. Simpson, M. Sims, A. Smimite, J. Snow, T. Staros, P. Stevens, J. M. Strawn, N. Sturmel, M. Szlapka, T. Thompson, P. Treleaven, A. Trevena, S. Turner, R. van der Zalm, B. van Kempen, I. Vysick, J. P. Waddell, Y. Wang, P. Warrington, H. Weibel, A. Williams, M. Willsher, A. Witham, J. Wood, J. A. Yeary, J. Yoshio, P. Yurt, U. Zanghieri, D. Zimmermann, R. Zwiebel.This document was edited by Kevin Gross.Richard FossChair, working group SC-02-122013-07-18Addendum 2014-03-24The Introduction has been updated with a clause 0.2 to show that a patent statement has been received under our patent policy.Note on normative languageIn AES standards documents, sentences containing the word “shall” are requirements for compliance with thedocument. Sentences containing the verb “should” are strong suggestions (recommendations). Sentences givingpermission use the verb “may”. Sentences expressing a possibility use the verb “can”.2014-03-24 printingAES standard foraudio applications of networks -High-performance streamingaudio-over-IP interoperability0 Introduction0.1 GeneralHigh-performance media networks support professional quality audio (16 bit, 44,1 kHz and higher) with low latencies (less than 10 ms) compatible with live sound reinforcement. The level of network performance required to meet these requirements is available on local-area networks and is achievable on enterprise-scale networks but is generally not available on wide-area networks or the public internet.The most recent generation of these media networks use a diversity of proprietary and standard protocols. Despite a common basis in Internet Protocol, the systems do not interoperate.This standard provides specific recommendations for interoperability. The standard focuses on defining how existing protocols are used to create an interoperable system. No new protocols have been developed to achieve this.The standard is expected to be useful for commercial audio applications including fixed and touring live sound reinforcement. It is also expected to be useful for distribution within broadcast, music production and post-production facilities.0.2 PatentsThe Audio Engineering Society draws attention to the fact that it is claimed that compliance with this AES standard or information document may involve the use of a patent.The AES holds no position concerning the evidence, validity and scope of this patent right.The holder of this patent right has assured the AES that it is willing to negotiate licenses under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent right is archived with the AES.Information may be obtained fromAudinate Pty Ltd.PO Box 855Ultimo, NSW 2007AustraliaAttention is drawn to the possibility that some of the elements of this AES standard or information document may be the subject of patent rights other than those identified above. AES shall not be held responsible foridentifying any or all such patent rights.2014-03-24 printing1 ScopeThis standard defines an interoperability mode for transport of high-performance audio over networks based on the Internet Protocol. For the purposes of the standard, high-performance audio refers to audio with full bandwidth and low noise. These requirements imply linear PCM coding with a sampling frequency of 44,1 kHz and higher and resolution of 16 bits and higher. High performance also implies a low-latency capability compatible with live sound applications. The standard considers latency performance of 10 milliseconds or less.2 Normative referencesThe following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.AES11 - AES recommended practice for digital audio engineering - Synchronization of digital audio equipment in studio operations; Audio Engineering Society, New York, NY., US.IEEE 1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, July 2008, Institute of Electrical and Electronics Engineers (IEEE), US.RFC 768 – User Datagram Protocol”, Internet Engineering Task ForceRFC 791 – Internet Protocol, Internet Engineering Task ForceRFC 1112 – Host Extensions for IP Multicasting, Internet Engineering Task ForceRFC 2236 - Internet Group Management Protocol, Version 2, Internet Engineering Task ForceRFC 2474 – Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Internet Engineering Task ForceRFC 2616 - Hypertext Transfer Protocol - HTTP/1.1, Internet Engineering Task ForceRFC 2974 – Session Announcement Protocol, Internet Engineering Task ForceRFC 3190 – RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio, Internet Engineering Task ForceRFC 3261 - SIP: Session Initiation Protocol, Internet Engineering Task ForceRFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP), Internet Engineering Task ForceRFC 3376 - Internet Group Management Protocol, Version 3, Internet Engineering Task ForceRFC 3550 – RTP: A Transport Protocol for Real-Time Applications, Internet Engineering Task ForceRFC 3551 - RTP Profile for Audio and Video Conferences with Minimal Control, Internet Engineering Task ForceRFC 4566 – Session Description Protocol, Internet Engineering Task Forcedraft-ietf-avtcore-clksrc - RTP Clock Source Signalling (work in progress) , Internet Engineering Task Force.https:///doc/draft-ietf-avtcore-clksrc/2014-03-24 printingNOTE The publication of this IETF draft as an IETF standard is anticipated in the next monthor two. When it is published, and assuming no changes that would affect its application in thisdocument, this reference will be updated with a corrigendum.3 Definitions and abbreviationsFor the purposes of this document, the following terms, definitions, and abbreviations apply.3.1Audio streamSee RTP stream.3.2Audio Video BridgingAVBdescribes enhanced Ethernet networks specified in IEEE 802.1BA, IEEE 802.1Q-2011 and IEEE 802.1AS. 3.3Boundary ClockA clock that has multiple Precision Time Protocol (PTP) ports in a domain and maintains the timescale used in the domain. It may serve as the source of time, that is, be a master clock; and may synchronize to another clock, that is, be a slave clock. See IEEE 1588-2008.3.4ByteA unit comprising 8 bits of data. Over IP networks, data is transported in units of bytes.3.5Digital Audio Reference SignalDARSan audio clock signal defined in AES11.3.6CSRCThe contributing source (CSRC) is the source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer3.7DiffServDifferentiated services (DiffServ) is a system for classifying traffic and providing quality of service (QoS) on an IP network.3.8DSCPThe differentiated services code point (DSCP) is a 6-bit field in the IP packet header that is used for classification purposes. DSCP is part of the differentiated services architecture.3.9End-to-end Transparent ClockA transparent clock that supports the use of the end-to-end delay measurement mechanism between slave clocksand the master clock. See IEEE 1588-2008.2014-03-24 printing3.10EthernetEthernet is a physical and data link layer family of computer networking technologies for local area networks (LANs). Ethernet uses a bus or star topology and supports data transfer rates from 10 Mbps, through 100 Mbs (Fast Ethernet) and onto Gigabit Ethernet, supporting data rates of 1 gigabit (1,000 megabits) per second.3.11EUI-64A 64-bit globally unique identifier formed by combining a registered 24 or 36-bit company identifier and a company unique device identifier. The EUI-64 is similar to the EUI-48 which is used to assign Ethernet media access control (MAC) addresses.3.12Grandmaster identifierGMIDan EUI-64 used in IEEE 1588 and IEEE 802.1AS synchronization standards to uniquely identify the grandmaster serving a synchronization domain.3.13GrandmasterThe master source of synchronization for clock distribution via PTP. The grandmaster is a network device and is identified by an EUI-64.3.14IEEEInstitute of Electrical and Electronics Engineers is a professional association dedicated to advancing Arraytechnological innovation and excellence. The IEEE publishes a wide range of communications standards.3.15IETFInternet Engineering Task Force is the volunteer standards-developing organization responsible for the Internet Protocol suite.3.16IGMPInternet Group Management Protocol (IGMP) is a communications protocol used by hosts to report their multicast group memberships to IPv4 routers.3.17Internet ProtocolIPthe network layer protocol commonly used to transport data on networks built through interconnection of one or more local-area networks.3.18IPv4Internet Protocol version 4 is the most widely deployed version of the protocol and is widely used on the Internet and on local area networks (LANs).3.19IPv6Internet Protocol version 6 is the most recent revision of the Internet Protocol and is intended to replace IPv4eventually.2014-03-24 printing3.20Link offsetLink offset specifies the amount of time media spends on the network and in buffers at the sender and receiver as illustrated in figure 1. Link offset is also known as network latency or playout delay.3.21Media clockThe clock used by senders to sample and receivers to play digital media streams. The media clock for audio streams reads in units of samples. The relationship between media clock and network clock is defined in 5.3.22Media packetOne of the data packets carrying media data as part of a media stream. A media packet contains one or more samples for one or more audio channels.3.23Media streamSee RTP stream.3.24Maximum transmission unitMTUThe size of the IP packet, measured in bytes, that can be transferred using a specific data link connection. The MTU for an Ethernet data link is 1500 bytes.3.25Network clockThe time delivered by the network synchronization mechanism defined in 4. The network clock reads in units of seconds.3.26Network layerThe network layer is layer 3 of the OSI model and is responsible for packet forwarding and routing of variable-length data sequences from a source to a destination.3.27OSI modelThe Open Systems Interconnect Model characterizes and standardizes the functions of a communications system in terms of abstraction layers.3.28Packet timeThe real-time duration of the media data contained in a media packet. For example, a packet containing 12 samples of 48 kHz audio has a packet time of 12 ÷ 48 kHz = 250 microseconds.3.29Peer-to-peer Transparent ClockA transparent clock that, in addition to providing Precision Time Protocol (PTP) event transit time information, also provides corrections for the propagation delay of the link connected to the port receiving the PTP event message. In the presence of peer-to-peer transparent clocks, delay measurements between slave clocks and themaster clock are performed using the peer-to-peer delay measurement mechanism. Source: IEEE 1588-2008.3.30Precision time protocolPTPThe general class clock distribution protocol standardized in IEEE 1588-2002, IEEE 1588-2008 and IEEE 802.1AS-2011.3.31Quality of serviceQoSdescribes a system for classifying, marking and delivering traffic across a network in accordance with its performance requirements.3.32ReceiverA network device with ability to receive at least one media stream from the network.3.33Request for CommentRFCRequest for Comments are memorandums published by the IETF relevant for the working of the Internet and Internet-connected systems. RFCs are referenced by number. RFC 791, for example, defines the Internet Protocol version 4 (IPv4).3.34RTCPA companion protocol of the Real-time Transport Protocol (RTP), providing statistics and control information Arrayfor RTP media packets.3.35Real-time Transport ProtocolRTPis defined in RFC 3550 and provides a means for applications to organize, mark and transport their media packets using UDP/IP networking.3.36RTP clockTimestamps are carried in RTP packets containing stream data. Each stream has its own RTP clock. There is a constant offset between the media clock and the RTP clock (see 8.2).3.37RTP sessionAn RTP session is a media connection between sender and receiver. RTP sessions may be unicast or multicast. In teleconferencing RTP applications, multicast sessions may have multiple senders and receivers. However, under this standard, a session is allowed only one sender (see 7.6).3.38RTP streamAn RTP stream is a sequence of RTP packets with media data sent at regular interval. A stream may containmultiple channels. There may be multiple media streams per RTP session.3.39Session Description ProtocolSDPa format for describing RTP sessions and their operating parameters including network addressing, encoding format and other metadata. SDP is defined in RFC 4566.3.40SenderA network device with ability to source at least one media stream onto the network.3.41SessionSee RTP session.3.42Session Initiation ProtocolSIPa telecommunications connection management protocol defined in RFC 3261.3.43SIP URIA SIP URI is a URI used by SIP to identify user agents. SIP URI take the form sip:<user>@<domain> or sips:<user>@<domain>. See 10.1.1.3.44Slave ClockA clock that is synchronized to a master clock (the provider of time) within an environment that uses the Precision Time Protocol (PTP). A slave may, in turn, be a master to another clock and may simultaneously be a boundary clock.3.45StreamSee RTP stream.3.46Transport Layer SecurityTLSa cryptographic protocol for secure communication over IP networks.3.47Transparent clockA device that measures the time taken for a Precision Time Protocol (PTP) event message to transit the device and provides this information to clocks receiving this PTP event message. See IEEE 1588-2008[1]. See also: end-to-end transparent clock; peer-to-peer transparent clock.3.48Transport layerThe network layer is layer 4 of the OSI model and provides end-to-end communication services for networkapplications.3.49User datagram protocolUDPconstitutes a simple transport layer for the IP network layer. Defined in RFC 768.3.50Uniform resource identifierURIan identifier for a network resource. An identification URI enables interaction with the resource over a network.3.51User agentA SIP endpoint device such as a VoIP telephone.3.52Virtual LANVLANA single layer-2 network may be partitioned to create multiple distinct broadcast domains, which are mutually isolated so that packets can only pass between them via one or more routers; such a domain is referred to as a Virtual Local Area Network.4 Synchronization4.0 GeneralThe ability for network participants to share an accurate common clock distinguishes high-performance media Arraystreaming from its lower-performance brethren such as Internet radio and IP telephony. Using a common clock, receivers anywhere on the network can synchronize their playback with one another. A common clock allows for a fixed and determinable latency between sender and receiver. A common clock assures that all streams are sampled and presented at exactly the same rate. Streams running at the same rate may be readily combined in receivers. This property is critical for efficient implementation of networked audio devices such as digital mixing consoles.Synchronization of a common clock shall be achieved using IEEE 1588-2008 Precision Time Protocol (PTP). IEEE 1588-2008 is profiled for use in different synchronization applications. A profile describes protocol attributes, available options and required device performance. IEEE 1588-2008 specifies default profiles for delay request-response (IEEE 1588-2008 annex J.3) and peer-to-peer (IEEE 1588-2008 annex J.4) mechanisms. Devices, with the exception of certain AVB devices (see below), shall support the IEEE 1588-2008 default profiles. Devices supporting the default profiles shall use IPv4 encapsulation as described in IEEE 1588-2008 annex D.As a single exception, devices that use the AVB synchronization mechanism described in 4.3, and that need to be connected to an AVB network in order to accomplish media streaming, are not required to implement the IEEE 1588-2008 default profiles.4.1 IP network synchronizationDevices on standard IP networks should use the media profile defined in annex A to assure adequateperformance for all applications. Devices may use the default profiles on IP networks but should recognize thatlock time and accuracy will be degraded.。

基于AoIP(AES67)网络化广播总控系统实践

图１　原有广播总控系统流程图原系统欠缺主要是：（1）2009年建设运行的总控系统，系统技术和设备老化问题逐渐显露，造成播出中各种隐患。

如：NETWORK 矩阵电源损坏后无法直通节目信号，时代广播的IP化、智能化潮流，设计了这次系统升级改造的信号流程，如图2所示，实现了广播节目的高质量不间断的播出和电台内部信号交换。

３．１　直播间到总控的音频信号双调音台的直通AES输出信号接入网络多选一C路，作为应急信号；直播间播出信号通过AoIP网络路由系统接入网络多选一智能切换器的AoIP接口，实现第二备份传输路由；网络多选一智能切换器的两路数字输出分别无源二选一和音频处理器；网络多选一智能切换器的两路数字信号具备掉电直通功能，保障了信号传输的安全。

３．３　转播信号的传输设计所有转播信号都通过数字无源一分二进入AoIP网络音频路由器和数字音频矩阵；然后通过AES电缆或者AoIP网络返送直播间；另外配置一台4路的A/ D数模转换，将模拟信号转为数字信号；３．４　多路传输和发射台返送的音频比对监测在直播间到总控再到发射台的传输通路的劣播、误播。

３．５　开路信号的传输监测配置了RadioStreamer网络版开路接收设备，对开路信号进行监测监听、通知提供场强、信噪比监测数据。

４　系统建设及效果正如前所述，此次广播总控系统改造是按照IP化、智能化的模式来考虑，所有核心设备如NTP矩阵、IBS300多选一切换器、SOUND4 PULSE音频处理器等，均选择使用具备AES67接口，主矩阵采用具备AES67接口的NTP矩阵，备矩阵采用成本较低的AoIPBox网络矩阵，信号双路由链路实现了主、备矩阵在线热备的功能。

关于此次选择使用SOUND4 PULSE音频处理器的主要原因，是玉林广播电视台原使用的ORBAN FM2300处理器不优于现在同等价位的其他品牌处理器。

同时系统还对环境、动力系统进行了全方面的检测，对核心机房、主播间进行温湿度、电流电压进行全方位监测，提供了系统智能化和可靠性。

AoIP和AES67及其对未来音频系统的影响

51技术与应用·研究1.网络音频AoIP由于网络技术的发展，对信息进行处理时，处理效率得到了明显提升。

根据音频行业的整体情况来分析，在这种环境的影响下，因为这些协议的存在，特别是新研发出来的协议，严重阻碍了AoIP的发展。

由于这种需求的作用，随之出现了AES67。

在AES67中，规定了相应的标准，而且，通过TCP/ IP网络协议，数字音频信号利用局域网、互联网，就能实现传输以及共享。

2.2 AES67的核心功能（1）传输、编码以及流媒体：在AES67中，明确定义了RTP协议以及UDP协议的应用，在此基础上，对数据包（标准IP格式）进行传输，在每个数据包中，含有1 ms的音频数据。

（2）与媒体的时钟同步：对离散的音频设备进行整合，使之成为一个系统，而且，要保证和彼此之间能够同步。

用于从与AES67兼容的音频信息信号中推导音频参数值的方法和装置[发明专利]

专利名称：用于从与AES67兼容的音频信息信号中推导音频参数值的方法和装置
专利类型：发明专利
发明人：F·鲍曼,F·伦耶夫斯基
申请号：CN201880046335.3
申请日：20180711
公开号：CN110892652B
公开日：
20220419
专利内容由知识产权出版社提供
摘要：本发明涉及用于从与AES67兼容的音频信息信号中推导音频参数值的方法和装置，该AES67兼容的音频信息信号由连续的IP数据包(IP(i))的串行数据流构成，其中IP数据包包含IP头(IPHDR)、UDP头(UDPHDR)、RTP头(RTPHDR)和数据段(DATA)，并且其中从存储在头中的信息中推导音频参数值，如采样频率和频道数量。

申请人：无线电广播技术研究所有限公司
地址：德国慕尼黑市
国籍：DE
代理机构：深圳市百瑞专利商标事务所(普通合伙)
代理人：金辉
更多信息请下载全文后查看。

IP架构下的网络音频技术发展与AES67基本协议

ｒ、ｎ网络与多媒体
Ｕ＠咖⑥ 护囿嗡圈凹０锄＠６囿
● 一杖一
ａｄｔｏｎｇｉｎｔ●ｒｉｎｇ
ＩＰ架构下的网络音频技术发展与ＡＥＳ６７基本协议
叶思成，袁邈桐（中国传媒大学艺术学部音乐与录音艺术学院，北京１０００２４）
【Ｋｅｙｗｏｒｄｓ】ＩＰ—ｂａｓｅｄ；ＡｕｄｉｏｏｖｅｒＩＰ（ＡｏＩＰ）；ＡＥＳ６７
１ＡｕｄｉｏｏｖｅｒＩＰ：广播电视等行业面临的发展趋势
在广播电视领域中，运用基于ＳＤＩ（ＳｅｒｉａｌＤｉｇｉｔａｌ
通过解读ＡＥＳ６７基本协议规定内容，具体了解该标准的设计理念与目的。
【关键词】网络音频；ＡｕｄｉｏｏｖｅｒＩＰ（ＡｏＩＰ）；ＡＥＳ６７
【中图分类号】ＴＮ９１９．８
【Ａｂｓｔｒａｃｔ】Ｗｉｔｈｔｈｅｒａｐｉｄｄｅｖｅｌｏｐｍｅｎｔｏｆａｕｄｉｏｓｉｇｎａｌｔｒａｎｓｍｉｓｓｉｏｎｔｅｃｈｎｏｌｏｇｙ，ＡｕｄｉｏｏｖｅｒＩＰｉｓｂｅｃｏｍｉｎｇｔｈｅｒｉｓｉｎｇａｕｄｉｏ
・技术交流・
【摘
要】随着音频信号传输技术的飞速发展，ＡｕｄｉｏｏｖｅｒＩＰ正全面进入音频技术领域，正成为广播电视数字音频技

AoIP技术与AES67标准应用探讨

播事建设实例，探讨ＡｏｌＰ技术发展与ＡＥＳ６７标准应用、Ｄａｎｔｅ协议网络音频技术解决方案，以及在实际应】ＡｏＩＰ，ＡＥＳ６７，Ｄａｎｔｅ，网络音频传输，广播总控系统，数字音频云台
ＡｏＩＰ技术与ＡＥＳ６７标准应用探讨
龙向东，管海建
（湖北广播电视台，湖北４３００２２）
【摘
要】广‘ 播中心总控系统的改造、建设是广播电视工程技术领域的重要课题。在Ｊ ’ 播中心数字化、刚络化改造大多
【中图分类号】ＴＮ９３１【文献标识码】Ｂ【ＤＯｌ编码】１０．１６１７１／ｊ．ｃｎｋｉ．ｒｔｂｅ．２０１７００２００４
ＥｘｐｌｏｒａｔｉｏｎｏｆＡｏＩＰＴｅｃｈｎｏｌｏｇｙａｎｄＡＥＳ６７Ｓｔａｎｄａｒｄ
ＩＰＰｒ。ｄｕｃｔｉ。ｎｉｎＲａｄｉ。ｓｔａｔｉ。ｎｓＩ电台制播ＩＰ化热点・论点／
【本文献信息】龙向东，管海建．ＡｏｌＰ技术与ＡＥＳ６７标准应用探讨【Ｊ】．广播与电视技术，２０１７，Ｖｏ１．４４（２）．
络技术已经具备传输多路高质量低延时
已全面完成后，ＡｏｌＰ技术发展迅猛而来，与之相应的ＡＥＳ６７标准也已推出，

AES67标准

AES67标准“AES67是一个开放的网络数字音频标准，它是基于IP网络架构，采用现有的IT网络协议，实现低时延、高性能的专业音频传输的互用性指导方针。

它的开放协议与可兼容性，极大地推动了数字音频技术基于IP网络架构之上的发展。

AES67标准产生的背景从广播电视音频系统的发展进程来看：从使用诸多线缆的模拟音频系统，到引入了“同步”概念的数字音频系统，再到TDM音频矩阵系统，进而到基于以太网实现多个工作间网络互联音频系统，接下来到基于IP架构下实现远程互通互联（工作间之间、不同地域之间）的网络音频技术，如今已形成基于IP架构下的多地点集中式分布系统。

咅频技术能力的演进，IT技术的发展，让整个音视频技术行业搭上了IT 技术的顺风车，音频行业也面临AoIP( Audio over Inter- net Protocol，互联网协议架构下的音频）时代的到来。

目前媒体网络联盟MNA (Media Networking Alliance)通过的网络协议有四个，Livewire、Ravenna、QLAN、Dante。

这四个协议分别对应着业内用的最好的四个厂家，The Telos代表Livewire，Lawo 代表Ravenna，QSC代表QLAN，雅马哈代表Dante。

但是，不同网络协议间是互不兼容的，这对于用户来说非常麻烦。

因为用户大部分选择的不是某一个品牌，而是一个系统，这个系统里可能有很多不同设备，有的设备用这个协议，有的用那个，这些设备往往不能互通。

现在就是有这么一套互通的机制——AES67，能够把不同的协议联通在一起。

当前，Dante、Livewire、Ravenna、QLAN四个协议所覆盖的厂家已经达到90%以上，这意味着AES67标准能打通市场上90%的设备，并解决了用户最棘手的问题。

AES67标准的关键技术1、同步机制网络上任何地点的接收端通过一个公共时钟，可以与其他接收端同步回放，公共时钟可以保证所有流均被以相同的速率采样和还原，同一速率的多个流可以被轻易合成。

AES67协议研究

广Ｉ电疆售ｌ · Ｎｗ．ｒｔｉ．ｏｎ１９
可容纳３２７６７个音频、控制信端可以与其他接
配合丰富的控制监测设备。可满足广
ＡＶＢ技术最主要的一个弊端在收端同步回放。公共时钟确保所有流均
新的以太网音频传输技术。
Ｌｉｖｅｗｉｒｅ音频传输网络是一个综
早期使用的是模拟传输技术采用
２相关技术研究
Ｐ２Ｐ方式，即点到点的传输模式，存２．１Ｄａｎｔｅ
合性、全功能的广播音频网络。除了音频，Ｌｉｖｅｗｉｒｅ网络中还传输Ｌｉｖｅｗｉｒｅ
实时音频节目传输技术发展经历点传输的局限，从而实现数字音频传输播电台数字音频的传输、路由、矩阵、
模拟传输技术、数字音频技术以及最的软交换和软路由。
监测、同步的专业音频系统。
播音频系统中的各种复杂需求。
于构建ＡＶＢ网络时需要使用专用的被以相同的速率采样和还原。同一速率
Ｌｉｖｅｗｉｒｅ音频传输网络中，音频以ＡＶＢ交换机，这意味着无法利用现有的多个流可以被接收端轻易合成。
平台。它主要起着调度音频节目信号、的传输能够兼容现有的以太网络，系统２．２Ｌｉｖｅｗｉｒｅ
质量监控和安全播出保障等作用。实架构将变得简单化，机房布线也将变得

AES标准介绍

发布日期: 12/6/2004 | 更新日期 : 12/6/2004Jam es McCaffrey本文假设您熟悉C# 和位操作。

下载本文的代码：AES.exe (143KB)摘要高级加密标准(AES) 是美国标准与技术研究院针对电子数据的加密所制定的规范，它将要成为公认的数字信息（包括财务数据、电信数据和政府数据）加密方法。

本文概述了AES 并解释了它所使用的算法。

本文还包括一个完整的C# 实现以及 .NET 数据加密的示例。

在阅读完本文后，您将能够使用 AES 对数据进行加密，测试基于 AES 的软件，并在自己的系统中使用AES 加密方法。

本页内容AES 算法概述GF(28) 中的域加法和乘法密钥扩展C# 中的AES 类构造函数C# 中的AES Cipher 方法C# 中的AES InvCipher 方法使用 AES 类实现替换方法小结美国标准与技术研究院(NIST) 于2002 年 5 月26 日制定了新的高级加密标准(AES) 规范。

在本文中，我将提供用C# 编写的AES 的工作实现，并将完整解释到底什么是AES 以及代码如何工作。

我将向您展示如何使用 AES 来加密数据，并扩展此处给出的代码以开发商用质量的AES 类。

我还将解释如何以及为何将 AES 加密合并到软件系统中，以及如何测试基于 AES 的软件。

请注意，本文中提供的代码以及基于本文的任何其他实现都受制于适用的联邦加密模块出口控制（有关确切的规章，请参阅Com m ercial Encryption Export Controls）。

AES 是一种可用来保护电子数据的新型加密算法。

特别是，AES 是可以使用128、192 和256 位密钥的迭代式对称密钥块密码，并且可以对128 位（16 个字节）的数据块进行加密和解密。

与使用密钥对的公钥密码不同的是，对称密钥密码使用同一个密钥来对数据进行加密和解密。

由块密码返回的加密数据与输入数据具有相同的位数。

AES67标准

AES67标准“AES67是一个开放的网络数字音频标准，它是基于IP网络架构，采用现有的IT网络协议，实现低时延、高性能的专业音频传输的互用性指导方针。

它的开放协议与可兼容性，极大地推动了数字音频技术基于IP网络架构之上的发展。

目前媒体网络联盟MNA (Media Networking Alliance)通过的网络协议有四个，Livewire、Ravenna、QLAN、Dante。

这四个协议分别对应着业内用的最好的四个厂家，The Telos代表Livewire，Lawo 代表Ravenna，QSC代表QLAN，雅马哈代表Dante。

但是，不同网络协议间是互不兼容的，这对于用户来说非常麻烦。

现在就是有这么一套互通的机制——AES67，能够把不同的协议联通在一起。

当前，Dante、Livewire、Ravenna、QLAN四个协议所覆盖的厂家已经达到90%以上，这意味着AES67标准能打通市场上90%的设备，并解决了用户最棘手的问题。