RTP实时传输协议规范.docx
《RTP实时传输协议规范.docx》由会员分享，可在线阅读，更多相关《RTP实时传输协议规范.docx（44页珍藏版）》请在冰点文库上搜索。
RTP实时传输协议规范
RFC3550
RTP：
实时应用程序传输协议
摘要
本文描述RTP（real-timetransportprotocol），实时传输协议。
RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：
音频，视频或者仿真数据。
RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。
数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。
RTP和RTCP被设计成和下面的传输层和网络层无关。
协议支持RTP标准的转换器和混合器的使用。
本文的大多数内容和旧版的RFC1889相同。
在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。
为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。
目录（TableofContents）
1. 引言（Introduction）
11 术语（Terminology）
2 RTP使用场景（RTPUseScenarios）
21 简单多播音频会议（SimpleMulticastAudioConference）
22 音频和视频会议（AudioandVideoConference）
23 混频器和转换器（MixersandTranslators）
24 分层编码（LayeredEncodings）
3 定义（Definitions）
4 字节序，校正和时间格式（ByteOrder,Alignment,andTimeFormat）
5 RTP数据传输协议（RTPDataTransferProtocol）
51 RTP固定头域（RTPFixedHeaderFields）
52 多路复用RTP会话（MultiplexingRTPSessions）
53 RTP头的配置文件详细变更（Profile-SpecificModificationstotheRTPHeader）
531 RTP报头扩展（RTPHeaderExtension）
6 RTP控制协议（RTPControlProtocol）--RTCP
61 RTCP包格式（RTCPPacketFormat）
62 RTCP传输间隔（RTCPTransmissionInterval）
621 维护会话成员数目（Maintainingthenumberofsessionmembers）
63 RTCP包的发送与接收规则（RTCPPacketSendandReceiveRules）
631 计算RTCP传输间隔（ComputingtheRTCPTransmissionInterval）
632 初始化（Initialization）
633 接收RTP或RTCP（非BYE）包（ReceivinganRTPorNon-BYERTCPPacket）
634 接收RTCP（BYE）包（ReceivinganRTCPBYEPacket）
635 SSRC计时失效（TimingOutanSSRC）
636 关于传输计时器的到期（ExpirationofTransmissionTimer）
637 传输一个BYE包（TransmittingaBYEPacket）
638 更新we_sent（Updatingwe_sent）
639 分配源描述带宽（AllocationofSourceDescriptionBandwidth）
64 发送方和接收方报告（SenderandReceiverReports）
641 SR：
发送方报告的RTCP包（SR:
SenderreportRTCPpacket）
642 RR：
接收方报告的RTCP包（RR:
ReceiverReportRTCPPacket）
643 扩展发送方和接收方报告（ExtendingtheSenderandReceiverReports）
644 分析发送方和接收方报告（AnalyzingSenderandReceiverReports）
65 SDES：
源描述RTCP包（SDES:
SourcedescriptionRTCPpacket）
651 CNAME：
规范终端标识符的SDES数据项（CNAME:
CanonicalEnd-PointIdentifierSDESItem）
652 NAME：
用户名的SDES数据项（NAME:
UsernameSDESitem）
653 EMAIL:
电子邮件地址的SDES数据项（EMAIL:
ElectronicMailAddressSDESItem）
654 PHONE：
电话号码的SDES数据项（PHONE:
PhoneNumberSDESItem）
655 LOC:
地理用户地址的SDES数据项（LOC:
GeographicUserLocationSDESItem）
656 TOOL：
应用程序或工具名字的SDES数据项（TOOL:
ApplicationorToolNameSDESItem）
657 NOTE：
通知/状态的SDES数据项（NOTE:
Notice/StatusSDESItem）
658 PRIV:
私有扩展的SDES数据项（PRIV:
PrivateExtensionsSDESItem）
66 BYE：
Goodbye RTCP包（BYE:
GoodbyeRTCPpacket）
67 APP:
定义应用程序的RTCP包（APP:
Application-DefinedRTCPPacket）
7 RTP转换器和混频器（RTPTranslatorsandMixers）
71 概述（GeneralDescription）
72 在转换器中的RTCP数据处理（RTCPProcessinginTranslators）
73 在混频器中的RTCP数据处理（RTCPProcessinginMixers）
74 级联混频器（CascadedMixers）
8 SSRC标识符的分配和使用（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）
附录A1 RTP数据头有效性检查（RTPDataHeaderValidityChecks）
附录A2 RTCP数据头有效性检查（RTCPHeaderValidityChecks）
附录A3 确定RTP包预期数目和丢失数目（DeterminingNumberofPacketsExpectedandLost）
附录A4 生成SDES RTCP包（GeneratingRTCPSDESPackets）
附录A5 解析RTCP SDES包（ParsingRTCPSDESPackets）
附录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实现的需要的级别。
2. RTP使用场景（RTPUseScenarios）
2.1 简单多播音频会议（SimpleMulticastAudioConference）
2.2 音频和视频会议（AudioandVideoConference）
2.3 混频器和转换器（MixersandTranslators）
2.4 分层编码（LayeredEncodings）
以下章节描述了用到RTP的一些方面。
所举例子用来说明RTP应用的基本操作，但RTP的用途不限于此。
在这些例子中，RTP运行于IP和UDP之上，并且遵循RFC3551所描述的音频和视频的配置文件中的约定。
2.1简单多播音频会议（SimpleMulticastAudioConference）
IETF的一个工作组开会讨论最新协议草案时，使用Internet的IP多播服务来进行语音通讯。
工作组中心分配到一个多播的组地址和一对端口。
一个端口用于音频数据，另一个端口用于控制（RTCP）数据包。
该地址和端口信息发布给预定的参与者。
如果有私密性要求，则可用章节9.1中说明的方法，对数据和控制包进行加密，这时就需要生成和发布加密密钥。
分配和发布机制的精确细节不在RTP的讨论范围之内。
每个与会者所使用的音频会议应用程序，都以小块形式（比方说持续２０秒时间）来发送音频数据。
每个音频数据块都前导RTP报头；RTP报头和数据依次包含在UDP包里。
RTP报头指明了各个包里音频编码的类型（如PCM,ADPCM,LPC），这样发送方可以在会议过程中改变编码方式，以适应状况的变化，例如，要加进一个低带宽接入的参与者，或是要应付网络拥塞。
Internet，像其他的报文分组网络一样，偶而会丢失和重排包，造成时长不等的延迟。
为弥补这个不足，RTP报头里包含计时信息和一个序列号，允许接收方重建来自源的计时信息，比如前文例子中音频块以20s的间隔在扬声器中连续播放。
会议中，对每个RTP包的源,单独地实施计时重建。
序列号还被接收方用来评估丢失包数目。
由于会议期间不断有工作组成员加入或离开，因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。
出于这个目的，会议中每个音频应用程序的实例，都在RTCP（控制）端口上周期性地多播一个附加用户名的接收报告。
接收报告指明了当前说话者被收听到的状况，可用于控制自适应性编码。
除了用户名外，通过控制带宽限度，可以包含其他标识信息。
一个站点在离开会议时发送RTCPBYE包（章节6.5）。
2.2 音频和视频会议（AudioandVideoConference）
一个会议如果同时使用音频和视频媒体，则二者传输时使用不同的RTP会话。
也就是说，两种媒体中RTP包和RTCP包的传输，是使用两个不同的UDP端口对和（或）多播地址。
在RTP层次，音频和视频会话没有直接的耦合，下面这种情况除外：
一个同时参加两个会话的参与者，在两个会话的RTCP包中，使用了相同的规范名，这样两个会话就发生关联（耦合）了。
这样区隔开来的目的之一，是允许一些会议参与者只接受自己选择的单一媒体（或者音频，或者视频）。
更进一步的说明在章节5.2给出。
尽管两种媒体区分开来了，但通过两个会话RTCP包内载有的计时信息，同源的音频与视频还是能够同步回放。
2.3 混频器和转换器（MixersandTranslators）
到目前为止，我们皆假设所有站点都收到相同格式的媒体数据。
然而这并不总是行得通。
考虑一下这种情况，一个地方的参与者只能低速接入会议，而其他大部分参与者都能享受高速连接。
与其让强迫大家都忍受低带宽，不如在只能低速接入的地方，放置一个减质量音频编码的RTP层次的中继（称作混频器）。
混频器将重新同步输入的音频包，重建发送方产生的20ms固定间隔，混频已重建过的音频流为单一的流，转换音频编码为低带宽格式，最后通过低带宽连接转发数据包流（packagestream）。
这些包可能被单播到一个接收方，也可能多播到另一个的地址而发给多个接收方。
RTP报头为混频器提供了一种方法，使其能辨识出对混频后的包有用的源，从而保证提供给接收方正确的说话者指示。
在音频会议中，一些预定参与者尽管有高带宽连接，但不能通过IP多播直接接入会议。
例如，他们可能位于一个不允许任何IP包通过的应用层防火墙后面。
对这些站点，可能就不需要混频，而需要另一种称为转换器的RTP层次中继。
可以在防火墙两侧分别安装一个转换器，外侧转换器将所有多播包通过安全连接转入内侧转换器，内侧转换器再转发给内部网的一个多播组（multicastgroup）。
混频器和转换器可以设计成用于各种目的。
比如，一个视频混频器在测量多个不同视频流中各人的单独影像后，将它们组合成一个单一视频流来模拟群组场景。
又如，在只用IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。
再如，在没有重新同步或混频时，用packet-by-packet编码转换来自各个独立源的视频流。
混频器和转换器的操作细节见章节7。
2.4分层编码（LayeredEncodings）
为了匹配接收方的能力（容量）以及适应网络拥塞，多媒体应用程序应当能够调整其传输速率。
许多应用实现把调适传输速率的责任放在源端。
这种做法在多播传输中并不好，因为不同接收方对带宽存在着冲突性需求。
这经常导致最小公分母的场景，网格中最小的管道支配了全部实况多媒体“广播”的质量和保真度。
相反地，可以把分层编码和分层传输系统组合起来，从而把调适速率的责任放在接收端。
在IP多播之上的RTP上下文中，对一个横跨多个RTP会话（每个会话在独自多播组上开展）的分级表示信号（ahierarchicallyrepresentedsignal），源能够把它的分层（layers）分割成条。
接收方仅需合并适当的多播组子集，就能适应异种网络和控制接收带宽。
RTP分层编码的细节在章节6.3.9，8.3和11中给出。
3. 定义（definitions）
RTP负载（RTPpayload）：
通过RTP传输的包中的数据，例如，音频样本或压缩好的视频数据。
负载格式与解释不在本文讨论范围。
RTP包（RTPpacket）：
一种数据包，其组成部分有：
一个固定RTP报头，一个可能为空的作用源（contributingsources）列表（见下文），以及负载数据。
一些下层协议可能要求对RTP包的封装进行定义。
一般地，下层协议的一个包包含一个RTP包，但若封装方法允许，也可包含数个RTP包（见章节11）。
RTCP包（RTCPpacket）：
一种控制包，其组成部分有：
一个类似RTP包的固定报头，后跟一个结构化的部分，该部分具体元素依不同RTCP包的类型而定。
格式的定义见章节６。
一般地，多个RTCP包将在一个下层协议的包中以合成RTCP包的形式传输；这依靠RTCP包的固定报头中的长度字段来实现。
端口（Port）：
“传输协议用来在同一主机中区分不同目的地的一种抽象。
TCP/IP协议使用正整数来标识不同端口。
”[12] OSI传输层使用的传输选择器（TSEL,thetransportselectors）等同于这里的端口。
RTP需依靠低层协议提供的多种机制，如“端口”用以多路复用会话中的RTP和RTCP包。
传输地址（Transportaddress）：
是网络地址与端口的结合，用来标识一个传输层次的终端，例如一个IP地址与一个UDP端口。
包是从源传输地址发送到目的传输地址。
RTP媒体类型（RTPmediatype）：
一个RTP媒体类型是一个单独RTP会话所载有的负载类型的集合。
RTP配置文件把RTP媒体类型指派给RTP负载类型。
多媒体会话（Multimediasession）：
在一个参与者公共组中，并发的RTP会话的集合。
例如，一个视频会议（为多媒体会话）可能包含一个音频RTP会话和一个视频RTP会话。
RTP会话（RTPsession）：
一群参与者通过RTP进行通信时所产生的关联。
一个参与者可能同时参与多个RTP会话。
在一个多媒体会话中，除非编码方式把多种媒体多路复用到一个单一数据流中，否则每种媒体都将使用各自的RTCP包，通过单独的RTP会话来传送。
通过使用不同的目的传输地址对（一个网络地址加上一对分别用于RTP和RTCP的端口，构成了一个传输地址对）来接收不同的会话，参与者能把多个RTP会话区隔开来。
单个RTP会话中的所有参与者，可能共享一个公用目的传输地址对，比如IP多播的情况；也可能各自使用不同的目的传输地址对，比如个体单播网络地址加上一个端口对。
对于单播的情况，参与者可能使用相同端口对来收听其他所有参与者，也可能对来其他每个参与者使用
升级会员 