《RTP协议的中文版.docx》由会员分享,可在线阅读,更多相关《RTP协议的中文版.docx(59页珍藏版)》请在第一文库网上搜索。
1、RFC3550RTP:实时应用程序传播合同摘要本文描述RTP(reaI-1imetransportprotoco1),实时传播合同。RTP在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传播功能,适合应用程序传播实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传播功能由一种控制合同(RTCP)来扩展,通过扩展,可以用一种方式对数据传播进行监测控制,该合同(RTCP)可以升级到大型时多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传播层和网络层无关。合同支持RTP原则的转换器和
2、混合器的使用。本文的大多数内容和旧版的RFC1889相似。在线路里传播的数据包格式没有变化,唯一的变化是使用合同的规则和控制算法。为了最小化传播,发送RTCP数据包时超过了设定的速率,而在这时,诸多的参与者同步加入了一种会话,在这样的状况下,一种新加入到(用于计算时可升级时)计时器算法中的元素是最大的变化。目录(TQbIe0fContents)1.引言(1trOduction)1 1术语(Termino1ogy)2 RTP使用场景(RTPUSeScerios)3 1简朴多播音频会议(SimPIeMu1ticastAudioConference)4 2音频和视频会议(AUC1iOQndVideo
3、Conferece)5 3混频器和转换器(MiXerSQndTransIators)6 4分层编码(1QyereC1Encodings)7 定义(De行nitions)8 字节序,校正和时间格式(ByteOrder,A1ignment,andTimeFormat)9 RTP数据传播合同(RTPDatoTrasferProtoco1)51RTP固定头域(RTPFixedHeaderFie1ds)52多路复用RTP会话(MUItiPIeXingRTPSessions)53RTP头的配备文献具体变更(Profi1e-SpedficModificatiostotheRTPHeader)531RTP报头
4、扩展(RTPHeQderExtension)6RTP控制合同(RTPContro1ProtocoI)-RTCP61RTCP包格式(RTCPPacketFormat)62RTCP传播间隔(RTCPTransmissionIntervaI)621维护会话成员数目(MQintQiningthenUmberofSessionmembers)63RTCP包时发送与接受规则(RTCPPQCketSenCIQnC1ReceiveRuIes)631计算RTCP传播间隔(ComPUtingtheRTCPTrsmissionIntervaI)632初始化(InitiQ1ization)633接受RTP或RTCP(
5、非BYE)包(ReCeiVinganRTPorNon-BYERTCPPacket)634接受RTCP(BYE)包(ReCeiVinganRTCPBYEPacket)635SSRC计时失效(TimingOutanSSRC)636有关传播计时器的到期(ExpirationofTrasmissionTimer)637传播一种BYE包(TransmittigaBYEPacket)638更新we_sent(Updatigwe_sent)639分派源描述带宽(AIIOCcItioofSourceDescriptionBandwidth)64发送方和接受方报告(SenderandReceiverReport
6、s)641SR:发送方报告的RTCP包(SR:SederreportRTCPpacket)642RR:接受方报告的RTCP包(RR:ReceiverReportRTCPPacket)643扩展发送方和接受方报告(EXtendingtheSenderandReceiverReports)644分析发送方和接受方报告(AnQ1yZingSenderandReceiverReports)65SDES:源描述RTCP包(SDES:SourcedescriptionRTCPpacket)651CNAME:规范终端标记符的SDES数据项(CNAME:Canoica1End-PointIdentifierS
7、DESItem)652NAME:顾客名的SDES数据项(NAME:UsernameSDESitem)653EMAI1:电子邮件地址的SDES数据项(EMA11:日ectroniCMaIIAddressSDESItem)654PHoN巳电话号码的SDES数据项(PHONE:PhOneNumberSDESItern)6551OC:地理顾客地址的SDES数据项(1OG:GeographicUser1ocationSDESItem)656TOO1:应用程序或工具名字的SDES数据项(TOO1:App1ictioorToo1NameSDESItem)657NOT巳告知/状态的ISDES数据项(NOT巳N
8、otice/StatusSDESItem)658PRIV:私有扩展的SDES数据项(PR1V:PrivateEXtensionsSDESItem)6 6BYE:GoodbyeRTCP包(BYE:GooCIbyeRTCPpacket)7 7APP:定义应用程序的RTCP包(APP:APP1ication-DefinedRTCPPacket)8 RTP转换器和混频器(RTPTrns1atorsandMixers)71概述(GenerQIDescription)72在转换器中的RTCP数据解决(RTCPPr。CeSSinginTras1tors)7 3在混频器中的RTCP数据解决(RTCPProce
9、ssinginMixers)8 4级联5昆频器(CascodedMixers)9 SSRC标记符的分派和使用(SSRC1CIentifierA11ocatioandUse)81冲突概率(ProbabiIityOfCoIIision)82冲突解决和循环检测(COIIisionResoIutiod1o0pDetectio)83在分层编码中使用(USeWith1ayeredEncodings)9安全(Security)91机密性(COnfie1entiaIity)9 2身份验证和消息完整性(AUthentiCQtiOnQndMessageIntegrity)10 拥塞控制(COngeStionCon
10、tro1)11网络和传播合同之上的RTP(RTPoverNetworkandTransportProtocoIs)12合同常量摘要(SUmmQryofProtoco1Constants)1 21RTCP包类型(RTCPPacketTypes)122SDES类型(SDESTypes)13RTP概况和负载格式具体阐明(RTPProfi1esandPay1oadFormatSpecificatios)14 安全考虑(SecurityConsiderations)15 IANA考虑(IANAConsiderations)16 知识产权声明(Inte11ectuaIPropertyRightsState
11、ment)17 鸣谢(AcknowIedgments)附录A算法(AIgorithms)附录A1RTP数据头有效性检查(RTPDataHeoderVa1idityChecks)附录A2RTCP数据头有效性检查(RTCPHeQderVaIidityChecks)附录A3拟定RTP包预期数目和丢失数目(DeterminingNumberofPacketsExPectedand1ost)附录A4生成SDESRTCP包(GenerC1tingRTCPSDESPackets)附录A5解析RTCPSDES包(PQrSingRTCPSDESPacketS)附录A6生成32位随机标记符(Generatinga
12、Random32-bitIdentifier附录A7计算RTCP传播间隔(ComPUtingtheRTCPTransmissionInterva1)附录A8估测两次达到间隔的抖动(EstimatingtheInterarriva1Jitter)附录B与RFeI889不同之外(ChangesfromRFC1889)参照书目(Refereces)原则化引用(NormQtiVeReferenCeS)资料性引用(InformativeReferences)作者地址完整的版权声明1.绪论本文具体的简介实时传播合同RTP,RTP提供带有实时特性的端对端数据传播服务,传播的数据如:交互式的音频和视频。那些服
13、务涉及有效载荷类型定义,序列号,时间戳和传播监测控制。应用程序在UDP上运营RTP来使用它的多路技术和checksum服务。2种合同都提供传播合同的部分功能。但是,RTP也许被其他合适的下层网络和传播合同使用(见11节)。如果下层网络支持,RTP支持数据使用多播分发机制转发到多种目的地。注意RTP自身没有提供任何的机制来保证明时的传播或其他的服务质量保证,而是由低层的服务来完毕。它不保证传播或避免乱序传播,它不假定下层网络与否可靠,与否按顺序传送数据包。RTP涉及的序列号容许接受方重构发送方的数据包顺序,但序列号也用来拟定一种数据包的对的位置,例如,在视频解码的时候不用按顺序时对数据包进行解码
14、。但是RTP原先的设计是用来满足多参与者的多媒体会议的需要,它没有限定于专门时应用。持续数据的储存,交互分布式仿真,动态标记,以及控制和测量应用程序也也许会适合使用RTPo该文档定义RTP,由2个密切联系的部分构成:O实时传播合同RTP,用于实时传播数据。ORTP控制合同RTCP,用于监控服务质量和传达有关在一种正在进行的会议中的参与者的信息。后者对“宽松控制”的会议也许已经足够,但是并没有必要去支持一种应用程序所有的通讯控制条件。这个功能也许充足的或者部分的被一种单独的会议控制合同所涉及,这超过了本文档的范畴。RTP体现了合同的一种新的类型,该类型由CIQrk和TennenhOUSe提出10
15、,遵循应用级(froming)框架和(integrted1ayerprocessing)统一层解决的原则。就是说,RTP被规定为可扩展的,用来提供一种专门的应用程序需要的信息,并将会常常性的被归并到应用程序的解决中,而不是作为一种单独时层被实现。RTP只是一种故意不完毕的合同框架。本文档具体阐明那些功能,但愿这些功能可以普遍贯穿于所有适合使用RTP时应用程序。和常规的合同不同,额外的功能也许通过完善合同自身或者增长一种也许需要分析的选项机制来增长,RTP被规定为可以根据需要通过修改和/或增长操作,“剪裁”到报头。具体的例子见5.3和6.4.3节。因此,除了本文档,用于专门应用程序的RTP完整的阐明将还需要一种或者更多的同类文档(见13节):O一种框架(大体轮廓)的阐明文档,该文档定义了一系列的有效载荷类型编码和它们与有效载荷格式之间的映射(例如,媒体编码)。一种框架也许也定义了应用程序对RTP的某些扩展和修改,具体到一种专门的类。典型的状况,一种应用程序将在一种框架下运营。一种用于音频和视频数据的框架可以在同类RFC35511文档里找到。有效载荷格式阐明文档,该文档定义了一种像一种音频或者视频编码的特殊载荷,在RTP里是如何被传播时。一种有关实时服务和算法如何实现的讨