摘要當前對IMS（ip多媒體子系統）技術的探討主要集中在網絡側上，而缺少對IMS客戶端的研究。

    1、引言

    IMS是基于SIP（sessioninitiationPRotocol，會話啟始協議）的系統，它為多媒體服務提供了一整套標準體系架構。作為日趨成熟的標準體系，IETF、3GPP、OMA（openmobile alliance，開放移動聯盟）等國際標準組織都在定義和完善IMS標準。IMS技術答應運營商能更好地控制業務層，能更快地集成和開展IMS多媒體服務，并減少網絡投資和運營開銷，所以運營商都很重視IMS技術。同時，IMS技術也能給用戶帶來統一的用戶體驗，用戶將會獲得更多質量和安全都有保障的IMS服務。IMS的提出，順應了通信網絡技術融合與業務融合發展的趨勢，它將在未來通信網絡中發揮重要作用。

    當前的IMS技術工作主要集中在探討IMS網絡上，而忽視了對IMS客戶端的研究，然而，IMS客戶端才是最終用戶享受IMS技術帶來的諸多成果的最直接的表現方式。當前還沒有統一的對IMS客戶端的定義，但根據作者的理解，可以將IMS客戶端定義為一個軟件包（包括了驅動程序、協議棧、各種引擎、應用程序、人機界面等），并可運行在多種終端上（如移動終端、固定終端、PDA、臺式機、筆記本電腦等），可在IMS網絡架構下提供多種實時與非實時IMS業務（如VoIP、視頻電話、呈現、即時消息、會議、組治理、一鍵通、協同工作、文檔共享等）和統一的用戶體驗，并且符合IETF、3GPP、OMA、JCP（javacommunityprocess，Java標準制定組織）等國際標準組織所規定的IMS相關規范。

    對IETF、3GPP、OMA和JCP等國際標準組織的相關IMS規范的研究是開發IMS客戶端軟件的基礎。通過對這些標準的研究，便于理解相關標準之間的關系，從而總結出IMS客戶端的基本需求，這將有助于描繪出IMS客戶端的軟件架構以及今后技術路線圖的研究，為將來IMS客戶端軟件開發與具體實現做好預備工作。

    2、IMS客戶端標準分析和架構參考

    在此首先分析包括IETF、3GPP、OMA和JCP在內的標準組織與IMS客戶端相關的規范，然后基于這些研究，給出了IMS客戶端的軟件架構參考設計圖。

    2.1IETF中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.23GPP中IMS客戶端相關規范

    如圖1所示，3GPP中描述的IMS客戶端（UE）通過兩個參考點訪問IMS網絡，即Gm和Ut參考點，其他IMS網絡節點對IMS客戶端都是不可見的。IMS客戶端通過Gm參考點連接到IMS網絡，它對應的節點是代理呼叫會話控制功能（P-CSCF），所有的SIP消息都必須經過P-CSCF。這些消息用于注冊過程（如Register）、會話控制過程（如Invite）和事務處理過程（如Message）。Ut參考點是IMS客戶端和應用服務器（applicationserver，AS）之間的交互點。用戶可以通過它安全地治理和配置存儲在AS上與網絡服務相關的信息。XCAP可以作為該參考點的協議。

    圖1 3GPP中IMS網絡和IMS客戶端間的接口

    3GPP中也定義了一些服務所需的IMS架構和功能，如呈現、即時消息、組治理、會議等服務。

    2.3OMA中IMS客戶端相關規范

    OMA主要定義移動服務規范，以確保運營商之間和終端之間端到端服務的互連性。OMA提出了一系列基于IMS的服務應用，每種應用都包含了客戶端的功能列表、協議要求、與應用服務器之間的交互等。

    OMA中呈現和可用性工作組定義了PresenceSimple服務。呈現功能是許多IMS應用的基礎。IMS客戶端既是呈現者也是觀察者。呈現者是信息源，提供呈現信息給呈現服務器；觀察者則請求獲取關于呈現者的呈現信息。呈現服務器存儲訂閱者和產生呈現信息改變通知。呈現信息包括網絡信息、用戶當前的狀態，也包括用戶終端的能力等。有些呈現信息是網絡側提供的，如用戶是否已經注冊；有些是呈現者提供的，如呈現者設置的通信偏好。呈現者的狀態只能被已授權的觀察者看到，因此當某個觀察者想訂閱某個用戶的狀態信息時，需要呈現者的確認，呈現者有權拒絕觀察者的訂閱請求。觀察者一般通過一個資源列表訂閱一組呈現者的呈現服務，由資源列表服務器再向呈現服務器逐個訂閱呈現信息，這樣能夠減少IMS客戶端的負擔和網絡負載。在協議方面，呈現者通過Publish方法發布自己當前的狀態，觀察者通過Subscribe訂閱呈現服務，呈現服務器通過Notify通知觀察者其訂閱用戶的狀態信息改變，呈現者也可以通過Subscribe訂閱能獲取其呈現信息的觀察者列表。資源列表和呈現服務授權是通過XCAP實現的。每個資源列表和呈現服務授權都是一個單獨的XML文檔，IMS客戶端可以通過XCAP生成和修改這些文檔。IMS客戶端需要一個友好的人機界面，同時需要實現相應的SIP消息類型擴展和XCAP，才能給用戶提供一個完整的呈現服務。

    OMA中消息工作組定義了IMSimple服務，它答應實時地交換用戶之間的即時信息。IMS中消息分為直接消息和基于會話的消息。直接消息是通過IMS客戶端直接發送和接收消息實現的（RFC3428），它適用于像短信這樣單獨的短消息通信。基于會話的消息是通過Invite發起MSRP（messagesession relay protocol）信道協商，所有消息通過MSRP建立的信道傳送，它適合于交互式的文本會話，如聊天。IM服務一般和呈現服務結合起來使用。通過呈現服務，用戶可以將自己的好友分成不同組，并能實時地看到好友的信息。用戶可以根據好友的狀態發送即時消息。IMS客戶端可以實現簡單的IM服務，如只是通過消息方法進行在線即時通信，也可以增加更復雜的功能，如聊天室、會議聊天、消息歷史存儲、延遲消息等功能的支持。

    OMA中移動一鍵通（pushtotalkover 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文檔、PoCXML文檔治理等。

    OMA還成立了一個名叫融合IP消息的新工作組。具有這種功能的IMS客戶端將對短信、彩信、即時消息、移動、一鍵通等這些傳統的消息方式進行整合。這些傳統的消息方式都是基于IP支持固定和移動網絡傳輸，基于呈現服務支持多媒體，并且與一個統一的地址簿集成，能保持一致的用戶體驗，其具體的技術方案還在制定之中。

    2.4JCP中IMS客戶端的相關規范

    JCP是主要的Java標準組織，JSR（Javaspecificationrequest）則定義了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.5IMS客戶端的軟件架構

    通過對于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（RFC3310和3GPPTS 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（gatewayGPrssupportnode，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（IMSsubscriberidentitymodule）卡中的信息來認證和注冊到IMS網絡。ISIM卡中包括了用戶的私有身份、公共身份、家鄉域、密鑰等與認證和注冊相關的重要信息。假如是USIM（universal subscriber identity module）卡，也可以通過相關的算法推導出類似信息。但是IMS終端種類是多樣性的，對非IMS移動終端，ISIM卡的支持不是必須的，可以通過其他方式實現IMS網絡認證和注冊。

    （9）CS域和IMS的結合應用

    3GPP中定義了CSI（combiningCSbearerwith 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）語音無縫切換

    語音控制連續性（voicecallcontinuity，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客戶端軟件應盡量保持與操作系統的無關性，這樣軟件會很輕易地被移植到其他的操作系統，如WindowsMobile、Symbian、linux或者一些專有的操作系統。這需要在軟件架構設計中將與系統相關的部分盡可能地分離出來。比如IMS客戶端中的引擎和協議棧部分應盡量保持系統無關性，但是人機界面部分一般在不同的系統中都需要重新實現。系統無關部分調用相同的消息通信、內存分配、文件治理、信號治理等應用編程接口，然后根據不同的操作系統重新編寫這些API。這種方法能很好地解決IMS客戶端的軟件移植問題。

    （7）支持傳輸層無關性

    由于手機上的CPU、內存、電池等資源都是有限的，IMS客戶端軟件中的要害部分應當注重實現性能上的優化，如對內存的分配機制、電源治理IMS客戶端應當支持不同的傳輸方式，如GPRS、xDSL、Wi-Fi、WiMax等接入方式，并盡量保持接入方式的無關性，但是不同的接入方式也會直接影響到IMS客戶端的行為。比如通過GPRS接入，就存在主和從PDP（Packetdataprotocol）上下文激活問題、在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 IETFRFC3261.SIP：sessioninitiation protocol，Jun 2002

    2 IETFRFC2327.SDP：sessiondescription protocol，Apr 1998

    3 IEFTdraft-ietf-simple-xcap.Theextensiblemarkup language（XML）configuration access protocol（XCAP），May 2006 (張翀編輯)