劉孫云，龍昭華，張 林

(重慶郵電大學計算機科學與技術學院，重慶400065)

0 引言

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

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

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

1.1 SIP協(xié)議分析

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

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

1.2 Silverlight分析

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

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

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

2 系統(tǒng)設計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 多臺Web SIP代理服務器獨立提供服務

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

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

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

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

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

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

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

5 系統(tǒng)負載均衡設計

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

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

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

5.1 負載均衡設計

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

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

5.1.1 負載描述

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

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

5.1.2 負載更新

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

圖6 負載更新通信過程

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

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

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

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

5.1.3 負載均衡

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

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

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

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

5.2 負載均衡算法測試與比較

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

5.2.1 負載更新性能比較

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

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

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

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

5.2.2 負載均衡算法比較

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

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

6 結(jié)束語

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

［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］.北京:北京郵電大學，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)絡核心控制協(xié)議:SIP及其應用［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)絡和通信［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］.北京:北京郵電大學出版社，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).［張昊，廖建新，朱曉民.增強型動態(tài)反饋隨機分發(fā)負載均衡算法 ［J］.計算機工程，2007，33(4):97-99.］