【IT168技术文档】
会话初始协议(Session Initiation Protocol, SIP)是一种信令协议，用于建立、修改和关闭多媒体会话。SIP并非新概念，和H.323一样，它是VoIP的主导信令协议，由国际工程任务组IETF开发，被认为是继TCP/IP和HTTP后第三个很重要的协议。 WebSphere Application Server从6.1版本开始提供对SIP的全面支持，以满足电信等行业日益多样化的需求。本文主要介绍了WebSphere Application Server 6.1(简称WAS 6.1)如何提供对SIP的支持。首先，介绍SIP的概念、SIP行业背景；其次，介绍WAS 6.1下的SIP集群应用架构及其核心组件：SIP容器和SIP代理服务器；最后，介绍WAS 6.1中SIP的其他组件及功能，包括：SIP Servlet API、聚合应用、SIP应用开发工具、SIP高可用性和故障恢复及SIP问题诊断等。
SIP的概念
在电信网络中，有两种流：
信令控制流——用于建立、修改以及终止会话
实际媒体流——用于传输数据
这两种流是分开、独立的，这样做的好处在于：会话管理更便捷，且更适用于功能变更频繁等需求。
会话初始协议(Session Initiation Protocol, SIP)是一种信令协议，用于建立、修改和关闭多媒体会话。SIP并非新概念，和H.323一样，它是VoIP(Voice over IP)的主导信令协议，由国际工程任务组（Internet Engineering Task Force, IETF)开发，目前支持RFC 3261标准，被认为是继TCP/IP和HTTP之后第三个很重要的协议，是IP多媒体子系统(IP Mulitmedia Subsystem, IMS)架构不可或缺的重要组成部分。
SIP支持以下几种会话管理方式：
User location: 用户能从远程访问电话网络或其他应用。
User availability: 被呼叫方可以选择是否参与会话。
User capability: 用户可以选择会话的媒体类型及其相关参数。
Session setup: 为点对点或多方会话建立会话参数。
Session management: 进行会话管理，包括：建立会话，修改会话参数，转移会话，触发会话服务，终止会话等功能。
SIP会话建立后，传输媒体时媒体流走不同线路。从图1可以看出，SIP通常要跟其他协议一起协同工作，才能完成VoIP等点对点功能和服务。会话描述协议(Session Description Protocol, SDP)定义了会话特征和参数，实时传输协议(Real-time Transport Protocol, RTP)定义了在Internet上传输声音和视频的标准数据包格式，实时传输控制协议(Real-time Transport Control Protocol, RTCP) 严密控制实时传输数据流的质量。
图1：SIP通信栈 
HTTP提供了Web页面内容（文本、声音、图像、连接等）的聚合功能，SIP则是将不同的媒体流集成到会话里。SIP借鉴了HTTP的请求/响应模式、HTTP消息头部和响应码格式（比如：404代表“地址不存在！”），但SIP和HTTP有几点关键的区别：
SIP是点对点协议。使用HTTP时，Web服务器只能响应请求，不能发起请求；但SIP用户代理既可作为客户端发送请求，也可作为服务器端发送响应。
SIP可以为一个请求产生多个响应。
HTTP服务通常驻留在Web服务器上，而SIP的代理服务器，重定向服务器和注册服务器提供了灵活的服务路由机制。
SIP产生的背景及IBM支持SIP的战略
发展下一代网络的目的是充分利用网络资源，尽可能实现性能价格比的最优化。VoIP目前有ITU-T的H.323和IETF的SIP两套实施标准。
基于网守（Gatekeeper）的H.323类似于传统的电话协议，它提供了窄带多媒体通信所需要的所有子协议，但它存在以下不足：控制协议非常复杂，不支持多点发送（Multicast）协议，只能采用多点控制单元MCU组成多点会议(因此只能同时支持有限个用户），不支持呼叫转移，建立呼叫的时间比较长。
SIP则是一个Internet范畴的简单协议，可应用于多媒体会议、远程教学及Internet电话等领域。SIP既支持单点发送，也支持多点发送，会话参与者可以随时加入一个已存在的会议，或为已存在的会议增加支持的媒体种类。SIP可用来呼叫人或机器设备，如呼叫一个媒体存储设备记录一个会议，或呼叫一个电视点播服务器向会议播放视频信号。SIP是一种应用层协议，可用UDP或TCP作为传输协议（参看图1）。与H.323不同的是，SIP是一种基于文本的协议，用SIP URI定位资源，这样易于实现和调试，更重要的是灵活性和扩展性好。由于SIP仅用于初始化呼叫，而不是传输媒体数据，因而造成的附加传输代价也不大。SIP的URI甚至可以嵌入到网页或其它超文本链接中，用户只需用鼠标一点即可发出一个呼叫。与H.323相比，SIP还有建立呼叫快，支持传送电话号码等特点。
尽管SIP以其简单灵活的特性得到了多方青睐，但目前看来，H.323和SIP均会长时间在下一代网络中占领一席之地并且互联互通。
随着电信等行业的需求日益多样化，许多支持SIP的应用服务器应运而生，WebSphere Application Server从 6.1版本开始也提供对SIP的全面支持。用户可以开发个性化的SIP应用，将其部署在WAS 6.1上，WAS 6.1提供一系列SIP组件支持其实现相应的处理逻辑。图2展示的是IBM下一代服务解决方案将要重点发展的公共基本设施软件和模块服务enablers。Parlay X是一套标准的Web Services，开发者可以通过它调用某个操作域中的远程通讯功能，包括：短信，多媒体通讯，呼叫控制，终端位置及状态等。
图2：IBM下一代服务解决方案将重点发展的公共基本设施软件和模块服务enablers
在WebSphere Application Server 6.1中，SIP基础架构是多层结构(见图3)，由SIP容器(SIP Container), SIP代理服务器(SIP Proxy)和负载均衡器(Load Balancer，后面我们称之为IP Sprayer)组成。
图3：WebSphere Application Server 6.1环境下的SIP集群应用架构
SIP容器是Web容器的扩展。除了Web应用，WAS 6.1还能部署和运行SIP应用，甚至可以部署和运行同时包含Web应用和SIP应用的聚合应用(Converged Application)。
SIP代理服务器处理会话亲和，负载均衡和故障恢复。在WAS 6.1中，代理服务器不仅支持HTTP协议，还支持SIP协议。
IP Sprayer提供高可用性。如果有多个代理服务器，前端应该设置一个负载均衡器，负责分派消息给各个SIP代理服务器。SIP代理服务器是无状态的，也叫Stateless SIP Proxy Server，简称SLSP。因此IP Sprayer可以无代价地随时改变目标。
SIP容器和SIP代理服务器是WebSphere Application Server 6.1提供的两个最核心的SIP组件，下面将做详细介绍。
SIP代理服务器
WebSphere Application Server 6.1的代理服务器有以下特点：
不仅支持HTTP协议，还支持SIP协议。
提供应用级别的会话故障恢复，而不用考虑协议层。
屏蔽和保护后台SIP容器组成的集群。
处理会话亲和。
代理服务器过滤层的API扩展了代理服务器的基本功能。
支持故障恢复和负载均衡。
可为每个代理服务器定义集群路由规则，规定消息如何被路由到各个后台集群上去。
允许其它产品对其进行扩展，比如：WebSphere XD能够扩展对SIP的支持，提供更好的服务质量(Quality of Services, QoS)。
WAS 6.1中，如果选择支持SIP协议，生成的代理服务器就可以叫做SIP代理服务器。单个SIP代理服务器可以作为多个SIP集群的前端，记住，即使在不同的节点上，它也必须和这些集群在同一个单元(cell)中。如果某个单元中部署了多个SIP代理服务器，其前端必须用负载均衡器(即IP Sprayer)。
我们可以为每个SIP代理服务器创建路由规格。但需要注意的是，WAS 6.1目前不支持为SIP代理服务器设置过滤条件(见图4)，只能简单地设置路由规则（例如：直接选择某个集群）。将来的版本中，我们还可以通过设置路由规则的定制属性和过滤条件，支持更复杂的路由规则。一般情况下，最好为每个SIP代理服务器配置缺省集群。这样，当到达SIP代理服务器的消息不符合所有路由规则时，就将其发送到缺省集群上去。
图4：设置SIP代理服务器的路由规则
部署聚合应用时，代理服务器必须同时支持HTTP和SIP，我们将这种服务器叫做聚合代理服务器(Converged Proxy Server)。
虽然SIP和HTTP代理服务器有许多相似之处，但还有几点重要的区别，包括：
SIP请求可以被双向传送，但是HTTP请求只能通过代理服务器从客户端发往服务器端。
SIP代理服务器不但能处理入站(inbound)的客户连接，也能发送出站(outbound)连接。HTTP代理服务器只能处理入站(inbound)的客户连接。
SIP协议（像SMTP和其他协议一样）不支持cookie，但HTTP支持cookie。SIP协议中包含会话状态，而HTTP用cookie维护会话状态。
SIP代理服务器能使用的传输协议除了TCP和SSL，还有UDP，而HTTP代理服务器不能将UDP作为传输协议。
我们要特别注意，SIP代理服务器应被部署到隔离区(Demilitarized Zone, DMZ)，通过尽可能地隔离SIP代理服务器和后台SIP容器来保护SIP容器。
SIP容器
WebSphere Application Server 6.1实现了SIP Servlet 1.0规范(JSR 116)。在WAS 6.1中，SIP容器是Web容器的一部分，所以也叫聚合容器(Converged Container)，请参看图5。它们共用会话管理、安全机制和其他属性，使得WebSphere应用服务器也能部署和运行SIP应用。SIP Servlets、HTTP Servlets或Portlets应用之间可以无缝交互，而不必考虑协议不兼容等问题。可以看出，对SIP的支持扩展了J2EE应用服务器，使之成为真正聚合HTTP/SIP的环境；对SIP协议的实现扩展了服务的种类和功能，并丰富了HTTP/SIP环境下的编程模型；我们还可以通过JMX(Java Management Extensions)或者wsadmin对HTTP/SIP应用进行统一配置和管理。
图5：WebSphere Application Server 6.1中的聚合容器
具体来说，聚合容器的好处在于：
减少HTTP应用和SIP应用间的延迟(latency)。SIP是实时协议，对SIP请求的及时响应非常关键。包含HTTP Servlet和SIP Servlet的聚合应用，需要借助聚合容器来尽可能地减少HTTP环境和SIP环境间的延迟。
在控制台中统一管理。可以像部署运行*.war应用一样，在同一个console中部署和运行包含SIP Servlet的*.sar应用。
跟HTTP一样，SIP利用JMX和wsadmin配置和管理系统。这有助于开发人员或管理人员将同时包含HTTP/SIP应用的整个环境自动化。
支持SOA架构，可以访问Web服务、企业服务总线(Enterprise Service Bus, ESB)和服务组合(Service Orchestration)，也可以将包含SIP应用的服务放到ESB上，作为Web服务提供给外界使用。
总之，WAS 6.1实现了SIP协议和编程模型，为HTTP/SIP应用提供了一个通用的执行平台。推广和管理通用的、基于开放标准的实时平台可以提高效率，同时完整、配套的工具集和对模块化服务的支持使部署变得更加容易。
因为Web容器和Channel Framework的重用，增加了UDP传输通道。此外，SIP容器用到了以下WAS组件和API：
通过Web容器，Web容器API将SIP请求转发给SIP servlet。
DRS(Data Replication Service)用于容器间相互复制会话信息，并最终用于故障恢复。
HAM(High Availability Manager)用于报告发生故障的服务器，并选择一个协调者来处理故障。
UCF(Unified Clustering Framework)用于发布负载信息和逻辑名称(Logical Names，将消息从无状态代理服务器路由到合适的容器所需的信息）。
PMI(Performance Monitoring Infrastructure)发布不同的SIP计数器，可以在TPV(Tivoli Performance Viewer)里查看这些计数器。
WCCM用于获取所有配置信息。
Channel Framework用于和网络层进行交互。需要特别指出的是，使用UDP, TCP和SSL作为传输协议。
为了支持SIP协议必需的摘要认证(digest authentication)，也部署了TAI(Trust Association Interceptor)。TAI和后台的LDAP(Light Directory Access Protocol)服务器通信，获取用户的密码，检查请求的用户标识。如果需要，TAI会产生包含摘要的错误提示响应，最终这些错误提示被发回客户端。
SIP Servlet API (JSR 116)
对任何通信基础设施而言，可编程性尤为重要，SIP Servlet API就是用于标准化那些提供基于SIP的服务的平台。SIP Servlet规范是一种Java Community Process规范(JSR 116)。使用SIP Servlet编写通信业务就如同用HTTP servlets编写WEB应用。
SIP Servlet的编程模型跟HTTP Servlet相似。HTTP Servlet API一直以来是开发Web应用的标准，它使得Web应用可以在不同软件提供商的Web容器(Web Container)间移植。Web容器负责管理Servlet的初始化、线程池、会话状态、安全及任何跟容器相关的参数设置。应用开发人员只需关注应用逻辑本身，而不必关心底层的操作，比如: HTTP头部等。SIP Servlet API(JSR 116)利用这些概念，简化SIP应用的开发过程。
SIP Servlet和HTTP Servlet的共同点：
利用部署描述符将Servlet加入到应用中，并部署到容器上。
容器根据部署描述符包含的信息选择应调用的Servlet。
容器根据部署描述符包含的信息为新来的请求进行认证或授权。
重写Servlet的基本类构成业务逻辑，然后调用之。
Servlet API向开发人员隐藏了底层协议的复杂性，将该协议概括成一组高级API。
尽管不同的容器实现提供不同的服务质量，但它们都是被Java Community Process标准化过的。
SIP Servlet和HTTP Servlet的不同点：
SIP Servlet可以初始化请求和接收SIP请求，可被用作SIP客户端；而HTTP Servlet只能作为服务器端，发送响应。
SIP Servlet可以生成异步响应。它不需要立即响应请求，并且可为一个请求生成多个响应。
一个SIP请求可以由多个SIP应用来服务，将请求映射到Servlet非常灵活。
SIP Servlet向开发人员隐藏了协议的复杂性，包括：呼叫次序、协议层路由、多种传输类型（TCP、UDP和SSL）、协议层重发等。
聚合应用
聚合应用就是SIP应用（声音、视频、到场等）和传统的Web应用一起协同工作。 SIP Servlet API(JSR 116)将SIP协议带入了J2EE领域，从而扩展了我们开发应用的范围，HTTP/SIP聚合应用扩展了服务的功能。
举个例子，用户Michael想查询一下适合自己的放贷信息，他打电话给呼叫中心(Call Center)，提交了自己所能承受的房贷要求，呼叫中心的SIP应用负责通过企业服务总线(Enterprise Service Bus)查出服务人员列表，Presence Server从中挑出当前空闲服务人员Janice，并向她提交请求；而Web应用则负责根据Michael提交的个人情况和要求找出适合他的房贷信息；最后，Janice接受SIP请求，与Michael建立了SIP会话，将Web应用所找出的有用信息以声音（视频或即时消息）的方式传达给Michael。这就是一个SIP应用和Web应用协同工作的一个典型例子（见图6）。
图6：聚合应用场景——呼叫中心
SIP应用开发工具
我们可以利用Application Server Toolkit 6.1(简称AST 6.1)开发SIP应用。AST 6.1支持SIP，实现了JSR 116规范所定义的SIP Servlet API。开发SIP应用的方式基本上跟开发Web应用一样，可以将包含SIP应用的工程导出为SAR包，也可以将已有的SAR包导入到AST 6.1中做进一步开发，还可以在AST 6.1中开发聚合(HTTP/SIP)应用。
AST 6.1中包含了一些SIP样例，从工作台点击进入“帮助->样本库->技术样本->SIP”，可以看到以下三个SIP样例及其使用向导，我们可以从这里导入并运行它们。
Call Blocking - 检查列表，确定呼叫者是否合法。如果呼叫者是合法的，呼叫继续被转发，否则，呼叫被阻止；
Call Forward - 检查并确认呼叫者在转发列表中。如果在，才将呼叫转发。
Third Party - 展示了如何通过实现一个控制器来使用聚合功能，该控制器创建并管理双方的通信关系。
这里就不讲述创建SIP应用的步骤了，但有几点需要注意：
创建SIP工程跟创建动态Web工程类似，不同的是SIP工程的WEB-INF包含的是sip.xml，而不是web.xml。如果创建的是聚合工程(Converged Project)，则同时包含web.xml和sip.xml。
动态Web模块2.3版本是支持SIP Servlet所必需的，在创建工程的过程中就对其进行了设置。
创建SIP Servlet时可设置要处理的消息映射和选择预定义好的相应的method stubs。
包含SIP Servlet的工程可以被导出为*.sar，并像部署*.war应用一样将其部署到WAS 6.1上去。
SIP高可用性和故障恢复
SIP高可用性解决方案的前提是同一会话的所有消息都由同一容器来处理，当某一容器发生故障时，该容器正在处理的所有会话将由位于同一复制域的其他容器接管，会话中后续的消息也将被发送到新的容器。高可用性包含以下方面：
可扩展(Scalability)：可以添加更多的服务器到集群中去以处理持续增加的负载。
负载均衡(Load Balancing)：将负载尽可能平均地分配到集群中的服务器上，以避免某服务器过载，而同时其他服务器被闲置的情况。
故障恢复(Failover)：当一个或多个服务器发生故障时，可以从故障中恢复过来。
保证SIP的高可用性，要用到以下组件：
SIP容器：维护所有的会话，触发所有的应用。
SIP代理服务器：处理大量的客户连接，将新来的消息路由到合适的SIP容器中去，创建出站连接，包括对客户端的连接和对其它域的连接。
IP Sprayer：在多个代理服务器间提供负载均衡。
UCF：负责交换SIP容器和SIP代理服务器间的路由信息。利用UCF，SIP代理服务器可以将消息发送到负载最小的SIP容器中去，或者在发生故障时，将消息发送给接管会话的容器。
SIP代理服务器具有故障恢复的功能，它处理的是可靠呼叫的故障恢复，而不是事务级别的故障恢复。SIP的故障恢复机制是这样的：首先，在SIP容器间复制会话信息。其次，每个SIP会话都设置了一些计时器，通过它们，可以监测到其所在的SIP容器是否发生故障，当监测到某个SIP容器发生故障时，与之相互复制的其他SIP容器立即激活因该SIP容器故障而失败了的会话，该会话的所有后续消息也将被发送到新的SIP容器中去。
需要指出的是，SIP和HTTP利用相同的复制拓扑结构，故障恢复至少需要一个复制域，出于性能考虑，每个复制域应最多包含2到3个SIP容器，副本数必须设置成“整个域”，复制方式应该是“客户机和服务器”，分布式会话需要设置成内存到内存(Memory-to-Memory)复制方式。此外，任何需要做会话复制的应用都应该在部署描述符web.xml和sip.xml中包含<distributable/>标记。对包含SIP协议的会话，目前只支持内存到内存的复制方式。
SIP问题诊断
我们可以通过多种方式对SIP相关的问题进行诊断，找出真正原因所在，并进行修复。包括：
Trace诊断：为SIP容器和SIP代理服务器所在的应用服务器（比如：server1）设置Trace。注意，设置Trace后必须重启相应进程才能生效。
设置SIP容器的相关Trace：
- 对SIP容器所在的应用服务器设置Trace：com.ibm.ws.sip.*=all
- 然后在trace.log中查找“onMessage”相关的信息，以定位原因。
设置SIP代理服务器的相关Trace：
- 对SIP代理服务器所在的应用服务器设置Trace：com.ibm.ws.proxy.*=all:com.ibm.ws.sip.*=all
- 然后在trace.log中查找“SipProxyConne 3 Message”相关的信息，以定位原因。
PMI：WAS 6.1新增了SipContainerModule这个类别，包含4个计数器(Incoming traffic, New SIP Application Sessions, Queue Size, Response Time)，用于监控以下指标。 - 当前活动的SIP会话及其数目，SIP消息传送速率，每秒新增的SIP会话数目
- 队列大小，SIP请求的平均响应时间
故障分析 - 用netstat查看SIP相关端口是否在监听，比如：netstat -an|grep 5062
- 确认SIP相关端口是否已被加入到虚拟主机(Virtual Host)的主机别名(Host Aliases)中。
- 如果安装了SIP应用，确认其是否已经启动。
SIP压力测试的基本规则 - 平均的CPU利用率应在60%-70%以下。
- SIP容器占用的内存空间不应超过其所在应用服务器JVM堆大小(Heap Size)的70%。呼叫速率和会话超时设置对堆的使用影响很大。
- SIP容器所在应用服务器JVM做垃圾回收(Garbage Collection)的时间最大不应超过500毫秒，平均应小于400毫秒。
结束语
SIP Servlet API(JSR 116)将SIP协议带入了J2EE领域，扩展了我们开发应用的范围，HTTP/SIP聚合应用扩展了服务的功能。IBM从WAS 6.1开始提供对SIP的全面支持，它通过两个主要组件SIP容器和SIP代理服务器支持运行SIP应用（或HTTP/SIP聚合应用）所定义的处理逻辑。可以利用AST 6.1开发SIP应用或HTTP/SIP聚合应用。WAS 6.1为SIP提供高可用性和故障恢复等功能。将来，WebSphere Extended Deployment 6.1(简称XD 6.1)也将提供更好的服务质量和基于SIP的服务策略。
