SIP会话发起协议的有关问题

前面，我们对一部分SIP会话发起协议的有关应用问题进行了处理。总结了不少解决方法。不知道大家是否已经掌握了。（可参阅《SIP会话发起协议的基础问答》）那么为了全面地剖析SIP有可能发生的问题。我们这篇文章再来补充一下有关的内容。

是否支持 X 标准?

我们实现并测试了大量标准｡我们在产品信息中心列出了这些标准(请参见参考资料)｡我们实际上将标准列表分为两组:

第一组是我们支持并进行了测试的标准｡这些标准仍然可能需要应用程序进行一些操作来确保遵从性,但是由于需要对容器或代理服务器进行更改,因此我们对其进行了测试,以确保遵从性｡不过,这并不是可能用于 WebSphere Application Server 的标准的完整列表｡

还有一个表,其中包含的是在无需更改应用服务器的情况下 WebSphere Application Server 上的应用程序就可以支持的标准｡不断推出的很多 IETF 标准不需要对应用服务器进行更改,但是需要进行应用程序更改,以保证在应用服务器上运行时遵循规范｡

我们是否可以修改SIP会话发起协议的消息上的系统 Header?

尽管 JSR 116 规范并不允许这样做,但很多人都要求提供此功能｡可以在SIP容器上配置 enable.system.headers.modify 自定义属性,此属性将允许应用程序修改在其他情况下不能更改的 Header｡关于如何对此进行配置的更多信息,请参见 WebSphere Application Server 信息中心｡

您是否有任何已公开的关于 WebSphere Application Server 中的SIP会话发起协议的性能数据?

目前没有SIPServlet 应用服务器的性能基准,这意味着要基于当前可用的数据相对于其他应用服务器比较一个应用服务器的性能将极为困难｡在一年前的新闻稿中,我们公布了以下性能信息:

“WebSphere Application Server 6.1.0.11 使用 Red Hat Linux,并集成在 IBM BladeCenter HT 套件中;此套件兼容网络设备构建系统(Network Equipment Building System,NEBS),实现了每秒 1296 个调用的行业领先SIP性能指标,使用 13 路消息SIP调用模型(持有时间为 80 秒),相当于每个刀片超过 460 万高峰调用尝试｡通过在高可用性运营商级配置中使用此调用模型,WebSphere Application Server 实现了每个刀片每秒 660 个会话复制调用｡达到这些结果的同时,还保持了极低的端到端SIP消息处理延迟,95% 的时间延迟低于 50 毫秒｡这充分展示了 WebSphere Application Server 处理调用量业务需求及确保服务质量的能力｡"

这全部是在 HS21 XM Blade 上完成的,此系统是双 CPU 四核 2.33 GHz 系统｡目前尚没有 WebSphere Application Server V7 的性能数据｡

WebSphere Application Server V7 中添加了哪些SIP会话发起协议新功能?

对于首次接触此版本的人,您会发现我们添加了对以下 RFC 的支持:

3263——查找SIP服务器 (LocatingSIPServers)

3311——SIP Update 方法 (TheSIPUpdate method)

3325——用于信任网络中断言标识的会话启动协议 (SIP) 的私有扩展 (Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks)

3891——SIP 替换 Header (TheSIPReplaces Header)

3911——SIP 联合 Header (TheSIPJoin Header)

4475——SIP 扭曲测试消息 (SIP Torture Test Messages)

WebSphere Application Server V6.1 支持 RFC 3263,但第5部分除外;现在已经在 WebSphere Application Server V7 中增加了对第 5 部分的支持｡未完成的 RFC(SIP“扭曲测试"消息)更多地讨论测试工作,而不是功能｡此测试与已经非常严格的电信运营商级测试结合,帮助 WebSphere Application Server V7 成为了市场上最为稳定的SIP应用服务器｡

除了其他标准支持外,我们位于应用服务器前的SIP会话发起协议的代理具有多项增强功能｡它现在可以支持这里讨论的 DMZ 部署,能在防火墙后建立代理服务器集群,并改善了负载平衡,从而进一步减少与重新传输关联的一些错误情况中的调用丢失｡在聚合 Servlet 容器中,用户将会注意到,与 V6.1 中的情况相比,摘要身份验证支持已经更为清楚地集成到了 WebSphere Application Server V7 中｡

HTTP 和SIP会话是否一起得以保存?

如这篇文章第二部分所述,在聚合应用程序中,HTTP 和SIP会话绑定在一起,且一起进行故障转移｡因此,无论在发生故障转移之后先收到 HTTP 消息还是SIP消息,都会将其路由到相同的计算机｡

虽然这样说,但是 HTTP 会话和SIP会话之间存在根本的区别｡由于协议本质的原因,SIP会话发起协议必须采用“主动"故障转移,而 HTTP 故障转移通常更为被动一些｡在新的 HTTP 请求传入前并不需要访问 HTTP 会话,而SIP会话具有关联的计时器,将需要在故障转移之后立即激活｡这意味着 HTTP 会话中的对象可能在访问之前都不会在新容器中反序列化,而SIP会话中的对象将尽快反序列化｡

HTTP 和SIP的代理中的集群选择有什么区别?

在 HTTP 中,集群通常由其公开的应用程序 URI 选择｡不过,在SIP中,URI 通常并不指示服务器应该进入哪个集群｡其中的应用程序经常按功能进行分组｡例如,组成在线状态和注册中心系统的应用程序集可能仅仅对 PUBLISH､SUBSCRIBE 和 REGISTER 方法感兴趣,而应用程序的调用控制集将对 INVITE 消息感兴趣｡

如这篇信息中心文章中所述,代理的SIP会话发起协议侧有能力基于各种机制路由到集群,包括在我的示例中介绍的消息类型｡不过,代理的 HTTP 侧将主要基于 Web 应用程序公开的 URI 进行路由｡