摘要 當前對IMS（IP多媒體子系統）技術的探討主要集中在網絡側上，而缺少對 IMS客戶端的研究。本文針對IETF、3GPP、OMA（開放移動聯盟）、JCP等國際標準組織中IMS客戶端的相關規範進行了研究和分析，給出IMS 客戶端的定義和IMS客戶端軟件架構設計參考，指出IMS客戶端區別於傳統SIP客戶端的一些特點以及在IMS客戶端軟件開發中應當注意的一些關鍵問題。
1、引言
IMS是基於SIP（session initiation protocol，會話啓始協議）的系統，它爲多媒體服務提供了一整套標準體系架構。作爲日趨成熟的標準體系，IETF、3GPP、OMA（open mobile alliance，開放移動聯盟）等國際標準組織都在定義和完善IMS標準。IMS技術允許運營商能更好地控制業務層，能更快地集成和開展IMS多媒體服務，並減少網絡投資和運營開銷，所以運營商都很重視IMS技術。同時，IMS技術也能給用戶帶來統一的用戶體驗，用戶將會獲得更多質量和安全都有保障的 IMS服務。IMS的提出，順應了通信網絡技術融合與業務融合發展的趨勢，它將在未來通信網絡中發揮重要作用。
當前的IMS技術工作主要集中在探討IMS網絡上，而忽視了對IMS客戶端的研究，然而，IMS客戶端纔是最終用戶享受IMS技術帶來的諸多成果的最直接的表現方式。當前還沒有統一的對IMS客戶端的定義，但根據作者的理解，可以將IMS客戶端定義爲一個軟件包（包括了驅動程序、協議棧、各種引擎、應用程序、人機界面等），並可運行在多種終端上（如移動終端、固定終端、PDA、臺式機、筆記本電腦等），可在IMS網絡架構下提供多種實時與非實時IMS業務（如VoIP、視頻電話、呈現、即時消息、會議、組管理、一鍵通、協同工作、文檔共享等）和統一的用戶體驗，並且符合 IETF、3GPP、OMA、JCP（Java community process，Java標準制定組織）等國際標準組織所規定的IMS相關規範。
對IETF、3GPP、OMA和JCP等國際標準組織的相關IMS規範的研究是開發IMS客戶端軟件的基礎。通過對這些標準的研究，便於理解相關標準之間的關係，從而總結出IMS客戶端的基本需求，這將有助於描繪出IMS客戶端的軟件架構以及今後技術路線圖的研究，爲將來IMS客戶端軟件開發與具體實現做好準備工作。
2、IMS客戶端標準分析和架構參考
在此首先分析包括IETF、3GPP、OMA和JCP在內的標準組織與IMS客戶端相關的規範，然後基於這些研究，給出了IMS客戶端的軟件架構參考設計圖。
2.1 IETF中IMS客戶端相關規範
IETF定義了一整套基礎協議包括SIP、SDP（會話描述協議）、RTP/RTCP（實時傳送協議/實時控制協議）、SCTP（流控制傳輸協議）和XCAP（XML配置接入協議）等，作爲IMS客戶端的基本協議簇。SIP用於兩個或者多個IP節點間會話的建立、維護和拆除，可以運行在可靠的傳輸層（如TCP和SCTP）上或者非可靠的傳輸層（如UDP）上。SIP的擴展很多，比如SIP消息類型的增加（如 Update、Refer、Publish、Notify等）、Simple、SIP信令壓縮、用於3GPP的私有包頭擴展、認證和安全機制等。在實現 IMS客戶端時，這些SIP擴展的部分都應當有所考慮。SDP是一種應用層協議，用來描述媒體會話能力、媒體格式、媒體流地址和端口等信息。RTP是用於端到端傳遞實時數據的協議，RTCP用於實時數據的服務質量監控。XCAP允許用戶上傳信息到XCAP服務器，通過HTTP更改、增加和刪除存儲在服務器上的XML文檔。XCAP複用了HTTP中的Get、Put和Delete方法來獲取、更改/增加和刪除XML文檔。通過一套巧妙的方法，將XML文檔的存儲路徑和文檔中的條目、元素和屬性映射到HTTP中的URL路徑。目前，XCAP在IETF中仍處於草案階段。
SIP及其擴展、SDP、RTP/RTCP和XCAP都是實現IMS客戶端最重要的基礎協議。
2.2 3GPP中IMS客戶端相關規範
如圖1所示，3GPP中描述的IMS客戶端（UE）通過兩個參考點訪問IMS網絡，即Gm和Ut參考點，其他IMS網絡節點對IMS客戶端都是不可見的。IMS客戶端通過Gm參考點連接到IMS網絡，它對應的節點是代理呼叫會話控制功能（P-CSCF），所有的SIP消息都必須經過P-CSCF。這些消息用於註冊過程（如Register）、會話控制過程（如Invite）和事務處理過程（如Message）。Ut參考點是IMS客戶端和應用服務器（application server，AS）之間的交互點。用戶可以通過它安全地管理和配置存儲在AS上與網絡服務相關的信息。XCAP可以作爲該參考點的協議。
圖1 3GPP中IMS網絡和IMS客戶端間的接口
3GPP中也定義了一些服務所需的IMS架構和功能，如呈現、即時消息、組管理、會議等服務。
2.3 OMA中IMS客戶端相關規範
OMA主要定義移動服務規範，以確保運營商之間和終端之間端到端服務的互連性。OMA提出了一系列基於IMS的服務應用，每種應用都包含了客戶端的功能列表、協議要求、與應用服務器之間的交互等。
OMA中呈現和可用性工作組定義了Presence Simple服務。呈現功能是許多IMS應用的基礎。IMS客戶端既是呈現者也是觀察者。呈現者是信息源，提供呈現信息給呈現服務器；觀察者則請求獲取關於呈現者的呈現信息。呈現服務器存儲訂閱者和產生呈現信息改變通知。呈現信息包括網絡信息、用戶當前的狀態，也包括用戶終端的能力等。有些呈現信息是網絡側提供的，如用戶是否已經註冊；有些是呈現者提供的，如呈現者設置的通信偏好。呈現者的狀態只能被已授權的觀察者看到，因此當某個觀察者想訂閱某個用戶的狀態信息時，需要呈現者的確認，呈現者有權拒絕觀察者的訂閱請求。觀察者一般通過一個資源列表訂閱一組呈現者的呈現服務，由資源列表服務器再向呈現服務器逐個訂閱呈現信息，這樣能夠減少IMS客戶端的負擔和網絡負載。在協議方面，呈現者通過Publish方法發佈自己當前的狀態，觀察者通過 Subscribe訂閱呈現服務，呈現服務器通過Notify通知觀察者其訂閱用戶的狀態信息改變，呈現者也可以通過Subscribe訂閱能獲取其呈現信息的觀察者列表。資源列表和呈現服務授權是通過XCAP實現的。每個資源列表和呈現服務授權都是一個單獨的XML文檔，IMS客戶端可以通過XCAP生成和修改這些文檔。IMS客戶端需要一個友好的人機界面，同時需要實現相應的SIP消息類型擴展和XCAP，才能給用戶提供一個完整的呈現服務。
OMA中消息工作組定義了IM Simple服務，它允許實時地交換用戶之間的即時信息。IMS中消息分爲直接消息和基於會話的消息。直接消息是通過IMS客戶端直接發送和接收消息實現的（RFC 3428），它適用於像短信這樣單獨的短消息通信。基於會話的消息是通過Invite發起MSRP（message session relay protocol）信道協商，所有消息通過MSRP建立的信道傳送，它適合於交互式的文本會話，如聊天。IM服務一般和呈現服務結合起來使用。通過呈現服務，用戶可以將自己的好友分成不同組，並能實時地看到好友的信息。用戶可以根據好友的狀態發送即時消息。IMS客戶端可以實現簡單的IM服務，如只是通過消息方法進行在線即時通信，也可以增加更復雜的功能，如聊天室、會議聊天、消息歷史存儲、延遲消息等功能的支持。
OMA中移動一鍵通（push to talk over cellular，PoC）工作組定義了一鍵通服務。提供PoC服務的IMS客戶端能實現基於分組交換、半雙工的VoIP方案。它用SIP作爲信令，用 RTP傳輸語音數據，同時它需要複用呈現和組管理功能來實現PoC服務。PoC應該是現實世界中第一個基於IMS的應用，因爲Presence和IM應用最初是基於XMPP（可擴展消息和呈現協議），後來又是基於IMPS（即時消息和呈現業務）協議實現。
OMA中呈現和可用性工作組還定義了XML文檔管理服務。用戶可以通過IMS客戶端定位、存取和處理可被其他的服務引擎所存取的用戶和服務相關信息，存儲和處理以XML文檔形式保存在網絡上的服務相關的數據，也可以通過SIP來訂閱和通知文檔變更。該服務集成了其他 IMS服務中的XML文檔管理功能。XML文檔管理功能包括：共享XML文檔、呈現XML文檔、資源列表XML文檔、即時消息XML文檔、PoC XML文檔管理等。
OMA還成立了一個名叫融合IP消息的新工作組。具有這種功能的IMS客戶端將對短信、彩信、即時消息、移動、一鍵通等這些傳統的消息方式進行整合。這些傳統的消息方式都是基於IP支持固定和移動網絡傳輸，基於呈現服務支持多媒體，並且與一個統一的地址簿集成，能保持一致的用戶體驗，其具體的技術方案還在制定之中。
2.4 JCP中IMS客戶端的相關規範
JCP是主要的Java標準組織，JSR（Java specification request）則定義了Java應用程序需調用的應用編程接口（API）。
JSR164規範提供給Java開發者基於Simple協議棧的一套標準API，用以開發基於呈現服務的Java程序。JSR165規範也提供給Java開發者基於Simple協議棧的一套標準API，用以開發基於即時消息服務的Java程序。而JSR180規範提供給Java開發者基於SIP協議棧的一套標準API，這套API屏蔽了SIP的許多實現細節，開發者不需要對SIP有非常詳細的瞭解就能開發出基於SIP 的諸多應用程序。
JSR281規範使應用開發者能很容易地開發出可以和IMS系統集成的應用程序，此規範以統一的高層API方式向用戶提供IMS的功能。這些API最大限度地隱藏了IMS實現細節，抽象了下層技術，同時提供給開發者最大的靈活性。其API中至少支持3種類型的功能：高級 IMS功能、PoC服務和組列表管理服務。JSR281規範目前沒有涉及在JSR164和JSR165中已經定義了的呈現服務和即時消息服務。此規範還在制定過程中。
2.5 IMS客戶端的軟件架構
通過對於IMS客戶端相關規範的研究與分析，可以看出IETF提供了IMS客戶端所需要的協議部分，包括詳細的SIP 信令消息交互，服務參數協商、媒體流的建立、XML文檔的交互等。3GPP和OMA提供了IMS客戶端所需要的服務引擎，與不同應用服務器之間的交互方式以及如何接入到IMS網絡等。JCP提供了一整套IMS客戶端上Java應用程序所需的標準Java應用編程接口。由此可以總結歸納出IMS客戶端軟件架構參考，具體參見圖2。
圖2 IMS客戶端軟件架構參考
IMS客戶端軟件架構主要包括了：
（1）協議棧
IMS客戶端的底層是協議棧部分。它們大都是基於IETF標準的，包括SIP、SDP、HTTP、XCAP、RTP/RTCP、DNS、DHCP等。其中用於接入3GPP定義的IMS網絡所要求的那些SIP擴展部分也必須支持。
（2）引擎/使能器
服務引擎是提供應用編程接口給上層應用程序或者第三方應用開發的關鍵部分。根據其所提供服務的不同，可以包括不同的引擎，比如呈現引擎、即時消息引擎等。這些引擎主要是在OMA和3GPP中定義的，其中一些共同的部件包括會話/呼叫管理、註冊、認證、安全、配置、供給等。
（3）Java應用編程接口
這些應用程序接口被上層的Java應用程序所使用。Java應用程序給用戶提供了可以下載的更豐富且與操作系統無關的IMS應用。
（4）應用層/圖形界面
應用程序給用戶提供了GUI界面。GUI界面應當足夠的友好和方便，這樣才能更好地展現IMS服務和應用。
3、IMS客戶端區別於一般SIP客戶端的特性
通過研究可以發現，IMS客戶端和一般的SIP客戶端有許多不同之處，它相比一般的SIP客戶端而言需要支持更多的功能，也更加複雜，對於IMS終端的要求也更高。其中關鍵的一點是IMS客戶端必須符合IMS相關規範，才能夠接入到IMS網絡。爲用戶提供一系列的IMS 服務。
（1）SIP擴展
IMS客戶端必須支持SIP擴展部分的有關規範，特別是3GPP所要求的那些SIP包頭擴展部分，這樣才能訪問IMS網絡。而一般SIP客戶端只需要支持RFC3261。
（2）認證機制
IMS標準中定義了不同的認證機制，如HTTP摘要（RFC2617）、IMS-AKA （RFC 3310和3GPP TS 33.203）和pre-IMS認證（3GPP TR 33.878）等。IMS客戶端需要支持更安全的認證方式（如IMS-AKA）才能保證IMS終端和IMS網絡之間的安全訪問。
（3）IPSec
IPSec在IP層上提供了多種安全機制，用於保證用戶客戶端和安全網關之間的安全通信。在IMS客戶端和P- CSCF之間建立一個安全的IPSec通道，能確保IMS客戶端安全地接入到IMS網絡中，這個通道是在IMS註冊過程中建立起來的，而一般SIP客戶端不需要支持這種特性。
（4）包壓縮功能
SIP包壓縮能改善服務質量，特別是在無線環境下大大縮短呼叫建立時間。通過壓縮網絡和傳輸協議中的包頭，能更有效地利用帶寬，對SIP/SDP消息的壓縮也提高了無線資源利用率。IMS客戶端一般都是通過移動無線方式接入IMS網絡的，所以包壓縮的功能是必須的。而一般SIP客戶端是通過寬帶接入，所以不需要支持這個特性。
（5）前提條件下的QoS保證
前提條件下的QoS保證是指在會話建立過程中，必須在確保雙方端到端的服務質量所需的媒體資源得以預留後，才能成功地建立起會話。比如在視頻呼叫建立中，該機制用以驗證會話中是否已經獲得恰當的端到端服務質量。但是，這種機制比較複雜，延長了會話建立的時間。因此，僅在必要的時候，IMS客戶端纔會打開這種機制。
（6）發現機制
P-CSCF是IMS客戶端訪問IMS網絡惟一的接入點，所有從IMS客戶端來的SIP信息都必須經過P-CSCF。所以，在SIP信息發送前，IMS客戶端必須知道P-CSCF的地址。該地址不是預先配置好的，而是IMS客戶端通過發現機制而獲得的。這些機制包括基於 OTA（空中下載）供給、基於GGSN（gateway GPRS support node，GPRS網關支持節點）和基於DHCP的P-CSCF發現機制，除非是手工地配置P-CSCF信息，否則IMS客戶端必須支持這個功能。
（7）IPv4/v6的支持
一般SIP客戶端只支持IPv4，但是3GPP最初規定IMS客戶端應當支持IPv6。如果IMS核心網是IPv4和IPv6雙棧，只支持IPv4的IMS客戶端也能接入到這樣的IMS網絡中。
（8）ISIM卡的支持
IMS客戶端通過ISIM（IMS subscriber identity module）卡中的信息來認證和註冊到IMS網絡。ISIM卡中包括了用戶的私有身份、公共身份、家鄉域、密鑰等與認證和註冊相關的重要信息。如果是 USIM（universal subscriber identity module）卡，也可以通過相關的算法推導出類似信息。但是IMS終端種類是多樣性的，對非IMS移動終端，ISIM卡的支持不是必須的，可以通過其他方式實現IMS網絡認證和註冊。
（9）CS域和IMS的結合應用
3GPP中定義了CSI（combining CS bearer with IMS），即電路交換（circuit switch，CS）域和IMS的結合應用。IMS客戶端間語音呼叫仍然使用CS域，同時利用分組交換（packet switch，PS）域傳送非實時媒體流。這樣能保證語音質量，提高頻譜利用率，解決了目前通過GSM/UMTS傳送IP語音包而造成的語音質量下降的問題。CSI的第一階段不涉及網絡側，主要是IMS客戶端間交換終端能力，保持CS域和PS域的同時通信。但是這種服務需要IMS終端支持雙傳輸模式（dual transfer mode，DTM）（如果是GERAN接入）或者是MultiRAB（multiple radio access bearer）能力（如果是UTRAN接入），這樣才能同時建立PS域會話和CS域通話。
（10）語音無縫切換
語音控制連續性（voice call continuity，VCC）是3GPP提出的解決CS域通話和IMS域會話之間的語音無縫切換的標準。支持VCC服務的IMS客戶端和呼叫連續控制服務器配合，能保證用戶進入和離開家庭或者辦公室裏的WLAN（無線局域網）時仍然能保持IMS域或CS域語音呼叫的連續性。但是這種服務要求IMS終端具備多種無線接入能力，如GSM/WLAN雙模終端就具備這樣的物理條件。
4、IMS客戶端軟件開發中需注意的問題
通過對IMS客戶端相關標準與技術的研究，以下幾點被認爲是在IMS客戶端軟件開發中應當注意的方面：
（1）符合標準及協議的一致性
IMS客戶端軟件開發應當遵照相關標準組織的協議與規範進行，特別是協議層的一致性，需要嚴格按照IETF中的規定去解析和組織SIP包頭。但是，如果還沒有提出相關的標準或者標準還沒有完全被定義好，一些私有的解決方案也是可行的，因爲標準總會存在一定的滯後。對 SIP包頭和攜帶的文檔一些域進行私有定義以及通過XCAP中交互的XML文檔中一些字段的私有定義，可以實現一些IMS服務的創新。
（2）保證與IMS網絡和終端的互聯互通性
IMS客戶端軟件應當和不同的IMS網絡提供商的應用服務器以及其他的IMS客戶端軟件進行互聯互通測試，從而保證客戶端具有良好的互連性。IMS客戶端的複雜性決定了IMS客戶端間互聯互通的重要性。不同的IMS客戶端可以支持不同的特性，但是應當保持相同功能特性間的互通。比如具備CSI的IMS客戶端仍然可以和不具備CSI的IMS客戶端進行PS域的會話連接。
（3）保持系統的可擴展性
IMS客戶端的功能和特性還在不停地變化與演進中，因此，應當確保IMS客戶端軟件架構設計中的可擴展性和靈活性，以方便新的特性和引擎的加入。如果IMS客戶端軟件架構合理，當有新的協議和引擎加入時，只需增加相應的功能模塊，而不需要對已有的功能模塊做較大的改動就可以增加新的IMS服務。
（4）實現軟件性能優化
由於手機上的CPU、內存、電池等資源都是有限的，IMS客戶端軟件中的關鍵部分應當注意實現性能上的優化，如對內存的分配機制、電源管理、XML文檔解析器算法優化等。
（5）提供軟件平臺的開放性
IMS客戶端軟件應該能夠提供相關的應用編程接口給第三方軟件開發者。由於IMS服務是多樣性的，IMS客戶端提供的這些接口會有助於更多的軟件開發人員更快地開發出更多創新的IMS應用程序。IMS客戶端軟件在提供接口的開放度和靈活性將有所權衡。JCP中的 JSR281爲IMS客戶端軟件的API開發提供了一個很好的參考。
（6）具有操作系統無關性
IMS客戶端軟件應儘量保持與操作系統的無關性，這樣軟件會很容易地被移植到其他的操作系統，如Windows Mobile、Symbian、Linux或者一些專有的操作系統。這需要在軟件架構設計中將與系統相關的部分儘可能地分離出來。比如IMS客戶端中的引擎和協議棧部分應儘量保持系統無關性，但是人機界面部分一般在不同的系統中都需要重新實現。系統無關部分調用相同的消息通信、內存分配、文件管理、信號管理等應用編程接口，然後根據不同的操作系統重新編寫這些API。這種方法能很好地解決IMS客戶端的軟件移植問題。
（7）支持傳輸層無關性
由於手機上的CPU、內存、電池等資源都是有限的，IMS客戶端軟件中的關鍵部分應當注意實現性能上的優化，如對內存的分配機制、電源管理IMS客戶端應當支持不同的傳輸方式，如GPRS、xDSL、Wi-Fi、WiMax等接入方式，並儘量保持接入方式的無關性，但是不同的接入方式也會直接影響到IMS客戶端的行爲。比如通過GPRS接入，就存在主和從PDP（Packet data protocol）上下文激活問題、在PDP上下文激活時獲得P-CSCF地址問題、SIP包壓縮問題等。如果是通過Wi-Fi接入，就不存在這些問題。如果IMS終端是雙模，其接入方式發生轉換時也會對IMS客戶端產生影響。在設計IMS客戶端軟件時應當適當考慮這些情況。
5、結束語
目前，業界在IMS客戶端的實際產品開發方面較之IMS網絡要滯後一些，但仍然已取得許多成果，如愛立信已經推出了基於愛立信移動平臺的IMS客戶端，實現了weShare（語音和多媒體共享業務）；美國Ecrio公司推出了手機IMS框架軟件，集成多種IMS功能，並提供了IMS軟件開發包。隨着IMS網絡測試和今後IMS網絡部署的展開，可以預見，IMS客戶端逐漸會成爲開發和研究的熱點。
隨着IMS應用的增加和豐富，IMS客戶端軟件會變得越來越複雜，對IMS終端的要求也會更高。比如對多線程和多任務的需要，這要求IMS終端是一個智能終端，比較低端的手機可能不支持這樣的特性。如果IMS客戶端支持CSI，IMS終端就必須支持DTM模式或者具備 MultiRAB能力。如果IMS客戶端支持VCC或者一些固定移動網絡融合服務，IMS終端必須是一個多模終端，包含多個無線空中接口。如果IMS客戶端必須支持IPSec和包壓縮，IMS終端可能需要更強的CPU/DSP和更多的內存來處理複雜運算，因此，來自芯片製造商對IMS終端中的某些特性的硬件支持將有助於IMS終端的性能增強。
IMS客戶端中仍有大量的課題有待研究。在IMS客戶端協議棧中SIP和XCAP都是基於文本的信令協議，需要大量的文本解析工作，SIP和XML解析器的性能和效率變得尤爲重要，因此如何優化解析器算法就是一個需要解決的課題。IMS客戶端的安全和認證機制也是比較複雜的，不同的接入方式有完全不同的安全和認證要求，同時上層各種IMS應用也有不同的服務級的安全要求，如何整合和實現這些功能也是需要解決的問題。 IMS客戶端的用戶設備能力管理也是很重要的，這些能力包括設備能力、網絡能力和用戶服務屬性等，這些能力可以是預設的，可以是存儲在網絡側的，也可以是通過會話協商獲得的。IMS客戶端的複雜性和多樣性決定了IMS客戶端的一致性測試和互聯性測試是今後要面臨的重大課題，互聯性沒有很好地解決將會影響 IMS技術和網絡的發展。
隨着IMS技術和應用的日漸成熟與推廣，對IMS客戶端相關技術以及軟件的設計實現方式等課題的深入研究，將會對有關設備生產商及電信運營商等具有重要的參考借鑑意義。
參考文獻
1 IETF RFC 3261.SIP：session initiation protocol，Jun 2002
2 IETF RFC 2327.SDP：session description protocol，Apr 1998
3 IEFT draft-ietf-simple-xcap.The extensible markup language（XML）configuration access protocol（XCAP），May 2006