前言：
RSVP(资源预留协议)是一种服务质量协议，也是一种商业的开放协议，当然它也是一种Internet上的大型协议，如果说它是网络上流动的一种钞票，这样的形容可以说是再合适不过了，利用RSVP消息，端点应用程序可以根据需求提出数据传送全程所必须网络带宽和缓冲大小以及延迟等等，同时也确定了沿途的路由器传输调度的策略，从而达到对每个数据流的QoS进行控制。
RSVP支持两种服务类型：受控载荷服务和保证服务，前者是在设定网络的载荷非常轻的情况下，所有的数据流都按照尽力的方式来处理且网络缓冲区为空，对于音频信号而言这种方法是正好合适的，而后者不是这样，不仅请求带宽，而且也要求最大传输延迟，那么所得到的结果就是在网络的负荷增加的时候不会让QoS有非常明显的减低。
如果从RSVP所支持的传输类型来区分QoS的服务，可以分成三种传输类型：最好性能（best-effort），速率敏感（rate-sensitive）与延迟敏感（delay-sensitive）。用来支持这些传输类型的数据流服务依赖保证QoS的协议实施。比如各种TCP/IP协议就是遵循最好性能传输的传输服务协议：TFTP，HTTP，SMTP，POP3等等；速率敏感传输放弃及时性，而确保传输速率。例如：速率敏感传输请求128 kbps带宽，如在扩展期实际发送256 kbps，路由器可能进行数据的队列缓冲，并且延迟传输；这类传输与采用电交换网络有关系，当然在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资源预留协议的具体内容可以参看RFC 1633中对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_session API）向发送端点发送OpenLogicalChannel Ack。
3. 在OpenLogical Ack中包含FlowControl=0，抑制当前的媒体数据流。
4. 4和5表示发送端点和接收端点执行RSVP过程。
5. 接收端点接收到ResvConfirm以后知道预留成功。
6. FlowControl为最大的比特率，当前的媒体数据流为最大。
要注意的一点是由于通讯是双向的实际上述的过程发送和接收方需要对掉，特别在双方的能力集不相同的情况之下需要变换主叫和被叫的身份执行上述过程。
在SIP中实现RSVP功能：
以Vovida的Vocal为例子，在Vocal的SIP协议栈软件中提供了一个非常简便的实现RSVP的方式，当然按照这个方式实现RSVP是相当的不成熟的，很多参量在应用程序都没有反馈并且处理，仅仅是在路由器之间相互的汇报，不过这个简单的方式实现RSVP的构架，所以仍然有一定的使用价值。
在Vovida的SIP中实现RSVP的步骤如下：
在上图中实线的部分是SIP命令，虚线部分是RSVP消息
Vocal中的RSVP实现过程：
我们先看一下RSVP API中定义的流程：
我们先来看一下RSVP的API调用过程：
首先通过rapi_session()打开一个Unix域的RAPI Socket，并创建一个RSVP的会话实例,如果成功则返回一个非零的数值用于表示建立的会话ID号。
例如在Vocal的SIP Stack中这样创建：
session_id = rapi_session(&(dest_addr),//会话对端的目的地址；
proto_id, //协议号 udp 17；
RAPI_USE_INTSERV,//这里表示采用IntServ定义（和Diffserv相对应）
(rapi_event_rtn_t)upcallHandler,//在RSVP错误发生时候的回调函数
0,//RSVP事件的过滤器
&rtn_code);//建立会话的错误返回值。
使用rapi_session创建会话是发送RSVP PATH或者是发送RSVP RESV都需要在调用相应的函数之前调用它，现在我们看下面具体的程序部分的调用过程：
1．首先是主叫部分发送INVITE命令，我们知道命令中包含有主叫的会话描述（这里我们称为Remote SDP）；
2．被叫部分此时处于OpRing的状态中接收到主叫的INVITE消息以后，根据主叫的INVITE消息和主叫的SDP，得到主叫的地址和主叫的RSVP端口（主叫的RTP端口）；被叫调用setupRsvp子程序发送包含有数据流标识和数据业务流特征的PATH消息到主叫，具体发送的业务流Tspec特征如下：
//Sender Tspec(数据流的话务描述特征)的定义：
rapi_tspec_t *tspec_ptr = &(snd_tspec);
qos_tspecx_t *qos_tspec = &(tspec_ptr->tspecbody_qosx);
qos_tspec->spec_type = QOS_TSPEC;//发送方业务流特征标示
qos_tspec->xtspec_r = 10000;//业务流量
qos_tspec->xtspec_b = 200;//标记存储桶宽度
qos_tspec->xtspec_p = 10000;//突发流量
qos_tspec->xtspec_m = 200;//本地缓冲最大保留量（漏桶参数）
qos_tspec->xtspec_M = 200;//SDU的最大值
tspec_ptr->len = sizeof(rapi_hdr_t) + sizeof(qos_tspecx_t);
// RAPI Sender
tspec_ptr->form = RAPI_TSPECTYPE_Simplified;
… …
我们先来看一下在RSVP API中定义的发送一个PATH消息的函数：
rtn_code = rapi_sender(session_id,//在rapi_session中创建的会话ID号。
0,//该标志暂时未被使用
&(src_addr), //源地址和源端口
NULL, //发送方的端口号和源地址，可以为空
&(snd_tspec), //发送方的数据流的话务描述特征
NULL, /* sender adsepc *///Apspec的内容，可以为空
NULL, /* Policy */ //发送方策略值，一般为空
ttl); //消息的生存周期`````
这里似乎和RSVP的——呼叫方发送PATH消息的精神有一些违背，是被叫方发送PATH消息，其实二者没有什么不同，首先主叫方，没有收到被叫方的SDP所以不能确定被叫方接收RSVP消息的端口和IP地址，其次，媒体流是双向的，双方都必须在网路上通过PATH——Reserve的方式预流资源。
来源：ZDNet
