SIP網頁呼叫擴展系統研究與設計

劉孫云，龍昭華，張 林

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

0 引言

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

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

1 SIP協議和Sliverlight技術分析

1.1 SIP協議分析

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

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

1.2 Silverlight分析

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

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

因此在網頁呼叫系統中需要通過服務器來對呼叫頁面與SIP客戶端之間進行消息以及通信數據的轉換。

2 系統設計

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

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

圖1 網頁呼叫系統部署

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

呼叫頁面與Web SIP代理服務器通信，由Web SIP代理服務器對消息以及音視頻數據進行轉化后傳遞給SIPUA。同樣，SIP UA與呼叫頁面通信的內容也需要通過Web SIP代理服務器進行處理后再轉發。Web SIP代理服務器通過建立多個處理線程來實現呼叫頁面與SIP UA多對多通信。其對應的軟件結構如圖2所示。

圖2 網頁呼叫系統軟件結構

3 網頁與Web SIP代理服務器通信協議設計

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

表1 網頁與Web SIP代理服務器通信協議

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

具體的網頁呼叫協議通信過程如圖3所示。

圖3 網頁呼叫過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 系統負載均衡設計

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

服務器負載均衡算法主要分為靜態算法和動態算法［11］。靜態負載均衡算法如轉輪算法，它不考慮后臺服務器執行的負載情況，僅按照預先設定的決策來進行任務的分配。動態負載均衡算法則是根據系統當前的負載情況動態分發請求，如最小連接調度算法等。

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

5.1 負載均衡設計

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

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

5.1.1 負載描述

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

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

5.1.2 負載更新

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

圖6 負載更新通信過程

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

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

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

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

5.1.3 負載均衡

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

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

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

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

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

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

5.2.1 負載更新性能比較

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

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

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

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

5.2.2 負載均衡算法比較

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

經實際測試發現，在系統服務強度較小時，兩種算法的應答時延相近，最小連接算法比改進算法連接數方差性能會略小。隨著服務強度的不斷增大，兩種算法的應答時延仍較為相近，而改進算法的連接數方差則會比最小連接算法小。

6 結束語

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

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

［2］LI Huijun.Silverlight 2 perfect journey［M］.Beijing:Electronic Industry Press，2009:86-103(in Chinese).［李會軍.Silverlight2完美征程 ［M］.北京:電子工業出版社，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).［黃永峰.下一代網絡核心控制協議: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網絡和通信［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).［張昊，廖建新，朱曉民.增強型動態反饋隨機分發負載均衡算法 ［J］.計算機工程，2007，33(4):97-99.］