前面，我們對一部分SIP會話發(fā)起協(xié)議的有關(guān)應(yīng)用問題進(jìn)行了處理。總結(jié)了不少解決方法。不知道大家是否已經(jīng)掌握了。（可參閱《SIP會話發(fā)起協(xié)議的基礎(chǔ)問答》）那么為了全面地剖析SIP有可能發(fā)生的問題。我們這篇文章再來補(bǔ)充一下有關(guān)的內(nèi)容。

是否支持 X 標(biāo)準(zhǔn)?

我們實(shí)現(xiàn)并測試了大量標(biāo)準(zhǔn)｡我們在產(chǎn)品信息中心列出了這些標(biāo)準(zhǔn)(請參見參考資料)｡我們實(shí)際上將標(biāo)準(zhǔn)列表分為兩組:

***組是我們支持并進(jìn)行了測試的標(biāo)準(zhǔn)｡這些標(biāo)準(zhǔn)仍然可能需要應(yīng)用程序進(jìn)行一些操作來確保遵從性,但是由于需要對容器或代理服務(wù)器進(jìn)行更改,因此我們對其進(jìn)行了測試,以確保遵從性｡不過,這并不是可能用于 WebSphere Application Server 的標(biāo)準(zhǔn)的完整列表｡

還有一個表,其中包含的是在無需更改應(yīng)用服務(wù)器的情況下 WebSphere Application Server 上的應(yīng)用程序就可以支持的標(biāo)準(zhǔn)｡不斷推出的很多 IETF 標(biāo)準(zhǔn)不需要對應(yīng)用服務(wù)器進(jìn)行更改,但是需要進(jìn)行應(yīng)用程序更改,以保證在應(yīng)用服務(wù)器上運(yùn)行時遵循規(guī)范｡

我們是否可以修改SIP會話發(fā)起協(xié)議的消息上的系統(tǒng) Header?

盡管 JSR 116 規(guī)范并不允許這樣做,但很多人都要求提供此功能｡可以在SIP容器上配置 enable.system.headers.modify 自定義屬性,此屬性將允許應(yīng)用程序修改在其他情況下不能更改的 Header｡關(guān)于如何對此進(jìn)行配置的更多信息,請參見 WebSphere Application Server 信息中心｡

您是否有任何已公開的關(guān)于 WebSphere Application Server 中的SIP會話發(fā)起協(xié)議的性能數(shù)據(jù)?

目前沒有SIPServlet 應(yīng)用服務(wù)器的性能基準(zhǔn),這意味著要基于當(dāng)前可用的數(shù)據(jù)相對于其他應(yīng)用服務(wù)器比較一個應(yīng)用服務(wù)器的性能將極為困難｡在一年前的新聞稿中,我們公布了以下性能信息:

 “WebSphere Application Server 6.1.0.11 使用 Red Hat Linux,并集成在 IBM BladeCenter HT 套件中;此套件兼容網(wǎng)絡(luò)設(shè)備構(gòu)建系統(tǒng)(Network Equipment Building System,NEBS),實(shí)現(xiàn)了每秒 1296 個調(diào)用的行業(yè)領(lǐng)先SIP性能指標(biāo),使用 13 路消息SIP調(diào)用模型(持有時間為 80 秒),相當(dāng)于每個刀片超過 460 萬高峰調(diào)用嘗試｡通過在高可用性運(yùn)營商級配置中使用此調(diào)用模型,WebSphere Application Server 實(shí)現(xiàn)了每個刀片每秒 660 個會話復(fù)制調(diào)用｡達(dá)到這些結(jié)果的同時,還保持了極低的端到端SIP消息處理延遲,95% 的時間延遲低于 50 毫秒｡這充分展示了 WebSphere Application Server 處理調(diào)用量業(yè)務(wù)需求及確保服務(wù)質(zhì)量的能力｡"

這全部是在 HS21 XM Blade 上完成的,此系統(tǒng)是雙 CPU 四核 2.33 GHz 系統(tǒng)｡目前尚沒有 WebSphere Application Server V7 的性能數(shù)據(jù)｡

WebSphere Application Server V7 中添加了哪些SIP會話發(fā)起協(xié)議新功能?

對于***接觸此版本的人,您會發(fā)現(xiàn)我們添加了對以下 RFC 的支持:

3263——查找SIP服務(wù)器 (LocatingSIPServers)

3311——SIP Update 方法 (TheSIPUpdate method)

3325——用于信任網(wǎng)絡(luò)中斷言標(biāo)識的會話啟動協(xié)議 (SIP) 的私有擴(kuò)展 (Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks)

3891——SIP 替換 Header (TheSIPReplaces Header)

3911——SIP 聯(lián)合 Header (TheSIPJoin Header)

4475——SIP 扭曲測試消息 (SIP Torture Test Messages)

WebSphere Application Server V6.1 支持 RFC 3263,但第5部分除外;現(xiàn)在已經(jīng)在 WebSphere Application Server V7 中增加了對第 5 部分的支持｡未完成的 RFC(SIP“扭曲測試"消息)更多地討論測試工作,而不是功能｡此測試與已經(jīng)非常嚴(yán)格的電信運(yùn)營商級測試結(jié)合,幫助 WebSphere Application Server V7 成為了市場上最為穩(wěn)定的SIP應(yīng)用服務(wù)器｡

除了其他標(biāo)準(zhǔn)支持外,我們位于應(yīng)用服務(wù)器前的SIP會話發(fā)起協(xié)議的代理具有多項(xiàng)增強(qiáng)功能｡它現(xiàn)在可以支持這里討論的 DMZ 部署,能在防火墻后建立代理服務(wù)器集群,并改善了負(fù)載平衡,從而進(jìn)一步減少與重新傳輸關(guān)聯(lián)的一些錯誤情況中的調(diào)用丟失｡在聚合 Servlet 容器中,用戶將會注意到,與 V6.1 中的情況相比,摘要身份驗(yàn)證支持已經(jīng)更為清楚地集成到了 WebSphere Application Server V7 中｡

HTTP 和SIP會話是否一起得以保存?

如這篇文章第二部分所述,在聚合應(yīng)用程序中,HTTP 和SIP會話綁定在一起,且一起進(jìn)行故障轉(zhuǎn)移｡因此,無論在發(fā)生故障轉(zhuǎn)移之后先收到 HTTP 消息還是SIP消息,都會將其路由到相同的計算機(jī)｡

雖然這樣說,但是 HTTP 會話和SIP會話之間存在根本的區(qū)別｡由于協(xié)議本質(zhì)的原因,SIP會話發(fā)起協(xié)議必須采用“主動"故障轉(zhuǎn)移,而 HTTP 故障轉(zhuǎn)移通常更為被動一些｡在新的 HTTP 請求傳入前并不需要訪問 HTTP 會話,而SIP會話具有關(guān)聯(lián)的計時器,將需要在故障轉(zhuǎn)移之后立即激活｡這意味著 HTTP 會話中的對象可能在訪問之前都不會在新容器中反序列化,而SIP會話中的對象將盡快反序列化｡

HTTP 和SIP的代理中的集群選擇有什么區(qū)別?

在 HTTP 中,集群通常由其公開的應(yīng)用程序 URI 選擇｡不過,在SIP中,URI 通常并不指示服務(wù)器應(yīng)該進(jìn)入哪個集群｡其中的應(yīng)用程序經(jīng)常按功能進(jìn)行分組｡例如,組成在線狀態(tài)和注冊中心系統(tǒng)的應(yīng)用程序集可能僅僅對 PUBLISH､SUBSCRIBE 和 REGISTER 方法感興趣,而應(yīng)用程序的調(diào)用控制集將對 INVITE 消息感興趣｡

如這篇信息中心文章中所述,代理的SIP會話發(fā)起協(xié)議側(cè)有能力基于各種機(jī)制路由到集群,包括在我的示例中介紹的消息類型｡不過,代理的 HTTP 側(cè)將主要基于 Web 應(yīng)用程序公開的 URI 進(jìn)行路由｡

總結(jié)

WebSphere Application Server 提供了可靠的會話發(fā)起協(xié)議 (SIP) Servlet 實(shí)現(xiàn),而 WebSphere eXtreme Scale 和 WebSphere Virtual Enterprise 產(chǎn)品又對此進(jìn)行了進(jìn)一步的增強(qiáng)｡我們真誠地希望本文的內(nèi)容能回答您自己關(guān)于這個支持的一些常見問題｡