寻找方向程序猿、攻城狮
分类： 网络与安全
2022-09-04 23:31:44
RTP: 实时应用的传输协议 (RFC1889,更新版本：3550)
概述 本备忘录描述RTP，实时传输协议。RTP提供端到端网络传输功能，适应于应用程序通过多播或单播的网络服务传输诸如音频，视频或并发数据之类的实时数据。RTP不解决资源保留问题(resource reservation)，也不保证实时服务的服务质量。数据传输
由控制协议RTCP进行协商，以能够用一种可扩展到大型多播网络的方法监督数据传输，并且提供最小控制和标识功能。RTP和RTCP被设计成独立于底层传输和网络层。该协议支持RTP级的转换器和混合器。
目录
1 介绍
2 RTP使用场景
2.1 简单的多播音频会议
2.2 音频和视频会议
2.3 混合器和转换器
3 定义
4 字节序，对齐，和时间格式
5 RTP数据传输协议
5.1 RTP固定头部字段
5.2 多路复用RTP会话
5.3 Profile-Specific Modifications to the RTP Header
5.3.1 RTP头部扩展
6 RTP控制协议RTCP
6.1 RTCP包格式
6.2 RTCP传输间隔
6.2.1 会话成员数的维护
6.2.2 source description带宽的分配
6.3 Sender和Receiver Reports
6.3.1 SR：Sender report RTCP包
6.3.2 RR：Receiver report RTCP包
6.3.3 sender和receiver reports的扩展
6.3.4 sender和receiver reports的分析
6.4 SDES：Source description RTCP包
6.4.1 CNAME：Canonical end-point identifier SDES item
6.4.2 NAME: User name SDES item
6.4.3 EMAIL: Electronic mail address SDES item
6.4.4 PHONE: Phone number SDES item
6.4.5 LOC: Geographic user location SDES item
6.4.6 TOOL: Application or tool name SDES item
6.4.7 NOTE: Notice/status SDES item
6.4.8 PRIV: Private extensions SDES item
6.5 BYE: Goodbye RTCP packet
6.6 APP: Application-defined RTCP packet
7 RTP Translators and Mixers
7.1 General Description
7.2 RTCP Processing in Translators
7.3 RTCP Processing in Mixers
7.4 级联(Cascaded) Mixers
8 SSRC Identifier 分配和使用
8.1 Probability of Collision （碰撞概率）
8.2 碰撞解决方案和循环探测出（Collision Resolution and Loop Detection）
9 安全性
9.1 机密性（Confidentiality）
9.2 报文鉴别和消息完整性（Authentication and Message Integrity）
10 RTP网络和传输协议
11 协议常量概要
11.1 RTCP包类型
11.2 SDES类型
12 RTP Profiles和负载格式规范
附录A 算法
A.1 RTP数据头部合法性检查
A.2 RTCP头部合法性检查
A.3 RTP包接收和丢失数目的确定（Determining the Number of RTP Packets Expected and Lost）
A.4 生成SDES RTCP包
A.5 分析RTCP SDES包
A.6 产生随机的32位标识符
A.7 计算RTCP传输间隔
A.8 估算间隔的Jitter（Estimating the Interarrival Jitter）附录B 安全性考虑
附录D 参考文献
. Introduction
这个备忘录规定了实时传输协议RTP，它为交互性的音频和视频此类有实时属性的数据提供端到端的传输服务。这些服务包含负载类型标识，序列号，时间戳和传输监控。应用程序一般基于UDP协议来传输RTP数据，利用了UDP协议的多路复用和检验和服务，综合利用了两个
协议的各一本部分。但是，RTP也可以使用其他合适的底层网络和传输协议(具体看第10章)。如果底层网络支持多播的话，RTP能够支持传输数据给多个目标。
注意RTP本身不提供某些机制来确保及时交付或者服务质量保证，而是依赖于底层服务来实现。它不保证传输或者防止乱序传输，而是假设底层网络是足够可靠的并按需传输数据包。 RTP中的序列号允许接收方重建发送方的包顺序，而且序列号也可用于确定一个包
的合适位置，譬如在视频解码中，没必要按顺序对包进行解码。
虽然RTP主要是为了满足多方参与的多媒体会议而设计，但它不局限于特定的应用。连续数据的存储，交互式分布式仿真，主动标记，控制和测量应用也可以找到RTP的应用。
本文档定义了RTP，由两个密切相关的部分构成：
不是作为一个单独的层实现。RTP是一个协议框架(protocol framework)，这是故意不完整的。跟其他传统协议不一样，传统协议设计的比较通用，或使用需要进行分析的option机制，因此更加具有包容性，RTP协议根据实际需要对头部进行修改或添加，从而进行定制。
相关例子可见5.3节和6.3节。 因此，除了这个文档之外，针对特定应用程序的完整的RTP规范将需要一个或多个相关文档(请看12节)。
实时服务和算法的实现，以及关于RTP的一些设计决策的背景，可以在[]中实现。 一些RTP应用，包括实验性和商业性的，已经根据规范草稿实现了。这些应用包括音频和视频工具，以及诸如进行流量监控的诊断工具。这些工具有数千个用户。然而，当前的因特网还不能够完全支持实时服务的所有需求。高带宽服务，譬如视频，使用RTP可能会严
重降低其他网络服务的质量。因此实现者应该采用预防措施限制意外的带宽使用。应用程序文档应该清晰地强调因特网上高带宽实时服务的限制和对其他网络服务的影响。. RTP使用场景
下面描述了RTP的一些使用场景。
选择这些例子是为了解释使用RTP的应用程序的基本操作，而不是局限于RTP可应用在什么上面。在这些例子中，RTP基于IP和UDP进行传输，遵循配套的Internet -Draft 中定义的音频和视频的profile。
2.1 简单的多播音频会议
IETF的一个工作组开会讨论最新的协议草稿，在语音通信中使用因特网的IP多播服务。通过一些分配机制，工作组主席获得一个多播组地址和一对端口。一个端口用于音频数据，另外一个用于控制包(RTCP)。这个地址和端口信息被分发给预期的参与者。如果需要隐私，数据和控制
报文要按照9.1节的规定进行加密，在这种情况下还需要产生和分发一个秘钥(an encryption key)。这个分配和分发机制的详情不在RTP的范围内。
一个会议的各方参与者使用的音频会议应用程序用小块数据，譬如20ms持续时间，发送音频数据。每块音频数据的前部是RTP头；RTP头和数据依次包含在UDP包中。RTP头说明了每个报文包含的音频编码(譬如PCM,ADPCM，或LPC)，这样发送者可以在会议途中改变编码，
例如，容纳通过低带宽链路连接的新的参与者，或应对网络拥塞。
跟其他报文网络一样，因特网偶尔丢失，重排列报文以及不定时间延迟报文。为了应对这些缺陷，RTP头部包含时序信息和序列号，使得接收者能够重建源产生的时序，所以在这个例子中，每20毫秒连续播放一个音频块。会议中，对RTP包的每个来源单独进行时序
重建。接收者可以利用序列号估算丢失了多少报文。 由于工作组成员在会议期间加入或离开，那么知道任何时刻的参与者以及他们接收音频数据的情况是非常有用的。为了达到这个目的，会议中每个音频应用程序会定期在RTCP端口上多播接收报告以及它的用户名。接收报告说明了接收当前讲话者的数据包的情况，也
可以被用于控制有适应能力的编码。除了用户名之外，其他标识性信息可以被包含用于控制带宽限制。当某一方离开会议时会发送RTCP BYE包(看6.5节)。
2.2 音频和视频会议
如果一个会议使用了音频和视频多媒体，他们会分别用独立独立的RTP会话进行传输，每种媒体有对应的RTCP包传输，使用两个不同的UDP端口对和/或多播地址。 除了音频会话和视频会话的用户(同一个用户)在两个会话的RTCP包中应该使用同一权威(canonical)名字是的
这两个会话能够关联之外，在RTP层次没有直接的关联。
设计成分离的一个动机是允许会议中的一些参与者可以选择仅接收一种媒体。5.2节中有进一步的解释。除了分离之外，可以利用RTCP包中传输的时序信息对两个会话进行同步回放。
2.3 混合器和转换器(Mixers和Translators)
到目前为止，我们一直假设所有站点都用同样的格式接收多媒体数据。但这可能不一定合适。考虑一种情况，某个区域的参与者使用低速率的链路链接而其他大部分参与者都使用高速率链路。与其强制每个人使用低带宽、低质量的编码，不如在低带宽区域的附近
放置一个被称之为混合器(mixer)的RTP层的中继。这个混合器重新同步进入的音频包以重构发送者产生的固定20ms的空间，混合这些被重构的音频流到一个单一流中，转换这个音频流的编码为低带宽的那个，并通过低速率链路传输。这些
包可以单播到一个接收者，也可以是多播包组播到多个接收者。RTP头包含了使得混合器能够识别专属于一个被混合的包的来源的方法，也就是说一个被混合的包的头部包含了某些字段，可以通过这些字段识别这个被混合的包的来源是谁。
音频会议中一些参与者可能通过高带宽链路连接但无法通过IP组播直接到达。例如，他们可能位于应用级防火墙后面从而任何IP包无法通过。对于这些站点，可能不需要混合，而是使用另外一种RTP级别的中继，称之为转换器(transla
tor)。 安装两个转换器，防火墙的一边一个。外部的转换器汇集所有的多播包并通过一个安全连接发送给防火墙内部的转换器。防火墙内部的转换器再把这些包重新作为多播包发送到内部网络的多播组中。 混合器和转换器设计的目的可能是多样的。一个例子是一个
视频混合器可以缩放分开的视频流的各个人的图像，并把他们合成一个视频流，从而模拟一个群组的场景。转换的一个例子包括一组仅使用IP/UDP的主机连接到仅理解ST-II的一组主机，或对来自各个源的视频流逐个数据包进行编码转换而不需要重新同步或混合。混
合器和转换器的操作详情请见第7章。
3 定义
RTP负载：RTP包传输的数据，例如音频采样或压缩的视频数据。负载格式和解析不在本文档范围内。
RTP包：由固定的RTP头，一个可能为空的源列表，以及负载数据构成的数据包。一些底层协议可能要求定义RTP包的封装。一般来说，底层协议的一个包包含一个RTP包，但如果封装方法允许的话，也可以包含几个RTP包。(见第10章) RTCP包：控制包由部分跟RTP数据包相似的固定头部，后跟与RTCP包类型相关的结构化元素构成。第6章定义了格式。一般来说，多个RTCP包一起作为一个复合的RTCP包在底层协议个一个包中发送；这在每个RTCP包的固定头部中的length
字段使能。 Port：传输层端口 Transport address：IP层和传输层的地址 RTP session:用RTP进行通信的若干参与者之间的关联。对于每个参与者，会话由一对特定的目标传输地址(一个网络地址加上一对RTP和RTCP的端口)定义。目标传输地址对对于所有的参与者来说可以是一样的，例如IP多播，也可以是不一样的，譬如独立的单播网络地址
加上普通的端口对。多媒体会话中每种媒体都是用独立的有自己的RTCP包的RTP会话传输的。多个RTP会话通过不同的端口号对和/或不同的多播地址进行区分。
Synchronization source(SSRC)：RTP包流的源，包含在RTP头中的32位数的SSRC标识符，不依赖于网络地址。来自同一个SSRC的所有数据包构成同一时序和序列号空间的一部分，所以接收者根据SSRC对数据包进行分组以进行回放。同步源SSRC的示例包括从一个信号源
(如麦克风或摄像头或RTP混音器)派生的数据包流的发送方，这里的意思应该是一个信号源对应一个SSRC。一个同步源SSRC可能会随着时间的推移改变它的数据格式，譬如音频编码。 SSRC标识符的值是随机选择的，在一个特定的RTP会话中是全局唯一的(看第8节)。
参与者不必对多媒体会话中的所有RTP会话使用相同的SSRC标识符;SSRC 标识符的绑定通过 RTCP 提供（参见第 6.4.1 节）。如果参与者在一个 RTP 会话中生成多个流（例如，从单独的摄像机生成），则必须将每个流标识为不同的 SSRC。
Contributing source (CSRC): 组成RTP混音器产生的混合流的一个RTP包流的来源。混音器把生成一个特定的数据包的所有流的SSRC标识符的列表插入到这个数据包的RTP头中。这个表称为CSRC列表。一个示例应用是音频会议，混音器说明发出的数据包中包含了哪些讲
话者的语音，允许接收者识别当前的讲话者，即使所有的音频包包含同一个SSRC标识符(混音器的)。
End system: 产生在发出的RTP包中的内容和消费接收到的RTP包的内容的应用程序。一个End system在一个特定的RTP会话中可以作为一个或多个同步源，但一般只有一个。
Mixer: 一个中间系统，接收一个或多个源的RTP包，可能会改变数据格式，用同样的方法对数据包进行组合然后发出一个新的RTP包。因为多个输入源的时序一般不是同步的，混音器会对所有流的时序进行调整并未组合流产生自己的时序。因此，混音器产生的数据包都会标识混音器
为他们的同步源。
Translator: 一个中间系统，转发RTP包并且保持数据包的同步源标识符不变。转换器的示例包括无需混合即可转换编码的设备、从多播到单播的复制器以及防火墙中的应用程序级筛选器。
Monitor: 一种应用程序，它接收 RTP 会话中参与者发送的 RTCP 数据包，特别是接收报告，并估计当前服务质量以进行分发监控、故障诊断和长期统计。监视功能可能内置于参与会话的应用程序中，但也可能是一个单独的应用程序，它不以其他方式参与，也不发送或接收 RTP 数据包。这些称为第三方监视器。
Non-RTP means: 非RTP意味着：除了RTP之外，可能还需要提供可用服务的协议和机制。特别是，对于多媒体会议，会议控制应用程序可以分发用于加密的多播地址和密钥，协商要使用的加密算法，并为没有预定义有效负载类型值的格式定义 RTP 有效负载类型值和它们表示的有效负载格式之间的动态映射。 对于简单
的应用程序，也可以使用电子邮件或会议数据库。此类协议和机制的规范不在本文档的讨论范围之内。