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

预留成功。

6.FlowControl为最大的比特率，当前的媒体数据流为最大。

要注意的一点是由于通讯是双向的实际上述的过程发送和接收方需要对掉，特别在双方的能力集不相同的情况之下需要变换主叫和被叫的身份执行上述过程。

在SIP中实现RSVP功能：

以Vovida的Vocal为例子，在Vocal的SIP协议栈软件中提供了一个非常简便的实现RSVP的方式，当然按照这个方式实现RSVP是相当的不成熟的，很多参量在应用程序都没有反馈并且处理，仅仅是在路由器之间相互的汇报，不过这个简单的方式实现RSVP的构架，所以仍然有一定的使用价值。

在Vovida的SIP中实现RSVP的步骤如下：

在上图中实线的部分是SIP命令，虚线部分是RSVP消息

Vocal中的RSVP实现过程：

我们先看一下RSVPAPI中定义的流程：

我们先来看一下RSVP的API调用过程：

首先通过rapi_session()打开一个Unix域的RAPISocket，并创建一个RSVP的会话实例,如果成功则返回一个非零的数值用于表示建立的会话ID号。

例如在Vocal的SIPStack中这样创建：

session_id=rapi_session(&(dest_addr),//会话对端的目的地址；

proto_id,//协议号udp17；

RAPI_USE_INTSERV,//这里表示采用IntServ定义（和Diffserv相对应）

(rapi_event_rtn_t)upcallHandler,//在RSVP错误发生时候的回调函数

0,//RSVP事件的过滤器

&rtn_code);//建立会话的错误返回值。

使用rapi_session创建会话是发送RSVPPATH或者是发送RSVPRESV都需要在调用相应的函数之前调用它，现在我们看下面具体的程序部分的调用过程：

1．首先是主叫部分发送INVITE命令，我们知道命令中包含有主叫的会话描述（这里我们称为RemoteSDP）；

2．被叫部分此时处于OpRing的状态中接收到主叫的INVITE消息以后，根据主叫的INVITE消息和主叫的SDP，得到主叫的地址和主叫的RSVP端口（主叫的RTP端口）；被叫调用setupRsvp子程序发送包含有数据流标识和数据业务流特征的PATH消息到主叫，具体发送的业务流Tspec特征如下：

//SenderTspec(数据流的话务描述特征)的定义：

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);

//RAPISender

tspec_ptr->form=RAPI_TSPECTYPE_Simplified;

……

我们先来看一下在RSVPAPI中定义的发送一个PATH消息的函数：

rtn_code=rapi_sender(session_id,//在rapi_session中创建的会话ID号。

0,//该标志暂时未被使用

&(src_addr),//源地址和源端口

NULL,//发送方的端口号和源地址，可以为空

&(snd_tspec),//发送方的数据流的话务描述特征

NULL,/*senderadsepc*///Apspec的内容，可以为空

NULL,/*Policy*///发送方策略值，一般为空

ttl);//消息的生存周期`````

这里似乎和RSVP的--呼叫方发送PATH消息的精神有一些违背，是被叫方发送PATH消息，其实二者没有什么不同，首先主叫方，没有收到被叫方的SDP所以不能确定被叫方接收RSVP消息的端口和IP地址，其次，媒体流是双向的，双方都必须在网路上通过PATH--Reserve的方式预流资源。