评论专栏

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

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 评论专栏

敬请期待该系列的后续内容。

此内容是该系列的一部分:评论专栏

敬请期待该系列的后续内容。

SIP 常见问题

在 IBM WebSphere Application Server V6.1 中首次添加了会话发起协议 (SIP) Servlet 1.0 支持 (JSR 116)。从那时起,SIP 功能以及关于细节的大量问题都一直在增加。下面是一些我听到的关于 SIP Servlet 1.0 支持的最常见问题,并提供了一些很好的参考材料的链接,可以帮助您回答很多其他问题。

WebSphere Application Server 的哪些版本具有 SIP Servlet 功能?

IBM WebSphere Application Server V6.1 基础版和 Express 版具有独立 SIP Servlet 支持,但不提供高可用性支持。WebSphere Application Server V6.1 Network Deployment 具有高可用性功能,包括无状态 SIP 代理,此代理为应用服务器实例提供会话关联支持。WebSphere Application Server V7 还提供 SIP Servlet 功能。

WebSphere Virtual Enterprise 和 WebSphere eXtreme Scale 是否包括 SIP 功能?

是的,这两个产品都提供应用服务器的 SIP 部署功能。

WebSphere Virtual Enterprise 增加了 SIP 代理和应用服务器的功能,提高了基本 WebSphere Application Server 提供的服务的易管理性和质量。WebSphere Virtual Enterprise 用于增强 SIP 应用程序的管理功能的一个功能是,提供了无缝升级应用程序的能力而且同时仍然支持现有应用程序的会话。另一个功能是智能许可控制功能,能够按用户会话监视后端应用服务器上的资源和管理服务策略及质量级别,以确保采用了恰当的决策来保证满足端到端延迟目标。WebSphere Virtual Enterprise 的很多其他功能应用于所有应用程序和应用服务器,如虚拟化、应用程序放置和服务器运行状况管理。

WebSphere eXtreme Scale 能提供更好的 SIP 会话复制服务质量。另外,还提供了比基本 WebSphere Application Server 更多的关于高可用性拓扑设计的选项。为了提高服务质量,WebSphere eXtreme Scale 提供了异步和同步复制,允许在会话之间进行复制,以保证所需的服务级别。

是否可以将 EJB 关联与 SIP 关联绑定?

对于无状态会话 Bean(StateLess Session Bean,SLSB),没有关联或关联机制,因此不能将 SLSB 请求绑定到 SIP 关联中。对于有状态会话 Bean(StateFul Session Bean,SFSB),首次访问 Bean 之后的状态得以保持。这意味着,SFSB 经常被应用于这样的场景:当 SFSB 启动一个对话框并可能希望在这个对话框中暴露操作。

在这种情况下,当 SFSB 创建对话框时,可以确保使用对拥有 SIP 对话框的相同计算机调用 SFSB。我们的在 WebSphere Application Server 中的 SFSB 实现和 SIP 一样使用数据复制服务(Data Replication Service,DRS)。SIP DRS 的常见设置就是简单地为每个复制域配置两个服务器,实质上仅仅支持对等复制。为了实现这个 SIP-SFSB 绑定,将必须进行此设置。然后,如果以相同方式设置 SFSB 复制域,则有状态 Bean 将始终位于启动对话框的相同计算机上。如果出现故障转移,SFSB 与 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 的性能数据?

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

“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 服务器 (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 产品又对此进行了进一步的增强。我们真诚地希望本文的内容能回答您自己关于这个支持的一些常见问题。有关更多信息,请访问下面列出的参考资料。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=390679
ArticleTitle=评论专栏: Erik Burckart:关于会话发起协议的最常见问题
publish-date=05262009