VoIP技术--RTP/RTCP/SRTP语音传输技术

3．语音传输技术

 

由因特网的七层架构来看，RTP协议是工作在UDP/IP协议之上的，如图6所示。

图6

在VoIP系统，在将编码语音数据交给UDP进行传输之前，要利用RTP/RTCP协议进行处理。RTP/RTCP协议实际上包含RTP协议和RTCP协议两部分。

3.1 RTP协议

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

通常RTP的协议数据单元是用UDP分组来承载的。而且为了尽量减少时延，语音净荷通常都很短。图7表示一个IP语音分组的结构，图中IP，UDP和RTP的控制头都按最小长度计算。

图7 基于RTP的话音分组

由上图可看出，这种IP话音分组的开销很大，约为66％～80％。于是有人提出了组合RTP分组的概念，如下图所示。

 

 

采用这种组合复用方法的确可以大大提高传输效率，但是目前尚无标准。

如果支持RTP的网络能提供组播功能，则它也可用组播方式将数据送给多个目的用户。

 

RTP协议用以传送实时数据，可以用来传送声音和活动图像数据。RTP分组由RTP头部和净荷数据组成；RTP分组由UDP包来进行传输，通常一个UDP包仅含一个RTP分组，若采用一定的封装方法，也可以包含多个RTP分组；其中的RTP净荷就是RTP传送的语音数据。RTP分组Header的格式如下：

0~1	2	3	4~7	8	9~15	16~31
V	P	X	CC	M	PT	序号
时戳
同步源(SSRC)标识
分信源(CSRC)标识(0~15个)

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

<1> V：RTP版本号。为“10”。

<2> P：填充指示位。P为“1”时表示分组结尾含有1个或多个填充字节，其中这部分不属于有效载荷。

<3> X：扩展指示位。X为“1”时，则表示固定头部后还有一个扩展头部，这种情况较复杂，很少使用。

<4> CC：CSRC计数。指示固定头部后的CSRC的个数

<5> M：由应用文档解释，通常不用。

<6> PT：净荷类型。表示RTP分组的净荷类型。我们常用的有：

                                “0”： G.711μ

                                “8”： G.711A

                                “4”： G.723.1

                                “18”： G.729

<7> 序号：序号顾名思义就是表示RTP分组的次序。初值为随机数，每发送一个增加1。可供接收方检测分组丢失和恢复分组次序。

<8> 时戳：表示RTP分组第一个字节的取样时刻。其初值为随机数，每个采用周期加1。如果每次传送20ms的数据，由于音频的采样频率为8000Hz，即每20ms有160次采样，则每传送20ms的数据，时戳增加160。

<9> SSRC：同步源标识(Synchronous Source)。表示信号的同步源，其值应随机选择，以保证同一个RTP会话中任意两个同步源的SSRC标识不同。

<10> CSRC：分信源(贡献源)标识(Contributing Source)。识别该数据包中的有效载荷的贡献源。换句话说，CSRC标识由混合器插入，其值就是组成复合信号的各个分信号的SSRC标识，用以标识各个组成分信号的信源。RTP分组的头部最多可以包含15个CSRC标识，其数目由CC字段指明。

3.2 RTCP协议

RTP本身没有提供任何确保及时传送的机制，也没有提供任何传输质量保证的机制，因而业务质量完全由下层网络的质量来决定。同时，RTP不保证数据包按序号传送，即使下层网络提供可靠性传送，也不能保证数据包的顺序到达。包含在RTP中的序列号就是供接收方重新对数据包排序之用。

RTCP是RTP的控制协议，它用于监视业务质量并与正在进行的会话者传送信息。

RTCP协议向会话中的所有与会者周期性地传送控制分组，从而提供RTP分组传送的QoS的监测手段，并获知与会者的身份信息。

RTCP分组主要有如下5种：

<1> SR：发送者报告(Send Report)由数据发送者发出的发送/接收的统计数据。

<2> RR：接受者报告(Receiver Report)，由非数据发送者发出的接收统计数据。

RR和SR都可以用来发送数据接收质量的反馈信息，其差别在于SR除了提供上述信息外，还可提供有关数据发送的信息。从分组结构上来看，SR除了有接收报告数据外，还有20个字节的发送者信息段。

SR和RR中有许多有用的信息可供信号发送者、接受者和第三方监测QoS性能和诊断网络问题，以及时调整发送模式，主要可以分为三类：累计信息、即时信息和时间信息。累计信息用于监测长期性能指标；即时信息可以测量短期性能；时间信息可以用来计算比率指标。

<3> SDES：源描述项(Source Description)，SDES在会议通信中比较有用，可以向用户显示与会者名单等有关信息。

<4> BYE：退出，BYE指示一个或多个信源不再工作，退出会话。

<5> APP：应用特定功能，APP供新应用或新功能试验使用。

3.3 SRTP协议

VoIP网络很不安全，这也是限制VoIP发展的一个考虑因素。为了提供一种策略满足VoIP的安全，SRTP应运而生。所谓SRTP，即安全实时传输协议(Secure Real-time Transport Protocol)，其是在实时传输协议(Real-time Transport Protocol)基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran(思科)和Rolf Blom(爱立信)开发的，并最早由IETF于2004年3月作为RFC 3711发布。

由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议(RTP Control Protocol)有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议(Secure RTCP或SRTCP)；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。

为了提供对数据流的保密，需要对数据流进行加密和解密。关于这一点，安全实时传输协议(结合安全实时传输控制协议)只为一种加密算法，即AES制定了使用标准。这种加密算法有两种加密模式，它们能将原始的AES块密文转换成流密文：分段整型计数器模式和f8模式。

除了AES加密算法，安全实时传输协议还允许彻底禁用加密，此时使用的是所谓的“零加密算法”。它可以被认为是安全实时传输协议支持的第二种加密算法，或者说是它所支持的第三种加密模式。事实上，零加密算法并不进行任何加密，也就是说，加密算法把密钥流想像成只包含“0”的流，并原封不动地将输入流复制到输出流。这种模式是所有与安全实时传输协议兼容的系统都必须实现的，因为它可以被用在不需要安全实时传输协议提供保密性保证而只要求它提供其它特性（如认证和消息完整性）的场合。

以上列举的加密算法本身并不能保护消息的完整性，攻击者仍然可以伪造数据——至少可以重放过去传输过的数据。因此，安全实时传输协议标准同时还提供了保护数据完整性以及防止重放的方法。

为了进行消息认证并保护消息的完整性，安全实时传输协议使用了HMAC-SHA1算法。这种算法使用的是默认160位长度的HMAC-SHA1认证密钥。但是它不能抵御重放攻击；重放保护方法建议接收方维护好先前接收到的消息的索引，将它们与每个新接收到的消息进行比对，并只接收那些过去没有被播放过的新消息。这种方法十分依赖于完整性保护的使用(以杜绝针对消息索引的欺骗技术)。

图8 组合RTP话音分组