RFC3550中文版

-1-RFC3550RTP：实时应用程序传输协议摘要本文描述RTP（real-timetransportprotocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。本文的大多数内容和旧版的RFC1889相同。在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。目录（TableofContents）1.引言（Introduction）11术语（Terminology）2RTP使用场景（RTPUseScenarios）21简单多播音频会议（SimpleMulticastAudioConference）22音频和视频会议（AudioandVideoConference）23混频器和转换器（MixersandTranslators）24分层编码（LayeredEncodings）3定义（Definitions）4字节序，校正和时间格式（ByteOrder,Alignment,andTimeFormat）5RTP数据传输协议（RTPDataTransferProtocol）51RTP固定头域（RTPFixedHeaderFields）52多路复用RTP会话（MultiplexingRTPSessions）53RTP头的配置文件详细变更（Profile-SpecificModificationstotheRTPHeader）531RTP报头扩展（RTPHeaderExtension）6RTP控制协议（RTPControlProtocol）--RTCP61RTCP包格式（RTCPPacketFormat）62RTCP传输间隔（RTCPTransmissionInterval）621维护会话成员数目（Maintainingthenumberofsessionmembers）63RTCP包的发送与接收规则（RTCPPacketSendandReceiveRules）631计算RTCP传输间隔（ComputingtheRTCPTransmissionInterval）632初始化（Initialization）633接收RTP或RTCP（非BYE)包（ReceivinganRTPorNon-BYERTCPPacket）634接收RTCP（BYE）包（ReceivinganRTCPBYEPacket）635SSRC计时失效（TimingOutanSSRC）636关于传输计时器的到期（ExpirationofTransmissionTimer）637传输一个BYE包（TransmittingaBYEPacket）638更新we_sent（Updatingwe_sent）639分配源描述带宽（AllocationofSourceDescriptionBandwidth）64发送方和接收方报告（SenderandReceiverReports）-2-641SR：发送方报告的RTCP包（SR:SenderreportRTCPpacket）642RR：接收方报告的RTCP包（RR:ReceiverReportRTCPPacket）643扩展发送方和接收方报告（ExtendingtheSenderandReceiverReports）644分析发送方和接收方报告（AnalyzingSenderandReceiverReports）65SDES：源描述RTCP包（SDES:SourcedescriptionRTCPpacket）651CNAME：规范终端标识符的SDES数据项(CNAME:CanonicalEnd-PointIdentifierSDESItem）652NAME：用户名的SDES数据项（NAME:UsernameSDESitem)653EMAIL:电子邮件地址的SDES数据项（EMAIL:ElectronicMailAddressSDESItem）654PHONE：电话号码的SDES数据项（PHONE:PhoneNumberSDESItem）655LOC:地理用户地址的SDES数据项（LOC:GeographicUserLocationSDESItem）656TOOL：应用程序或工具名字的SDES数据项（TOOL:ApplicationorToolNameSDESItem）657NOTE：通知/状态的SDES数据项（NOTE:Notice/StatusSDESItem）658PRIV:私有扩展的SDES数据项（PRIV:PrivateExtensionsSDESItem）66BYE：GoodbyeRTCP包（BYE:GoodbyeRTCPpacket）67APP:定义应用程序的RTCP包（APP:Application-DefinedRTCPPacket）7RTP转换器和混频器（RTPTranslatorsandMixers）71概述（GeneralDescription）72在转换器中的RTCP数据处理（RTCPProcessinginTranslators）73在混频器中的RTCP数据处理（RTCPProcessinginMixers）74级联混频器（CascadedMixers）8SSRC标识符的分配和使用（SSRCIdentifierAllocationandUse）81冲突概率（ProbabilityofCollision）82冲突解决和循环检测（CollisionResolutionandLoopDetection）83在分层编码中使用（UsewithLayeredEncodings）9安全（Security）91机密性（Confidentiality）92身份验证和消息完整性（AuthenticationandMessageIntegrity）10拥塞控制（CongestionControl）11网络和传输协议之上的RTP（RTPoverNetworkandTransportProtocols）12协议常量摘要（SummaryofProtocolConstants）121RTCP包类型（RTCPPacketTypes）122SDES类型（SDESTypes）13RTP概况和负载格式详细说明（RTPProfilesandPayloadFormatSpecifications）14安全考虑（SecurityConsiderations）15IANA考虑（IANAConsiderations）16知识产权声明（IntellectualPropertyRightsStatement）17鸣谢（Acknowledgments）附录A算法（Algorithms）附录A1RTP数据头有效性检查（RTPDataHeaderValidityChecks）附录A2RTCP数据头有效性检查（RTCPHeaderValidityChecks）附录A3确定RTP包预期数目和丢失数目（DeterminingNumberofPacketsExpectedandLost）附录A4生成SDESRTCP包（GeneratingRTCPSDESPackets）附录A5解析RTCPSDES包（ParsingRTCPSDESPackets）-3-附录A6生成32位随机标识符（GeneratingaRandom32-bitIdentifier附录A7计算RTCP传输间隔（ComputingtheRTCPTransmissionInterval）附录A8估测两次到达间隔的抖动（EstimatingtheInterarrivalJitter）附录B与RFC1889不同之外（ChangesfromRFC1889）参考书目（References）标准化引用（NormativeReferences）资料性引用（InformativeReferences）作者地址完整的版权声明1.绪论本文详细的介绍实时传输协议RTP，RTP提供带有实时特性的端对端数据传输服务，传输的数据如：交互式的音频和视频。那些服务包括有效载荷类型定义，序列号，时间戳和传输监测控制。应用程序在UDP上运行RTP来使用它的多路技术和checksum服务。2种协议都提供传输协议的部分功能。不过，RTP可能被其他适当的下层网络和传输协议使用（见11节）。如果下层网络支持，RTP支持数据使用多播分发机制转发到多个目的地。注意RTP本身没有提供任何的机制来确保实时的传输或其他的服务质量保证，而是由低层的服务来完成。它不保证传输或防止乱序传输，它不假定下层网络是否可靠，是否按顺序传送数据包。RTP包含的序列号允许接受方重构发送方的数据包顺序，但序列号也用来确定一个数据包的正确位置，例如，在视频解码的时候不用按顺序的对数据包进行解码。但是RTP原先的设计是用来满足多参与者的多媒体会议的需要，它没有限定于专门的应用。连续数据的储存，交互分布式仿真，动态标记，以及控制和测量应用程序也可能会适合使用RTP。该文档定义RTP，由2个密切联系的部分组成：○实时传输协议RTP，用于实时传输数据。○RTP控制协议RTCP，用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息。后者对“宽松控制”的会议可能已经足够，但是并没有必要去支持一个应用程序所有的通讯控制条件。这个功能可能充分的或者部分的被一个单独的会议控制协议所包含，这超过了本文档的范围。RTP表现了协议的一种新的类型，该类型由Clark和Tennenhouse提出[10]，遵循应用级（framing）框架和（integratedlayerprocessing）统一层处理的原则。就是说，RTP被规定为可扩展的，用来提供一个专门的应用程序需要的信息，并将会经常性的被归并到应用程序的处理中，而不是作为一个单独的层被实现。RTP只是一个故意不完成的协议框架。本文档详细说明那些功能，希望这些功能能够普遍贯穿于所有适合使用RTP的应用程序。和常规的协议不同，额外的功能可能通过完善协议本身或者增加一个可能需要分析的选项机制来增加，RTP被规定为可以根据需要通过修改和/或增加操作，“剪裁”到报头。具体的例子见5.3和6.4.3节。因此，除了本文档，用于专门应用程序的RTP完整的说明将还需要一个或者更多的同类文档（见13节）：○一个框架（大致轮廓）的说明文档，该文档定义了一系列的有效载荷类型编码和它们与有效载荷格式之间的映射（例如，媒体编码）。一个框架可能也定义了应用程序对RTP的一些扩展和修改，详细到一个专门的类。典型的情况，一个应用程序将在一个框架下运行。一个用于音频和视频数据的框架可以在同类RFC3551[1]文档里找到。○有效载荷格式说明文档，该文档定义了一个像一个音频或者视频编码的特殊载荷，在RTP里是如何被传输的。一个关于实时服务和算法如何实现的讨论和关于一些RTP设计结果的后台讨论能够在[11]中找到。1.1术语在这个文档里的关键词“一定要”，“一定不能”，“必需的”，“会”，“不会”，“应该”，“不应该”，“推荐”，“可能”和“可选”将会像在BCP14（BasicControlProgram，基本控制程序），RFC2119[2]里描述一样的解释。并指出适合RTP实现的需要的级别。-4-2.RTP使用场景（RTPUseScenarios）2.1简单多播音频会议（SimpleMulticastAudioConference）2