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的服务策略。
