首頁>>>技術(shù)>>>視像通信　　視像通信產(chǎn)品

在H.323和SIP系統(tǒng)中如何實(shí)現(xiàn)RSVP協(xié)議

盧政 2003/08/19

摘要：
　　本文主要介紹了RSVP協(xié)議在IP網(wǎng)絡(luò)通訊協(xié)議H.323和SIP中的運(yùn)用，以及在語音/視頻通訊數(shù)據(jù)的特殊性，然后詳細(xì)敘述了Vocal系統(tǒng)中如何使用RAPI來實(shí)現(xiàn)RSVP的QoS管理，以及如何改善Vocal中RSVP的性能，并且論述了在主干網(wǎng)絡(luò)使用DiffServ的時(shí)候如何修改RAPI中的數(shù)據(jù)結(jié)構(gòu)，從而實(shí)現(xiàn)RSVP到DiffServ的映射。

前言：

　　RSVP(資源預(yù)留協(xié)議)是一種服務(wù)質(zhì)量協(xié)議，也是一種商業(yè)的開放協(xié)議，當(dāng)然它也是一種Internet上的大型協(xié)議，如果說它是網(wǎng)絡(luò)上流動(dòng)的一種鈔票，這樣的形容可以說是再合適不過了，利用RSVP消息，端點(diǎn)應(yīng)用程序可以根據(jù)需求提出數(shù)據(jù)傳送全程所必須網(wǎng)絡(luò)帶寬和緩沖大小以及延遲等等，同時(shí)也確定了沿途的路由器傳輸調(diào)度的策略，從而達(dá)到對(duì)每個(gè)數(shù)據(jù)流的QoS進(jìn)行控制。

　　RSVP支持兩種服務(wù)類型：受控載荷服務(wù)和保證服務(wù)，前者是在設(shè)定網(wǎng)絡(luò)的載荷非常輕的情況下，所有的數(shù)據(jù)流都按照盡力的方式來處理且網(wǎng)絡(luò)緩沖區(qū)為空，對(duì)于音頻信號(hào)而言這種方法是正好合適的，而后者不是這樣，不僅請(qǐng)求帶寬，而且也要求最大傳輸延遲，那么所得到的結(jié)果就是在網(wǎng)絡(luò)的負(fù)荷增加的時(shí)候不會(huì)讓QoS有非常明顯的減低。

　　如果從RSVP所支持的傳輸類型來區(qū)分QoS的服務(wù)，可以分成三種傳輸類型：最好性能（best-effort），速率敏感（rate-sensitive）與延遲敏感（delay-sensitive）。用來支持這些傳輸類型的數(shù)據(jù)流服務(wù)依賴保證QoS的協(xié)議實(shí)施。比如各種TCP/IP協(xié)議就是遵循最好性能傳輸?shù)膫鬏敺⻊?wù)協(xié)議：TFTP，HTTP，SMTP，POP3等等；速率敏感傳輸放棄及時(shí)性，而確保傳輸速率。例如：速率敏感傳輸請(qǐng)求128 kbps帶寬，如在擴(kuò)展期實(shí)際發(fā)送256 kbps，路由器可能進(jìn)行數(shù)據(jù)的隊(duì)列緩沖，并且延遲傳輸；這類傳輸與采用電交換網(wǎng)絡(luò)有關(guān)系，當(dāng)然在internet主干網(wǎng)絡(luò)和邊沿網(wǎng)絡(luò)也有這樣的情況出現(xiàn)，RSVP服務(wù)支持速率敏感傳輸，稱為位速率保證服務(wù)。延遲敏感傳輸要求傳輸及時(shí)，并因而改變其速率。例如：SIP或者H.323協(xié)議傳輸采用H.261協(xié)議壓縮圖象并且傳輸?shù)臅r(shí)候流量可能達(dá)到384-768kbps，384Kbps可能對(duì)應(yīng)一個(gè)靜態(tài)的背景，而768kbps 可能是一個(gè)動(dòng)態(tài)的圖象。熟悉H.261協(xié)議的人都知道在H.261中存在I-frame和P-frame的兩種壓縮方式，前者是本地壓縮，那么必然產(chǎn)生一個(gè)淬發(fā)的數(shù)據(jù)尖峰，而后者和平均帶寬的要求和接近，以Microsoft NetMeeting 為例子每15個(gè)P-frame產(chǎn)生一個(gè)I-frame，由于單個(gè)幀要求在一幀時(shí)間內(nèi)發(fā)送出去，或解碼器速度跟不上，必須對(duì)I-frame的傳輸進(jìn)行特定優(yōu)先級(jí)別協(xié)調(diào)，RSVP服務(wù)支持延遲敏感傳輸，可以被看作控制延遲服務(wù)（非實(shí)時(shí)服務(wù)）與預(yù)報(bào)服務(wù)（實(shí)時(shí)服務(wù)）的混合。

　　上面詳細(xì)的闡述了RSVP的服務(wù)類型和傳輸類型，這樣我們可以看出在以H.323或者是SIP為基礎(chǔ)的視頻通訊系統(tǒng)中，QoS的保證是比較復(fù)雜的，即有延遲敏感傳輸?shù)姆⻊?wù)也有速率敏感傳輸?shù)姆⻊?wù)，RSVP目前對(duì)這兩種服務(wù)都可以做到很好的支持,我在下面的文章中會(huì)闡述一下如何在H.323和SIP的協(xié)議棧中實(shí)現(xiàn)RSVP，重點(diǎn)介紹Vovida中Vocal的SIP的實(shí)現(xiàn)方式，但是這里之介紹點(diǎn)對(duì)點(diǎn)的情況，而不介紹多點(diǎn)互聯(lián)和廣播的情況。

　　RSVP資源預(yù)留協(xié)議的具體內(nèi)容可以參看RFC 1633中對(duì)RSVP的具體定義，另外在draft-ietf-rsvp-rapi-01.txt中定義關(guān)于RSVP相關(guān)的基本API函數(shù)調(diào)用。

　　RSVP工作順序描述如下圖所示：


　　發(fā)送方發(fā)送PATH消息，消息中包含有數(shù)據(jù)業(yè)務(wù)特征，該消息沿所選的路徑傳送，沿途的路由器按照PATH準(zhǔn)備路由資源，接收方接收到PATH消息以后，根據(jù)業(yè)務(wù)特征和所需要的QOS計(jì)算出所需要的資源，回送RESV消息，消息中包含的參數(shù)就包括請(qǐng)求預(yù)留的帶寬，延PATH的原路途返回，沿途的路由器接收到RESV操作后才執(zhí)行資源預(yù)留操作。發(fā)送方接收到RESV消息以后才發(fā)送用戶數(shù)據(jù)。

簡述在H.323協(xié)議中如何實(shí)現(xiàn)RSVP功能：

　　對(duì)于一個(gè)H.323或者是SIP的多媒體通訊系統(tǒng)而言，為了保證實(shí)時(shí)通訊的質(zhì)量，一般來說采用了很多方面來保證QoS，對(duì)于H.323來說方式?jīng)]有SIP那樣靈活，在H.323v3版本采用了一些幾種方式來增強(qiáng)QOS保證,另外這里暫時(shí)不對(duì)多播的情況考慮。
　　a. 增強(qiáng)的RAS過程，在ARQ中指明了是否具備資源預(yù)留能力；
　　b. 增強(qiáng)的能力交換過程，收發(fā)端點(diǎn)都具備RSVP功能，通過能力交換過程可以雙方具備RSVP能力（RSVP屬于能力集合的一個(gè)部分），在OpenLogicalChannel原語中定義了一個(gè)參數(shù)qOSCapability來表示；
　　c. 增強(qiáng)的邏輯信道能力在邏輯信道打開過程中包含Path和Resv兩個(gè)過程。
　　下面我們用圖來表示邏輯信道的打開過程和資源預(yù)留過程：


1. 發(fā)送端點(diǎn)向接受端點(diǎn)發(fā)送OpenLogicalChannel消息在qOSCapability中標(biāo)明該信道的RSVP參數(shù)和綜合業(yè)務(wù)類別。
2. 接收端點(diǎn)創(chuàng)建RSVP會(huì)話（調(diào)用Rapi_session API）向發(fā)送端點(diǎn)發(fā)送OpenLogicalChannel Ack。
3. 在OpenLogical Ack中包含F(xiàn)lowControl=0，抑制當(dāng)前的媒體數(shù)據(jù)流。
4. 4和5表示發(fā)送端點(diǎn)和接收端點(diǎn)執(zhí)行RSVP過程。
5. 接收端點(diǎn)接收到ResvConfirm以后知道預(yù)留成功。
6. FlowControl為最大的比特率，當(dāng)前的媒體數(shù)據(jù)流為最大。
　　要注意的一點(diǎn)是由于通訊是雙向的實(shí)際上述的過程發(fā)送和接收方需要對(duì)掉，特別在雙方的能力集不相同的情況之下需要變換主叫和被叫的身份執(zhí)行上述過程。

在SIP中實(shí)現(xiàn)RSVP功能：

　　以Vovida的Vocal為例子，在Vocal的SIP協(xié)議棧軟件中提供了一個(gè)非常簡便的實(shí)現(xiàn)RSVP的方式，當(dāng)然按照這個(gè)方式實(shí)現(xiàn)RSVP是相當(dāng)?shù)牟怀墒斓模芏鄥⒘吭趹?yīng)用程序都沒有反饋并且處理，僅僅是在路由器之間相互的匯報(bào)，不過這個(gè)簡單的方式實(shí)現(xiàn)RSVP的構(gòu)架，所以仍然有一定的使用價(jià)值。

　　在Vovida的SIP中實(shí)現(xiàn)RSVP的步驟如下：


　　在上圖中實(shí)線的部分是SIP命令，虛線部分是RSVP消息
　　Vocal中的RSVP實(shí)現(xiàn)過程：
　　我們先看一下RSVP API中定義的流程：
　　我們先來看一下RSVP的API調(diào)用過程：


（點(diǎn)擊放大）

　　首先通過rapi_session()打開一個(gè)Unix域的RAPI Socket，并創(chuàng)建一個(gè)RSVP的會(huì)話實(shí)例,如果成功則返回一個(gè)非零的數(shù)值用于表示建立的會(huì)話ID號(hào)。
　　例如在Vocal的SIP Stack中這樣創(chuàng)建：
　　session_id = rapi_session(&(dest_addr),//會(huì)話對(duì)端的目的地址；
　　　　　　　proto_id,　　　//協(xié)議號(hào) udp 17；
　　　　　　　RAPI_USE_INTSERV,//這里表示采用IntServ定義（和Diffserv相對(duì)應(yīng)）
　　　　　　　(rapi_event_rtn_t)upcallHandler,//在RSVP錯(cuò)誤發(fā)生時(shí)候的回調(diào)函數(shù)
　　　　　　　0,//RSVP事件的過濾器
　　　　　　　&rtn_code);//建立會(huì)話的錯(cuò)誤返回值。
　　使用rapi_session創(chuàng)建會(huì)話是發(fā)送RSVP PATH或者是發(fā)送RSVP RESV都需要在調(diào)用相應(yīng)的函數(shù)之前調(diào)用它，現(xiàn)在我們看下面具體的程序部分的調(diào)用過程：
1．首先是主叫部分發(fā)送INVITE命令，我們知道命令中包含有主叫的會(huì)話描述（這里我們稱為Remote SDP）；
2．被叫部分此時(shí)處于OpRing的狀態(tài)中接收到主叫的INVITE消息以后，根據(jù)主叫的INVITE消息和主叫的SDP，得到主叫的地址和主叫的RSVP端口（主叫的RTP端口）；被叫調(diào)用setupRsvp子程序發(fā)送包含有數(shù)據(jù)流標(biāo)識(shí)和數(shù)據(jù)業(yè)務(wù)流特征的PATH消息到主叫，具體發(fā)送的業(yè)務(wù)流Tspec特征如下：
　　//Sender Tspec(數(shù)據(jù)流的話務(wù)描述特征)的定義：
　　rapi_tspec_t *tspec_ptr = &(snd_tspec);
　　qos_tspecx_t *qos_tspec = &(tspec_ptr->tspecbody_qosx);
　　qos_tspec->spec_type = QOS_TSPEC;//發(fā)送方業(yè)務(wù)流特征標(biāo)示
　　qos_tspec->xtspec_r = 10000;//業(yè)務(wù)流量
　　qos_tspec->xtspec_b = 200;//標(biāo)記存儲(chǔ)桶寬度
　　qos_tspec->xtspec_p = 10000;//突發(fā)流量
　　qos_tspec->xtspec_m = 200;//本地緩沖最大保留量（漏桶參數(shù)）
　　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中定義的發(fā)送一個(gè)PATH消息的函數(shù)：
　　rtn_code = rapi_sender(session_id,//在rapi_session中創(chuàng)建的會(huì)話ID號(hào)。
　　0,　　　　　　　　　　　　　　//該標(biāo)志暫時(shí)未被使用
　　&(src_addr),　　　　　　　　　//源地址和源端口
　　NULL,　　　　　　　　　　　　 //發(fā)送方的端口號(hào)和源地址，可以為空
　　&(snd_tspec),　　　　　　　　 //發(fā)送方的數(shù)據(jù)流的話務(wù)描述特征
　　NULL,　/* sender adsepc */　　//Apspec的內(nèi)容，可以為空
　　NULL,　/* Policy */　　　　　 //發(fā)送方策略值，一般為空
　　ttl);　　　　　　　　　　　　 //消息的生存周期`````

　　這里似乎和RSVP的——呼叫方發(fā)送PATH消息的精神有一些違背，是被叫方發(fā)送PATH消息，其實(shí)二者沒有什么不同，首先主叫方，沒有收到被叫方的SDP所以不能確定被叫方接收RSVP消息的端口和IP地址，其次，媒體流是雙向的，雙方都必須在網(wǎng)路上通過PATH——Reserve的方式預(yù)流資源。

3．在完成了一系列SIP命令和狀態(tài)的交換(RING，OK過程)以后，主叫方開始準(zhǔn)備發(fā)送ACK消息了，也就是處于操作OpFarEndAnswered（）的時(shí)候，調(diào)用rsvpFarEndAnswered發(fā)送Reserve消息，為什么要在這個(gè)時(shí)候發(fā)送Reserve消息呢？因?yàn)橹鹘性谙乱粋�(gè)過程（收到ACK消息后，打開RTP通道之前）的時(shí)候，已經(jīng)保證了所有的主叫到被叫之間的路由器都已經(jīng)收到了PATH預(yù)留消息，

4．第5，6兩個(gè)消息是主叫端點(diǎn)向被叫端點(diǎn)之間的路由器發(fā)送PATH消息，并且接收對(duì)端的RESV消息的過程。和1，2，3的過程基本上一樣，最后在雙方的RTP通道打開之前，主叫/被叫之間的路由器實(shí)現(xiàn)穩(wěn)定狀態(tài)，也就是都收到主叫和被叫的資源預(yù)留的信息。
我們來看一下在主叫是如何定義RESV消息的：
　　//預(yù)留方式的選擇：
　　//RAPI_RSTYLE_WILDCARD的方式適合于聲音媒體傳輸，在多個(gè)請(qǐng)求的時(shí)候按最大的要求滿足//Flowspec需要為空；
　　// RAPI_RSTYLE_FIXED的方式適合于聲音媒體傳輸，對(duì)每個(gè)發(fā)送源進(jìn)行單獨(dú)的預(yù)留；
　　// RAPI_RSTYLE_SE表示預(yù)留數(shù)量應(yīng)該為自該接口收到的所有預(yù)留請(qǐng)求的最大數(shù)值，這個(gè)方//式主要適合于視頻媒體
　　style = RAPI_RSTYLE_FIXED;　/* RAPI_RSTYLE_WILDCARD = 1
　　　　　　　　　　　　　　　　　 RAPI_RSTYLE_FIXED = 2
　　　　　　　　　　　　　　　　　 RAPI_RSTYLE_SE = 3 */

　　resv_flag = 0; /* RAPI_REQ_CONFIRM */

　　rapi_flowspec_t *flowspec_cl_ptr = &(flowspec_cl);
　　qos_flowspecx_t *qos_flowspec_cl = &flowspec_cl_ptr->specbody_qosx;
　　//數(shù)據(jù)流說明(Flowspec)中的Tspec項(xiàng)目，要和PATH中的業(yè)務(wù)特征相同
　　qos_flowspec_cl->spec_type = QOS_CNTR_LOAD;
　　qos_flowspec_cl->xspec_r = 10000;
　　qos_flowspec_cl->xspec_b = 200;
　　qos_flowspec_cl->xspec_p = 10000;
　　qos_flowspec_cl->xspec_m = 200;
　　qos_flowspec_cl->xspec_M = 200; /* 65535 */
　　flowspec_cl_ptr->form = RAPI_FLOWSTYPE_Simplified;
　　flowspec_cl_ptr->len = sizeof(rapi_flowspec_t);
　　//數(shù)據(jù)流說明中的Rspec項(xiàng)目，根據(jù)PATH的端到端延遲和指標(biāo)和Adspec的參數(shù)計(jì)算出的，//在Vocal中直接采用估算的方法得出，Rspec是預(yù)留說明。
　　rapi_flowspec_t *flowspec_g_ptr = &(flowspec_g);
　　qos_flowspecx_t *qos_flowspec_g = &flowspec_g_ptr->specbody_qosx;
　　qos_flowspec_g->spec_type = QOS_GUARANTEEDX//類型為QoS保證，最為常用的設(shè)定;
　　qos_flowspec_g->xspec_R = 10000;//預(yù)流帶寬
　　qos_flowspec_g->xspec_S = 0;//松弛項(xiàng)（relaxation），用于指示Qos富裕量
　　qos_flowspec_g->xspec_r = 10000;// 業(yè)務(wù)流量
　　qos_flowspec_g->xspec_b = 200;// 標(biāo)記存儲(chǔ)桶寬度
　　qos_flowspec_g->xspec_p = 10000; //突發(fā)流量
　　qos_flowspec_g->xspec_m = 200; //本地緩沖最大保留量（漏桶參數(shù)）
　　qos_flowspec_g->xspec_M = 200; //SDU的最大值
　　flowspec_g_ptr->form = RAPI_FLOWSTYPE_Simplified;
　　flowspec_g_ptr->len = sizeof(rapi_flowspec_t);
　　//篩選說明，用于表示對(duì)哪個(gè)或者那些發(fā)送方進(jìn)行資源預(yù)留
　　filter_spec.form = RAPI_FILTERFORM_BASE;//表示包含發(fā)送方的套接字地址
　　//發(fā)送方的套接字地址
　　filter_spec.len = sizeof(rapi_hdr_t) + sizeof(rapi_filter_base_t);
　　filter_spec.rapi_filt4 = *(struct sockaddr_in *) & src_addr;

　　rtn_code = rapi_reserve(session_id,// 在rapi_session中創(chuàng)建的會(huì)話ID號(hào)。
　　　　　　　 resv_flag,//指示是否使用回吊函數(shù)（可以設(shè)置成0）
　　　　　　　 (struct sockaddr *) & rcv_sockaddr,//接收地址和端口
　　　　　　　 style,//預(yù)留方式（WF,FF,SF）
　　　　　　　 NULL,//擴(kuò)展的預(yù)留類型列表，可以為空
　　　　　　　 NULL,//接收策略
　　　　　　　 1,// FilterNo值，為1表示不能忽略Filterspec_list
　　　　　　　 &(filter_spec), //篩選說明
　　　　　　　 1,//FlowspecNo值，為1表示不能忽略Flowspec_list
　　　　　　　 &(flowspec_cl)); //FlowSpec數(shù)據(jù)流說明結(jié)構(gòu)。

5．在被叫端主要調(diào)用的函數(shù)：
　　a. void setupRsvp(SipSdp& localSdp, SipSdp& remoteSdp)
主要由被叫端調(diào)用，用于在收到主叫發(fā)送過來的INVITE消息以后根據(jù)主叫的SDP回送被叫資源預(yù)留PATH消息。
　　b. void rsvpFarEndAnswered(Sptr localSdp, Sptr remoteSdp)
主要由主叫端調(diào)用，用于在向被叫端發(fā)送ACK消息前向被叫發(fā)送RESV消息和開始主叫資源預(yù)留PATH消息。
　　c. void rsvpAckHandler(Sptr localSdp, Sptr remoteSdp)
主要由被叫端調(diào)用，用于在收到主叫發(fā)送過來的ACK消息以后根據(jù)主叫的SDP回送主叫資源預(yù)留RESV消息。

6. 如何實(shí)現(xiàn)的RSVP機(jī)制到Diffserv的映射：
　　對(duì)于目前在Vocal中對(duì)于RSVP的處理過程是非常簡單的，在用戶端都沒有對(duì)AdSpec和Tspec做任何具體的運(yùn)算，得出端到端的延遲指標(biāo)，以及預(yù)留帶寬，僅僅是通告路徑上的路由器去預(yù)留資源，這樣做如果是一個(gè)簡單的沒有太復(fù)雜的網(wǎng)絡(luò)狀態(tài)的區(qū)域網(wǎng)內(nèi)部，采用這種方法當(dāng)然是無可厚非的，不過如果是在有復(fù)雜網(wǎng)絡(luò)狀態(tài)的廣域網(wǎng)上這樣就可以說是不是很行得通了，一般來說在主干網(wǎng)絡(luò)上會(huì)運(yùn)行DiffServ（分類服務(wù)）的機(jī)制（所有的流都分組為多個(gè)服務(wù)類別的方式），這樣在骨干網(wǎng)上的RSVP消息當(dāng)然就會(huì)被忽略，所以我們的PATH和SESV消息都要實(shí)現(xiàn)對(duì)Diffserv的映射，換一句話來說，就地讓骨干網(wǎng)看起來象RSVP的一個(gè)節(jié)點(diǎn)，一般來說我們把AdSpec中的DTOT最小路徑延遲（或者說是子網(wǎng)絡(luò)到主干網(wǎng)絡(luò)的傳播延遲 在RFC2205中有定義）改變成透過骨干網(wǎng)的傳播延遲和平均排隊(duì)延遲的值（這個(gè)是由主干網(wǎng)羅入口/出口路由器做的工作）這個(gè)近似的方式一般來說是有效的，因?yàn)楣歉删W(wǎng)絡(luò)失效的機(jī)會(huì)畢竟比較小，如果主干網(wǎng)絡(luò)是千兆路由器，那么每條PATH消息是可以在中繼段上更新的。
　　返回RESV消息的時(shí)候，對(duì)于分類服務(wù)而言，并不是將每個(gè)相對(duì)應(yīng)的RSVP操作定義一個(gè)單獨(dú)的隊(duì)列，對(duì)于骨干網(wǎng)絡(luò)路由器是不現(xiàn)實(shí)的，只能相對(duì)服務(wù)等級(jí)接近的安排在最相近的隊(duì)列中。
　　另外有幾個(gè)情況是在如果主干網(wǎng)絡(luò)使用DiffSev需要注意的：
　　a. 如果有一個(gè)流不符合Tspec時(shí)——而這個(gè)時(shí)候路由器已經(jīng)為所有的入口和出口規(guī)劃了每一條虛鏈路的時(shí)候，一個(gè)不符合Tspec的流就足以毀壞同一類別所有其他留所爭取的服務(wù)質(zhì)量，例如入口處歸納低質(zhì)量的視頻/音頻流時(shí)候，出現(xiàn)了高質(zhì)量的視頻流。
　　b. 分散的/突發(fā)的流合并到平緩的流中時(shí)候。
　　不過一般來說每個(gè)路由器都具備檢查流的Tspec的能力，特別是作為主干網(wǎng)絡(luò)入口的路由器（例如一些大的網(wǎng)絡(luò)（BGP/EBGP）的入/出口地方）。在運(yùn)行視頻會(huì)議或者是其他突發(fā)流很多的惡劣工作狀況的時(shí)候。

7. 修改Vocal的SIP協(xié)議棧來更好的實(shí)現(xiàn)RSVP：
　　我們前面已經(jīng)反復(fù)地闡述：在Vocal中只不過是實(shí)現(xiàn)了一個(gè)簡單RSVP構(gòu)架，最重要的一點(diǎn)就是它不能夠?qū)崿F(xiàn)軟狀態(tài)，也就是定期刷新消息的Tspec和Rspec，如果在傳輸視頻信號(hào)的時(shí)候這樣的情況出現(xiàn)得特別頻繁，由于視頻信號(hào)并不總是處于一種穩(wěn)定的平緩的狀態(tài)傳輸，另外當(dāng)路由改變的時(shí)刻，RSVP消息需要能準(zhǔn)確的沿著新的路由往復(fù)（這種情況是可能出現(xiàn)的，特別在大型網(wǎng)絡(luò)中）。
　　解決上述問題的途徑首先就是要在RSVP建立保證服務(wù)預(yù)定，也就是要根據(jù)接收端根據(jù)發(fā)送端的AdSpec消息計(jì)算預(yù)留的帶寬（而在Vocal中基本上沒有處理AdSpec），AdSpec中參加帶寬運(yùn)算的主要是兩個(gè)參數(shù)：Dtot和Ctot，第一個(gè)參數(shù)是最小路徑延遲，第二個(gè)是路徑帶寬，通過這兩個(gè)參數(shù)根據(jù)公式D=(b(存儲(chǔ)桶深度)+Ctot)/p + Dtot計(jì)算出端到端之間的延遲:
　　例如：
　　PATH流的初始特征：
　　Tspec(p=10mbps,L=2kbps,r=1mbps,b=32kbps) AdSpec(Ctot=0,Dtot=0)
　　經(jīng)過第一個(gè)路由器：
　　Tspec(p=10mbps,L=2kbps,r=1mbps,b=32kbps) AdSpec(Ctot=11,Dtot=0.05s)
　　經(jīng)過第二個(gè)路由器：
　　Tspec(p=10mbps,L=2kbps,r=1mbps,b=32kbps) AdSpec(Ctot=55,Dtot=0.1s)
　　現(xiàn)在我們來計(jì)算Resv中Rspec項(xiàng)目：
　　最長的延遲為0.1s的延遲，我們?cè)赗spec中所計(jì)算的預(yù)留帶寬必須符合這個(gè)要求，那么根據(jù)公式：
　　D=(b+Ctot)/p + Dtot
　　b：存儲(chǔ)桶深度
　　計(jì)算出的D為0.185S我們?cè)诟鶕?jù)這個(gè)公式來計(jì)算預(yù)留帶寬
　　R=((p-r)（L+Ctot）+(b-L)p)/((t-Dtot)(p-r)+b-L)
　　r:業(yè)務(wù)流量
　　t:所需要的延遲
　　注意：所需要的延遲在0.1-0.185之間變化，這樣我們通過上述公式得出一個(gè)比較確切的R值R=1.66Mbps。所以Rspec為：R=1.66Mbps;松弛項(xiàng)(S)：用于指示Qos的富裕量,如果所有的路由器按照R預(yù)留，那么整個(gè)路徑上的端到端的延遲會(huì)比要求的時(shí)延要少5毫秒：這里可以選擇0.05S，也就是說有一個(gè)比較寬余的帶寬，可以實(shí)現(xiàn)其他的數(shù)據(jù)傳輸，或者是讓當(dāng)前的媒體數(shù)據(jù)實(shí)現(xiàn)盡力傳輸，具體的松弛項(xiàng)計(jì)算可以參看RFC2205定義。
　　上面我們解決了服務(wù)預(yù)定的問題，但是它只不過讓我們的終端程序運(yùn)行進(jìn)一步合理化，可以正確的規(guī)劃需要預(yù)留的帶寬，但是中間還是有關(guān)鍵問題沒有解決，也就是我們上面說的軟狀態(tài)——定期刷新Tspec和Rspec，以及探測/感知主干路由的變化
　　從程序上實(shí)現(xiàn)這些事實(shí)上并不困難，我們?cè)诖蜷_媒體通訊的RTP信道以后，可以用一個(gè)進(jìn)程定期的發(fā)送PATH和RESV消息，讓流的接收者進(jìn)行定期刷新，特別是在視頻通訊階段（采用H.263算法）出現(xiàn)幀間幀的時(shí)候，數(shù)據(jù)的流量必然會(huì)大大增加，這個(gè)時(shí)候，如果提前刷新預(yù)留的狀態(tài)，那么我們可以在初期就避免網(wǎng)絡(luò)出現(xiàn)阻塞的問題，當(dāng)然，如果流量超過了路徑所承受的標(biāo)準(zhǔn)，那么必然會(huì)依靠侵占S（松弛度）來發(fā)送數(shù)據(jù)包，如果超過了帶寬許可，這個(gè)時(shí)候，必然通訊會(huì)出現(xiàn)一個(gè)比較明顯的延遲，不過根據(jù)實(shí)驗(yàn)結(jié)果表明，這些還是可以接受的。
　　如果IP路由發(fā)生了變化，那么上述的解決辦法同樣的適用，定期傳送RSVP的消息可以重新根據(jù)流的路徑進(jìn)行新的定義，所以他們也會(huì)沿著新的路徑進(jìn)行傳輸，所以沿著相反路徑的RESV消息將試圖沿著新的路由進(jìn)行預(yù)定，舊的預(yù)定就會(huì)超時(shí)然后取消。
　　但是我們?nèi)绻紤]到主干網(wǎng)絡(luò)使用DiffServ就不會(huì)那么樂觀了（當(dāng)然主干網(wǎng)絡(luò)的路由變化不會(huì)那么劇烈），主干網(wǎng)絡(luò)上PATH項(xiàng)目中變化的部分就是AdSpec中的Dtot/Ctot，我們?cè)谏厦嬉呀?jīng)說了如何定義Dtot的內(nèi)容（子網(wǎng)絡(luò)到主干網(wǎng)絡(luò)的傳播延遲的計(jì)算 在RFC2205中有定義）改變成透過骨干網(wǎng)的傳播延遲和平均排隊(duì)延遲的值，正如上面所說的，如果主干網(wǎng)絡(luò)是功能強(qiáng)大的千兆路由器組成，那么PATH中的Dtot和Ctot可以在中繼的時(shí)候得到更新，如果是ATM或者是MPLS網(wǎng)絡(luò)的話，出入口也可以得到更新，這樣的話你事實(shí)上完全不必操心。

8．一些其他的設(shè)想：
　　不過不管怎么說上述的數(shù)值如果是周期性計(jì)算并在RESV消息中更新的話，必然大大的加大路由器的運(yùn)算開銷，特別在跨洋多點(diǎn)視頻會(huì)議的時(shí)候，這樣用戶接入服務(wù)供應(yīng)商區(qū)域網(wǎng)入口路由器可能會(huì)發(fā)生“餓死”的情況（沒有用戶媒體數(shù)據(jù)時(shí)候反而被大量無用的RSVP消息所淹沒），所以在使用主干網(wǎng)絡(luò)的時(shí)候，我們考慮必須有一個(gè)機(jī)制探測主干網(wǎng)絡(luò)的傳播延遲并且通報(bào)給服務(wù)供應(yīng)商區(qū)域網(wǎng)入口路由器，這個(gè)對(duì)于入口路由器并不使什么難事，最好是主干入口路由器本身就具備這樣的功能，進(jìn)一步簡化主干網(wǎng)絡(luò)為一個(gè)簡單的RSVP節(jié)點(diǎn)，變成由主干網(wǎng)絡(luò)的接入路由器通告服務(wù)供應(yīng)商的路由器端對(duì)端的延遲 ，這樣把計(jì)算的過程交給主干路由器，而服務(wù)供應(yīng)商區(qū)域網(wǎng)入口路由器只負(fù)責(zé)更新AdSpec，對(duì)于用戶來說，并不需要設(shè)定AdSpec,也就是可以讓AdSpec為空，這樣效率就可以得到大大的提高，代價(jià)就是增加了協(xié)議復(fù)雜性。

9．Vocal中采用策略服務(wù)器來管理QoS：
　　在H.323和SIP等大型的通訊協(xié)議中實(shí)現(xiàn)QoS的保證的確不是一個(gè)小的問題，和普通的傳輸服務(wù)協(xié)議所不同，H.323和SIP的傳遞數(shù)據(jù)都有著非常明顯的延遲和速率敏感特性，在建立一個(gè)大型的視頻會(huì)議/IP網(wǎng)絡(luò)電話系統(tǒng)的時(shí)候需要有專門的設(shè)備來管理和保證QoS，在Vocal系統(tǒng)中實(shí)現(xiàn)這個(gè)的設(shè)備是PoS Server(Policy Server),它使用了OSP和COPS(Common Open Policy Service)協(xié)議。可以和路由器之間傳遞消息,PoS的工作流程非常簡單，當(dāng)代理服務(wù)器轉(zhuǎn)遞180 /183的振鈴消息時(shí)（也就是被叫發(fā)送PATH消息前），發(fā)送一個(gè)COPS消息給PoS，同時(shí)被叫發(fā)送PATH消息到路由器上，路由器產(chǎn)生一個(gè)COPS-Request消息給PoS，以便確定用戶的帶寬申請(qǐng)授權(quán)，如果授權(quán)合法校驗(yàn)通過的話，PoS回送一個(gè)COPS-Decision到被叫端的路由器上，同樣在主叫端的路由器回送RESV消息的時(shí)候也會(huì)向PoS進(jìn)行同樣操作。

作者供稿 CTI論壇編輯

相關(guān)鏈接:
“非典”過后，視訊業(yè)務(wù)這么辦 2003-08-13
實(shí)戰(zhàn)視頻會(huì)議 2003-08-01
企業(yè)視訊會(huì)議網(wǎng)的建設(shè)應(yīng)當(dāng)注重技術(shù)標(biāo)準(zhǔn) 2003-07-29
傳統(tǒng)視訊產(chǎn)業(yè)鏈已成桎梏 視訊僵局急需打破 2003-07-21
聯(lián)通五年IP路 2003-07-11

分類信息:  網(wǎng)絡(luò)文摘_與_視像通訊     文摘   網(wǎng)絡(luò)文摘   技術(shù)_視像通訊_文摘
韶山市| 崇仁县| 句容市| 济宁市| 花垣县| 山阴县| 富平县| 巴林左旗| 全椒县| 浦城县| 福贡县| 韶关市| 文登市| 巧家县| 江都市| 西乌| 淳化县| 勐海县| 剑河县| 无为县| 青河县| 丹凤县| 锡林浩特市| 霍林郭勒市| 陇西县| 麦盖提县| 乡城县| 青冈县| 乳山市| 雷波县| 西丰县| 老河口市| 宝清县| 南川市| 太康县| 天全县| 凤冈县| 苏州市| 孝昌县| 海晏县| 晋江市|