关于会话发起协议的最常见问题

核心提示： WebSphere Application Server V7 中添加了哪些 SIP 新功能？对于首次接触此版本的人，您会发现我们添加了对以下 RFC 的支持：3263——查找 SIP 服务器 (Locating SIP Servers)3311—&mdash

WebSphere Application Server V7 中添加了哪些 SIP 新功能？

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

3263——查找 SIP 服务器 (Locating SIP Servers)

3311——SIP Update 方法 (The SIP Update method)

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

3891——SIP 替换 Header (The SIP Replaces Header)

3911——SIP 联合 Header (The SIP Join 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 进行路由。

总结

WebSphere Application Server 提供了可靠的会话发起协议 (SIP) Servlet 实现，而 WebSphere eXtreme Scale 和 WebSphere Virtual Enterprise 产品又对此进行了进一步的增强。我们真诚地希望本文的内容能回答您自己关于这个支持的一些常见问题。有关更多信息，请访问下面列出的参考资料。