基于SIP的视频会议系统模型、协议栈及相关扩展的研究

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

视频会议系统模型

设计一种良好的基于SIP的视频会议系统模型，将有助于加快系统开发进度，降低系统开发难度和风险。系统模型的优劣将在很大程度上影响系统开发的难度、进度和稳定性等，而且甚至决定系统开发的成败。本文提出了对不同规模的视频会议系统采用不同的系统模型，根据视频会议的主要数据流：信令流和媒体流，分别分析这两种流可能的系统拓扑结构，然后比较优劣，得出的结论是：控制拓扑都可以采用集中式，媒体拓扑则视不同的会议规模而不同。这样建立的系统模型是比较经济的，具有较高的商业价值。

SIP扩展

SIP扩展可以视为是SIP工具包，其中每个扩展解决一个具体的问题，可以预见到，为了解决一个大的问题，比如怎样提供一种新服务，将需要把核心规范和适当的扩展结合起来使用。SIP标准的方法只有6种，加上现有扩展，仍然不能满足视频会议系统的需要，因此需要对SIP方法进行扩展，本文提出了一种AGENT扩展方法，利用该方法结合现有一些扩展，才能对视频会议提供有效、简洁、完备的信令控制。

SIP协议栈

最具有代表性的5个开源SIP协议栈是：OPAL、VOCAL、sipX、ReSIProcate、oSIP。OPAL有发展潜力，VOCAL比较完善，sipX兼容性好，ReSIProcate较稳定，oSIP小巧而快速。本文选取oSIP为基础，通过改写和增加一些新功能，然后进行合理的封装，提供了更多接口和回调函数，方便了上层的开发。为实现视频会议打下了坚实的基础。

SIP协议及其网络体系结构

SIP协议及其网络体系结构是本文研究的基础，本文研究的视频会议系统模型、协议栈及扩展，都是基于SIP的，同时研究了与视频会议相关的RTP、RTCP、RTSP、SAP、SDP、视音频编解码等相关的协议和技术。

视频会议系统的种类

基于硬件的视频会议系统

该系统使用简单，维护方便，视频的质量非常好，但系统造价较高，对网络要求高，需要专线。与纯软件的视频会议系统相比，基于硬件的视频会议系统投入较大，建设复杂，灵活性不够，但对用户来说，如果要求高品质和高稳定性，基于硬件的视频会议系统是理想的选择。从视频会议系统的技术体系上看，目前市场成熟的、基于硬件的视频会议系统大体上可以分为两类：(1)基于H．320标准的视频会议系统：(2)基于H．323标准的视频会议系统。

基于软件的视频会议系统

使用软件来完成硬件的功能，主要借助于高性能的计算机来实现硬件解码功能，其特点是充分利用已有的计算机设备，总体造价较低，其原理与硬件视频会议系统基本相同，不同之处在于其MCU和终端都是利用高性能的PC机与服务器结合的软件来实现，视频编码大部分采用MPEG-4标准。另外，软件视频会议完全依赖于PC，因此在数据共享和应用方面比硬件视频会议灵活方便。

软件视频会议系统的优势和制约因素

优势

(1)纯软件系统在硬件设备上投入少，维护量小，因而成为低成本高收效的方案；

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

(2)系统对网络的适应能力非常好，可以穿透防火墙，参加会议的灵活性较好；

(3)移动性较强，而硬件视频会议固定性强；

(4)投资灵活，根据视频会议要求效果的不同，软件视频会议可以达到会议室级效果或桌面级效果；

(5)系统安装部署方便，易于扩容和产品升级。

制约软件视频会议系统发展的因素

(1)CPU的处理能力。音视频的编解码需要很强的运算处理能力，这在很大程度上制约了软件视频会议的发展。

(2)通信网络的带宽和成本价格。高质量的视频信号传输需要一定的带宽，过去网络带宽的限制以及高成本大大限制了视频会议的应用，随着中国电信运营商大规模部署ADSL，宽带得以普及，这极大地促进了软件视频会议的应用。

(3)客户使用习惯。硬件视频会议操作简单，维护方便，而软件视频会议要求有专业的IT维护人员。当然，随着电脑应用的普及，人们的生活、工作已同因特网紧密相关，这个因素也正在被淡化。

如今，限制视频会议系统发展的“瓶颈”(网络带宽和计算能力)逐步打破，这意味着视频会议系统的发展将越来越快。

软件视频会议系统中的主要技术

信令技术

目前被广泛接受的视频会议控制信令体系包括ITU-T的H．323系列和IETF的会话初始化协议SIP。

H．323是ITU-T有关多媒体通信的一个协议集，包括用于ISDN的H．320，用于B-ISDN的H．32l和用于PSTN终端的H．324等建议。虽然H．323提供了窄带多媒体通信所需要的所有子协议，但H．323的控制协议非常复杂。此外，H．323不支持多点发送(Multicast)协议，只能采用多点控制单元(MCU)构成多点会议，因而同时只能支持有限的多点用户。H．323也不支持呼叫转移，且建立呼叫的时间比较长。与H．323相反，SIP是一种比较简单的会话初始化协议。它不像H．323那样提供所有的通信协议，而是只提供会话或呼叫的建立与控制功能。SIP可以应用于多媒体会议、远程教学及Internet电话等领域。SIP既支持单点发送(Unicast)也支持多点发送，会话参加者和媒体种类可以随时加入一个已存在的会议。SIP可以用来呼叫人或机器设备，如呼叫一个媒体存储设备记录一个会议，或呼叫一个点播电视服务器向会议播放视频信号。

SIP是一种应用层协议，可以用UDP或TCP作为其传输协议。与H．323不同的是：SIP是一种基于文本的协议，用SIP规则资源定位语言描述(<SIP Uniform Resource Locators)，这样易于实现和调试，更重要的是灵活性和扩展性好。由于SIP仅作于初始化呼叫，而不是传输媒体数据，因而造成的附加传输代价也不大。SIP的URL也甚至可以嵌入到web页或其它超文本链路中，用户只需用鼠标一点即可发出一个呼叫。与H．323相比，SIP还有建立呼叫快，支持传送电话号码的特点。

编解码技术

视频会议系统要求高质量和占用更少的带宽，因此，编解码技术，尤其是图像编解码技术的发展将有效推动视频会议系统的应用。用于视频会议系统的编解码技术必须是能够实时应用的，要求延时不能过大，这就限制了压缩编码时一些技术的使用。ITU(国际电信联盟)最近推出了H．264的图像编解码标准。在同样图像质量的情况下，H．264编码数据量仅为H．263

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

的50％左右，但代价是编解码的复杂性上升，H.264编码复杂性是H．263的3倍，解码复杂性是H．263的2倍。H．264一经推出就广受欢迎，并很快被ISO批准为MPEG-4的图像编解码标准。

实时传输技术

实时传输技术主要是采用实时传输协议RTP。RTP是提供端到端的包括音视频在内的实时数据传送的协议。RTP包括数据和控制两部分，后者叫RTCP。

实时传输协议RTP是针对Internet上多媒体数据流的一个传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步（RTP提供了时间标签和控制不同数据流同步特性的机制，可以让接收端重组发送端的数据包）。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

工作时，RTP协议从上层接收流媒体信息码流(如H．263 ），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。

资源预留协议

RSVP协议的设计思想是期望通过应用和网络的协商，保证实时传输所需要的网络资源，在互联网上同时提供尽力传送和实时传送的综合服务能力。RSVP只负责资源的预留，并不牵涉到具体数据流的传输。

根据当前的RSVP规范建议，RSVP适合于小型的，私有的网络上，扩展性和策略控制问题不会表现的很突出。因此，RSVP协议适用于互联网的边缘区域，除非扩展性问题得到解决，在互联网的骨干网上不适合采用RSVP协议。

实时传输控制协议(RTCP)

RTCP与RTP协同使用，它把传输状态信息发送给所有与会者以进行媒体流性能和质量的监测。发送方也可以用它来确保SSRC的唯一性，RTCP协议主要依靠在所有成员之间周期性的传输控制分组来实现控制检测功能，它要求下层协议必须提供时间和控制分组的复用功能，如UDP协议可以提供不同的端口号。

RTCP主要完成以下四大功能，前三项是所有系统都支持的功能，最后一项是可以选择的功能。提供数据传输质量的反馈信息，这些反馈信息与流量控制和拥塞控制密切相关，也可以直接用于故障诊断。对每一个RTP信息源，RTCP带有一致的传输层标识，称为通用名。当SSRC（同步源标志）在由于冲突而发生改变时，接收方需要CNAME（通用名）标识来区分多个媒体流中给定应用的应用成员；当前参与成员的动态估计，可以用来计算数据发送速率，并且在成员动态变化时对速率进行动态调整以合理利用网络资源；传送最少量的控制信息以保证系统可以很容易的扩展成为大规模的松散耦合系统。

RTCP协议具有很好的伸缩性，允许应用从几个人的小规模系统扩展成上千人的大规模系统。

服务质量保证(QoS)技术

IP网络执行“尽最大可能提供服务”的策略，对所有数据一视同仁，而视频会议系统传输的数据的重要性是不同的，如少量的视频数据丢失可能影响不大，但认证信息丢失会导致整个会议呼叫失败。QoS的目的是在现有条件下尽可能获得好的效果，如保证重要的数据优先得到传输，必要的情况下，可以丢弃一些相对不重要的数据等等。

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

组播(Multicast)技术

组播技术是一个发送者一次发送数据给多个接收者的技术，其优点是可以减少数据传输量。在因特网中设计了组播方案，并预留了一些IP地址作为组播地址，但由于设备能力、安全等因素，IP层次上的组播无法在广域网范围内实现，因此，目前比较看好的是应用层组播，本质上是通过多个单播实现“组播”的效果，但同时引入了诸如动态负载均衡等技术，效果会优于简单的多个单播。

因此SIP有着与H.323完全不同的设计思想，它是一个分散式协议，它将网络设备的复杂性推向了网络边缘，使核心网络仍是一个“Best Effort”的传送通道。与以前应用比较广泛的H.323标准相比，SIP具有更高的功能性和增长潜力。

视频会议系统的信息安全技术

目前，用于视频会议系统的信息安全技术主要有两大类：

1．解扰技术

该类技术的目的是防止信息被非法盗用，可以用于视音频数据的加密。该技术已经广泛用于数字电视的加密频道中，其基本原理是在发送端对要发送的数据加扰，同时在授权的接收端(拥有相应的解密密钥)对接收的数据解扰。加解扰技术可以有很多的变化，比如使用3方加解扰体系可以对不同的用户授权不同的接收频道。

2．数字签名

这类技术的目的是防止有人伪造和篡改信息，同时也可以防止有人对做过的事不认账，可以用在身份认证、数据真实性验证、电子文档的会签等场合。

基于SIP的视频会议系统模型的设计

网络多媒体会议体系结构

先进的实时服务包括几种媒体(如：视频会议包括视频流和音频流)，同时也被大家称作多媒体服务。

视频会议拓扑结构

在IP网络上的多媒体会议系统中，通常使用SIP或者H.323协议来进行信令控制，使用实时传输协议RTP协议来传送实时的媒体流量。因此各个参与方之间的连接关系实际上包含了

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

信令和媒体两个方面，会议的拓扑结构也可由此分为控制拓扑和媒体拓扑。

控制拓扑

所谓控制拓扑是指各个参与方之间信令控制关系的结构，有集中式和分布式两种形式，如图所示。图中每个圆圈代表一个参与方，

每条双向箭头代表一个两方之问的信令会话关系。

媒体拓扑

所谓媒体拓扑是指各个参与方之间媒体流传送关系的结构，有集中式、分布式和组播式等三种形式，如图4-3所示。集中式媒体拓扑如子图(a)，指存在一个集中处理实体，负责多路媒体流的解码、混合、再编码和转发；分布式媒体拓扑如子图(b)所示，各参与方两两之间直接进行媒体传送；组播式媒体拓扑如子图(c)所示，媒体流并不直接发送到其他各方，而是送到一个共用的IP组播地址，由IP组播功能来负责把媒体传送到其他各方，当然，这要求底层网络必须支持IP组播功能；另外，分散式和组播式都要求参与方的终端具有媒体混合 的能力。

由于控制拓扑和媒体拓扑均可各自采用不同的结构，因此会议的拓扑结构作为这两种拓扑结构的组合，就有多种可能的结构。基于不同结构的会议系统在传输效率、处理能力、健壮性、可扩展性等各方面大不相同。对媒体拓扑而言，组播式无疑是传输效率最高的，这也正是IETF的MMUSIC工作组多年来一直推崇的方式，然而，在实际的网络中IP组播还远没有得到广泛支持，域间组播和组播可靠性等技术还不成熟，因此这种组播式的媒体拓扑一直难以实用。集中式和分布式则各有利弊，前者的优点在于提高了传输效率，同时减轻了终端处理媒体的负担；但另一方面，集中处理实体又容易成为整个系统的性能瓶颈和致命故障点，限制了会议规模的可扩展性。因此实际中，往往对于规模较小的会议采用集中式媒体拓扑，而对于规模较大的会议采用分布式媒体拓扑，两者各有所长。

但对于控制拓扑而言，集中式控制则要明显优于分布式控制。集中式控制拓扑可以和上述任意一种媒体拓扑结合使用，因此适用于各种规模大小的会议，具有很好的可扩展性；而分布式控制拓扑不能和集中式媒体拓扑一起使用，因为媒体的集中处理实体将无法得知会议

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

各方的状态，不知道如何对媒体进行混合和转发处理，所以分布式控制拓扑只能与分布式或组播式媒体拓扑相结合，用于规模较小的会议。

集中式控制拓扑的优点

(1)集中式控制拓扑便于实现管理、监控、计费和安全性等功能，这些功能对于会议系统的实用性和商用化至关重要。

(2)集中式控制拓扑便于在基本会议功能的基础上，开发新的增值业务，新业务只需要修改集中控制实体即可，对参与方的终端没有影响。

(3)相对于媒体处理而言，信令处理的负荷要轻得多，因此当会议规模扩大时，集中控制实体的处理能力不会迅速成为系统的瓶颈，集中式的缺陷并不突出。

基于SIP的视频会议系统模型

先介绍几个术语：

(1)普通终端：一个普通的SIP用户代理，所谓普通是指该用户代理只支持基本的SIP协议RFC3261，不支持其他会议功能相关的扩展要求。

(2)会议终端：一个支持会议相关扩展功能的SIP用户代理，能够完成一些高级的信令流程。

(3)多点控制器：一个信令的集中控制实体，负责协调与会议中各方的信令流程从而完成对整个会议的控制，并控制媒体处理器完成对媒体的处理，作为整个会议系统的核心。

(4)媒体处理器：一个媒体的集中处理实体，依照多点控制器的指示，完成对媒体的混合和转发等处理。

小型视频会议系统模型

小型视频会议系统，因为参与的终端比较少，因而需要传送的媒体流和信令流并不多，故可以把多点控制器和媒体处理器合在一起，可以极大的减少成本。增加系统的稳定性和提高资源的利用率，同时减少了维护成本，是理想的小型视频会议系统模型。模型如图所示：

中型视频会议系统模型

对于中型视频会议系统，由于参与的终端比较多，多点控制器必须和媒体处理器分离，否则假如他们合在一起，将成为系统的瓶颈，但由于中型视频会议，终端也不是特别多，故可以增加性能优良的单个媒体处理器，使控制中心和媒体处理器分离，这样既提高了系统的效率，又不至于增加太多成本。

由于中型视频会议控制信令不是很多，系统配置中等即可，单媒体处理需要性能优良的服务器来承担媒体数据的转发和接收。模型如图所示：

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

大型视频会议系统模型

对于大型视频会议系统，由于参与的终端数量巨大，虽然控制信令有限，但也必须配备性能优良的控制中心，同时，由于有海量的媒体数据需要传送，单个性能优良的媒体处理器已经不可能承受，必须增加多个性能优良的媒体处理器，媒体数据有时需要在媒体处理器之间转发。

考虑到控制中心的复杂度，对多个邻近的终端分为一组，由一个代理服务器负责，同一组内的的终端和代理服务器通讯，各代理服务器再和控制中心通讯，这样控制中心的复杂性就降低了。

若终端直接和控制中心通讯的话，将增加系统的复杂性，诸如维护一致性和系统的同步，以及他们之间的通讯。系统稳定性将急剧下降，因此，采用性能优良的单个控制中心和各个代理服务器通讯是个理想的选择。模型如图所示：

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

系统模型的有效性

以上分别针对不同规模的视频会议系统提出了不同的系统模型，这是充分考虑了视频会议系统的媒体拓扑与控制拓扑的不同特点：充分考虑到，集中式控制拓扑的优点和系统规模的不同，从商业性开发和应用的角度，给出上述3种模型。

对于小型视频会议系统模型，多点处理器和媒体处理器合并在一个服务器中，这极大的节省了成本，同时提高的系统的稳定性和减少了系统通讯的开销。

对于中型视频会议系统模型，多点控制器和媒体处理器分开，有利于降低开发的难度。同时，由于是中型规模，终端有一定的数量，让性能优良的媒体处理器负责处理媒体流的转发，让配置普通的多点控制器处理信令，具有较强的经济价值。

对于大型视频会议系统模型，在多点控制器和终端之间增加了代理服务器，同时，媒体处理器是由多个性能优良的服务器组成，由于每个服务器承担的任务都不是太多，都不会成为系统的瓶颈，这样极大的增强了系统的稳定性，同时开发的难度也不是很高，有利于系统的维护和升级。

oSIP2协议栈的改进

基于SIP的视频会议的实现需要一个性能良好的协议栈，SIP协议栈的好坏直接关系到视频会议的性能、开发难度以及周期。因此，一个好的协议栈对基于SIP的视频会议是十分重要的。

SIP协议栈的实现需包括IP网络通信、SIP消息的词法分析、消息的可靠性、状态的管理以及向高层应用实体提供方便、灵活的接口等。

因此，SIP协议栈的实现应遵循以下原则：

(1)SIP协议独立于传输层：可采用UDP或TCP进行传输。

(2)SIP协议独立于应用程序：以支持多种应用。

(3)SIP协议是发展中的协议：应支持SIP的易扩展性。

(4)SIP协议用于互联网环境：应支持易移植性。

(5)软件重用：以避免重复开发工作。

(6)具备并发处理能力：满足呼叫对实时性的要求。

SIP协议虽然是应用层协议，为了对SIP协议进一步细化，借鉴OSI的网络层次参考模型， 本文提出了协议栈的层次结构，如图所示。每一层使用下层提供的服务并为上层提供服务，应用从最高层开始访问SIP服务。

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

A层向上层提供网络通信功能，直接与网络层交互。A层将SIP消息通过UDP数据报发送出去，并将收到的UDP数据报上报至B层。

B层把c层传下来的内部消息格式转换成符合SIP规范的消息，并对A层传上来的UDP数据包进行词法分析，以生成内部SIP消息格式。B层根据C层的指示，采用指数衰减方式对SIP消息进行重传，以保证SIP消息的可靠性。

c层分为Client和Server，分别支持D层的客户方和各种服务器。其状态处理器向本层和D层提供接口，维护SIP消息的状态。c层还负责基于UDP传输时SIP消息的重传管理，包括过滤收到的重传SIP消息和指示B层对发出的SIP消息进行重传。

D层包含有用户代理和多种SIP服务器，对SIP请求消息和相应的响应消息进行语义处理。用户代理包括UAC和UAS，完成用户的全双工呼叫功能；代理服务器同时具备客户方和服务器方的能力，负责对用户呼叫的代理；重定向服务器负责对用户呼叫的重定向；注册服务器负责提供用户位置的登记功能。D层向上面的应用层提供灵活、方便的接口。

E层为各种应用程序(包括会议电话、基于IP网的VPN业务、接入智能网的点击拨号业务等)利用D层提供的接口来使用SIP服务。E层不属于SIP协议栈的范畴。

上述层次结构中，各层之间可并发执行，提供SIP协议栈的第一级并发机制。在两层之间接口不变的情况下，任何一层的修改都不会影响相邻层的软件，有效支持了SIP协议的可扩展性。由于C层和B层屏蔽了底层传输协议的使用情况，D层和E层不需了解具体的传输协议，使SIP协议栈易于使用多种传输协议。

此外，D层提供了丰富的接口，作为通信核心，可支持各种不同的应用程序。A、B、C层可以被不同的SIP实体（用户代理，各种服务器)重用，重用颗粒由传统的类重用扩大为软件构件的重用，大大缩小了软件开发周期。

因此开发一个良好的SIP协议栈不是一件容易的事情，需要做大量的工作，从头做起，需要很多时间。

因此，在现有的协议栈的基础上，进行一定的修改，以更适应视频会议系统的需要，是个明智的选择。考虑现有的协议栈，很自然的就会想起各种SIP开源协议栈。

开源SIP协议栈

(1)OPAL

OPAL是Open Phone Abstraction Library，是Openh323的下一个版本，它仍然使用了Openh323的体系结构，并在其基础上进行扩展，同时实现了SIP、H．323，但在音频和视频的编码和传输部分有较大改动。OPAL初衷设计是包含任何电话通信协议，所以其底层进行了高度的抽象化，所以也能够很容易的支持MGCP、PSTN和将来会出现的协议。不过由于Openh323的最后一个版本还在开发中，所以原本6月发布的OPAL也被推迟，现有的OPAL还非常不完善，BUG也非常多，不过以Openh323的开发班底，让OPAL十分优秀是可能的。

(2)VOCAL

VOCAL是vovida．org开发的SIP系统，VOCAL应该是目前功能最完善，使用者最多的开源SIP协议栈了。它不只包括了协议栈，还包括了H．323与SIP转换网关，对SIP的各种Server的功能支持也非常完善。不过很可惜，不支持Windows平台，而且自从vovida被CISCO收购以后就停止了开发，最后的版本是2003年4月的1.5.0。

(3)sipX

sipX是一个SIP系统，由SIPFoundry开发。sipx是从reSIProcate分离出来的，sipX除了

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

包括SIP stack外，还包括了sipXphone、sipXproxy、sipXregistry等等，由它们构成了完整的SIP系统，而且sipX还支持嵌入式系统，各个模块可以按需取舍。不过可惜是儿乎没有任何开发文档。

(4)ReSIProcate

ReSIProcate同样也是由SIPFoundry开发，ReSIProcate最开始起源于Vocal，由于Vocal开始只支持RFC3254，为了支持最新的RFC3261，ReSIProcate诞生了，但现在，ReSIProeate已经成为一个独立SIP协议栈了，它十分稳定，并且很多商业程序都在使用。

(5)oSIP

oSIP的开发开始于2000年7月，第一个版本在2001年5月发布，到现在已经发展到2．0．9了。它采用ANSIC编写，而且结构简单小巧，所以速度特别快，它并不提供高层的SIP会话控制API，它主要提供一些解析SIP／SDP消息的API和事务处理的状态机。

5种协议栈不同的对比如下表所示：

可以看出5种SIP协议栈各有千秋，OPAL有发展潜力，VOCAL比较完善，sipX兼容性好，ReSIProcate较稳定，oSIP小巧而快速。

在综合权衡各种开源SIP协议栈，以及视频会议系统的特定应用以及开发周期和成本的情况下，本文选择以oSIP2协议栈为基础，进行必要的修改和扩充，作为基于SIP视频会议的SIP协议栈。

第6章 SIP在视频会议上的扩展

SIP的设计应使它的核心功能在每个实现中便于显现出来。这使得它在全局范围内提供了互操作性。每个SIP实现都能利用这样一个事实，即任何其他SIP实现都会理解所有在SIP RFC[RFC 2543]中描述的机制。可是，一些实现还需要一些超出核心协议范围的功能，这意

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

味着需要想办法增强SIP。

SIP很灵活并且易于扩展。于是，团体很快定义了一些扩展，对一些有特殊需求的应用设计一些扩展来满足他们特殊的需要。这些扩展是采用一种模块化的风格实现，并且它们的使用方法可以在会话建立期间协商，从而保证一个中心任务是：实现核心协议的简单的用户代理(UA)将总能和高级的用户代理实现互操作。

SIP扩展可以视为是SIP工具包，其中每个扩展解决一个具体的问题，可以预见到，为了解决一个大的问题，比如怎样提供一种新服务，将需要把核心规范和适当的扩展结合起来使用。

所以，许多组织和个人也致力于研究对SIP的扩展和增强，以使其功能更强，应用范围更广。总的来看，对SIP的扩展主要体现在SIP在不同领域中的应用，如和ISDN用户部分(ISUP)互通，提供即时消息和在线状态(presence)服务，与资源管理综合，以及在3G、多方会议中的应用，安全认证和保密机制等。

6．1 SIP扩展应遵循的原则

对新SIP扩展的有效设计必须遵循一定的规则。已经定义了一些SIP扩展的设计原理

[daft-ietf-sip-guidelines]以保证新扩展不会改变SIP的精神。以Internet草案形式出现的新提议扩展在它们作为标准SIP扩展被接收以前，在SIP工作组种被小心地分析。因此要设计扩展，必须遵循一定的扩展原则：不能破坏SIP简单性和可管理性；不能破坏SIP对等关系；必须保持SIP会话建立过程与SIP会话描述之间的独立性；不要改变原有方法的语义。

(1）不能破坏SIP简单性和可管理性

SIP是Internet工程任务组（IETF)多媒体工具包的一部分。它按照它被设计的目标工作并且利用其他协议完成其他任务(例如会话描述协议(SDP)用于会话描述)。SIP扩展不应该扩大SIP的范围以使SIP用于能被其他Internet协议处理的更好的的任务。

SIP应该被用于定位一个特定的SIP实体和传送一个对象(如一个会话描述符)。这之中可能有一个协商的过程。SIP应该用于这样的应用：他们支持用户的可移动性、对象传送和SIP提供的协商机制。所有其他的应用落在SIP范围之外。如果我们尝试用SIP解决每一个它可能解决的问题，协议将变的大而且复杂，那将与IETF设计原理背道而驰，IETF要求设计的精简、优雅。IETF标准化过程确保了SIP保持简单和可管理性。

(2)不能破坏SIP对等关系

SIP实体通常有一个对等关系。当服务器从客户端收到一个请求时，它处理一些任务，接着返回一个有请求结果的应答。客户端并不持续向服务器端发送命令告诉它如何处理。因此，SIP在一个主体对从属有很强的控制的主／从体系结构中并不真正有效。

SIP扩展不应该用于提供这样的控制功能，这种功能已经被更适合的协议如H.248[RFC3015]所提供。相反，SIP实体间的对等关系，使得协议非常适合域间通讯。主／从协议被证明在域问通讯中无效，那些域的所有者通常想要阻止不同域的所有者控制他们的资源。

(3)会话类型的独立性

SIP将会话建立过程和会话描述分开来，只要将扩展添加到核心协议中，就应该维持这一分离原则，这是为了保证扩展能在将来证明。

尽管SIP可能被用于建立所有类型的会话，SIP在数据通信方面的发展已经十分集中在IP电话(VoIP)应用方面，这种集中在发展的协议的过程中是不寻常的，但是，我们不得不防止这样一种自然倾向：仅设计那些在VoIP环境中应用的扩展。现在，SIP扩展已足够用来覆盖不同类型的会话，尽管他们当前的用处只是一种VoIP服务。

(4)不要改变方法的语义

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

如一个SIP请求的目的由它的方法来定义，通过检查它的方法就能知道它的目的，标题头和参数给出了关于请求的更多信息，但请求的一般目的不会被任何标题头的内容所改变。因此需要一个新的功能扩展时，不要尝试改变一个已存在方法的语义。

6．2 视频会议中的SIP扩展

多媒体会议系统中传输的信息流包含音频、视频、数据和控制信息，会议系统主要包含两个部分内容：(1)使得参与者可以加入或者离开会议，如SIP这样的信令协议可以支持这样的操作；(2)会议控制，其中包括会议管理(如创建、修改和删除会议)、用户管理(增加和删除会议参与者，修改他们的属性)和底层管理。SIP本身为适应分组网的特性，在设计上是为分布式IP体系结构服务的，具有分布式的组网功能，其分布式控制方式使得系统能组建任意规模的网络，但这也使得会议控制更加困难，特别在保证会议参加者的一致性方面。最初SIP提出是可以用于多方会议中，但在文献中主要还是针对于点到点形式的，从SIP的呼叫流程也可以看出，因此目前已经有对于SIP在会议系统中的研究，一般是通过扩展来达到的，对于SIP消息的扩展可以通过增加某个SIP消息内的字段，也可以增加另外一种消息，为了支持将SIP应用于多媒体会议中，已经提出了几种针对多方会议的SIP扩展方法，这些方法都是将用户状态保留在单个会议服务器中，在会议规模较大时，中心会议服务器的负载也会较大。本文提出的大型视频会议系统模型，中心会议控制服务器，不保存用户状态，而是保留多个代理服务器的信息，转由多个代理服务器来保存用户状态，由SIP代理服务器之间的协调来实现成员的一致性，以满足多SIP方会议扩展性的要求。

对于这样的系统模型，需要扩展SIP，本文提出如下的一种SIP扩展解决方案：从对协议的分析可知，标准方法是没有实现对SIP于成员变化事件的响应，在文献[30]中提出了使用CONF的方法来通告用户状态，用来更新一个Proxy中的成员状态，但是对于多个Proxy之间的如何传递各自的状态成员没有定义，因此采用原来的方法是不够的，必须对其进行扩展，本文定义了一种新的AGENT方法用来实现在Proxy之间传递各自的状态成员，若有成员加入或离开，对于域中则采用SUBSCRIBE／NOTIFY方法，对于域间则采用AGENT的扩展方法，下面分别讨论这两种扩展方法。

6．2．1 SUBSCRIBE/NOTIFY扩展的应用

网络中的一些实体可以订阅网络中某些资源或呼叫的状态信息，当那些被订阅的资源的状态发生改变时，负责这一资源的网络实体将向订阅者发送通告，通报当前资源状态的变化情况。为实现这一机制，IETF的SIP工作组对SIP进行了扩充，提出了RFC 3265。这个文档中定义了预订(SUBSCRIBE)和通知(NOTIFY)两种扩展方法。

预订消息指预订者向他所感兴趣的远方节点T终端请求发送其状态以及及时地获得更新。一般是，预订请求应该包含一个“生存时间”头，这一消息头指定了预订的期限。为了在到期后仍能使预订有效，预订者需要间隔地发送新的预订请求。当然，这是在同一个SIP会话中。预定请求只有被200应答代码应答时才表明预订成功，随即会有通知消息，来通知预订端当前被请求端的状态。以后当预定的终端资源状态有变化时，也会发送通知消息。

事件包是通告者向订阅者发送的一组资源的状态信息。RFC 3265中给出了抽象的事件包模板定义，对应具体妲务可定义相应的事件包类型， 例如：在席事件包、对话事件包等，这些事件包可使用不同的语法并具有各自的语义。这种框架赋予会话启动协议事件通告机制极大的生命力和灵活性，有助于快速提供新的业务。

因此，在视频会议中，可以利用事件包，将视频会议中的各种需要在域中通讯的事件，分类为不同的事件包，这样就可以方便处理事件。

典型的会话启动协议事件通告机制流程如下图6-l所示：

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

(1)UA a预定Proxy_m的SUBSCRIBLE消息

(2)Proxy_m中有成员变化时对UA a的NOTIFY消息

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

6．2.2 一种新的AGENT扩展

AGENT并不是代理服务器本身产生的，而是在有用户变化时才产生的，这也是符合文献中定义的代理服务器的性质的。对于各个参加到会议中Proxy的而言，首先必须了解到本次会议中的其他Proxy，这可以通过一个定位服务器(LS)来实现，对于某次会议，某个域中首次有要求加入的UA时，UA向会议服务器呼叫，域中的Proxy向定位服务器注册成为本次会议的一个Proxy，请求本次会议媒体服务器的地址，同时请求本次会议其他的Proxy地址，每个 Proxy要保留某次会议的其他的Proxy列表，以便在以后有UA加入时不必再请求Proxys列表，之后Proxy要向其列表中的其他Proxy发送AGENT消息，含有其本身地址及状态成员的属性，向其他Proxy表明其存在，其他Proxy以此来更新Proxy的列表，同时向原Proxy发送ACK消息，并使用方法CONF来通知各自定购事件通知的状态成员。只有在域中有成员变化的Proxy才主动向其他的Proxy发送消息，如果域中Proxy最后一个成员离开，在其发出的AGENT消息中含有一个状态，表明退出会议，并向定位服务器注销。之后其他Proxy不会再向其发送消息，在定位服务器中只保留Proxy的数据。

Proxy根据定位服务器的信息发出AGENT消息，对AGENT消息进行处理，而不是简单地对消息转发，通过对上面的分析，构造了消息的结构，对于AGENT的其他字段不详细描述，主要说明在多方会议中的如下关键字段：

(1)Proxy_m因UA a加入而发往Proxy_n的AGENT消息

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

其中status表明proxy_m目前的状态，alive表明仍在当前的会议中，若本域中不再存在会议成员，则status值为leave，其中还有从定位服务器得到的列表及其proxy_m状态，此外还包括刚加入的UA a。

(2)Proxy_m因UA a离开而发往Pmxy n的AGENT消息

(3)Proxy_m因UA a离开而且本域中没有UA时而发往Proxy_n的AGENT消息

基于SIP的视频会议系统模型、协议栈及相关扩展的研究

由于Proxy只保留其本域内的状态成员，多点控制器保留会议Proxy的成员列表，而且相比之下Proxy要比会议成员的个数要少得多，因此不会造成会议瓶颈，大大提高了会议系统的扩展性，特别适合予目前的网络下多媒体应用。

AGENT扩展的优点

对于本文提出的大型视频会议系统模型，信令的传输主要在终端和代理服务器之间以及代理服务器和多点控制器之间，对于成员之间的状态改变，标准方法是没有实现对SIP于成员变化事件的响应，CONF的方法可以用来通告同一组中的用户状态，用来更新一个Proxy中的成员状态，但是对于多个Proxy之间的如何传递各自的状态成员没有定义，因此采用原来的方法是不够的，必须对进行扩展，AGENT扩展方法充分利用了大型视频会议系统模型的特点，在多个Proxy之间用AGENT扩展进行成员状态通知，使得消息流转更加合理、简单，与系统模型相一致，即终端与Proxy之间进行通讯，Proxy与多点控带制器进行通讯，大大减少了多点控制器的负担，同时Proxy可以进行一些预处理，使得系统更灵活，扩充和升级相当方便，也能容易的增加新的业务逻辑。

总之，AGENT扩展方法充分适应大型视频会议系统这样的系统模型，扩展是十分有效的。

本文来源：https://www.bwwdw.com/article/rat4.html