RTP协议和语音封装

时间：2021-09-01 12:12 作者：admin 分享到：

如何提高实时性能，确保通信的QoS，是IP电话系统的关键技术要求，也是它的一个技术难点。在这一点上，基于H.323和基于SIP的两大IP电话系统都采用IETU提出的实时协议和网络技术，这些技术并非为IP电话专门设计的，而是适用于一般多媒体通信的通用技术。

首先，话音信号采用实时传送协议(RTP-Real-timeTransport Protocol)封装传输。RTP协议为音频、视频等实时数据提供端到端的传递服务，可以向接收端点传送恢复实时信号必需的定时和顺序信息，并向收发双方和网络运营者提供QoS监测手段。但是，RTP本身并不提供任何保证QoS的机制，要确保通信的实时性还需要1P网络本身具有这方面的增强的能力。目前主要采用的有两大技术：一是资源预留技术，它参照面向连接的ATM技术，根据用户需要和网络资源可用性为每个呼叫保留所需的带宽，藉此保证服务质量。其主要的协议就是资源预留协议(RSVP- Resource Reseivation Protocol)。该协议的理论性能很好，IETF倾注了很大热情予以研究，但是由于过程复杂，应用于大型网络较为困难，目前一般用于专用网或较小的网络，如LAN和企业网等。另一项技术就是业务区分(differentiatedSerrices)技术，或称为业务分类技术。它将业务数据流根据其行为特性和服务要求划分为若干类别，网络根据类别对业务流提供不同等级的服务，执行不同的处理策略，以保证高级别的业务流得到高质量的服务。此项技术可望用于大型网络，受到人们的普遍重视。

结合IP电话系统的应用，介绍上述三个方面的协议和网络技术。

6.1RTP协议和语音封装

6.1.1 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的应用。

(1)多播电话会议

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

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

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

(2) 音频和视频会议

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

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

(3)混合器和翻译器

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

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

3.术语和定义

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

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

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

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

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

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

6.1.2 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个比特由应用文档定义，使得一个扩展头部可有多种不同的含义。扩展头部供各种应用传送和净荷格式无关的附加的公共信息。建议尽可能不用，因为它将增加协议处理的复杂度。

图6.2 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(Synchronous Source)：同步源标识，32比特。

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

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

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

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

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

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

6.1.3 RTP会话的复用

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

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

6.1.4 H.225.0应用文档

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

1.RTP和RTCP分组

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

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

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

2.净荷类型

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

(1)总则

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

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

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

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

1：左声道r：右声道c：中心声道S：围绕声道F：前声道R：后声道

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

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

(2))波形编码音频信号

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

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

(3)) 参数编码音频信号

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

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

(4)净荷类型

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

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

(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封装

本小节说明1P电话中常用的几种低比特率编码话音信号的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个采样的采样时刻。