前面，我們對一部分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 進行路由?
總結
WebSphere Application Server 提供了可靠的會話發起協議 (SIP) Servlet 實現,而 WebSphere eXtreme Scale 和 WebSphere Virtual Enterprise 產品又對此進行了進一步的增強?我們真誠地希望本文的內容能回答您自己關于這個支持的一些常見問題?
