相关专题：
摘要 当前对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
来源：中国联通网站
