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.］