GY_T 304-2016高性能流化音频在IP网络上的互操作性规范.pdf

GY中华人民共和国广播电影电视行业标准GY/T 304—2016高性能流化音频在IP网络上的互操作性规范High-performance streaming audio-over-IP interoperability2017-01-04发布2017-01-04实施国家新闻出版广电总局发布 GY/T 304—2016目次前言引言范国规范性引用文件3术语、定义和缩略语4同步5媒体时钟6传输2编码与成流8会话描述6发现服务10连接管理..14附录A（规范性附录）媒体类别，16附录B（资料性附录）IEEE802.1AS时钟域接口附录C（资料性附录）网络QoS配置建议21附录D（资料性附录）AVB网络传输附录E（资料性附录)发现系统.26参考文献，28 GY/T 304—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概述本章介绍编码和封包的媒体数据如何在网络中传输。基于开放式系统互联模型（0SImode1）本章定义第3层（网络层）和第4层（传输层）上的操作方式。本标准并未规定如何在0SImode1的更低层实现互操作。本标准是基于理想的IP网络传输技术。注：IP报文在以太网上的传输标准见RFC894.6.2网络层媒体数据包应使用RFC791中定义的IPv4传输。注1：本标准暂不支持IPr6.尽管RFC791中要求支持分片数据包重组，但本标准对接收器不作此要求。不支持分片数据包重组的接收器应忽略IP分片数据包。发送器可在传出的媒体数据包的IP包头中设置禁止拆分标记（DF）位。如果网络要对标记为DF的数据包进行分片，此数据包将被丢弃，发送器将收到ICMP“TooBig”消息。发送器在收到此消息后，宜终止传输该流。组播消息，例如同步消息，应使用RFC1112中描述的IP组插播实现。注2：有关IP组据的更多信总光RFC3170，所有设备应支持RFC2236中定义的IGMPv2，也可支持RFC3376中定义的IGMPv3。注3：上文提出支持IGMPv2的要求是因为运行于IGJIPv2网络中的IGNPv3设备需两分钟启动延时来查找网络中的IGMPv3 服务注4：RFC 2236和RFC 3376提出了向下兼容的要求，支持IGIPv2的设备可以在IGMPv1或IGJIPv2的网络中正常运行，支持IGJIPv3的设备可以在IGMPv1、IGMPv2或IGNPv3的网络中正常运行。设备应使用互联网组管理协议（IGMP）来请求接收所需的组择，包括接收同步信息（见GB/T25931一2010附永D中D.3）、使用组播导址的媒体流（见7.7）以及设备上可能使用的其他应用协议信息（例如第9章的发现服务），注5：在案些路由重新配置的情况下，IGWP注册数帮可能会被网络清除，这可能会导致流数据中断，重传IGM成员报告，是一种有效的快速恢复服务的方法，可通过关闭并立即重启受影响的组插网络套接字来实现。在发送组播媒体数据包之前，发送器应使用IGMP协议向接收器发送查询并收到确认报文。注6：通过发送IGVP请求，发送器实际上不会接收到它发送的数据包，面是为了阻止不必要的组择媒体数据泛董有些IGJP探测的实现可能会造成无注期成员的组播组数据包泛置。7 GY/T 304—2016注7：这种需求通常以发送器接收实时传输控制协议（RTCP）消息的方式实现：在RF