RTP/RTCP流媒体数据还原技术

作者：阎卫国 北京邮电大学   

    1引言

    要完成RTP（Real-TimeTransportProtocol）媒体还原的工作，首先要对RTP数据流进行识别捕捉，通过对RTP和RTCP进行识别解码，获取其传输的负载数据，再根据RTP解码得到的负载类型，使用不同的音视频解码器，对音视频数据进行解码还原播放。

    RTP运行在UDP的上层，可以看成是传输层的子层。RTP是用来传输

实时数据，RTCP（Real-TimeTransportControlProtocol）是用来控制和监视它的传输。

 

    由于RTP没有简单的特征字，不能简单地通过包特征过滤进行识别，要想识别RTP流量，只有两种方法，第一种是通过分析呼叫信令的内容，获取传输媒体流的源、目的地址和端口号，再通知给过滤器进行数据捕捉；第二种是通过对数据的“流特征”进行分析，确定所要捕捉的RTP数据流。

    2RTP分析

    RTP/RTCP是一种应用型的传输层协议，它并不提供任何传输可靠性的保证和流量的拥塞控制机制。它是由IETF（InternetEngineeringTaskForce）为视音频的实时传输而设计的传输协议。RTP没有连接的概念，它既可以建立在面向连接的底层协议上，又可以建立在面向无连接的底层协议上，因此RTP对传输层是独立的。RTP一般由数据报文部分（RTP报文）和控制报文部分（RTCP）组成。

    其中，RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP来监视和控制。

图1

    如图1所示，RTP运行在UDP的上层，目的是为了使用UDP的端口号和校验和。在功能上独立于下面的传输层（UDP）和网络层，但不能单独作为一个层次存在，RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和视频数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，利用低层的UDP对实时视音频数据进行组播（Multicast）或单播（Unicast）,从而实现多点或单点视音频数据的传输。

    UDP是一种无连接的数据报投递服务，虽然没有TCP那么可靠，并且无法保证实时视音频传输业务的服务质量（QoS）,需要RTCP实时监控数据传输和服务质量，但是，由于UDP的传输延时低于TCP，能与音频和视频流很好地匹配。因此，在实际应用中，RTP/RTCP/UDP用于音视频媒体，而TCP用于数据和控制信令的传输。其RTP的表头结构如图2所示。

图2

    从图2可以看出，RTP报文由报文头和数据部分组成。固定头报文头开始的12个字节出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。RTP报文中没有一个“长度”字段，这是因为RTP把数据分段的任务交给了底层的协议UDP去处理了，由UDP进行数据的分段，再组成若干个UDP数据包进行传输。

    RTP消息头由以下各Field值确定。

    (1)V（版本）—2bit版本号，置2；

    (2)P（填充）—lbit填充位，置0；

    (3)X（扩展）—lbit扩展位，置0；

    (4)CC（CSRC数）—4bitCSRC标识的数量，如此字段填充为0，则说明不使用CSRC；

    (5)M（标志）—lbit标志位，该标志在静音后的第一个语音包时置位。静音包仅发送一个，不连续发送，或视频帧最后一个数据包时置位。

    (6)PT（有效净荷类型）：见下面说明。

    lSequencenumber（序列号）：16bit序列号，初始值为一随机数，此后以1递增，接收端以此判定包丢失及恢复包顺序。

    lTimestamp（时戳）：32bit时戳。用于标识RTP数据包中第一个字节收到时的时刻，其起始值为一随机值，根据净荷的不同，以不同的速率递增。

    lSynchronizationSource（SSRC）identifiers（同步源标志）：32 bit，用来标识 RTP包的数据源，在一个会话中惟一。

    lContributingSource（CSRC）identifiers（贡献源标志）：每个CSRC32 bit，0～ 15个 CSRC序列。

    RTP信息包中的有效载荷域(PayloadTypeField)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。图3列出了目前RTP所能支持的声音有效载荷类型。

    RTCP是RTP的控制协议，它用于监视服务质量，单独运行在底层协议上。根据协议规定，RTP和RTCP选用不同的网络端口号，RTP选择一个偶数位的端口号，而RTCP则选用下一个奇数位的端口号。RTCP是由接收方向发送的报文，它负责监视网络的服务质量、通信带宽以及网上传送的信息，并将这些信息发送给发送端。RTCP包周期性地向同一个组播网内的所有成员发送。RTCP报文共有5类：SR（发送报告）、RR（接收报告）、SDES（源描述项）、BYE（表示标识）、APP（应用特定函数）。RTCP的基本做法是周期性地向会话的所有参加者进行通信，采用和数据包分配传送的相同机制来发送控制包。与RTP相同，RTCP也要求下层协议提供复用手段（如要UDP提供不同的端口号来实现复用）。

    RTP报文中提供了SSRC字段来进行源标识，然而，进一步的会话参与者的描述是需要的。RTCP报文中的源描述（SEDS）提供了会话参与者的详尽描述，包括姓名、住址、E-mail等。由于视频和音频在时间轴上的相关性不强，而数据的实时性要高于其可靠性，所以在UDP之上利用RTP/RTCP对媒体（视频和音频）流进行封装、打包和同步，可以使数字视音频信号的网络传输延时达到最小。

    3采用异或位移哈希算法进行UDP数据流识别

    要实现RTP流量判别，必须在高速网络流量中，对IP流进行高速分析，而哈希算法是整个算法的核心。1997年，MCI网络中的并发流数量大约为25万条；2003年CERNETOC48主干网络流量并发流数达到300万条；近两年随着P2P技术的迅速发展，网络流量的并发数更进一步增加，这对网络流量的测量和分析工作提出了更高的要求。为此我们采用异或位移哈希算法解决。

    另外为提高流查找的速度，我们根据IP流的本地性，即最近访问过的会话节点很有可能被再次访问的特点，将刚访问的节点放置在链表头部，以减少哈希表的整体内存访问次数，提高流查找的速度。通过多种有效手段的采用可以大大提高分析效率。

    4RTP流量判别

    在前面已经说过，由于RTP流量没有明显的包特征值，要识别RTP流量，只有两种方法；第一种是通过分析呼叫信令的内容，获取传输媒体流的源、目的地址和端口号，再通知给过滤器进行数据捕捉识别；第二种是通过对数据的“流特征”进行分析，确定所要捕捉的RTP数据流。第一种方法简单且效率高，但对应用系统要求较高。在实际应用中，我们采用两种方法结合使用以提高准确性。

    在上节流查找算法的基础上，我们根据协议的定义，制订了以下几条RTP流的判别策略。

    (1)UDP负荷头两个比特是0x10（RTPheader的版本号是2）。

    (2)RTP流负荷类型PT值不变(9～15bit)。

    (3)RTP流的每包SN值后包比前包递增为1。

    (4)RTP值的Timestamp值为递增。

    (5)RTP包的SSRC值为定值。

    我们采用此5条作为判断RTP流量的必要条件，经过实际测试，当对每一个UDP数据流，如能连续检出5个包符合上述策略，则认定其满足为RTP数据流的充分条件。经过大量实际数据的测试，未发现错判现象。但在如此判别策略的基础上，判出的RTP流均为单方向流量，如要得到一个完整的呼叫，还需在应用层按照源、目的地址进行关联，将双方向的呼叫合并到一起，以达到所要求的目的。

    5结束语

    RTP媒体还原可以为运营企业提供服务质量测试工具，也可以为发现网络不法行为提供必要的证据。随着互联网增值业务的发展，RTP将成为保证网络有序发展的一个重要手段。

流媒体实时数据，RTCP（Real-TimeTransportControlProtocol）是用来控制和监视它的传输。

实时数据，RTCP（Real-TimeTransportControlProtocol）是用来控制和监视它的传输。 实时数据，RTCP（Real-TimeTransportControlProtocol）是用来控制和监视它的传输。