RTP协议和语音封装

RTP概述

1.协议功能和设计思想

RTP实际包括两个协议：

· RTP本身：用以传送实时数据。其功能是提供净荷类型指示

（即数据类型和编码方法）、数据分组序号、数据发送时戳和数据源标识。接收端根据这些信息可以正确地重组原始信号。在视频解码时，还可以根据序号判定接收分组在数据流中的位置，从而不一定完全按顺序解码。

· RTCP：用以传送实时信号传递的质量参数，提供QoS监视机制；同时还可传送会议通信中的参会者信息，向没有显式的成员控制和呼叫建立的“松弛型”会议通信提供控制机制。

RTP的设计采用“集成处理”和“应用成帧＂的思想。所谓“集成处理”指的是RTP一般由应用层综合处理，而不作为一个单独的协议层来处理。所谓“应用成帧”指的是RTP只规定所有应用都需要的公共功能，它不像一般协议那样通过任选机制等办法追求全面和完备，而是留有余地，允许具体应用修改和／或增加头部信息以满足其特定需要。因此，用RTP封装应用数据，除了要遵从RTP协议本身的要求外，还需要制定两个应用文件：

．应用文档(profile)：该文档定义一组净荷类型码及它们至净荷格式（如媒体编码）的映射关系。文档也可定义在该类应用中RTP应作的修改和扩充。

．净荷格式规范：具体定义每一种净荷（例如音频或视频编码）如何在RTP中传送。

IP电话系统如何使用RTP就由H.225.0的应用文件所规定，它们和RTP协议一起决定了话音信号在IP网络中的封装传送方式。

RTP通常运行在UDP之上，二者共同完成运输层的功能，但协议并不排除采用其它合适的运输层协议。UDP提供复用及校验和服务，也就是通过分配不同的端口号来传送多个RTP流。协议规定，RTP流应使用偶数(2n)端口号，相应的RTCP应使用相邻的奇数(2n+1)端口号。因此，应用进程应在一对端口上接收RTP数据和控制信号，同时向另一对端口发送数据和控制信号。

2.RTP应用背景

下面列举3个应用情况说明RTP的应用。

(l)多播电话会议

假设通过某种分配机制，会议主席获得了一个多播组地址和一对端口号，并将该地址和端口号分配给了各参会者。参会端点的电话会议应用程序每次发送一小段话音数据，通常是20ms间隔内的话音。每段话音数据前加上RTP头部后，装入UDP数据包。RTP头部指示每个包采用的是什么音频编码（如PCM,ADPCM或LPC等），这样，端点在会议中可以随时改变其编码方式。例如，一个新的参会者通过低带宽链路接入会议或者网络发生拥塞时，就可改用低比特率编码方式。

在Internet中，数据包常会发生丢失、错序和时延抖动，为此，RTP头部中含有定时信息和序号，供接收端点恢复信号的时序关系，同时可判定丢失了多少数据分组。定时重建处理对会议中的每个RTP源分别进行。

由于参会者随时可能离开或加入会议，因此有必要知道在任何时候有多少与会者以及他们接收话音数据的情况。为此，每个应用进程通过RTCP端口周期性多播发送接收报告，并在报告中注明其用户名，如果带宽允许还可传送其它的用户标识信息。接收报告指示接收当前发言者话音的质量情况。当一端点离开会议时，就发送RTCPBYE分组。

(2)音频和视频会议

该类会议既有音频信号，又有视频信号，两种信号作为不同的RTP会话发送，也就是说，音频和视频媒体的RTP和RTCP分组使用两对不同的UDP端口地址和两个多播地址传送。音频和视频会话在RTP层并无直接关联。如果一个用户同时参与两个会话，则可以在二者的RTCP分组中使用相同的”规范名“(CNAME-CanonicalName)，应用层藉此关联这两个会话，并可利用RTCP分组提供的定时信息同步播放信源的音频和视频信号。

音频和视频之所以采用两个RTP会话传送，是为了使参会者可以选择只接收其中一种媒体信号。

(3)混合器和翻译器

混合器完成的是RTP级中继功能，其典型应用是集中型电话会议中的MP。它接收来自各终端的话音信号，解码并重新同步后混合成一个单一的信号流，多播传送给各终端。封装的RTP头部可以指明构成复合信号的各个信号源，接收端可以据此向用户指示讲话者的身份。混合器还可对话音编码进行变换。例如，某地区的用户只能通过低速率链路接入会议，其它用户采用的都是高速接人链路。此时，混合器可以将来自其它用户的高比特率编码转换成低比特率编码，混合后多播传送给该地区用户。混合器的另一应用是视频混合，它将来自各处的与会者图像缩小后复合成一个视频流，以模拟小组会议情景。

翻译器也是RTP层的中继功能，但是不涉及混合操作。例如防火墙的内外可分别设置一翻译器，外部翻译器负责过滤，内部翻译负责将信号多播传给内部网的用户。翻译器一般有编码转换功能，但尤重新同步和混合功能。翻译器也可以复制多播信号成为多个单播信号。

3.术语和定义

在分析RTP协议时，必须理解下述RTP基本术语的含义。

• RTP净荷：由RTP传送的数据，如音频抽样信号、压缩视频数据等。净荷格式及其解释由应用层规定。

• RTP分组：由RTJ>头部和净荷数据组成。通常下层传送协议的一个数据包（如一个UDP包）只含一个RTP分组；如果采用一定的封装方法，也可以包含多个RTP分组。

• RTCP分组：为控制分组，由一个和RTP分组类似的固定头部和若干个结构化数据单元组成，数据单元的结构和内容随RTCP分组类型而异。通常下层传送协议的一个数据包包含多个RTCP分组，以节省头部开销。由于各分组头部含有长度字段，因此复用时各分组不会混淆。

• RTP会话：一组通信参与者经由RTP互相通信即构成一个RTP会话。对于每个参与者来说，该会话由一对目的地运输层地址（一个网络层地址＋用于RTP和RTCP的一对端口）定义。在IP多播方式中，每个参与者的目的地运输层地址对可以都相同；在单播方式中，每个参与者的地址对均不相同，因为每个人的网络层地址都不相同。在多媒体会话中，每个媒体信号由不同的RTP会话传送，有其自己的RTCP分组。各RTP会话由不同的端口对和／或不同的多播地址区分。

• RTP媒体类型：由一个RTP会话传送的所有净荷类型的集合。RTP应用文档指定RTP媒体类型和RTP净荷类型的关系。

RTP分组头部

RTP分组固定头部的格式如图6.1所示。前12个字节为固定的头部，其后的CSRC名单为任选部分，由混合器插入。

图6.1 RTP 分组固定头部格式

头部中所有整数字段按网络字节顺序传送，即最高有效字节为首字节。除无特殊说明，数字常数均为十进制数。所有头部数据都按其自然长度对齐，即16比特字段的末字节都为偶数字节，32比特字段的未字节位置都能被4整除。分组填充字节都为零值。

分组头部各字段的含义为：

1.V：版本号，2比特。指示RTP版本号。

2.p：填充指示位，1比特。

如果P位置”1"，表示分组结尾含有1个或多个填充字节，这些字节不属于分组净荷。最后1个填充字节指示共有多少个填充字节（包括该字节本身在内)。在两种情况下可能需要填充，一是某些加密算法要求数据块大小固定；二是在一个低层协议数据包中装载多个RTP分组。

3.  X：扩展指示位，1比特。

如果X位置”1"，则固定头部后还有一个扩展头部。扩展头部的格式如图6.2所示。其中，长度字段指示扩展头部含有多少个32比特字（不包括第一个32比特字）；前16个比特由应用文档定义，使得一个扩展头部可有多种不同的含义。扩展头部供各种应用传送和净荷格式无关的附加的公共信息。建议尽可能不用，因为它将增加协议处理的复杂度。

RTP分组扩展头部格式

4.CC:CSRC计数，4比特。

指示固定头部后部的CSRC标识的个数。

5.M：标志位，1比特。

标志位的含义由应用文档解释。例如，可以表示在分组流中有帧边界标志。应用文档可以定义更多的标志位，也可以规定没有标志位，相应地，净荷类型字段的比特数将随之改变。

6.PT：净荷类型，7比特。

该字段表明RTP净荷类型，其定义和解释由应用确定。应用文档可以规定一个缺省的净荷类型码至净荷格式的静态映射关系。非缺省的净荷类型码可以通过非RTP手段（例如数据库、E-mail等方法）动态定义。在会话过程中，RTP源可以改变净荷类型，但该字段不应用于复用不同的媒体流。

接收端如果不理解净荷类型字段，则必需丢弃该分组。

7.序号：16比特。

每发送一个RTP分组，序号加1。序号可供接收方检测分组丢失和恢复分组顺序。序号的初值应为随机数，使得加密后不易受到攻击。

8.时戳：32比特。

时戳指示的是RTP数据分组第1个字节的取样时刻。导出取样时刻的时钟必须随时间线性单调递增，以支持同步和抖动计算。时钟必须有足够的分辨率以获得所需的同步精度和进行分组到达时延抖动的测量。时钟频率取决于净荷数据格式，可由应用文档静态规定，或者由净荷格式规范规定，或者由非RTP方式定义的净荷格式动态规定。如果RTP分组周期性生成，则使用由采样时钟决定的标称取样时刻，而不是通过读系统时钟获得。例如，对千固定速率音频信号，时戳时钟每一个取样周期加1。如果音频处理应用程序每次从输入设备读取160个取样周期的数据块，则时戳时钟应该是每一个数据块加100，不管该数据块是作为RTP分组往外发送还是作为静音丢弃。

和序号一样，时戳的初值也应是随机数。如果几个相邻的RTP分组是同时生成的，例如属于同一视频帧的数据，则它们的时戳值应相同。如果数据不是按取样顺序发送，例如MPEG交织视频帧，则相邻RTP分组的时戳值可能不符合单调上升的规律，但此时分组序号仍应为单调递增。

9.SSRC(SynchronousSoruce)：同步源标识，32比特。

该字段用以标识信号的同步源，其值应随机选择，以保证同一个RTP会话中任意两个同步源的SSRC标识都不相同。尽管如此，仍有可能多个源选到相同的SSRC值，这称之为冲突。协议中规定了SS­RC分配冲突的检测和消除方法。如果某个信源的运输层地址改变了，它必须重新选择一个新的SSRC，以免接收端误认为发生冲突或信号经过混合器和翻译器发生环路。

需要注意的是，当混合器对多个输入流进行混合操作时，由于这些输入信号的定时一般说来是不同步的，因此混合器需对它们进行定时调整，对复合信号的RTP分组赋予它自己的时戳和自己的序号，也就是说，复合信号将成为一个新的RTP分组流，其同步源变为涅合器，相应地，SSRC值也由混合器重新赋值。

另外，如上一章所述，在多点通信中，SSRC的最低字节取为源终端标记的最低字节，使接收端可以将RTP流和逻辑信道相关联。

10.CSRC(ContributingSo皿e)：分信源标识，32比特。

RTP分组头部最多可包含15个CSRC标识，其数目由CC字段指明。如果分信源的个数大于15，只能标识其中15个源。CSRC标识由混合器插入，其值就是组成复合信号的各个分信号的SSRC标识，用以标识各个组成分信号的信源。例如，在电话会议中，MP对各终端话音进行复合，CSRC给出各个讲话者的标识，接收端就可向用户给出明确的指示。

如前所述，不同的应用还可根据需要修改或增加头部数据，以传送净荷格式还不能表示的附加信息。修改部分主要是标志位和净荷类型。增加部分可以是新增加一个固定头部，或者在净荷部分增加一个头部。一般尽可能避免增加长度可变的扩展头部。所有这些修改和增加都在应用文档中规定。

RTP会话的复用

每个RTP会话有其不同的端口地址，藉此可在UDP上复用。在音频和视频分别编码的电信会议应用中，每个媒体流应由不同的R开会话传送。应避免不同媒体信号由同一RTP会话传送，根据净荷类型或SSRC字段予以区分。这样做会有许多问题。例如：两个音频流共享同－RTP会话和SSRC值，如果其中一个要改变编码方式而改变其RTP净荷类型，就没有办法识别哪一个音频流改变了编码方式；一个SSRC只能使用统一的定时标记和序号，但是在交织编码中，不同的净荷类型可能需要不同的定时标记（因为媒体时钟速率不同），为了识别哪一种净荷分组发生丢失，又需要独立的分组序号；RTCP控制消息只能报告同－SSRC分组的定时和序号情况，无法区分其中不同净荷类型的情况；混合器尤法将不同类型媒体的交织流复合成单一信号流。另外，在同一RTP会话中复用不同媒体流还尤法对各媒体采用不同的网络资源分配；在带宽超限时，只接收音频而不接收视频信号；接收方对不同媒体采用不同进程处理等。

但是，上述讨论并不限制同一信源不同信道的信号流在同一RTP会话中的复用，例如立体声的左、右声道信号，因为它们必定属于同一净荷类型。

应用文档

H.225.0针对音频和视频会议应用给出了RTP应用文档。其假设条件是会议没有参数协商和成员控制功能，采用静态净荷类型和RTCP提供的成员指示。

I.RTP和RTCP分组

RTP分组头部采用标准格式的固定头部，带1比特的标志位。其后没有附加的固定头部，也不定义扩展头部。但需要时，顺从该文档的具体应用可以使用扩展头部，因此不能认为X比特恒为零。

RTP分组静态净荷类型由该文档定义。具体应用尚可定义动态类型。RTP协议中的缺省安全服务在该文档中未作要求。RTP分组的封装术作规定。

RTCP分组均顺从RTCP协议，未作另外规定。

2.净荷类型

这里主要讨论话音的净荷类型。

(I)总则

如果采用静音抑制，在静音期不发送任何分组，则话音突发段的第一个分组（也就是静音期后的第一个分组）头部的标志位(M)应置“1”。如果没有静音抑制，则M位恒为“0”。

生成时戳的RTP时钟速率与编码方式及所含声道数无关，它等千每秒取样周期数。对于N声道编码，每个取样周期生成N个样值。

如果使用多声道，声道编码从1开始，顺序是从左到右。在RTP音频分组中，低编号声道的信息置于高编号声道之前。表6.1示出多声道系统的声道排列情况。属于同一取样时刻的多个声道采样值应置于同一分组中，不同声道采样的交织由编码方式确定。

表6.1   多声道系统的声道排列

采样频率只能取下列频率值之一：8000、16000、24000、48000、11025、22050、44100Hz。

对于分组化话音，缺省的分组间隔为20ms。分组间隔决定了最小端到端时延，间隔时间长，头部开销小，但时延将增加，且分组丢失影响较大。对于做报告等非交互式应用或者链路带宽很窄的情况，可以允许有较大的时延。接收器应能接收从0~200ms时间间隔内的话音数据，此值决定了接收方所需的缓冲器大小。

(2)波形编码音频信号

在这种编码方式中，每个采样包含固定数目的比特，RTP分组可以包含任意多个采样值，分组的时间间隔由采样点数决定。

在多声道情况下，同一采样时刻所得的不同声道采样值应按字节连续排列。例如，在二声道系统中，字节顺序为（左声道，第1采样点）、（右道声，第1采样点）、（左道声，第2采样点）、（声右道，第2采样点）..。若每个采样包含多个字节，则高字节放在前面。

(3)参数编码音频信号

这种编码方式将固定长度的音频信号块编码为另一个通常也是固定长度的压缩数据块，称之为帧。发送者可以在一个RTP分组中发送多个编码帧。由于帧长度是确定的，因此接收方知道该分组中含有多少个话音帧。

对于多声道系统，各声道音频信号独立编码，然后按序将各帧装入分组。

(4)净荷类型

表6.2示出H.225.0定义的音频信号静态净荷类型。唯一定义的视频静态净荷类型为PT=31,H.261编码。类型96~127为动态净荷类型，供具体应用通过非RTP方式定义。

表6.2音频信号静态净荷类型

*：指传输帧，包含4个编码帧。

(5)端口号分配

按RTP协议规定，RTP数据分组分配偶数UDP端口号，对应的RTCP分组分配次大奇数UDP端口号。由于一个主机可运行多个应用，且某些操作系统不允许多个不同多播地址的进程使用相同的UDP端口，因此不可能只分配一对固定的端口地址，而应由会话管理程序动态分配端口对。

H.225.0应用文档注册了5004和5005为缺省端口对。这样，如果某项应用工作于多个应用文档，使用这对端口号就表明它选择的是H.225.0应用文档。但并不要求所有应用都有一对缺省端口，可以自行规定。如对于UNIX操作系统，应在5000以上范围内选择RTP端口，因为在该系统中，1024以下端口号用于特权进程，1024~5000端口号是由操作系统自动指配的。

    6.1.5音频信号的RTP封装

本小节说明IP电话中常用的几种低比特率编码话音信号的RTP封装方法。

1.G.728

编码速率16kbit/s，编码帧长0.625ms，传输帧长2.5ms。一个G.728传输帧由4个向量(V1~V4)组成，每个向量10比特，VI为时间上最早的向量。上述40个比特组成5个字节(Bl-B5)，向量和字节的对应关系如图6.3所示。尤论是向量、字节还是帧，都是最高有效位在左面，最低有效位在右面。Bl置于RTP分组的最前部，B5置于最后。

为了减小开销，每一个RTP分组包含多个G.728帧，典型值为8帧。各帧按时间顺序依次排列。分组头部的时戳对应第1帧第1向最(VI)的第1个采样的采样时刻。

图6.3 G.728信号字节

2.G.729

编码速率8kbit/s，帧长I0ms。考虑到G.729可以采用静音抑制，因此其帧有两种大小：10字节数据帧(8khit/s)和2字节静音插入指示语(SID-SilenceInsertionDescriptor)帧。SID帧用于规定舒适噪声参数，实际帧长为15比特，其第2字节的最低有效位为备用比特。

一个RTP分组通常包含2个G.729帧，时间较早的帧置于分组的前面。根据静音和数据的不同组合，有下述几种可能情况：

．分组中含20个字节：两个帧均为激活话音帧。

．分组中含10个字节：第1帧为空帧（静音），未发送，所包含的激活话音帧是第2帧。其原因是话音帧的后面只可能是SID帧或者是另一个话音帧，也就是说，一个突发段最后一个话音帧之后必定是SID帧，指示接收端如何生成背景噪声，SID之后才是完全抑制的静音空帧。

．分组含13个字节：该分组必包含1个话音帧和1个SID帧。加入的第1字节用以指示哪一帧是SID帧。如果第1字节为0，表示第1帧是SID帧；如果第1字节为1，表示第2帧是SID帧。

．分组含3个字节：该分组必包含1个SID帧和1个空帧。第1字节为0，表示第1帧是SID帧；第1字节为1，表示第2帧是SID帧。

另外规定，话音突发段的第1个分组（即静音期后的第1个分组）头部的标志位(M)置1。

3. G.723.1

编码速率5.3/6.3kbit/s，帧长30ms。G.723.1帧有3种大小：24字节(6.4kbit/s帧）2、0字节(5.3kbit/s帧）和4字节，其中4字节帧为SID帧。三种帧如何间插没有限制。G.723.1R'IP分组间隔为30ms,两种速率可以按帧切换，话音突发段第1分组的标志位置1。

实际应用中的注意事项

在实际应用中，需要根据具体的网络条件和音频编码格式调整RTP封装的参数，以优化传输性能和减少丢包。此外，还需要考虑如何处理网络抖动、丢包重传和流量控制等问题。

[RFC3550]将实时传输协议（RTP）定义为端到端的传输实时数据的协议，它还包含一系列实时数据的端到端传输服务：净荷类型（编码方案）识别、序列号编码、时间戳和传输监控等。RTP不提供服务质量（QoS）,而是通过RTP控制协议（RTCP）提供对QoS的监控。RTCP还传递有关媒体会话参与者的信息。

15.1 RTP的实时数据传递

15.1.1RTP的固定报头字段

出现在RTP分组（见图15-1）中的RTP字段代表如下含义：

•  版本（V）——RTP的版本。若该协议实现遵循[RFC3550],则总是设为“2”。

• 填充（P）——若设置了该字段，则RTP分组包含填充字节。某些固定分块大小的加密算法或在一个底层协议分组里携带多个RTP分组时就可能需要填协充。

•  扩展（X）——若设置了该字段，则存在RTP报头扩展。

•  CSRC计数（CC）——固定报头后面的贡献源（CSRC）ID的个数。

•  标记（M）——其解释在配置中定义。

•  净荷类型（PT）——标识净荷的格式（编码方案）。

•  序列号——每发送一个RTP数据分组，其序列号加1。该号码被接收者用来对错序到达的分组进行重排序，它还使接收者有办法确定是否有分组丢失。

•  时间戳——指示净荷的第一个字节被取样时的时间，该字段和序列号一起用来去除抖动（见15.1.2节）。

图15-1 RTP分组格式

• 同步源（SSRC）——RTP不依赖于底层的IP协议，因此，用这个字段来标识RTP分组的源。

• 贡献源（CSRC）——如果涉及媒体流的混合，则该字段携带一个SSRC列表，用来指示对于该混合媒体流有贡献的源。其中允许有0〜15个SSRC,如果媒体源超过15个，则仅标识前15个。音频会议混合器是一个很好的例子。

什么是抖动？

接收方可能接收到错序且被延时的分组，从而引起媒体中断或变形，该变形称为抖动。图15-2给出了RTP分组如何错序到达并被延时的例子。当存在拥塞因素时，这种情况对于任何TCP/IP网络都存在。在RTP中，序列号用来对错序分组进行重新排序。时间戳用来使接收者在正确的时间播放分组，从而使变形最小化。

图15-2  分组抖动

15.2 RTCP

RTP控制协议（RTCP）分组周期性地传送给所有的会话参与者。RTCP有四个功能：

• 对实时数据发送时的QoS提供反馈。

• 携带一个持久的RTP源标识（称作CNAME）。

• 允许RTCP分组发送的时间间隔可调（报告周期）。

• 传递会话控制信息。

15.2.1 RTCP分组类型

有五种类型的RTCP分组：

•SR——发送者报告，提供发送和接收统计，由活跃的媒体发送者发出。

•RR——接收者报告，提供接收统计，由非活跃的发送者发出。

•SDES——源描述条款，例如CNAME。

•BYE——标志参与的结束。

•APP——与特定应用有关的函数（由配置定义）。

15.2.2 RTCP报告传送间隔

每个参与者都被要求发送RTCP分组。如果存在多个参与者（如在会议中），则当进一步有新用户加入时，就产生可扩展性问题。为了对可扩展性问题进行控制，RTCP分组发送的速率必须要调低，这通过动态计算RTCP分组发送时间间隔来实现。

应将一定比例的会话带宽专用于RTCP,这个比例和报告传送的时间间隔由配置定义。

15.3 RTP配置和净荷格式规范

在设计传统协议的时候，要注重协议的普遍性以支持协议应用所需要的附加功能。对于RTP,这是通过按照应用的需要对现有报头进行修改和增加来实现的。因此，对于特定应用的RTP,如音频，要求一个或多个伴随文档，即一个配置规范文档和一个净荷格式规范文档。

15.3.1配置规范

[RFC3550]中指出，下列字段为一个应用的配置规范中可能进行定义的内容：RTP数据报头、净荷类型（编码方案）、RTP数据报头增加、RTP数据报头扩展、RTCP特定应用相关的分组类型、RTCP报告间隔（见15.2.2节）、SR/RR扩展、SDES使用、安全服务和算法、加密密钥匹配的字符串（口令）、拥塞控制行为、下层协议、RTP和RTCP与传输层地址的匹配以及一个底层分组中封装多个RTP分组等。

15.3.2净荷格式规范

一个RTP应用的净荷格式规范定义了特定净荷如何在RTP中携带。

15.4 音频和视频的RTP配置和净荷格式规范（RTP/AVP）

正如15.3节定义的那样，采用RTP协议的应用必须为自己指定一个配置和净荷格式。本节将说明音频和视频应用的配置和净荷格式（完整的规范在相关文档[RFC3551]中定义）。表15-1包含为音频和视频应用指定的配置，而表15-2则包含为音频和视频指定的净荷格式举例。

静态和动态净荷类型

静态净荷类型定义为具有固定的标识编号、时钟速率和一定数量的信道。动态净荷类型没有定义一个编号，而是编号可以动态分配，为动态净荷类型分配的号码在96〜127之间。

表15-1 RTP/AVP的具体配置

在SDP中，静态净荷类型不需要rtpmap属性。例如，PCMU净荷类型可如下

 m=audio 49170 RTP/ATP 0

     或                m=audio 49170RTP/ATP 0

                         a=rtpmap:0 PCMU/8000

动态净荷类型的举例如下：

        m=video 49172 RTP/AVP 96

                         a=rtpmap:96 H263-1998/90000

表15-2音频和视频的净荷格式举例