劉孫云，龍昭華，張 林

(重慶郵電大學(xué)計算機(jī)科學(xué)與技術(shù)學(xué)院，重慶400065)

0 引言

大多數(shù)的網(wǎng)站僅提供內(nèi)容的瀏覽，不提供或只提供簡單的留言功能給網(wǎng)站瀏覽者。少數(shù)的網(wǎng)站提供即時消息交互，對于音視頻的交互則少之又少。如果能夠在網(wǎng)站上提供音視頻、即時通訊等交互業(yè)務(wù)，將可以極大的豐富網(wǎng)站的功能，同時可以為網(wǎng)站瀏覽者提供便利的咨詢交流平臺。目前提供的網(wǎng)頁呼叫服務(wù)，多為網(wǎng)頁與其他通話系統(tǒng)如GSM(global system of mobile communication)網(wǎng)絡(luò)之間的呼叫連接［1］或者是網(wǎng)頁之間的呼叫。而針對廣泛應(yīng)用的SIP(session initiation protocol)通話系統(tǒng)的網(wǎng)頁呼叫擴(kuò)展卻很少。所以針對SIP通話系統(tǒng)進(jìn)行網(wǎng)頁功能擴(kuò)展就可以讓很多已經(jīng)采用SIP通話系統(tǒng)的公司在不需要修改原有系統(tǒng)的基礎(chǔ)上實現(xiàn)支持網(wǎng)頁呼叫功能。而目前使得網(wǎng)頁支持多媒體功能的插件主要包含:ActiveX、Flash和 Silverlight。其中Silverlight以及是微軟推出的一種跨瀏覽器、跨平臺的RIA(rich internet application)開發(fā)技術(shù)，具有極其優(yōu)越的矢量圖形、動畫和多媒體支持的能力，內(nèi)置支持豐富的網(wǎng)絡(luò)通信功能［2］。并且在Silverlight 4版本中還添加了對麥克風(fēng)和攝像頭的支持。

本文描述了通過Silverlight 4來實現(xiàn)網(wǎng)頁呼叫頁面，并結(jié)合SIP通信系統(tǒng)的特點進(jìn)行設(shè)計，使得新的功能擴(kuò)展系統(tǒng)在不修改原SIP系統(tǒng)的基礎(chǔ)上提供網(wǎng)頁呼叫服務(wù)。從而提高網(wǎng)頁呼叫系統(tǒng)的對一般的SIP系統(tǒng)的兼容性。結(jié)合排隊論對系統(tǒng)的服務(wù)器組織進(jìn)行分析，從而確定系統(tǒng)服務(wù)器之間關(guān)系。對于多服務(wù)器之間的負(fù)載均衡和本文設(shè)計的系統(tǒng)，提出具體的系統(tǒng)部署方案以及多個服務(wù)器下負(fù)載均衡算法，使得系統(tǒng)具有較強(qiáng)的性能和穩(wěn)定性。

1 SIP協(xié)議和Sliverlight技術(shù)分析

1.1 SIP協(xié)議分析

SIP是IETF(internet engineering task force)提出的一套多媒體IP的體系結(jié)構(gòu)。SIP協(xié)議主要是為了解決在IP網(wǎng)中信令的控制，以及與軟交換機(jī)的通信，從而構(gòu)成新一代的通信平臺［3］。SIP用戶使用類似于E-mail的統(tǒng)一資源定位器 (URL)來標(biāo)識自己，并通過注冊服務(wù)器、重定向服務(wù)器和代理服務(wù)器等來完成用戶的注冊、定位以及呼叫處理［4］。還可以通過 SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)協(xié)議簇對SIP協(xié)議進(jìn)行了擴(kuò)展，以使其支持 IM服務(wù)［5］。通過 SIMPLE中的 Presence Server可以完成對好友狀態(tài)的訂閱。

因此可以在網(wǎng)頁呼叫系統(tǒng)中使用一個服務(wù)器用于存儲原SIP通話系統(tǒng)中對外提供在線服務(wù)的用戶的URL。并且通過Presence Server訂閱這些用戶的狀態(tài)信息來控制網(wǎng)頁呼叫連接的對象。

1.2 Silverlight分析

Silverlight是微軟所發(fā)展的Web前端應(yīng)用程序開發(fā)解決方案，是微軟RIA策略的主要應(yīng)用程序開發(fā)平臺之一，提供Web應(yīng)用程序中多媒體與高度交互性前端應(yīng)用程序的解決方案［6］。Silverlight提供了豐富的與服務(wù)器端通信能力。目前 Silverlight支持直接使用套接字，以及 HttpHandler、WebServices等多種應(yīng)用層協(xié)議，還可以通過WCF RIA Service數(shù)據(jù)“透明”訪問方式快速實現(xiàn)實體通信［7］。

但由于安全原因限制，在Silverlight 4的套接字中僅提供TCP和UDP多播支持［8］。而通常情況下，SIP客戶端部分采用UDP進(jìn)行通信，并使用RTP(real-time transport protocol)協(xié)議來保證音視頻信息的流暢與實時［9］。這使得呼叫頁面無法直接與SIPUA進(jìn)行連接通信。

因此在網(wǎng)頁呼叫系統(tǒng)中需要通過服務(wù)器來對呼叫頁面與SIP客戶端之間進(jìn)行消息以及通信數(shù)據(jù)的轉(zhuǎn)換。

2 系統(tǒng)設(shè)計

基于上述的分析，本文設(shè)計實現(xiàn)了Web SIP代理服務(wù)器。該服務(wù)器用于控制和管理對Web提供在線服務(wù)的SIP用戶列表，并且為Web呼叫客戶端提供消息以及傳輸數(shù)據(jù)轉(zhuǎn)換服務(wù)。

所以在網(wǎng)頁呼叫系統(tǒng)中邏輯上至少需要兩個服務(wù)器:一個是用于發(fā)布呼叫頁面的Web Server，另一個是Web SIP代理服務(wù)器。用戶通過瀏覽網(wǎng)站進(jìn)入呼叫頁面，點擊呼叫按鈕建立呼叫。Web SIP代理服務(wù)器通過Presence Server訂閱客服的狀態(tài)信息并存儲起來，當(dāng)有網(wǎng)頁呼叫請求時再具體安排該請求與哪個客服進(jìn)行連接。如果原系統(tǒng)中不存在Presence Server，則Web SIP代理服務(wù)器不訂閱用戶狀態(tài)，直接事先存儲客戶列表信息。當(dāng)有呼叫請求時直接對客服列表進(jìn)行遍歷并呼叫來查找空閑客服。從而實現(xiàn)了在不修改原SIP通話系統(tǒng)的基礎(chǔ)上添加網(wǎng)頁呼叫服務(wù)。整個網(wǎng)頁呼叫系統(tǒng)的部署如圖1所示。

圖1 網(wǎng)頁呼叫系統(tǒng)部署

由于安全原因限制使得采用Silverlight 4實現(xiàn)的呼叫頁面無法直接與SIP UA(user agent)進(jìn)行連接通信。因此Web SIP代理服務(wù)器中還需要分別實現(xiàn)與呼叫頁面的通信、與SIP UA的通信以及通信內(nèi)容的轉(zhuǎn)換。

呼叫頁面與Web SIP代理服務(wù)器通信，由Web SIP代理服務(wù)器對消息以及音視頻數(shù)據(jù)進(jìn)行轉(zhuǎn)化后傳遞給SIPUA。同樣，SIP UA與呼叫頁面通信的內(nèi)容也需要通過Web SIP代理服務(wù)器進(jìn)行處理后再轉(zhuǎn)發(fā)。Web SIP代理服務(wù)器通過建立多個處理線程來實現(xiàn)呼叫頁面與SIP UA多對多通信。其對應(yīng)的軟件結(jié)構(gòu)如圖2所示。

圖2 網(wǎng)頁呼叫系統(tǒng)軟件結(jié)構(gòu)

3 網(wǎng)頁與Web SIP代理服務(wù)器通信協(xié)議設(shè)計

為了便于網(wǎng)頁與Web SIP代理服務(wù)器通信和控制，需要為其設(shè)計專門用于呼叫網(wǎng)頁與Web SIP代理服務(wù)器之間通信的協(xié)議。參考已有的SIP協(xié)議，設(shè)計出針對網(wǎng)頁呼叫的協(xié)議。專用的網(wǎng)頁呼叫協(xié)議采用XML進(jìn)行描述，從而便于網(wǎng)頁和Web SIP代理服務(wù)器解析和生成。其中具體協(xié)議設(shè)計見表1。

表1 網(wǎng)頁與Web SIP代理服務(wù)器通信協(xié)議

由于呼叫頁面采用TCP與Web SIP代理服務(wù)器進(jìn)行通信，所以當(dāng)Web SIP代理服務(wù)器發(fā)現(xiàn)與呼叫頁面連接的TCP由于其他原因斷開或者是呼叫頁面長時間沒有方法相應(yīng)的消息，則默認(rèn)為網(wǎng)頁呼叫中斷。Web SIP代理服務(wù)器將通知SIP UA結(jié)束網(wǎng)頁呼叫。

具體的網(wǎng)頁呼叫協(xié)議通信過程如圖3所示。

圖3 網(wǎng)頁呼叫過程

(1)SIP通話系統(tǒng)中的所有用戶通過向Presence Server提交自己當(dāng)前的狀態(tài)。

(2)Web SIP代理服務(wù)器向Presence Server訂閱SIP通話系統(tǒng)中客服的狀態(tài)并將獲得的信息存儲在列表中以備網(wǎng)頁呼叫連接使用。在系統(tǒng)運行過程中，Web SIP代理服務(wù)器還需要定時的向Presence Server查詢訂閱客服的狀態(tài)，以保證列表中信息的有效。

(3)當(dāng)呼叫頁面請求建立連接時，頁面會發(fā)送一個請求消息Web Call給Web SIP代理服務(wù)器。

(4)服務(wù)器在接收到該消息后，將頁面請求信息保存并生成相應(yīng)的INVITE消息發(fā)給SIP UA。

(5)SIP UA收到INVITE后回復(fù)Web SIP代理服務(wù)器Ringing振鈴消息。

(6)Web SIP代理服務(wù)器接收到Ringing消息后發(fā)送一個等待消息Wait給呼叫頁面。

(7)呼叫頁面將提示用戶進(jìn)行等待。

(8)當(dāng)SIP UA接通連接后會發(fā)送200 OK消息給Web SIP代理服務(wù)器。

(9)Web SIP代理服務(wù)器處理后轉(zhuǎn)發(fā)給呼叫頁面。

(10)如果此時呼叫頁面仍然存在，則會回復(fù)一條ACK確認(rèn)消息。

(11)Web SIP代理服務(wù)器轉(zhuǎn)發(fā)該消息給SIP UA，至此呼叫連接建立成功。

Web SIP代理服務(wù)器如果在一定時間內(nèi)沒有收到呼叫頁面返回的確認(rèn)消息，則認(rèn)為此次呼叫停止，其將發(fā)送BYE該SIP UA取消。網(wǎng)頁呼叫建立成功以后，呼叫頁面通過TCP與Web SIP代理服務(wù)器交互數(shù)據(jù)，而SIP UA則采用RTP協(xié)議與Web SIP代理服務(wù)器進(jìn)行數(shù)據(jù)傳輸。當(dāng)呼叫頁面點擊掛機(jī)后會發(fā)送一個斷開通話消息End Call到Web SIP代理服務(wù)器，Web SIP代理服務(wù)器發(fā)送BYE消息給SIP UA斷開整個通話過程。

4 多臺Web SIP代理服務(wù)器組織方案選擇

由于呼叫頁面采用TCP與Web SIP代理服務(wù)器進(jìn)行通信，所以Web SIP代理服務(wù)器的承載量可能受限。因此在實際運營時可能就需要多臺Web SIP代理服務(wù)器提供服務(wù)。然而如何安排Web SIP代理服務(wù)器之間的關(guān)系會影響到系統(tǒng)的性能和承載量。采用排隊論對可能采用的服務(wù)器組織方案進(jìn)行分析對比。

4.1 多臺Web SIP代理服務(wù)器獨立提供服務(wù)

由于每臺Web SIP代理服務(wù)器相對于其他臺服務(wù)器都是獨立的。則當(dāng)采用多臺Web SIP代理服務(wù)器分別提供服務(wù)的話，那么每個Web SIP代理服務(wù)器可以看作一個M/M/1/∞排隊模型。整個系統(tǒng)則是一個 S個獨立的M/M/1/∞ 模型排隊，如圖4所示。

4.2 采用負(fù)載均衡服務(wù)器進(jìn)行調(diào)度多臺Web SIP代理服務(wù)器

該方案下采用負(fù)載均衡服務(wù)器進(jìn)行調(diào)度，在不考慮負(fù)載均衡服務(wù)器的均衡算法優(yōu)劣的情況下。假設(shè)每個呼叫接入都能公平合理的進(jìn)行安排。則整個系統(tǒng)可以看作是一個M/M/S/∞的排隊模型。其中S表示系統(tǒng)含有的服務(wù)器數(shù)量。如圖5所示。

4.3 比較兩種組織方案的性能

由于系統(tǒng)是用于處理用戶呼叫連接，所以在系統(tǒng)優(yōu)劣方面更多是考慮給用戶提供的服務(wù)質(zhì)量以及系統(tǒng)資源的利用程度。為了便于比較，假設(shè)系統(tǒng)中含有5個Web SIP代理服務(wù)器，用戶發(fā)出呼叫請求服從Poisson流，平均到達(dá)率為0.9人/分鐘，呼叫服務(wù)時間服從負(fù)指數(shù)分布，平均服務(wù)率為0.5人/分鐘 。結(jié)合已有的排隊論模型公式［10］可以得到兩種不同組織方案下系統(tǒng)性能的對比表格見表2。

表2 不同組織方案性能對比

通過上表的對比可以看出采用負(fù)載均衡服務(wù)器的系統(tǒng)比不采用負(fù)載均衡服務(wù)器的系統(tǒng)的資源利用率高且用戶排隊時長短。其主要原因是采用負(fù)載均衡服務(wù)器以后，用戶的請求可以在各個服務(wù)器之間進(jìn)行調(diào)度調(diào)整，而不是只在一個服務(wù)器上進(jìn)行等待。所以在構(gòu)建系統(tǒng)時需要負(fù)載均衡服務(wù)器進(jìn)行調(diào)度呼叫連接。

5 系統(tǒng)負(fù)載均衡設(shè)計

系統(tǒng)采用負(fù)載均衡服務(wù)器進(jìn)行具體呼叫的調(diào)度，用戶通過網(wǎng)頁發(fā)送呼叫請求到負(fù)載均衡服務(wù)器，服務(wù)器根據(jù)均衡算法確定呼叫連接的Web SIP服務(wù)器之后給呼叫頁面發(fā)送重定向Redirect消息。之后呼叫頁面將斷開與負(fù)載均衡服務(wù)器的連接轉(zhuǎn)向與安排的Web SIP服務(wù)器連接并建立呼叫。負(fù)載均衡服務(wù)器承擔(dān)了整個系統(tǒng)資源的分配以及調(diào)度。而其核心在于其所采用的負(fù)載均衡算法。該算法必須合理的分配呼叫連接到Web SIP代理服務(wù)器上，從而使得整個系統(tǒng)負(fù)載平衡，提高系統(tǒng)的處理能力和服務(wù)質(zhì)量。

服務(wù)器負(fù)載均衡算法主要分為靜態(tài)算法和動態(tài)算法［11］。靜態(tài)負(fù)載均衡算法如轉(zhuǎn)輪算法，它不考慮后臺服務(wù)器執(zhí)行的負(fù)載情況，僅按照預(yù)先設(shè)定的決策來進(jìn)行任務(wù)的分配。動態(tài)負(fù)載均衡算法則是根據(jù)系統(tǒng)當(dāng)前的負(fù)載情況動態(tài)分發(fā)請求，如最小連接調(diào)度算法等。

由于靜態(tài)負(fù)載均衡算法不能很好的根據(jù)系統(tǒng)的情況調(diào)整算法策略，所以本文在設(shè)計算法時考慮采用動態(tài)負(fù)載均衡算法。然而由于系統(tǒng)是用于提供呼叫服務(wù)，所以用戶的通話時間存在較大差異。導(dǎo)致采用已有的動態(tài)負(fù)載均衡算法將出現(xiàn)負(fù)載均衡服務(wù)器所知的負(fù)載情況與實際情況相差較大。容易造成負(fù)載分配上的不均衡。所以必須結(jié)合系統(tǒng)的特點進(jìn)行負(fù)載均衡算法的設(shè)計。

5.1 負(fù)載均衡設(shè)計

在動態(tài)調(diào)整策略中主要分為集中式調(diào)度策略和分布式調(diào)度策略。集中式調(diào)度是由一個中心服務(wù)器從系統(tǒng)中其他服務(wù)器收集負(fù)載信息然后進(jìn)行決策。而分布式調(diào)度策略則是通過每個服務(wù)器發(fā)送自己負(fù)載變化情況給所有的服務(wù)器或者鄰居實現(xiàn)。結(jié)合系統(tǒng)的特點和網(wǎng)絡(luò)拓?fù)?，本文采用以?fù)載均衡服務(wù)器為處理中心的集中式調(diào)度策略。

在負(fù)載均衡設(shè)計過程中包含三個重要部分:負(fù)載描述、負(fù)載更新和負(fù)載均衡算法。其中負(fù)載描述是系統(tǒng)對于負(fù)載的定義。負(fù)載更新是負(fù)載均衡服務(wù)器上具體服務(wù)器的負(fù)載信息的更新方法。而負(fù)載均衡算法則是負(fù)載均衡服務(wù)器決定負(fù)載分配的算法。

5.1.1 負(fù)載描述

負(fù)載描述是系統(tǒng)對負(fù)載的定義。常用的負(fù)載描述包括:服務(wù)器連接數(shù)和服務(wù)器性能參數(shù)。服務(wù)器連接數(shù)描述是通過服務(wù)器已與用戶建立連接數(shù)目為該服務(wù)器負(fù)載的刻畫。使用連接數(shù)表示服務(wù)器負(fù)載具有簡單易獲得等優(yōu)點。但是如果用戶需要的服務(wù)消耗不同則無法從連接數(shù)上區(qū)別開來，也無法準(zhǔn)確獲知服務(wù)器當(dāng)前負(fù)載狀態(tài)。使用服務(wù)器性能參數(shù)如CPU使用率、內(nèi)存使用率、磁盤I/O使用率、帶寬以及進(jìn)程數(shù)目等來描述服務(wù)器負(fù)載可以很好的體現(xiàn)服務(wù)器當(dāng)前工作情況以及負(fù)載強(qiáng)度。但是采用這種描述運算復(fù)雜，消耗比連接數(shù)描述大。

由于本系統(tǒng)用于提供網(wǎng)頁呼叫服務(wù)，相對于其他服務(wù)系統(tǒng)不同之處在于系統(tǒng)為每個用戶提供的服務(wù)的工作強(qiáng)度幾乎相同。所以相比之下采用連接數(shù)作為系統(tǒng)負(fù)載描述可以在保證較為準(zhǔn)確描述系統(tǒng)負(fù)載強(qiáng)度的情況下，降低系統(tǒng)的運算量。

5.1.2 負(fù)載更新

由于采用集中式調(diào)度策略，所以負(fù)載均衡服務(wù)器必須通過負(fù)載更新方法獲得下屬服務(wù)器的具體負(fù)載，從而為正確的負(fù)載均衡決策做準(zhǔn)備。可知，負(fù)載更新方法將直接影響負(fù)載均衡服務(wù)器對系統(tǒng)當(dāng)前狀況的了解。所以負(fù)載更新方法應(yīng)該盡可能的使得負(fù)載均衡服務(wù)器獲取最準(zhǔn)確的服務(wù)器負(fù)載信息。而且要盡可能的通信少和算法簡單，以減少系統(tǒng)在負(fù)載更新上的消耗。如圖6所示。

圖6 負(fù)載更新通信過程

通常集中式調(diào)度策略使用定時查詢方式來獲取各個下屬服務(wù)器的負(fù)載。即負(fù)載均衡服務(wù)器定時發(fā)送查詢請求給每個下屬服務(wù)器，下屬服務(wù)器在獲得查詢消息后返回當(dāng)前服務(wù)器的負(fù)載信息。然而這種方式存在缺點:如果定時時長較長，則負(fù)載均衡服務(wù)器得知的負(fù)載信息與實際負(fù)載信息差別將很大，從而影響后續(xù)負(fù)載均衡算法的準(zhǔn)確;如果定時時長較短，雖使得負(fù)載信息較為準(zhǔn)確，但將大大增加系統(tǒng)的通信開銷以及性能消耗。

由系統(tǒng)負(fù)載均衡服務(wù)器工作流程可以知道，每一個Web SIP代理服務(wù)器上的連接都是由負(fù)載均衡服務(wù)器轉(zhuǎn)接過去。所以負(fù)載均衡服務(wù)器可以得知每個Web SIP代理服務(wù)器上目前的負(fù)載最大值。由于用戶斷開呼叫并未通知負(fù)載均衡服務(wù)器，所以其不知道具體的有多少呼叫連接已斷開。

因此可以結(jié)合系統(tǒng)的工作流程進(jìn)行定時查詢方法的改進(jìn)。負(fù)載均衡服務(wù)器維護(hù)一個定時器和下屬Web SIP代理服務(wù)器的連接列表。定時器負(fù)責(zé)定時通知負(fù)載均衡服務(wù)器發(fā)送查詢消息給下屬服務(wù)器。而連接列表用于記錄下屬Web SIP代理服務(wù)器的連接個數(shù)。當(dāng)經(jīng)過算法計算確定用戶呼叫請求與某個Web SIP代理服務(wù)器連接后，負(fù)載服務(wù)器在發(fā)送重定向Redirect消息給呼叫頁面的同時，對相應(yīng)連接列表中的值進(jìn)行加一。

采用該方式進(jìn)行負(fù)載更新能夠比常用的定時詢問在相同的通信量下的方式準(zhǔn)確率高，能夠適合服務(wù)時間差別較大的情況。

5.1.3 負(fù)載均衡

雖然在本系統(tǒng)中采用了改進(jìn)的負(fù)載更新方法，但是其獲取的值與實際負(fù)載值仍存在誤差。并且由于系統(tǒng)采用用戶連接數(shù)來描述服務(wù)器負(fù)載，與實際負(fù)載仍存在誤差。所以在負(fù)載均衡算法中可以通過采用隨機(jī)策略來提高系統(tǒng)的性能。

對于每個新來的呼叫請求:

根據(jù)均勻分布生成隨機(jī)數(shù)，如果該隨機(jī)數(shù)分布于Pi所對應(yīng)的概率空間內(nèi)，則將請求分配給第i臺服務(wù)器。

(3)修改連接列表對應(yīng)值Li=Li+1。

5.2 負(fù)載均衡算法測試與比較

本文設(shè)計的負(fù)載均衡算法主要是在負(fù)載更新和負(fù)載均衡中提出創(chuàng)新，使得負(fù)載均衡服務(wù)器在較少的通信量下能夠獲得較為精確的負(fù)載信息以及能夠通過均衡算法控制下屬服務(wù)器負(fù)載程度相當(dāng)。

5.2.1 負(fù)載更新性能比較

為了驗證負(fù)載更新方法的性能，通過仿真進(jìn)行比較理想狀態(tài)下、普通定時查詢下以及改進(jìn)定時查詢下的性能。以M/M/S/∞排隊模型進(jìn)行模擬系統(tǒng)運行，以下屬服務(wù)器上連接數(shù)的方差為衡量指標(biāo)進(jìn)行仿真。為了便于比較，負(fù)載算法采用最小連接數(shù)方法。

理想狀態(tài)是以下屬服務(wù)器的實際連接數(shù)作為負(fù)載算法依據(jù)。而定時查詢方式和改進(jìn)定時查詢方式都是以500s為時間間隔定時查詢到的下屬服務(wù)器的連接數(shù)為負(fù)載算法依據(jù)。通過仿真獲得仿真數(shù)據(jù)如圖7所示。

按照同樣原理分別測試不同服務(wù)強(qiáng)度下理想狀態(tài)、普通定時調(diào)度以及改進(jìn)定時調(diào)度性能，獲得仿真數(shù)據(jù)如圖8所示。

可以看出采用普通定時調(diào)度的性能波動大，且下屬服務(wù)器連接數(shù)差別均較大。采用改進(jìn)的定時調(diào)度方法性能波動小，下屬服務(wù)器連接數(shù)差值較小。普通定時調(diào)度在服務(wù)強(qiáng)度越高的情況下，各服務(wù)器之間負(fù)載偏差越大。而改進(jìn)定時調(diào)度則較為平穩(wěn)，偏差小。

5.2.2 負(fù)載均衡算法比較

為了驗證算法的性能，對最小連接算法和本文提出的改進(jìn)算法進(jìn)行實際測試。測試設(shè)備包含一臺負(fù)載均衡服務(wù)器，三臺Web SIP服務(wù)器。測試主要指標(biāo)為Web SIP服務(wù)器連接數(shù)方差和用戶請求平均應(yīng)答時延。

經(jīng)實際測試發(fā)現(xiàn)，在系統(tǒng)服務(wù)強(qiáng)度較小時，兩種算法的應(yīng)答時延相近，最小連接算法比改進(jìn)算法連接數(shù)方差性能會略小。隨著服務(wù)強(qiáng)度的不斷增大，兩種算法的應(yīng)答時延仍較為相近，而改進(jìn)算法的連接數(shù)方差則會比最小連接算法小。

6 結(jié)束語

本文介紹了一種兼容性強(qiáng)的SIP網(wǎng)頁呼叫擴(kuò)展系統(tǒng)的設(shè)計與實現(xiàn)。通過網(wǎng)頁呼叫系統(tǒng)可以較好的對在線服務(wù)應(yīng)用提供支持。并且由于其無端性，使得該呼叫部分部署方便。而本文設(shè)計實現(xiàn)的網(wǎng)頁呼叫系統(tǒng)可以快速的在已有的SIP通話系統(tǒng)的基礎(chǔ)上實現(xiàn)網(wǎng)頁呼叫功能的擴(kuò)展且不需要對原系統(tǒng)進(jìn)行修改。但由于Silverlight本身安全限制，只能通過Web SIP代理服務(wù)器進(jìn)行消息以及通信內(nèi)容的轉(zhuǎn)化，增加了服務(wù)器的負(fù)擔(dān)。所以在實際應(yīng)用中需要多臺Web SIP代理服務(wù)器提供服務(wù)。本文通過結(jié)合排隊論模型對系統(tǒng)進(jìn)行分析，確定引入負(fù)載均衡服務(wù)器。并對相應(yīng)的負(fù)載均衡和調(diào)度方法進(jìn)行改進(jìn)，獲得較好的改進(jìn)效果。

［1］JIA Rui.Research of web voice system based on SIP ［D］.Beijing:Beijing University of Posts and Telecommunications，2010(in Chinese).［賈睿.基于SIP的Web語音系統(tǒng)的研究 ［D］.北京:北京郵電大學(xué)，2010.］

［2］LI Huijun.Silverlight 2 perfect journey［M］.Beijing:Electronic Industry Press，2009:86-103(in Chinese).［李會軍.Silverlight2完美征程 ［M］.北京:電子工業(yè)出版社，2009:86-103.］

［3］IETF RFC3261，SIP:Session initiation protocol［S］.

［4］HUANGYongfeng.The core control protocol of next-generation networks:SIP and its application ［M］.Beijing:People＇s posts and Telecommunications Press，2009:3-7(in Chinese).［黃永峰.下一代網(wǎng)絡(luò)核心控制協(xié)議:SIP及其應(yīng)用［M］.北京:人民郵電出版社，2009:3-7.］

［5］IETF RFC3428，SIMPLE:Session initiation protocol(SIP)extension for instant messaging［S］.

［6］Laurence Moroney.Microsoft silverlight 4 step by step［M］.A-merica:Microsoft Press，2010.

［7］Microsoft.Silverlight network and communication ［EB/OL］.［2011-08-21］.http://msdn.microsoft.com/library/cc645029(VS.95).aspx(in Chinese).［Microsoft.Silverlight網(wǎng)絡(luò)和通信［EB/OL］.［2011-08-21］.http://msdn.microsoft.com/library/cc645029(VS.95).aspx.］

［8］Microsoft.Microsoft silverlight 4 offline documentation［M］.A-merica:Microsoft，2011.

［9］IETF RFC1889，RTP:A transport protocol for real-time applications ［S］.

［10］LU Chuanglai.Queueing theory［M］.Beijing:Beijing University of Posts and Telecommunications Press，2009:31-99(in Chinese).［陸傳賚.排隊論 ［M］.北京:北京郵電大學(xué)出版社，2009:31-99.］

［11］ZHANG Hao，LIAO Jianxin，ZHU Xiaoming.Advanced dynamic feedback and random dispatch load-balance algorithm ［J］.Computer Engineering，2007，33(4):97-99(in Chinese).［張昊，廖建新，朱曉民.增強(qiáng)型動態(tài)反饋隨機(jī)分發(fā)負(fù)載均衡算法 ［J］.計算機(jī)工程，2007，33(4):97-99.］