基于RTP的多媒体通信的监控/发布的设计与实现

为实现对多媒体通信的监听，首先要能够捕获到媒体流的数据包，并剔除掉无效的信息，保留有用的信息，然后根据通信协议对有效信息做进一步的解析。

1协议原理分析

　　1.1传输层协议分析

　　很多多媒体通信的数据传输都是利用实时传输协议RTP实现的，因此要对多媒体通信进行监听要先分析RTP协议。RTP是实现数据实时传输非常有效的协议，能够提供端对端的网络传输功能，适合单播或多播网络的多媒体数据的实时传输应用。

　　RTP传输协议有如下一些特点。

　　(1)灵活性和简单性。RTP不具备传输层协议的完整功能，不支持资源预留，也不保证实时传输的服务质量。另外，RTP将部分传输层协议功能(比如流量控制)上移到应用层完成，简化了传输层处理，提高了该层效率。同时RTP的数据报文和控制报文使用相邻的不同端口，保证了数据流和控制流的分离；

　　(2)可扩展性和适用性。RTP通常为一个具体的应用来提供服务，通过一个具体的应用进程实现，而不作为OSI体系结构中单独的一层来实现，RTP只提供协议框架，开发者可以根据应用的具体要求进行充分的扩展。

　　RTP在UDP协议之上，由包头和负载构成。其包头的前12byte是固定存在的，负载数据可以是音视频信息。其包头中含有负载类型，以及保证数据实时连续性的信息(如Sequence Number、Timestamp等)，能够保证音视频的同步。

　　RTP协议本身不提供流量控制和拥塞控制功能，它靠一个专门的实时传输控制协议(RTCP)来实现。RTCP根据携带控制信息的不同，分为5种分组类型：发送方报告RR、接收方报告SR、资源描述条目SDES、结束参与显示包BYE，以及特别应用功能APP。RTCP的分发机制与RTP相同，它周期性地与所有会话参与者传输控制包，统计数据包传输时的丢失情况等信息，服务器根据这些反馈信息来制定流量控制的策略，改变传输码率甚至负载类型，能够大大提高实时数据的传输性能。

　　1.2H.323协议栈分析

　　H.323呼叫建立过程涉及3种信令：RAS信令，H.225呼叫信令和H.245控制信令。RAS信令用来完成终端与GK之间的登记注册、授权许可、带宽改变、状态和脱离解除等过程；H.225呼叫信令用来建立两个终端之间的连接，这个信令使用Q.931消息来控制呼叫的建立和拆除；H.245控制信令用来传送终端到终端的控制消息，包括主从判别、能力交换、打开和关闭逻辑信道、模式参数请求、流控消息和通用命令与指令等。图1描述了两个H.323终端通过GK进行呼叫建立的过程。

　　1.3SIP协议分析

　　SIP是应用层的控制协议，用来建立、修改、和终止多媒体会话或者呼叫。SIP 的终端系统叫做UA(用户代理)，中间的结点叫做proxy服务器。SIP是基于消息机制的文本协议，使用UTF-8字符集。一个SIP消息既可以是一个从客户端到服务器端的请求，也可以是一个从服务器端到客户端的一个应答。图2是SIP会话建立的一个例子。

　　SIP协议凭借其简单、易于扩展、便于实现等诸多优点越来越得到业界的青睐，它正逐步成为NGN(下一代网络)和3G多媒体子系统域中的重要协议，并且市场上出现越来越多的支持SIP的客户端软件和智能多媒体终端，以及用SIP协议实现的服务器和软交换设备。

　　2对媒体流监听的设计和实现

　　通过分析H.323和SIP这两种多媒体通信中应用最广泛的协议，可以捕获数据包并进行解析来达到监听的目的。

　　在H.323协议下，所要捕获的数据包为终端与终端(包括MCU)间通信传输的RTP包。在呼叫建立之初就在H.323协议框架下对每个IP包进行解析判断。首先经过比对获得H.225 RAS ARQ，解析得到多媒体会话ID用来确定所要发布的媒体流；然后判断解析H.245 OpenLogicalChannelAck包，获得RTP通信的IP地址，确定此地址是指定终端的IP地址，同时记录负载分别为音频和视频的端口号，作为过滤后继RTP数据流的依据。

　　由于SIP是文本协议，判断起来与H.323协议相比较为便捷。经过比对首先获得被监听端与UA呼叫建立后回发的200 OK消息，在其消息体中获得RTP通信的端口号，包括音频和视频。进而对RTP包进行过滤，将IP地址和端口号符合条件的RTP包保留，就是我们所要捕获的媒体流。

　　3媒体流发布的设计与实现

　　媒体流的传输和播放都可以基于微软的DirectShow技术实现。DirectShow系统位于应用层中，它使用一种叫Filter Graph的模型来管理整个数据流的处理过程；参与数据处理的各个功能模块叫做Filter；各个Filter在Filter Graph中按一定的顺序连接成一条“流水线”协同工作。

　　3.1方案设计

　　由发送端和接收端组成。以视频为例，图4、5两幅Filter Graph详细说明了各个filter之间的关系和流程。

　　同时考虑视频和音频，并将Filter Graph简化，可以得到图6。

　　3.2发送速度的控制

　　RTP协议没有规定RTP包的长度和发送数据的速度，因此需要根据具体情况调整服务器端发送媒体流的速度。对于来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易；对于媒体文件来说，如H.263格式的视频文件，由于其本身不包含帧率信息，需要事先知道其原有的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，然后根据帧率和预设初始值来计算时延。

　　时间戳字段是RTP包头中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送端不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失。RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。

　　对于本应用来说，捕获的RTP数据包头包含时间戳，发送数据时，只需比较前后两包时间戳的差异，就能够确定输出的时间间隔，从而以适当的速度发送数据。

　　3.3音视频的同步

　　音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率变化，接收端必须同步两个流，以保证声音与图像的一致。

　　音视频数据流能够同步的前提是接收端能够知道哪个音频流与哪个视频流是关联的，为此RCTP要求发送端给每个传输分配一个能够唯一标识数据源的规范名 (Canonical Name)。尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但由于有相同的规范名，这样接收端就知道哪些流是有关联的。然后利用SR报文所包含的信息，接收方协调两个流中的时间戳值。SR中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，结合RTP包中的时间戳值就能够确定同步的音视频数据。由于发送端发出的音视频数据流和SR都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。

　　4结论

　　由于RTP协议支持多播技术，因此发送端可以作为多媒体服务器实现对流媒体的分发，从而达到直播或转播的效果。

　　通过对于多媒体通信的监控，可以在实际生活中得到许多应用，比如对点对点视频通信以及视频会议的监控。不仅如此，在DirectShow框架下可以将接收端接收到的数据流存储在硬盘上，就能够对媒体流进行录制，并进一步提供下载等服务。