六、傳 AES5-2008(AESrecommendedpracticeforprofessionaldigitalaudioPreferredsamplingfrequenciesforapplicationsemployingpulse-codemodulation)AES11-2009(R2014(AESrecommendedpracticefordigitalaudioengineeringSynchronizationofdigitalaudioequipmentinstudioEBUTech3326音頻在IP(AudiocontributionoverIP-RequirementsIEEE1588-2002(IEEEStandardforaPrecisionClockSychronizationProtocolforNetworkedMeasurementandControlSystems)IEEE802.1AS-2011(TimingandSnchronizationforTime-SensitiveApplicationsinBridgedLocalAreaNetworks)IEEE802.10-2011(MediaAccessControl(MACBridgesandVirtualBridgedLocalAreaNetworks)GYT+304-2016高性能流化音頻在IP網絡上的互操作性規范GYT+341-2020IP傳輸的地面數字電視廣播單頻網組網技術規范GYT+348-2021專業廣播環境下音視頻設備精確時間同步協議規范GYT+285-2014數字音頻設備音頻特性測量方法boundary(PTPprecisiontimeprotocol由IEEE1588-2002、GB/T25931-2010和IEEE802.1AS-2011media3.1.5網絡時鐘networkclockRTPRTPordinary(PTP為主時鐘:或與另一個時鐘同步，即為從時鐘[GB/T25931--2010，定義3.1.23]digitalaudioreferencesignal;DARSAES11一2009(R2014)中定義的音頻時鐘信號。contributingsourcedifferentiateddifferentiatedservicescode6464bitextendeduniqueidentifierEUl-3.2.6最高級時鐘標識符grandmasteridentifier;GMID一種EUI-64唯一標識符，用于標識為同步域提供服務的最高級時鐘，在GB/T25931一2010和internetgroupmanagementprotocol;linkmediamaximumtransmission3.2.11開放式系統互聯模型opensystemsinterconnectionmodel;networkpacketqualityofservice接收器receiver一種可以從網絡接收媒體流的網絡設備requestforcomment3.2.16實時傳輸協議real-timetransportprotocol;RTPreal-timetransportcontrolprotocolRTPRTPRTPRTPaudiostreamsessiondescriptionprotocol發送器sender一種可以將媒體流發送到網絡上的網絡設備。SIP一種在SIP協議中用于識別用戶代理URI的字段。SIPURI采用sip:<user>@<domain>或transportlayersecurity;transparent(PTPPTP事件報文的時鐘提供該信息的transportuser[GB/T25931--2010，定義expeditedARB任意(Arbitrary)

(AudioVideoBridging)盡力轉發(BestEffort)(DomainNameIEEE(InstituteofElectricalandElectronicsIETF(InternetEngineeringTaskForce)IP(InternetIPv44(InternetProtocolversion4)IPV66(InternetProtocolversion6)SAP會話公告協議(SessionAnnouncementProtocol)SIP會話發起協議(SessionInitiationProtocol)UDP用戶數據報協議(UserDatagramProtocol)URI(UniformResource時鐘的同步應通過GB/T25931一2010中規定的精確時間協議(PTP)來實現。GB/T25931-2010定義了各種同步傳輸應用類別(profile)。這些類別描述了協議的屬性、可選項和設備的性能需求。GB/T25931-2010為延時請求-響應機制(GB/T25931一2010附錄J中J.3(GB/T25931一2010中支持缺省類別的設備應使用GB/T25931-2010附錄D規定的IPv4封裝。在GB/T25931一2010則媒體時鐘前進48000個采樣時間。在GB/T25931一2010中7.2.2定義的歷元，媒體理所有發生在歷元與當前時間之間的溢出。OSImodel)，本章定義網絡層和傳輸層上的操作方式。本標準并未規定如何在OSImodel的更低層實現互操作。IP報文在以太網上的傳輸標準見RFC894媒體數據包應使用RFC791中定義的IPv4傳輸。注1:本標準暫不支持IPv6。進行分片，此數據包將被丟棄，發送器將收到ICMP“TooBig”消息。發送器在收到此消息后,宜終止傳輸該流。組播消息，例如同步消息，應使用RFC1112中描述的IP組播實現。注2IPRFC3170注3:上文提出支持IGMPv2IGMPV2IGMPV3查找網絡中的IGMPv3服務。注4:RFC2236和RFC3376提出了向下兼容的要求。支持IGMPV2的設備可以在IGMPV或GMP2的網絡中正常運行。支持IGMPv3的設備可以在IGMP1、IGMPv2或IGMPv3的網絡中正常運行。設備應使用互注5:在某些路由重新配置的情況下，IGMP注冊數據可能會被網絡清除，這可能會導致流數據中斷。注6IGMP體數據泛濫。有些IGMP探測的實現可能會造成無注冊成員的組播組數據包泛濫。不強求設備發送或接收RTCP數據包。設備應使用RFC3550中定義的實時傳輸協議。設備應運行與RFC3551中定義的滿足最低控制要求的音注:在盡管RTP協