在H.323和SIP系統中如何實(shí)現RSVP協(xié)議
盧政 2003/08/19
摘要：
本文主要介紹了RSVP協(xié)議在IP網(wǎng)絡(luò )通訊協(xié)議H.323和SIP中的運用，以及在語(yǔ)音/視頻通訊數據的特殊性，然后詳細敘述了Vocal系統中如何使用RAPI來(lái)實(shí)現RSVP的QoS管理，以及如何改善Vocal中RSVP的性能，并且論述了在主干網(wǎng)絡(luò )使用DiffServ的時(shí)候如何修改RAPI中的數據結構，從而實(shí)現RSVP到DiffServ的映射。
前言：
RSVP(資源預留協(xié)議)是一種服務(wù)質(zhì)量協(xié)議，也是一種商業(yè)的開(kāi)放協(xié)議，當然它也是一種Internet上的大型協(xié)議，如果說(shuō)它是網(wǎng)絡(luò )上流動(dòng)的一種鈔票，這樣的形容可以說(shuō)是再合適不過(guò)了，利用RSVP消息，端點(diǎn)應用程序可以根據需求提出數據傳送全程所必須網(wǎng)絡(luò )帶寬和緩沖大小以及延遲等等，同時(shí)也確定了沿途的路由器傳輸調度的策略，從而達到對每個(gè)數據流的QoS進(jìn)行控制。
RSVP支持兩種服務(wù)類(lèi)型：受控載荷服務(wù)和保證服務(wù)，前者是在設定網(wǎng)絡(luò )的載荷非常輕的情況下，所有的數據流都按照盡力的方式來(lái)處理且網(wǎng)絡(luò )緩沖區為空，對于音頻信號而言這種方法是正好合適的，而后者不是這樣，不僅請求帶寬，而且也要求最大傳輸延遲，那么所得到的結果就是在網(wǎng)絡(luò )的負荷增加的時(shí)候不會(huì )讓QoS有非常明顯的減低。
如果從RSVP所支持的傳輸類(lèi)型來(lái)區分QoS的服務(wù)，可以分成三種傳輸類(lèi)型：最好性能（best-effort），速率敏感（rate-sensitive）與延遲敏感（delay-sensitive）。用來(lái)支持這些傳輸類(lèi)型的數據流服務(wù)依賴(lài)保證QoS的協(xié)議實(shí)施。比如各種TCP/IP協(xié)議就是遵循最好性能傳輸的傳輸服務(wù)協(xié)議：TFTP，HTTP，SMTP，POP3等等；速率敏感傳輸放棄及時(shí)性，而確保傳輸速率。例如：速率敏感傳輸請求128
kbps帶寬，如在擴展期實(shí)際發(fā)送256 kbps，路由器可能進(jìn)行數據的隊列緩沖，并且延遲傳輸；這類(lèi)傳輸與采用電交換網(wǎng)絡(luò )有關(guān)系，當然在internet主干網(wǎng)絡(luò )和邊沿網(wǎng)絡(luò )也有這樣的情況出現，RSVP服務(wù)支持速率敏感傳輸，稱(chēng)為位速率保證服務(wù)。延遲敏感傳輸要求傳輸及時(shí)，并因而改變其速率。例如：SIP或者H.323協(xié)議傳輸采用H.261協(xié)議壓縮圖象并且傳輸的時(shí)候流量可能達到384-768kbps，384Kbps可能對應一個(gè)靜態(tài)的背景，而768kbps
可能是一個(gè)動(dòng)態(tài)的圖象。熟悉H.261協(xié)議的人都知道在H.261中存在I-frame和P-frame的兩種壓縮方式，前者是本地壓縮，那么必然產(chǎn)生一個(gè)淬發(fā)的數據尖峰，而后者和平均帶寬的要求和接近，以Microsoft
NetMeeting 為例子每15個(gè)P-frame產(chǎn)生一個(gè)I-frame，由于單個(gè)幀要求在一幀時(shí)間內發(fā)送出去，或解碼器速度跟不上，必須對I-frame的傳輸進(jìn)行特定優(yōu)先級別協(xié)調，RSVP服務(wù)支持延遲敏感傳輸，可以被看作控制延遲服務(wù)（非實(shí)時(shí)服務(wù)）與預報服務(wù)（實(shí)時(shí)服務(wù)）的混合。
上面詳細的闡述了RSVP的服務(wù)類(lèi)型和傳輸類(lèi)型，這樣我們可以看出在以H.323或者是SIP為基礎的視頻通訊系統中，QoS的保證是比較復雜的，即有延遲敏感傳輸的服務(wù)也有速率敏感傳輸的服務(wù)，RSVP目前對這兩種服務(wù)都可以做到很好的支持,我在下面的文章中會(huì )闡述一下如何在H.323和SIP的協(xié)議棧中實(shí)現RSVP，重點(diǎn)介紹Vovida中Vocal的SIP的實(shí)現方式，但是這里之介紹點(diǎn)對點(diǎn)的情況，而不介紹多點(diǎn)互聯(lián)和廣播的情況。
RSVP資源預留協(xié)議的具體內容可以參看RFC 1633中對RSVP的具體定義，另外在draft-ietf-rsvp-rapi-01.txt中定義關(guān)于RSVP相關(guān)的基本API函數調用。
RSVP工作順序描述如下圖所示：
發(fā)送方發(fā)送PATH消息，消息中包含有數據業(yè)務(wù)特征，該消息沿所選的路徑傳送，沿途的路由器按照PATH準備路由資源，接收方接收到PATH消息以后，根據業(yè)務(wù)特征和所需要的QOS計算出所需要的資源，回送RESV消息，消息中包含的參數就包括請求預留的帶寬，延PATH的原路途返回，沿途的路由器接收到RESV操作后才執行資源預留操作。發(fā)送方接收到RESV消息以后才發(fā)送用戶(hù)數據。
簡(jiǎn)述在H.323協(xié)議中如何實(shí)現RSVP功能：
對于一個(gè)H.323或者是SIP的多媒體通訊系統而言，為了保證實(shí)時(shí)通訊的質(zhì)量，一般來(lái)說(shuō)采用了很多方面來(lái)保證QoS，對于H.323來(lái)說(shuō)方式?jīng)]有SIP那樣靈活，在H.323v3版本采用了一些幾種方式來(lái)增強QOS保證,另外這里暫時(shí)不對多播的情況考慮。
a. 增強的RAS過(guò)程，在A(yíng)RQ中指明了是否具備資源預留能力；
b. 增強的能力交換過(guò)程，收發(fā)端點(diǎn)都具備RSVP功能，通過(guò)能力交換過(guò)程可以雙方具備RSVP能力（RSVP屬于能力集合的一個(gè)部分），在OpenLogicalChannel原語(yǔ)中定義了一個(gè)參數qOSCapability來(lái)表示；
c. 增強的邏輯信道能力在邏輯信道打開(kāi)過(guò)程中包含Path和Resv兩個(gè)過(guò)程。
下面我們用圖來(lái)表示邏輯信道的打開(kāi)過(guò)程和資源預留過(guò)程：
1. 發(fā)送端點(diǎn)向接受端點(diǎn)發(fā)送OpenLogicalChannel消息在qOSCapability中標明該信道的RSVP參數和綜合業(yè)務(wù)類(lèi)別。
2. 接收端點(diǎn)創(chuàng )建RSVP會(huì )話(huà)（調用Rapi_session API）向發(fā)送端點(diǎn)發(fā)送OpenLogicalChannel Ack。
3. 在OpenLogical Ack中包含FlowControl=0，抑制當前的媒體數據流。
4. 4和5表示發(fā)送端點(diǎn)和接收端點(diǎn)執行RSVP過(guò)程。
5. 接收端點(diǎn)接收到ResvConfirm以后知道預留成功。
6. FlowControl為最大的比特率，當前的媒體數據流為最大。
要注意的一點(diǎn)是由于通訊是雙向的實(shí)際上述的過(guò)程發(fā)送和接收方需要對掉，特別在雙方的能力集不相同的情況之下需要變換主叫和被叫的身份執行上述過(guò)程。
在SIP中實(shí)現RSVP功能：
以Vovida的Vocal為例子，在Vocal的SIP協(xié)議棧軟件中提供了一個(gè)非常簡(jiǎn)便的實(shí)現RSVP的方式，當然按照這個(gè)方式實(shí)現RSVP是相當的不成熟的，很多參量在應用程序都沒(méi)有反饋并且處理，僅僅是在路由器之間相互的匯報，不過(guò)這個(gè)簡(jiǎn)單的方式實(shí)現RSVP的構架，所以仍然有一定的使用價(jià)值。
在Vovida的SIP中實(shí)現RSVP的步驟如下：
在上圖中實(shí)線(xiàn)的部分是SIP命令，虛線(xiàn)部分是RSVP消息
Vocal中的RSVP實(shí)現過(guò)程：
我們先看一下RSVP API中定義的流程：
我們先來(lái)看一下RSVP的API調用過(guò)程：
（點(diǎn)擊放大）
首先通過(guò)rapi_session()打開(kāi)一個(gè)Unix域的RAPI Socket，并創(chuàng )建一個(gè)RSVP的會(huì )話(huà)實(shí)例,如果成功則返回一個(gè)非零的數值用于表示建立的會(huì )話(huà)ID號。
例如在Vocal的SIP Stack中這樣創(chuàng )建：
session_id = rapi_session(&(dest_addr),//會(huì )話(huà)對端的目的地址；
proto_id, //協(xié)議號 udp 17；
RAPI_USE_INTSERV,//這里表示采用IntServ定義（和Diffserv相對應）
(rapi_event_rtn_t)upcallHandler,//在RSVP錯誤發(fā)生時(shí)候的回調函數
0,//RSVP事件的過(guò)濾器
&rtn_code);//建立會(huì )話(huà)的錯誤返回值。
使用rapi_session創(chuàng )建會(huì )話(huà)是發(fā)送RSVP PATH或者是發(fā)送RSVP RESV都需要在調用相應的函數之前調用它，現在我們看下面具體的程序部分的調用過(guò)程：
1．首先是主叫部分發(fā)送INVITE命令，我們知道命令中包含有主叫的會(huì )話(huà)描述（這里我們稱(chēng)為Remote SDP）；
2．被叫部分此時(shí)處于OpRing的狀態(tài)中接收到主叫的INVITE消息以后，根據主叫的INVITE消息和主叫的SDP，得到主叫的地址和主叫的RSVP端口（主叫的RTP端口）；被叫調用setupRsvp子程序發(fā)送包含有數據流標識和數據業(yè)務(wù)流特征的PATH消息到主叫，具體發(fā)送的業(yè)務(wù)流Tspec特征如下：
//Sender Tspec(數據流的話(huà)務(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ù)流特征標示
qos_tspec->xtspec_r = 10000;//業(yè)務(wù)流量
qos_tspec->xtspec_b = 200;//標記存儲桶寬度
qos_tspec->xtspec_p = 10000;//突發(fā)流量
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;
… …
我們先來(lái)看一下在RSVP API中定義的發(fā)送一個(gè)PATH消息的函數：
rtn_code = rapi_sender(session_id,//在rapi_session中創(chuàng )建的會(huì )話(huà)ID號。
0, //該標志暫時(shí)未被使用
&(src_addr), //源地址和源端口
NULL, //發(fā)送方的端口號和源地址，可以為空
&(snd_tspec), //發(fā)送方的數據流的話(huà)務(wù)描述特征
NULL, /* sender adsepc */ //Apspec的內容，可以為空
NULL, /* Policy */ //發(fā)送方策略值，一般為空
ttl); //消息的生存周期`````
這里似乎和RSVP的——呼叫方發(fā)送PATH消息的精神有一些違背，是被叫方發(fā)送PATH消息，其實(shí)二者沒(méi)有什么不同，首先主叫方，沒(méi)有收到被叫方的SDP所以不能確定被叫方接收RSVP消息的端口和IP地址，其次，媒體流是雙向的，雙方都必須在網(wǎng)路上通過(guò)PATH——Reserve的方式預流資源。
3．在完成了一系列SIP命令和狀態(tài)的交換(RING，OK過(guò)程)以后，主叫方開(kāi)始準備發(fā)送ACK消息了，也就是處于操作OpFarEndAnswered（）的時(shí)候，調用rsvpFarEndAnswered發(fā)送Reserve消息，為什么要在這個(gè)時(shí)候發(fā)送Reserve消息呢？因為主叫在下一個(gè)過(guò)程（收到ACK消息后，打開(kāi)RTP通道之前）的時(shí)候，已經(jīng)保證了所有的主叫到被叫之間的路由器都已經(jīng)收到了PATH預留消息，
4．第5，6兩個(gè)消息是主叫端點(diǎn)向被叫端點(diǎn)之間的路由器發(fā)送PATH消息，并且接收對端的RESV消息的過(guò)程。和1，2，3的過(guò)程基本上一樣，最后在雙方的RTP通道打開(kāi)之前，主叫/被叫之間的路由器實(shí)現穩定狀態(tài)，也就是都收到主叫和被叫的資源預留的信息。
我們來(lái)看一下在主叫是如何定義RESV消息的：
//預留方式的選擇：
//RAPI_RSTYLE_WILDCARD的方式適合于聲音媒體傳輸，在多個(gè)請求的時(shí)候按最大的要求滿(mǎn)足//Flowspec需要為空；
// RAPI_RSTYLE_FIXED的方式適合于聲音媒體傳輸，對每個(gè)發(fā)送源進(jìn)行單獨的預留；
// RAPI_RSTYLE_SE表示預留數量應該為自該接口收到的所有預留請求的最大數值，這個(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;
//數據流說(shuō)明(Flowspec)中的Tspec項目，要和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);
//數據流說(shuō)明中的Rspec項目，根據PATH的端到端延遲和指標和Adspec的參數計算出的，//在Vocal中直接采用估算的方法得出，Rspec是預留說(shuō)明。
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//類(lèi)型為QoS保證，最為常用的設定;
qos_flowspec_g->xspec_R = 10000;//預流帶寬
qos_flowspec_g->xspec_S = 0;//松弛項（relaxation），用于指示Qos富裕量
qos_flowspec_g->xspec_r = 10000;// 業(yè)務(wù)流量
qos_flowspec_g->xspec_b = 200;// 標記存儲桶寬度
qos_flowspec_g->xspec_p = 10000; //突發(fā)流量
qos_flowspec_g->xspec_m = 200; //本地緩沖最大保留量（漏桶參數）
qos_flowspec_g->xspec_M = 200; //SDU的最大值
flowspec_g_ptr->form = RAPI_FLOWSTYPE_Simplified;
flowspec_g_ptr->len = sizeof(rapi_flowspec_t);
//篩選說(shuō)明，用于表示對哪個(gè)或者那些發(fā)送方進(jìn)行資源預留
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ì )話(huà)ID號。
resv_flag,//指示是否使用回吊函數（可以設置成0）
(struct sockaddr *) & rcv_sockaddr,//接收地址和端口
style,//預留方式（WF,FF,SF）
NULL,//擴展的預留類(lèi)型列表，可以為空
NULL,//接收策略
1,// FilterNo值，為1表示不能忽略Filterspec_list
&(filter_spec), //篩選說(shuō)明
1,//FlowspecNo值，為1表示不能忽略Flowspec_list
&(flowspec_cl)); //FlowSpec數據流說(shuō)明結構。
5．在被叫端主要調用的函數：
a. void setupRsvp(SipSdp& localSdp, SipSdp& remoteSdp)
主要由被叫端調用，用于在收到主叫發(fā)送過(guò)來(lái)的INVITE消息以后根據主叫的SDP回送被叫資源預留PATH消息。
b. void rsvpFarEndAnswered(Sptr localSdp, Sptr remoteSdp)
主要由主叫端調用，用于在向被叫端發(fā)送ACK消息前向被叫發(fā)送RESV消息和開(kāi)始主叫資源預留PATH消息。
c. void rsvpAckHandler(Sptr localSdp, Sptr remoteSdp)
主要由被叫端調用，用于在收到主叫發(fā)送過(guò)來(lái)的ACK消息以后根據主叫的SDP回送主叫資源預留RESV消息。
6. 如何實(shí)現的RSVP機制到Diffserv的映射：
對于目前在Vocal中對于RSVP的處理過(guò)程是非常簡(jiǎn)單的，在用戶(hù)端都沒(méi)有對AdSpec和Tspec做任何具體的運算，得出端到端的延遲指標，以及預留帶寬，僅僅是通告路徑上的路由器去預留資源，這樣做如果是一個(gè)簡(jiǎn)單的沒(méi)有太復雜的網(wǎng)絡(luò )狀態(tài)的區域網(wǎng)內部，采用這種方法當然是無(wú)可厚非的，不過(guò)如果是在有復雜網(wǎng)絡(luò )狀態(tài)的廣域網(wǎng)上這樣就可以說(shuō)是不是很行得通了，一般來(lái)說(shuō)在主干網(wǎng)絡(luò )上會(huì )運行DiffServ（分類(lèi)服務(wù)）的機制（所有的流都分組為多個(gè)服務(wù)類(lèi)別的方式），這樣在骨干網(wǎng)上的RSVP消息當然就會(huì )被忽略，所以我們的PATH和SESV消息都要實(shí)現對Diffserv的映射，換一句話(huà)來(lái)說(shuō)，就地讓骨干網(wǎng)看起來(lái)象RSVP的一個(gè)節點(diǎn)，一般來(lái)說(shuō)我們把AdSpec中的DTOT最小路徑延遲（或者說(shuō)是子網(wǎng)絡(luò )到主干網(wǎng)絡(luò )的傳播延遲
在RFC2205中有定義）改變成透過(guò)骨干網(wǎng)的傳播延遲和平均排隊延遲的值（這個(gè)是由主干網(wǎng)羅入口/出口路由器做的工作）這個(gè)近似的方式一般來(lái)說(shuō)是有效的，因為骨干網(wǎng)絡(luò )失效的機會(huì )畢竟比較小，如果主干網(wǎng)絡(luò )是千兆路由器，那么每條PATH消息是可以在中繼段上更新的。
返回RESV消息的時(shí)候，對于分類(lèi)服務(wù)而言，并不是將每個(gè)相對應的RSVP操作定義一個(gè)單獨的隊列，對于骨干網(wǎng)絡(luò )路由器是不現實(shí)的，只能相對服務(wù)等級接近的安排在最相近的隊列中。
另外有幾個(gè)情況是在如果主干網(wǎng)絡(luò )使用DiffSev需要注意的：
a. 如果有一個(gè)流不符合Tspec時(shí)——而這個(gè)時(shí)候路由器已經(jīng)為所有的入口和出口規劃了每一條虛鏈路的時(shí)候，一個(gè)不符合Tspec的流就足以毀壞同一類(lèi)別所有其他留所爭取的服務(wù)質(zhì)量，例如入口處歸納低質(zhì)量的視頻/音頻流時(shí)候，出現了高質(zhì)量的視頻流。
b. 分散的/突發(fā)的流合并到平緩的流中時(shí)候。
不過(guò)一般來(lái)說(shuō)每個(gè)路由器都具備檢查流的Tspec的能力，特別是作為主干網(wǎng)絡(luò )入口的路由器（例如一些大的網(wǎng)絡(luò )（BGP/EBGP）的入/出口地方）。在運行視頻會(huì )議或者是其他突發(fā)流很多的惡劣工作狀況的時(shí)候。
7. 修改Vocal的SIP協(xié)議棧來(lái)更好的實(shí)現RSVP：
我們前面已經(jīng)反復地闡述：在Vocal中只不過(guò)是實(shí)現了一個(gè)簡(jiǎn)單RSVP構架，最重要的一點(diǎn)就是它不能夠實(shí)現軟狀態(tài)，也就是定期刷新消息的Tspec和Rspec，如果在傳輸視頻信號的時(shí)候這樣的情況出現得特別頻繁，由于視頻信號并不總是處于一種穩定的平緩的狀態(tài)傳輸，另外當路由改變的時(shí)刻，RSVP消息需要能準確的沿著(zhù)新的路由往復（這種情況是可能出現的，特別在大型網(wǎng)絡(luò )中）。
解決上述問(wèn)題的途徑首先就是要在RSVP建立保證服務(wù)預定，也就是要根據接收端根據發(fā)送端的AdSpec消息計算預留的帶寬（而在Vocal中基本上沒(méi)有處理AdSpec），AdSpec中參加帶寬運算的主要是兩個(gè)參數：Dtot和Ctot，第一個(gè)參數是最小路徑延遲，第二個(gè)是路徑帶寬，通過(guò)這兩個(gè)參數根據公式D=(b(存儲桶深度)+Ctot)/p
+ Dtot計算出端到端之間的延遲:
例如：
PATH流的初始特征：
Tspec(p=10mbps,L=2kbps,r=1mbps,b=32kbps) AdSpec(Ctot=0,Dtot=0)
經(jīng)過(guò)第一個(gè)路由器：
Tspec(p=10mbps,L=2kbps,r=1mbps,b=32kbps) AdSpec(Ctot=11,Dtot=0.05s)
經(jīng)過(guò)第二個(gè)路由器：
Tspec(p=10mbps,L=2kbps,r=1mbps,b=32kbps) AdSpec(Ctot=55,Dtot=0.1s)
現在我們來(lái)計算Resv中Rspec項目：
最長(cháng)的延遲為0.1s的延遲，我們在Rspec中所計算的預留帶寬必須符合這個(gè)要求，那么根據公式：
D=(b+Ctot)/p + Dtot
b：存儲桶深度
計算出的D為0.185S我們在根據這個(gè)公式來(lái)計算預留帶寬
R=((p-r)（L+Ctot）+(b-L)p)/((t-Dtot)(p-r)+b-L)
r:業(yè)務(wù)流量
t:所需要的延遲
注意：所需要的延遲在0.1-0.185之間變化，這樣我們通過(guò)上述公式得出一個(gè)比較確切的R值R=1.66Mbps。所以Rspec為：R=1.66Mbps;松弛項(S)：用于指示Qos的富裕量,如果所有的路由器按照R預留，那么整個(gè)路徑上的端到端的延遲會(huì )比要求的時(shí)延要少5毫秒：這里可以選擇0.05S，也就是說(shuō)有一個(gè)比較寬余的帶寬，可以實(shí)現其他的數據傳輸，或者是讓當前的媒體數據實(shí)現盡力傳輸，具體的松弛項計算可以參看RFC2205定義。
上面我們解決了服務(wù)預定的問(wèn)題，但是它只不過(guò)讓我們的終端程序運行進(jìn)一步合理化，可以正確的規劃需要預留的帶寬，但是中間還是有關(guān)鍵問(wèn)題沒(méi)有解決，也就是我們上面說(shuō)的軟狀態(tài)——定期刷新Tspec和Rspec，以及探測/感知主干路由的變化
從程序上實(shí)現這些事實(shí)上并不困難，我們在打開(kāi)媒體通訊的RTP信道以后，可以用一個(gè)進(jìn)程定期的發(fā)送PATH和RESV消息，讓流的接收者進(jìn)行定期刷新，特別是在視頻通訊階段（采用H.263算法）出現幀間幀的時(shí)候，數據的流量必然會(huì )大大增加，這個(gè)時(shí)候，如果提前刷新預留的狀態(tài)，那么我們可以在初期就避免網(wǎng)絡(luò )出現阻塞的問(wèn)題，當然，如果流量超過(guò)了路徑所承受的標準，那么必然會(huì )依靠侵占S（松弛度）來(lái)發(fā)送數據包，如果超過(guò)了帶寬許可，這個(gè)時(shí)候，必然通訊會(huì )出現一個(gè)比較明顯的延遲，不過(guò)根據實(shí)驗結果表明，這些還是可以接受的。
如果IP路由發(fā)生了變化，那么上述的解決辦法同樣的適用，定期傳送RSVP的消息可以重新根據流的路徑進(jìn)行新的定義，所以他們也會(huì )沿著(zhù)新的路徑進(jìn)行傳輸，所以沿著(zhù)相反路徑的RESV消息將試圖沿著(zhù)新的路由進(jìn)行預定，舊的預定就會(huì )超時(shí)然后取消。
但是我們如果考慮到主干網(wǎng)絡(luò )使用DiffServ就不會(huì )那么樂(lè )觀(guān)了（當然主干網(wǎng)絡(luò )的路由變化不會(huì )那么劇烈），主干網(wǎng)絡(luò )上PATH項目中變化的部分就是AdSpec中的Dtot/Ctot，我們在上面已經(jīng)說(shuō)了如何定義Dtot的內容（子網(wǎng)絡(luò )到主干網(wǎng)絡(luò )的傳播延遲的計算
在RFC2205中有定義）改變成透過(guò)骨干網(wǎng)的傳播延遲和平均排隊延遲的值，正如上面所說(shuō)的，如果主干網(wǎng)絡(luò )是功能強大的千兆路由器組成，那么PATH中的Dtot和Ctot可以在中繼的時(shí)候得到更新，如果是ATM或者是MPLS網(wǎng)絡(luò )的話(huà)，出入口也可以得到更新，這樣的話(huà)你事實(shí)上完全不必操心。
8．一些其他的設想：
不過(guò)不管怎么說(shuō)上述的數值如果是周期性計算并在RESV消息中更新的話(huà)，必然大大的加大路由器的運算開(kāi)銷(xiāo)，特別在跨洋多點(diǎn)視頻會(huì )議的時(shí)候，這樣用戶(hù)接入服務(wù)供應商區域網(wǎng)入口路由器可能會(huì )發(fā)生“餓死”的情況（沒(méi)有用戶(hù)媒體數據時(shí)候反而被大量無(wú)用的RSVP消息所淹沒(méi)），所以在使用主干網(wǎng)絡(luò )的時(shí)候，我們考慮必須有一個(gè)機制探測主干網(wǎng)絡(luò )的傳播延遲并且通報給服務(wù)供應商區域網(wǎng)入口路由器，這個(gè)對于入口路由器并不使什么難事，最好是主干入口路由器本身就具備這樣的功能，進(jìn)一步簡(jiǎn)化主干網(wǎng)絡(luò )為一個(gè)簡(jiǎn)單的RSVP節點(diǎn)，變成由主干網(wǎng)絡(luò )的接入路由器通告服務(wù)供應商的路由器端對端的延遲
，這樣把計算的過(guò)程交給主干路由器，而服務(wù)供應商區域網(wǎng)入口路由器只負責更新AdSpec，對于用戶(hù)來(lái)說(shuō)，并不需要設定AdSpec,也就是可以讓AdSpec為空，這樣效率就可以得到大大的提高，代價(jià)就是增加了協(xié)議復雜性。
9．Vocal中采用策略服務(wù)器來(lái)管理QoS：
在H.323和SIP等大型的通訊協(xié)議中實(shí)現QoS的保證的確不是一個(gè)小的問(wèn)題，和普通的傳輸服務(wù)協(xié)議所不同，H.323和SIP的傳遞數據都有著(zhù)非常明顯的延遲和速率敏感特性，在建立一個(gè)大型的視頻會(huì )議/IP網(wǎng)絡(luò )電話(huà)系統的時(shí)候需要有專(zhuān)門(mén)的設備來(lái)管理和保證QoS，在Vocal系統中實(shí)現這個(gè)的設備是PoS
Server(Policy Server),它使用了OSP和COPS(Common Open Policy Service)協(xié)議。可以和路由器之間傳遞消息,PoS的工作流程非常簡(jiǎn)單，當代理服務(wù)器轉遞180
/183的振鈴消息時(shí)（也就是被叫發(fā)送PATH消息前），發(fā)送一個(gè)COPS消息給PoS，同時(shí)被叫發(fā)送PATH消息到路由器上，路由器產(chǎn)生一個(gè)COPS-Request消息給PoS，以便確定用戶(hù)的帶寬申請授權，如果授權合法校驗通過(guò)的話(huà)，PoS回送一個(gè)COPS-Decision到被叫端的路由器上，同樣在主叫端的路由器回送RESV消息的時(shí)候也會(huì )向PoS進(jìn)行同樣操作。
作者供稿 CTI論壇編輯
相關(guān)鏈接:
亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩
元氏县|
游戏|
大安市|
内乡县|
延庆县|
临朐县|
界首市|
依安县|
澄城县|
那坡县|
西丰县|
襄城县|
铁岭市|
团风县|
吉木乃县|
车险|
佳木斯市|
静海县|
分宜县|
沅江市|
九江市|
龙州县|
浦县|
平利县|
吉木萨尔县|
天柱县|
阜康市|
托克逊县|
岫岩|
红河县|
福海县|
韶关市|
全南县|
清水县|
遂溪县|
如皋市|
吴忠市|
阜新|
穆棱市|
阿克陶县|
甘南县|
http://444
http://444
http://444
http://444
http://444
http://444