在H.323和SIP系统中如何实现RSVP协议

前言：

RSVP(资源预留协议)是一种服务质量协议，也是一种商业的开放协议，当然它也是一种Internet上的大型协议，如果说它是网络上流动的一种钞票，这样的形容可以说是再合适不过了，利用RSVP消息，端点应用程序可以根据需求提出数据传送全程所必须网络带宽和缓冲大小以及延迟等等，同时也确定了沿途的路由器传输调度的策略，从而达到对每个数据流的QoS进行控制。

RSVP支持两种服务类型：受控载荷服务和保证服务，前者是在设定网络的载荷非常轻的情况下，所有的数据流都按照尽力的方式来处理且网络缓冲区为空，对于音频信号而言这种方法是正好合适的，而后者不是这样，不仅请求带宽，而且也要求最大传输延迟，那么所得到的结果就是在网络的负荷增加的时候不会让QoS有非常明显的减低。

如果从RSVP所支持的传输类型来区分QoS的服务，可以分成三种传输类型：最好性能（best-effort），速率敏感（rate-sensitive）与延迟敏感（delay-sensitive）。用来支持这些传输类型的数据流服务依赖保证QoS的协议实施。比如各种TCP/IP协议就是遵循最好性能传输的传输服务协议：TFTP，HTTP，SMTP，POP3等等；速率敏感传输放弃及时性，而确保传输速率。例如：速率敏感传输请求128kbps带宽，如在扩展期实际发送256kbps，路由器可能进行数据的队列缓冲，并且延迟传输；这类传输与采用电交换网络有关系，当然在internet主干网络和边沿网络也有这样的情况出现，RSVP服务支持速率敏感传输，称为位速率保证服务。延迟敏感传输要求传输及时，并因而改变其速率。例如：SIP或者H.323协议传输采用H.261协议压缩图象并且传输的时候流量可能达到384-768kbps，384Kbps可能对应一个静态的背景，而768kbps可能是一个动态的图象。熟悉H.261协议的人都知道在H.261中存在I-frame和P-frame的两种压缩方式，前者是本地压缩，那么必然产生一个淬发的数据尖峰，而后者和平均带宽的要求和接近，以Microsoft NetMeeting 为例子每15个P-frame产生一个I-frame，由于单个帧要求在一帧时间内发送出去，或解码器速度跟不上，必须对I-frame的传输进行特定优先级别协调，RSVP服务支持延迟敏感传输，可以被看作控制延迟服务（非实时服务）与预报服务（实时服务）的混合。

上面详细的阐述了RSVP的服务类型和传输类型，这样我们可以看出在以H.323或者是SIP为基础的视频通讯系统中，QoS的保证是比较复杂的，即有延迟敏感传输的服务也有速率敏感传输的服务，RSVP目前对这两种服务都可以做到很好的支持,我在下面的文章中会阐述一下如何在H.323和SIP的协议栈中实现RSVP，重点介绍Vovida中Vocal的SIP的实现方式，但是这里之介绍点对点的情况，而不介绍多点互联和广播的情况。

RSVP资源预留协议的具体内容可以参看RFC1633中对RSVP的具体定义，另外在draft-ietf-rsvp-rapi-01.txt中定义关于RSVP相关的基本API函数调用。

RSVP工作顺序描述如下图所示：

发送方发送PATH消息，消息中包含有数据业务特征，该消息沿所选的路径传送，沿途的路由器按照PATH准备路由资源，接收方接收到PATH消息以后，根据业务特征和所需要的QOS计算出所需要的资源，回送RESV消息，消息中包含的参数就包括请求预留的带宽，延PATH的原路途返回，沿途的路由器接收到RESV操作后才执行资源预留操作。发送方接收到RESV消息以后才发送用户数据。

简述在H.323协议中如何实现RSVP功能：

对于一个H.323或者是SIP的多媒体通讯系统而言，为了保证实时通讯的质量，一般来说采用了很多方面来保证QoS，对于H.323来说方式没有SIP那样灵活，在H.323v3版本采用了一些几种方式来增强QOS保证,另外这里暂时不对多播的情况考虑。

a.增强的RAS过程，在ARQ中指明了是否具备资源预留能力；

b.增强的能力交换过程，收发端点都具备RSVP功能，通过能力交换过程可以双方具备RSVP能力（RSVP属于能力集合的一个部分），在OpenLogicalChannel原语中定义了一个参数qOSCapability来表示；

c.增强的逻辑信道能力在逻辑信道打开过程中包含Path和Resv两个过程。

下面我们用图来表示逻辑信道的打开过程和资源预留过程：

1.发送端点向接受端点发送OpenLogicalChannel消息在qOSCapability中标明该信道的RSVP参数和综合业务类别。

2.接收端点创建RSVP会话（调用Rapi_sessionAPI）向发送端点发送OpenLogicalChannelAck。

3.在OpenLogicalAck中包含FlowControl=0，抑制当前的媒体数据流。

4.4和5表示发送端点和接收端点执行RSVP过程。

5.接收端点接收到ResvConfirm以后知道