RCS

 

 

RCS的定位     

          Rich communication Suit（RCS），即丰富通信套件(有时翻译为：富通信)，是一个业务能力的集合；RCS的目标是：在目前通信能力基础上，提供更多、更丰富的业务能力，组成一个集合，为移动终端与固定终端提供融合业务，具备多终端的用户可以获得统一的用户体验。

                  RCS突破传统语音以及消息类应用的框架，融合语音、消息、视频、呈现技术、社区网络等多种通信方式及功能，被运营商视为未来沟通产品，为用户提供融合、丰富的通信体验。

                        RCS已经发布了R4版本。另外还有RCS-e版本，它基于RCS V2版本升级，优化了语音、数据传送方式。此外，RCSe与RCS R2在好友添加机制、用户账户共享、业务能力指示技术、IM即时消息等方面均存在一定的差异。

 

RCS对于运营商的作用

            RCS为运营商应对互联网挑战提供了机遇。它是一种基于增强的手机本地地址本的、集语音、消息、视频、内容共享等多种通信方式及功能为一体的融合通信服务，并以全球50多亿移动用户为基础，基于全球互连性和互操作性可以构建一个最庞大的“社交网络”，增强用户黏性，以应对MSN等互联网即时通信平台业务、社交网络等的竞争。

                运营商面临着成为管道提供商的风险：网络是运营商的核心竞争力，如何将网络与互联网应用融合?如何将可靠的电信网络质量和灵活的互联网业务方式相融合？

        RCS给电信运营商找到了两个平衡点：

                                  新业务增长与原有业务的投资保护

                                  电信业务与互联网业务的融合

      目标：基础电信业务的提升+对抗虚拟运营

 

 

RCS业务分类

1,地址簿业务与社交呈现

                  增强型的地址簿

      除传统地址本（联系人名称、电话号码、电子邮件等）外，此业务可以在地址簿中提供一些实用的信息。其中包含联系人的在线状态(即呈现信息)、业务能力(即通信能力)，让用户可以选择可用和有效的通信方式。用户的状态呈现还包括个性化的特征，例如用户的头像、喜好、时间戳以及心情短语。           

                业务能力信息指明了当前有哪些通信能力可以被用户使用，用来与联系人进行沟通，例如，语音、短信、文件传输等。    从增强地址簿中用户可以直接初始各种通信服务。

            通信历史记录功能：服务器统一保存每个联系人各种形式的媒体通信纪录。

              用户可以设置个性化的请求来提出RCS邀请。如用户可以设置在被叫终端来显示主叫电话的号码、用户的昵称，同时在呈现信息中还可以包含用户的位置信息，用户可以共享位置信息，同时还可以通过授权方式对位置信息进行管理。

 

RCS的业务能力包括：

        电路域语音通信（仅移动终端）

        电路域视频通信（仅WCDMA和TD-CDMA移动终端）

        文件传输

        图片共享

        视频共享

        IM聊天

        SMSoverIP

        呈现状态信息

 

          增强型地址簿是RCS的核心，分为基于PRESENCE方式的增强型地址簿和基于OPTIONS方式的增强型地址簿 两种实现模式。

        基于PRESENCE方式的增强型地址簿 更强大，可以进行      社交呈现状态授权，用户和其联系人之间能够进行邀请、接受、拒绝社区呈现状态等动作，社交呈现状态授权是双方的。        RCS使用社交呈现状态授权保护用户的呈现状态隐私，只有建立了社交呈现状态关系的用户和联系人之间才能共享状态信息。

            基于OPTIONS的增强型地址簿的核心是其能力发现机制，该机制使得用户可以实时查询RCS联系人所具有的通信能力。这种查询是点到点的，即两个终端之间发送SIP option。
       

                  网络地址簿

      用来把本地地址信息存储在网络上，由运营商进行维护和管理。用户可以管理地址本的具体联系人信息，例如增加、删除、修改和更新联系人等。同时如果用户使用多个终端，所有终端也会同步进行更新。

           

 

2,增强型呼叫

              RCS所提供的增强型呼叫包括语音呼叫和视频呼叫，增强型呼叫由各运营商 原有网络方式承载。

            此业务可以在通话过程中和他人分享多媒体内容，如在通话过程中可分享视频或静态图像等多媒体信息。

 

3,增强型消息

              除了SMS和MMS服务外，RCS设备也能提供聊天服务给终端用户，支持群聊、多媒体内容、“正在输入”指示信息以及文件传输。

                RCS可以提供通用的消息编辑器以及包含有好友信息的通信日志，目的在于为用户提供统一的消息业务。用户可以灵活选择使用短信、彩信或者即时通信等形式，同时也可以与不同的设备终端（移动电话、固定电话或者PC，PC通过宽带接入）进行通信。支持点对点消息会话、点对多点自组织群组消息会话。          SMS支持发送较大的文本信息。

            RCS消息交互时，为每个联系人提供一个对话视图，支持添加多媒体内容。

            消息业务的具体技术实现方式（SMS、MMS、一对一聊天）对用户是透明的。对话方式的消息交互应可以在交互模式下运行其它应用，例如语音、视频、文件传输等。

              由终端根据消息（SMS、MMS或一对一聊天）自动地选择承载网络。选择承载网络的规则基于消息的接收者、寻址标准、内容和长度。用户应能选择承载网络来发送消息，并且被选择的承载网络应被显示出来以告知用户

                聊天服务支持一对一和一对多（群聊）两种模式。在聊天服务中交换的消息可以包含文本内容和多媒体内容。

 

4，共享业务

        基本的内容共享：      指用户能够共享不同类型内容的能力，与文件传输的区别为，内容共享能够实时共享图片、视频（对WCDMA、TD-SCDMA接入终端）。

          在一个电路交换语音呼叫的过程中，能够共享内容，要求终端应支持CS语音流和数据流并发。

          内容共享会话的结束不会导致语音通话结束

          语音通话结束会自动终止内容共享会话

       

        增强型内容共享独立于语音呼叫而单独建立：即可以在通信双方未建立语音呼叫的前提下直接发起增强型内容共享业务。

        RCS用户可以向传统用户终端进行视频共享。向传统用户进行视频共享时，需要根据传统用户的终端支持能力（支持SMS/MMS或WEB方式）由网络负责传输视频。

      R4增强了对共享信息的数据操作功能。通信双方可对所分享的图像实时进行缩放、旋转、描绘等一系列图形操作，通信双方同时也可对所分享的视频进行暂停和恢复等多个操作。通过增加对分享数据的操作，进一步增强了用户对RCS业务功能的体验效果。

 

   文件传输

      此业务可以允许用户在会话或非会话状态交换不同类型的内容（文件）。

          文件能够在一个会话中被交换（例如语音、聊天）。

          文件能够在没有事先建立一个会话的情况下交换。

 

 

               

 

5, RCS终端特点

                RCS终端是一种基于增强型手机地址簿，集语音、视频、消息、呈现、内容共享等多种通信方式和功能于一体的融合通信终端产品。用户可以对自己的呈现（如个人图片、心情短语、推荐链接以及状态）进行更新；实现即时消息、聊天、文件传输等多种通信需求；实现在一个会话过程中进行视频共享和图片共享；通过标准协议接口与网络侧对接，实现注册、鉴权、音视频呼叫能力；实现网络地址本和手机本地地址本的数据同步。

 

                多终端环境

            用户可以同时使用多个终端，其中移动终端为基本终端，宽带接入终端为第二终端。用户可以用任意终端进行通信。每个终端上使用同样的社交呈现信息以及好友列表等。

                R2支持用户使用PC通过宽带接入的方式使用RCS业务，客户端安装在PC机上，使用用户名和密码或者XSIM卡。

                R3可以使用宽带接入方式发送MMS和SMS短消息。用户在没有移动终端情况下可以把PC客户端设为基本终端来使用RCS业务。

                R4可以使SMS和MMS用户参与到一个会话中，而且支持在会话中使用标准文本和多媒体短信服务。同时，在共享内容和网络地址簿方面也有进步。

                当RCS终端接入LTE网络时，通过较高可用带宽为用户在语音及视频业务上提供更高质量的服务，增强LTE接入技术的用户体验。R4版本在提供基本语音业务的基础上，同时定义了多种增补语音业务供用户选择。在视频业务方面，R4版本可支持H.264视频编码格式，即可达到的视频速率为384kbps，此版本最大视频速率可达到768kbps，为用户提供更清晰的视频体验。

 

            RCS设备/客户端部署和配置

      这项功能可以让用户的终端设备开机即自动注册到网络上，无需手工操作即可使用RCS的业务和功能。

               

        固定接入方式增强

              在固定接入业务方面，R4版本增加了归属号码的认证、归属地址薄的同步、支持多种固定设备终端（包括：TV、PC、Wi-Fi设备，DECT等）、固定设备用户与移动设备用户进行RCS业务通信等业务功能。

 

6,其它业务       

                  网络增值业务

              这个业务主要体现在运营商侧，如向用户提供语言翻译，图像添加效果等。用户注册到网络时可以自动获取储存在网络上的NVAS菜单，选择使用菜单上包含的NVAS业务。

 

      开放了API接口供第三方开发

              R4版本中对第三方应用开放API，从而提供更加丰富的应用（如与社交网络的融合等）。

 

信令流程

增强型地址簿 流程(XCAP，SIP Subscribe，SIP Notify)

增强型地址簿-添加联系人 流程 

        1，UE-1从Shard XDMS 获取联系人列表(XCAP Get)。

      2，UE-1需要添加一个联系人UE-2，发XCAP PUT 到Shard XDMS，得到后者的200 ok响应。

  3，Shared XDMS 发SIP Notify给RLS服务器(表示新增联系)，RLS发SIP subscribe 给UE-2的Presence Server(以订阅 UE-2的社交呈现信息)

  4，UE-2的Presence Server从presence XDMS、Shared XDMS分别得到 共享文档管理服务器列表、 呈现文档管理服务器规则(判断此用户有授权)，使用2个XCAP Get。

  5，Presence Server先用Notify通知UE-2，收到成功响应后再用Notify通知UE-1。

 

增强型地址簿-接受邀请 流程

  是添加联系人流程的反向操作，即由UE-2把UE-1加入自己的联系人

 

2 视频共享 流程（RTP)

              图：视频共享

 

3  图像共享、文件传输、1对1聊天流程(MSRP)

                                                        图：图像共享、文件传输、1对1聊天流程。

 

RCS终端配置

        当具备RCS能力的终端首次登陆网络时，将触发对于终端的自动配置过程：网络会将包含以下参数的配置文件推送至终端，实现对于终端的自动配置。

终端参数	描述	用法
SIP Proxy	SBC地址（IP:port或者FQDN:port）	必选
XDM Address	XDMS服务器地址（IP：port）	必选
TEL-URI	用户的TEL-URI	可选
SIP-URI	用户的SIP-URI	必选
PRID/PASSWORD	用户的私有标识与密码（如果选择DIGEST鉴权）	必选
IM CONFERENCE FACTORY URI	IM服务器的URI标识，如果没有配置，意味着没有IM服务器提供服务，并且与IM服务器相关的业务（例如：1对多聊天）将无法进行。	可选
IM CAP ALWAYS ON	此参数控制终端显示IM能力时是否支持存储前转的功能。当设置为（1）的时，所有的RCS-e联系人IM的业务能力会设置为支持；当设置为（0）的时，能力的显示会视情况而定。	可选 （为必选如果支持IM CONFERENCE FACTORY URI）
IM WARN SF	如果IM CAP ALWAYS ON设置为开（支持存储转发），此参数起到控制UI提醒的作用。当其设置为（1）并且试图与支持存储转发的离线联系人聊天时，终端需要提醒使用者；如果设置为（0），UI不需做任何提示，其体验与在线联系人聊天相同。	可选 （为必选如果支持IM CONFERENCE FACTORY URI并且IM CAP ALWAYS ON设置为1）
POLLING PERIOD	此参数以秒计，对于联系列表中能力显示不支持或者能力显示超时的用户定期查询更新的频率。如果设置为（0）,表示不会做周期查询。	必选
CAPABILITY INFO EXPIRY	如果使用OPTIONS的机制来降低网络压力，在获取到能力时会附带一个时间标签。当终端对联系人进行能力查询时，只需发送给超时的联系人OPTIONS而不必发给所有的人。	可选 （为必选如果POLLING PERIOD的设置大于0）
USE PRESENCE	此参数用来开启或者关闭呈现能力。如果设置为（0），呈现被关闭，如果设置为（1），呈现能力打开，此时RCS2.0与呈现相关的参数适用。	必选
PRESENCE DISCOVERY	此参数控制终端是否使用呈现来发现联系人业务能力。如果设置为（0），终端不可以通过呈现来发现联系人业务能力，反之设置为（1）则可以。此参数会影响到终端在执行OPTIONS时是否包含呈现能力的信息。	可选 （为必选如果USER PRESENCE设置为1）
PRESENCE PROFILE	此参数控制终端是否支持社交呈现信息。如果设置为（0），终端不支持社交呈现信息；反之设置为（1）则支持社交呈现信息。此参数会影响到终端在执行OPTIONS时是否包含社交呈现信息的业务信息。	可选 （为必选如果USER PRESENCE设置为1）
ENABLE RCS‐E SWITCH	此参数控制是否在终端街面上固定显示RCS-E业务。如果设置为（1），终端固定显示RCS-E的状态图形；反之设置为（0）时终端只在漫游时显示RCS-E的状态图形。	必选
RCS‐E ONLY APN	此参数用来标识仅为RCS-E提供PS连接的APN	必选
FT WARN SIZE	用来设置是否提醒用户当文件传输超过特定KB大小而带来的费用。如果设置为（0）用户将不被提醒。	必选
FT MAX SIZE	文件传输上限设置，以KB为单位。如果所传文件大于此值，文件传输会失败。如果设置为（0），则没有限制。	必选
END USER CONF REQ ID	用来发送终端确认请求的标识	必选

 

网络基础与RCS架构

              RCS服务提供需要 IMS平台+SIP服务器  的支持，服务的实现以IMS标准架构作为控制平台，需要提供用以提供OMA兼容的在线状态/组列表管理和IM（即时通信）功能。

RCS架构

       

              RCS业务功能架构如图所示，服务器侧主要分为三个子系统：状态呈现和群组管理（PG）子系统、即时消息（IM）子系统、网络地址本（NAB）子系统。

              PG子系统主要包括七个部分：呈现服务器（Presence Server）、呈现文档管理服务器（Presence XDMS）、资源服务器（RLS）、资源文档管理服务器（RLS XDMS）、Aggregation Proxy、共享文档管理服务器（Shared XDMS）、内容文档管理服务器（Content XDMS）。

              IM子系统负责处理文件传输、1对1聊天、即时群组聊天的功能，包括IM共享模块、IM控制模块：

              （1）IM共享模块提供IM业务使用权限、基于用户的内容过滤、产生计费信息；

              （2）IM控制模块可以将即时群组聊天请求发送给所有的被邀请方、产生计费信息；

              NAB子系统负责提供用户通信录的网络存储、与用户终端的同步等功能。NAB采用SyncML协议将用户终端上的地址本数据备份到网络侧服务器，并允许用户将备份数据下载到终端上，从而满足了用户丢手机时找回地址本的需求和换手机时迁移地址本数据的需求。

 

                          呈现服务器（Presence Server）接收并存储发布者的发布的呈现信息（业务能力和hyper-availability），当发布者的个人文档或呈现信息改变时通知观察者（watcher）。用户终端（UE）、其他的应用服务器（AS）都可以作为订阅者（Watcher），向呈现服务器订阅指定用户的呈现信息；

                          呈现文件管理服务器（Presence XDMS）管理有关呈现信息的文档，如呈现授权策略，并且接收相关呈现文档的变化的订阅以及发送变化的通知；

                          资源列表服务器（RLS）支持用户使用订阅列表来订阅一组用户的呈现信息；用户的订阅列表信息保存在RLS上，由用户自己来维护；

                          资源列表文件管理服务器（RLS XDMS）管理有关资源列表文档，如呈现列表，并且接收相关资源文档的变化的订阅以及变化的通知；

                          聚合代理（AP）提供用户XCAP接入的鉴权，为XCAP请求服务器提供代理分发功能；

                          共享文档管理服务器（Shared XDMS）存储用户联系人列表（RCS列表，Block列表，Revoke列表），接收相关网元的订阅提供文档变化的通知；

                          内容服务器（Content XDMS）存储并且管理呈现的MIME对象；

 

RCS接口

               

              RCS平台提供SIP、XCAP、MSRP、SyncML、SOAP、SNMP等接口与周边网络或者接入终点互联。

              RCS平台通过XCAP/MSRP与RCS终端直接相连，实现RCS列表/规则管理、个人静态数据更新、授权、聊天媒体、文件传送等。

              RCS平台使用SIP消息经过CSCF与终端交互，实现 订阅、通知、呈现、 聊天信令、文件传输信令。RCS服务器中PGM负责前三种信令，IM服务器负责后两种信令的处理。

              RCS平台作为NTP Client从NTP Server同步系统时钟。

              RCS平台使用SyncML协议与终端交互，实现用户地址本的网络存储、同步到用户终端等功能。

              RCS终端通过SIP（IMS Gm接口）与IMS核心网实现注册鉴权、注销、能力查询、订阅、通知、呈现、聊天信令、文件传输信令、内容共享信令的交互。

              业务管理系统通过SOAP来实现业务的运营管理，包括用户业务受理、业务变更、客户服务等。

              网络管理系统通过SNMP来实现IMS业务模块的加载和调测；除此之外，网络管理系统还用来检测IMS业务的告警和日志。

              计费接口，支持离线计费和在线计费两种模式，

                    离线计费：RCS业务平台生成计费话单，并定期使用离线接口通过FTP方式将计费话单提交给计费服务器；

                    在线计费：RCS业务平台生成计费话单，并实时通过Diameter接口将计费信息提交给计费服务器。

 

 

关键技术要求

1，RCS会话的兼容性强于其它任何IM软件

              一次RCS会话可以同时允许CS域接入、IMS域接入、固网接入。

              一次RCS会话中中含各种媒体流、信令流，它们可能分别通过CS域互通、IMS域互通。

              RCS业务是否能成功的关键在于服务的互通程度，也即无论用户使用哪种网络都能确保在与其家人、朋友及同事通信过程中切身感受到RCS业务带来的好处。

 

2，内容共享技术（ 视频共享通过RTP，图片共享通过MSRP）

  内容共享技术基于GSMA IR84、IR74，它明确了和呼叫无关的视频共享的以下技术要求：

          支持PC终端、移动终端等多种接入方式。

          多终端支持： IMS核心网根据被叫用户预配置的触发规则触发 视频共享应用服务器，被叫用户可选择由 任意一个终端接受请求，进行视频共享。

          点对点视频共享不需经过视频共享应用服务器。

          增加了多终端视频共享的流程，支持pre-condition方式 和非prec-ondition

          对于RTP的NAT穿越，可采用 STUN（NAT的UDP简单穿越）技术或空RTP包保活。

 

3，文件传输技术（文件传输通过MSRP）

文件传输技术基于GSMA IR79 和OMA IM制定，包含以下方面：

          支持PC终端、移动终端等多种接入方式。

          多终端支持： IMS核心网根据被叫用户预配置的触发规则触发 文件传输应用服务器，被叫用户可选择由 任意一个终端接受请求，进行文件传输。

          文件传输发起方式有 通信录/通信记录、媒体库/文件浏览器以及IM聊天窗口等。

          被叫用户的 选择性接收：用户可根据等待被接收的文件的大小和类型选择接受或拒绝接受文件传输请求，运营商有权限设置文件传输的最大文件大小和文件格式。

          使用 MSRP进行文件传输，发送方客户端要求采用 en-block发送文件数据，同时接收端客户端要求支持 en-block和分片(chunk)文件数据传输。

 

4，业务能力指示技术

                用户可以直接在通信录中查询到好友支持的 业务能力信息，这些信息指明了当前有哪些通信能力可以被用户使用，用来与联系人进行沟通，例如，语音、短信、文件传输等。并直接发起通信

                在RCS-e中，业务能力指示首选使用 SIP OPTIONS消息，通过终端间 点对点交换信息实现。

 

5，RCS业务运营商间互通

                为实现对跨运营商的RCS信令及媒体互通，同时保证网间通信的安全性及可靠性，需要在运营商间部署 RCS业务互通网关。RCS业务互通网关应具备以下功能：

        安全及管理功能：信令加密、拓扑隐藏、计费结算；

        路由及寻址功能：路由解析与转发、地址转换；

        协议互通功能：SIP、MSRP、XCAP。

 

6，开放RCS API

                RCS-e标准组在GSMA One-API框架内为所有RCS服务定义开放API，主要工作在OMA ARC标准组进行制定。

                OMA定义的标准化API包括：RCS网络通讯录、RCS呼叫功能、RCS聊天功能、RCS文件传送、RCS视频/图像共享、RCS在线状态、OAuth框架等。

与已经发布的IMS业务能力开放系列规范API开放列表相比较，OMA新增网络通信录、文件传输、视频/图片共享等API。

             

      对运营商来说，RCS是短信之后的另一个开放平台

 

 

 

RCS业务流程

一、增强型地址簿

1 共享社交型通话

                用户A、B的终端都可能是手机或宽带接入的固定终端。XDM Server上存储了用户A、B的Contact地址。Presence Server上存储了用户A、B的在线状态。

 

特点：

          访问终端可以是手机或者安装了客户端的宽带终端；

          该邀请的授权基于对等性原则。如果共享社交型通话在邀请后被接受，所有用户都会看到对方的通话属性，如果一方终止通话，则所有方都会终止查看对方的通话属性。该方式允许在对方没有电话号码的情况下使用昵称发起邀请。

 

2 业务能力查询

  用户A、B的终端都可能是手机或宽带接入的固定终端。XDM Server上存储了用户A、B的Contact地址。Presence Server上存储了用户A、B的在线状态。

  Step 1，用户B在他的PC机上打开RCS终端，并且把这些能力使能：呼叫中共享、聊天中共享。这些能力也被Presence Server中存储起来。

  Step 2，用户A如果订阅了 用户B 的能力，则用户A会收到一个通知：告知用户B的能力被改变，并且在用户B的联地址本图标集上会增加其它的图标，显示用户B拥有共享、聊天的能力。

 

特点：

          访问终端可以是手机或安装了客户端的宽带终端；

          用户组中所有联系人都可以被告知某用户的业务能力信息，并在菜单中添加相应的操作图标。

 

3 高可用性

          用户A修改可用性参数，设置为可用或不可用（忙，无通信意愿）来表明此时刻的通信意愿。

          拥有用户A呈现状态的RCS用户可看到其通信意愿状态，此显示状态将在5分钟后消失。

            这个信息存储在Presence Server，订阅与通知都通过Presence Server交互。

 

4 个性化留言

          RCS允许用户在其个人联系信息中添加一段简短的个性化留言；

          RCS用户可以在不同设备终端更新个性化留言，通讯薄中拥有该用户社交呈现信息的用户可在不同设备终端会看到其更新的个性留言。

            这个信息存储在Presence Server，订阅与通知都通过Presence Server交互。

 

5 头像变更

          RCS允许用户改变其个人头像(如通过PC 客户端来更新头像)，新头像图标会存放在XDM服务器上，同时呈现Presence 服务器也会被告知该行为。所有设置成关注该用户的联系人(各种终端)都会被告知这个替换行为，同时自动从XDM服务器上取得该用户的新头像。

          如果某用户是非VIP用户，但其联系信息已进行了更新，则VIP用户无法立刻看到该更新。直到VIP方用户的客户端主动检查非VIP方是否有更新或用户自己进行更新操作。

 

二、增强型呼叫

1视频呼叫

      主叫用户A是手机接入。被叫用户B同时打开两个终端（手机、PC机）。双方能力通过Presence server交互。

Step 1：主叫用户A发现他的地址本(enhanced Address Book)显示用户B有视频呼叫的能力，则用户A点击 地址本上用户B的图标 发起视频呼叫。这个视频呼叫仅能在主设备（手机）上建立。

Step 2：这个视频呼叫通过 CS域建立。

Step 3：被叫用户B的主设备（手机）上建立了CS域视频呼叫。仅手机终端能收到呼叫请求。

 

特点：

          增强型地址簿会首先确认用户是否具备视频通话的能力，视频通话只能在手机之间进行；

          一个CS视频呼叫会通过CS域建立起来。

 

2视频共享

      主叫用户A是手机接入。被叫用户B同时打开两个终端（手机、PC机）。双方能力通过Presence server交互。

Step 1：主叫用户A发现他的地址本(enhanced Address Book)显示用户B有 共享(Sharing) 的能力，则用户A点击 地址本上用户B 发起语音呼叫。

Step 2：这个语音呼叫通过 CS域建立，信令中携带了 共享的选择项(Sharing Option) 发给被叫用户B。

Step 3：用户B通过手机接收了CS域呼叫。

Step 4：主叫用户A通过 IMS域信令传递　共享细节(Sharing details) 给被叫用户B，被叫侧也会选择一种或几种共享，如视频共享 回应给主叫用户A，并选择他的PC终端来接受视频共享(Video Share)

Step 5：用户A选择共享的视频，通过 PS域发给被叫B的PC机终端。 (MSRP协议）

 

          增强型地址簿首先鉴别用户是否具有视频共享的功能；

          用户A通过CS域建立一个包含共享选项的语音呼叫，等待用户B接收；

          共享的细节内容通过IMS域进行传输；

          所有共享的选项都将在用户A的手机上显示出来，选择视频共享选项；

          用户B可以选择PC或者手机用来接收共享视频资料；

          视频最终通过PS域进行共享。

注：当语音通话终止时，视频共享仍然可以进行，宽带带宽越高，视频接收质量也越高。

 

3图片共享

图片共享(Image Share)流程与 视频共享 流程一样，区别是主叫用户A可能是手机或宽带接入。 (MSRP协议）

 

在RCS中，和视频共享原理一样，用户可以进行图片共享。

          增强型地址簿首先鉴别用户具有图片共享的能力；

          用户A通过CS域建立一个包含共享选项的语音呼叫，用户B同意语音呼叫；

          共享的细节内容通过IMS域进行传输；

          所有共享的选项都将在用户A的手机上显示出来，选择图片共享选项；

          用户B可以选择PC或者手机用来接收共享图片资料；

          图片最终通过PS域进行共享。

 

 

三、增强型消息

1会话中发送短信和彩信

                Step 1：主叫用户A与被叫用户B的 会话已经建立，通过手机建立会话。

                Step 2: 短信和彩信通过在IMS域中的短信服务器进行传输，如果短信很大，则可采用PS域进行传输。

                                      即：IMS域中通过SIP message发短信。PS域中通过MSRP发短信。

RCS允许用户在会话过程中发送短信或彩信，相比较SMS短信，增强型短信的限制更少。同时用户可以要求收到一个发送和被读取情况的报告。

 

2 一对一或多方聊天

Step 1：用户A的增强型地址薄中显示：用户B有聊天能力。

Step 2：用户A选择聊天图标，并发送信息：Hi

Step 3：聊天邀请与会话都通过IMS域的IM服务器进行管理。

                                      即：通过IMS域的SIP协议发送聊天邀请，并建立MSRP会话。

Step 4：用户B的手机、PC机都显示第一个消息：Hi

Step 5：用户B在PC客户端回复消息。

Step 6：聊天通过PS域使用MSRP，并被IM服务器管理。

      聊天会话一般在2个参与者之间进行，也可扩展到多个参与者。

 

四、文件传输

                        RCS允许用户直接进行文件传输操作。用户需首先设置文件为共享状态，选择传输选项，并通过通话服务器进行传输。

Step 1：主叫用户A的 增强地址薄 可显示用户B 具有文件传输能力。

Step 2: 用户A在功能菜单中选择共享文件选项。

Step 3: 文件传输请求通过IMS域传送。

Step 4：用户B已经同时打开了手机端与PC端。

                              用户B在PC端接受文件传输请求。

Step 5：文件通过PS域进行传送。(MSRP协议）

               

RCS-e

 

 

RCS对SIP\IMS架构的影响

              RCS业务要求核心网网络架构基于3GPP定义的IMS R8版本。

 

                注册、认证、授权要求

RCS移动及固定接入终端应在注册时，在SIP REGISTER消息的Contact header注册其支持的所有业务标签。比如一个支持IM聊天，视频共享和图片共享的终端应注册如下的特征标签：

+g.oma.sip-im

+g.3gpp.cs-voice

+g.3gpp.iari-ref:urn:urn-xxx:3gpp-application.ims.iari.gsma-is

支持PS语音业务的宽带接入终端应注册如下的特征标签：

+g.3gpp.icsi-ref=”urn:urn-7:3gpp-service.ims.icsi.mmtel”

audio

 

                用户数据管理要求

RCS应支持用户数据的集中管理，HSS需要有标识指明用户签约了RCS业务，并且在采用Presence增强型地址簿时，Presence Server需要储存用户的永久呈现信息（头像，链接等）以及用户的业务能力指示数据。XDMS需要储存用户的社交呈现授权列表，黑名单以及授权规则等数据。

 

                多终端管理要求

RCS业务同时允许移动接入以及宽带接入，允许同一个用户申请多个不同接入类型的RCS终端，而且允许同一个用户的多个RCS终端可以同时登陆，同时收发。因此，为解决归属于同一个用户的多个终端之间存在的互操作的问题，对网络提出了新的要求，包括：

          网络应够支持对于不同接入类型终端的帐号管理，相关的帐号标识应能够指明终端的接入类型、业务类型（个人帐号、家庭帐号等），可以支持更为复杂的业务需求；

          网络应够支持多个终端之间的业务配置及数据共享，如共享网络地址簿等；

          网络需支持Forking，可以向多个公有用户标识相同的终端群发信令，当接收到某一个终端的响应时，即进行后续处理，完成相应的会话流程，同时取消发往其他终端的业务邀请；

          网络应支持区分RCS用户的主从终端，在RCS R2版本中默认移动接入终端为主终端，宽带接入终端为从终端，而在R3版本中，新增了宽带接入终端也可被作为主终端的要求。

          对于不同的业务需要进行区别分析。如对于语音呼叫，网络应向CS域移动终端，宽带接入的IMS PC终端等多个被叫终端发起寻呼，可以有多个不同方案进行处理（如终端优先级等方案）；

          当同一个用户的多个终端同时与网络交互时，网络应能够识别并处理可能引发的信令冲突；

          当网络与终端的RCS版本不符时，可以遵循以下原则：当网络支持低版本RCS业务能力，但终端支持高版本业务能力时，终端按照低版本业务功能执行，因此要求终端向下兼容；支持高版本RCS业务能力的网络，应能够支持低版本RCS终端接入。

 

                媒体编解码要求

RCS视频共享业务，网络侧相关设备必须要支持H.263编码，MP4、H.264及Real Video9等编码作为可选，运营商可根据自己的运营策略决定是否允许使用这些可选编码。

RCS图片共享业务，网络侧相关设备必须支持JPEG格式的传输,BMP、GIF及PNG等格式作为可选。对于RCS文件传输业务，网络应禁止可执行文件的发送。

 

 

                公共业务标识（PSI）

公共业务标识用于标识IMS网络中的业务，它是在一个应用服务器上为某种业务所创建的特定资源，用于将IMS域的业务路由到相应的服务器上，RCS业务公共业务标识的分配如下：

      呈现业务公共业务标识：presence@operator.com。

      群组聊天业务公共业务标识：groupchat@operator.com

      即时消息业务公共业务标识：imchat@operator.com

 

基础协议

       3GPP中定义了IMS基本架构与各种接口。

　　OMA主要定义移动服务规范，以确保运营商之间和终端之间端到端服务的互连性。OMA提出了一系列基于IMS的服务应用，每种应用都包含了客户端的功能列表、协议要求、与应用服务器之间的交互等。

 

1, 即时消息协议MSRP（图片共享、视频共享、增强型消息、聊天、文件传输）

OMA的要求

        　OMA中消息工作组定义了IMSimple服务，它允许实时地交换用户之间的即时信息。

              IMS中消息分为直接消息和基于会话的消息。

                      直接消息是通过IMS客户端直接发送和接收消息实现的（RFC3428），它适用于像短信这样单独的短消息通信。

                      基于会话的消息是通过Invite发起MSRP（messagesession relay protocol）信道协商，所有消息通过MSRP建立的信道传送，它适合于交互式的文本会话，如聊天。

                IM服务一般和呈现服务结合起来使用。通过呈现服务，用户可以将自己的好友分成不同组，并能实时地看到好友的信息。用户可以根据好友的状态发送即时消息。

                IMS客户端可以实现简单的IM服务，如只是通过消息方法进行在线即时通信，也可以增加更复杂的功能，如聊天室、会议聊天、消息历史存储、延迟消息等功能的支持。

 

MSRP简述

                RFC4975定义了消息会话中继协议(MSRP:Message Session Relay Protocol),用于在已经建立的IM 会话中传输即时消息的内容，完成信息交互过程。

                在即时消息应用中，MSRP主要是用来传送数据量较大的业务数据，如大的图片和文字消息，文件传送等，较小的业务数据一般采用SIP协议的MESSAGE消息来传送。

                即时消息业务可以分为三种子类型：

                                      Page-mode：

传统的即时消息业务中，每一条消息都是独立发送，消息之间没有关联，这种模式也叫“寻呼模式”的即时消息。

 

                                        Session-Mode：

会话模式的即时消息业务，则在传递即时消息时，需要通过 SIP先建立会话，所有 MSRP消息的交互都是在这个会话内进行。会话内传递的即时消息可以看作是这个会话中用户和用户之间的 媒体流，即：会话内媒体流通过MSRP协议传递。

 

                                      Large Message Mode：

使用MSRP协议来发送单条比较大的消息（如超过1300个字节），由于使用了MSRP协议，所以发送前会建立SIP会话，该消息发送完后会将SIP会话被释放。这种方式下，不会建立即时消息会话。

                                        MSRP协议支持即时消息的分段发送。分段机制只适用于MSRP的SEND请求。在MSRP协议中，同一条即时消息的所有分段消息都拥有相同的Message-ID。

 

                在Page-mode模式下，消息直接以SIP的MESSAGE方法发送，该模式一般只用来传送小型的IM消息。

                  Large Message Mode模式和Session-Mode模式发送即时消息时，使用MSRP协议。

                MSRP只用在用户面之间，而即时消息在这个即时消息会话中的传递是用户到用户的。但也可以 通过中继点中转。

                MSRP媒体面的连接是基于TCP的。

 

MSRP消息

              MSRP是一种基于文本的、面向连接的协议，可用于交换 二进制的MIME内容，尤其是即时消息。

              MSRP定义了两种请求类型：

              ——SEND请求：SEND用来递送一则完整的即时消息或一条分段消息（chunk）。这里的分段消息是指一则完整消息的一部分，例如拆分成多条消息后其中的一条。

              ——REPORT请求：REPORT用来传送之前发送的消息的状态报告，或者是关于消息中字节范围的报告。

              接收方收到SEND请求后应产生适当的响应，但是无需对REPORT请求发送响应。

              响应是事务性的，是对请求的证实，表示 下一跳端点是否收到该请求； 报告则是端到端的，表示请求是否最终送到最终的实体。

 

MSRP请求行表示请求消息的开始，包括请求名称、事务ID。事务ID在同一时间必须唯一，它至少包含64比特的随机数。

头字段包括To-Path，From-Path、Message-ID、Byte-Range、Failure-Report、Success-Report、Status等。

—— To-Path：用来指示收端的地址。如果该字段中有多个URI地址，最左边的地址是需要率先访问的，最后的则最后访问；

—— From-Path：用来指示发送方的URI地址；

——Message-ID：用来标识发端用户期望传递给收端用户的即时消息，REPORT请求的Message-ID必须与对应的SEND请求的Message-ID一致。如果该即时消息被拆分成多条分段消息，则每条分段消息的Message-ID都应该一样；

——Byte-Range: 该头字段用于指示该分段消息在整条即时消息中所处的位置；

 

如果包含消息体，则请求中还应含有Content-Type头字段。此外，还可能有一些特定MIME消息体相关的头字段。

 

结束行表示请求消息的结尾，包含七个连续的“-”符、事务ID和标志符。事务ID应与起始行中的事务ID一致。

标志符的取值有$、#和+，其含义为：

——“+”：表示该分段消息不是一条完整即时消息的最后一个分段消息；

——“$”：表示该分段消息是一条完整消息的最后一条分段消息；

——“#”：表示终止发送一条尚未完成的消息，且并不打算发送后续分段。

 

当MSRP端点收到一条消息，或一条消息的多个分段消息，且这些消息中的Success-Report头字段设成“yes”，则它应产生一个或多个报告，说明已经收到的内容。

 

MSRP对SIP的要求

                MSRP媒体流应在建立的TCP或TLS/TCP连接中传递。该连接的建立需要SIP和SDP协议的支持。

                SIP协议用以在两个MSRP端点（如即时消息用户终端）之间会话。

                通常语音类的会话需要被叫用户应答之后才能建立，但对于即时消息业务来说，用户更习惯于即时消息直接呈现出来而不需要用户确认。因此建议MSRP端点可以支持 自动接受会话请求的模式，即收到INVITE请求，能够自动产生针对INVITE的200 OK响应。

                如果MSRP端点支持早期媒体，MSRP端点也可以实现在会话建立之前传送即时消息。

 

MSRP对SDP的要求

        基本要求

                        MSRP端点的媒体协商通过SDP的协商来完成。SDP的协商依然采用SDP Offer和SDP Answer的交互的方式。期望建立 TCP连接的两端需要把各自的MSRP地址信息和支持的媒体类型放在SDP中提供给对方。

                MSRP协议中使用的SDP Offer和SDP Answer的示例见附录D。

        URI的协商

                        MSRP端点的地址通过MSRP URI来提供。每个SDP Offer或SDP Answer都会包含一个“path”属性，这个属性会带上一个或多个MSRP-URI。“path”属性通过SDP的“a”行提供。这里MSRP-URI可以是msrp URI，也可以是msrps URI，

                        Path中如果带有多个MSRP-URI，最右边的一个URI是产生这个SDP的端点的URI，其他的都是中继点的URI。从左到右的URI分别表示离对端由近及远的顺序排列的中继点的URI。也就是说，第一个也是最左边的一个URI是离对端最近的一 个中继点的URI。如果用户建立了多条连接，不同连接的URI不能相同。

                        SDP交互完成后，MSRP端点之间就可以建立连接。

 

URI

                PRES URI是一种新的通用的资源标识，用以标识即时消息业务中的呈现实体（Presentity）和观察者（Watcher）。PRES URI的示例如下：

示例：pres:fred@example.com

呈现业务的客户端根据目的地PRES URI中的域名部分的解析确定下一条的路由。

 

        IM URI

IM URI用来标识即时消息的收件箱。IM URI的示例如下：

示例：im:fred@example.com

IM业务的客户端根据目的地IM URI中的域名部分的解析确定下一条的路由，并将即时消息前转出去。

 

  MSRP URI

                MSRP端点的地址通过MSRP URI来标识。这里说的MSRP URI包括两种URI，即msrp URI和msrps URI。后者用于TCP连接受TLS保护的场景。

                MSRP URI是一个临时的URI，它与特定的会话关联。同一个MSRP端点在不同的会话中的MSRP URI是不一样的。

                MSRP URI遵循URI的一些基本语法，它采用的方案（sheme）是“msrp”和“msrps”。详细语法见6.7节。

                在MSRP URI中，“authority”字段标识一个会话的参与方。如果该字段是一个IP地址，则应带上端口号。“session-id”标识参与方的一个特定的会话。“session-id”缺省的情况下表示MSRP设备本身，而不是该MSRP设备中的某个会话。

 

 

MSRP流程

                上面是最基本的消息会话的信令流程。在这个流程中，会话由SIP协议建立，消息媒体由SDP来协商。即时消息通过MSRP协议在用户面进行端到端的传递。为了简化，流程中省略了一些SIP消息，也没有画出中间服务器。

 

消息的具体参数字段如下。同样，出于简化的考虑，下面的消息只给出了关键的参数字段。

    (1) Alice->Bob (SIP): INVITE sip:bob@example.com

            v=0

            o=alice 2890844557 2890844559 IN IP4 alicepc.example.com

            s= -

            c=IN IP4 alicepc.example.com

            t=0 0

            m=message 7777 TCP/MSRP *

            a=accept-types:text/plain

            a=path:msrp:// alicepc.example.com: 7777/iau39soe2843z; tcp

  (2) Bob 侦听8888端口，并发送下面的响应:

            Bob->Alice (SIP): 200 OK

            v=0

            o=bob 2890844612 2890844616 IN IP4 bob.example.com

            s= -

            c=IN IP4 bob.example.com

            t=0 0

            m=message 8888 TCP/MSRP *

            a=accept-types:text/plain

            a=path:msrp:// bob.example.com:8888/9di4eae923wzd;tcp

  (3) Alice->Bob (SIP): ACK sip:bob@example.com

  (4) Alice打开到Bob的连接，并通过MSRP向Bob发送即时消息：

            MSRP d93kswow SEND

       To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp

       From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp

            Message-ID: 12339sdqwer

            Byte-Range: 1-16/16

            Content-Type: text/plain

 

        Hi, I'm Alice!

            -------d93kswow$

  (5)  Bob->Alice (MSRP):

            MSRP d93kswow 200 OK

            To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp

            From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp

            -------d93kswow$

  (6)  Bob->Alice (MSRP)，Bob也向Alice发送给即时消息:

       MSRP dkei38sd SEND

            To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp

            From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp

            Message-ID: 456s9wlk3

            Byte-Range: 1-21/21

            Content-Type: text/plain

 

            Hi, Alice!  I'm Bob!

            -------dkei38sd$

  (7)  Alice->Bob (MSRP):

            MSRP dkei38sd 200 OK

            To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp

            From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp

            -------dkei38sd$

  (8)  Alice向Bob发送SIP：BYE，结束会话。

  (9)  Bob->Alice (SIP): 200 OK

 

              即时消息拆分成多条消息后，每一条分段消息都放在一个MSRP协议的SEND请求中发送。下面的例子将一条即时消息拆成两条，并分别通过两个MSRP协议的SEND请求来发送。该例子中假定即时消息通过CPIM消息封装。

              CPIM的元数据头只出现在第一个分段消息中，但MSRP的Content-Type和Byte-Range头字段在每条分段消息中都应该提供。

 

 

2, Presence呈现协议（增强型地址簿、业务能力查询、高可用性、个性化留言）

OMA对于Presence的规定

　　OMA中呈现和可用性工作组定义了PresenceSimple服务。呈现功能是许多IMS应用的基础。

              IMS客户端既是呈现者也是观察者。呈现者是信息源，提供呈现信息给呈现服务器；观察者则请求获取关于呈现者的呈现信息。

            呈现服务器存储订阅者和产生呈现信息改变通知。呈现信息包括网络信息、用户当前的状态，也包括用户终端的能力等。有些呈现信息是网络侧提供的，如用户是否已经注册；有些是呈现者提供的，如呈现者设置的通信偏好。

                呈现者的状态只能被已授权的观察者看到，因此当某个观察者想订阅某个用户的状态信息时，需要呈现者的确认，呈现者有权拒绝观察者的订阅请求。

                观察者一般通过一个资源列表订阅一组呈现者的呈现服务，由资源列表服务器再向呈现服务器逐个订阅呈现信息，这样能够减少IMS客户端的负担和网络负载。

                在协议方面，呈现者通过Publish方法发布自己当前的状态，观察者通过Subscribe订阅呈现服务，呈现服务器通过Notify通知观察者其订阅用户的状态信息改变，呈现者也可以通过Subscribe订阅能获取其呈现信息的观察者列表。

                资源列表和呈现服务授权是通过XCAP实现的。每个资源列表和呈现服务授权都是一个单独的XML文档，IMS客户端可以通过XCAP生成和修改这些文档。

                IMS客户端需要一个友好的人机界面，同时需要实现相应的SIP消息类型扩展和XCAP，才能给用户提供一个完整的呈现服务。

 

Instant Messaging（即使消息）和Presence（好友）业务 的概念

                  rfc里描述Presence业务模型为：

      Presentity和Watcher都是客户端，其中Presentity提供Presence信息，Watcher接收信息。这两类功能通常在一个应用程序上实现。

      Watcher功能又可以如下图分为几个部分：

      Subscriber：表示Watcher向Presence Service订阅某个 Presentity的Presence信息；

      Fetcher：表示Watcher向Presence Service查询某个 Presentity的Presence信息；

      Poller：表示根据某种条件查询所有的Presentity的Presence信息。

 

      与Presence业务类似，Instant Message的模型如下：

      参考资料：

      Rfc 2778: A Model for Presence and Instant Messaging

      Rfc 2779: Instant Messaging / Presence Protocol Requirement

      Ietf draft: Common Presence and Instant Messaging (CPIM )

      URL: http://www.ietf.org/html.charters/impp-charter.html

 

XMPP协议和SIMPLE协议

               

              SIMPLE：SIP for IMP Leveraging Extensions

              SIMPLE：SIP for Instant Messaging and Presence Leveraging Extensions；

              PIDF：Presence Information Data format，SIMPLE中Presence数据格式的通用定义；

              Presence User Agent：

              操作零个或者多个Presentity的逻辑实体；本身应该不在Presence System之内的。从终端的角度来说，实际上就是有关Presentity状态显示的模块，它与Presentity之间是“model/view”之间的关系；

              Presentity(presence entity)：

              提供Presence信息给Presence Service的逻辑实体；

              Presence Agent（PA）：

              可以接收SUBSCRIBE请求和返回NOTIFY的SIP user agent。PA必须知道Presentity的状态，这可以通过两种方法来实现，一是直接从proxy/registrar那里得到状态，二是与Presentity上的Presence User Agent在一起。协议没有规定采用哪一种方法；

              Presence Server：

              既是Presence Agent又是Proxy的实体；

              Edge Presence Server：

              既是Presence Agent又是Presence User Agent的实体；

 

                在IETF有两个工作组分别提出了实现Presence协议的不同框架：基于XML的XMPP协议和基于SIP的SIMPLE协议

 

 

 

 

3,  Group Management群组管理协议（头像变更）

GM功能简介

                        组用户的管理一般不用SIP协议，3GPP、OMA推荐使用的是XCAP协议；

                        XCAP允许用户上传信息到XCAP服务器，通过HTTP更改、增加和删除存储在服务器上的XML文档。XCAP复用了HTTP中的Get、Put和Delete方法来获取、更改/增加和删除XML文档。通过一套巧妙的方法，将XML文档的存储路径和文档中的条目、元素和属性映射到HTTP中的URL路径

                      在IMS网络中，IMS客户端和应用服务器（applicationserver，AS）之间的交互接口是Ut接口，用户可以通过它安全地管理和配置存储在AS上与网络服务相关的信息。Ut接口使用XCAP协议。

                        在语音业务中，Ut接口配置各补充业务的业务配置信息，如前转是否开通、前转号码等。

                        在RCS中，Ut接口可配置的信息是 Presence服务中的 资源列表和呈现服务授权 。

 

群组管理系统GM的基本功能包括：

          用户个人信息管理（Shared Profile）：为用户的个人信息提供网络管理的能力，包括用户的个人信息。

          用户联系人列表管理（Shared List）：对用户联系人列表的信息保存和维护；用户默认有三个联系人列表，用户地址簿、黑名单列表和白名单列表。

          用户群组管理（Shared Group）：对所有用户公有群组的管理，以及邀请用户加入群组。

支持用户通过SIP请求来订阅用户个人信息、用户联系人列表信息、用户群组信息的变化情况。

 

从应用功能来说，GM与UE、AS有接口，均是XCAP、SIP。

UE从GM得到用户个人信息、发起群组信息管理指令.

其它IMS AS指需要使用群组管理平台提供的服务 的AS，例如PS、PoC、IM等。IMS AS对于群组管理平台来说等同于UE。不再细谈。

 

GM协议的功能点

GM与UE的接口分为两类，分别基于XCAP协议和基于SIP协议。

 

XCAP协议 包括

1．      服务器能力查询

              IMS终端用户和IMS AS可以查询当前服务器支持的application usages、扩展和命名空间。对于IMS终端用户来说，该操作只能由手机终端或者PC终端通过XCAP协议来查询，而不能通过Portal来完成。

2．      用户个人信息管理

              包括查询/修改个人用户信息。

3．      联系人列表管理

              包括添加/修改/删除联系人信息；创建/删除/查询分组；添加/删除分组成员；查询联系列表。

4．      群组管理

              包括创建/修改/删除/查询群组、 模糊查询当前服务器上所有群组；群组管理员邀请成员加入群组、用户对邀请者的应答；用户主动申请加入指定群组、群组管理员对申请的应答；群组管理员删除群组成员、群组成员修改自己的群组属性、群组成员退出群组。

              需要说明的是，IMS架构中，聚合代理（AP）用于对用户终端的XCAP请求的统一接入代理，并在此进行权限验证和请求分发。群组管理平台和UE XDMC两个功能模块在传递信息的过程中要经过聚合代理。

 

 

基于SIP协议的接口功能

1.      文档订阅管理：支持群组管理平台上文档状态改变的订阅、通知功能。

2.      群组订阅管理：支持群组状态改变的订阅、通知功能。

 

流程举例

1，修改用户个人信息

1. 请求

PUT http://xcap.example.com/services/ims-pim/user/sip:bill@cmcc.com/index/~~/persion-info/user-info/contact-info/other-tel/home-tel HTTP/1.1

…

Content-type: application/xcap-el+xml

Content-Length: (…)

 

<home-tel>075528780808</home-tel>

 

2. 应答

HTTP/1.1 200 OK

Etag: “hihihi”

…

Content-Length: 0

 

 

2，      查询用户个人信息

 

1.请求

GET http://xcap.example.com/services/ims-pim/user/sip:bill@cmcc.com/index HTTP/1.1

…

Content-Length: 0

 

2.应答

HTTP/1.1 200 OK

Etag: “acdcd”

…

Content-type: application/ims-pim+xml

Content-Length: (…)

 

<  xml version="1.0" encoding="UTF-8"  >

<person-info xmlns=”com:cmcc:ims-pim”>

      <user-info>

              …

      </user-info  >

      <private-group-list>

              …

      </private-group-list>

      <public-group-list>

              …

      </public-group-list>

</person-info>

 

3，添加联系人

1. 请求

PUT

http://xcap.example.com/services/resource-lists/user/sip:user@cmcc.com/addresslist.xml/~~/resource-lists/list[@name="Address List"]/entry[@uri="sip:lisa@example.com"]

…

Content-type: application/xcap-el+xml

Content-Length: (…)

 

<entry uri="sip:lisa@example.com">

      <display-name>Lisa Jones</display-name>

      <info>

              …

      </info>

</entry>

 

2.应答

HTTP/1.1 200 OK

Etag: “cdcdee”

…

Content-Length: 0

 

4，文档订阅(SIP SUBSCRIBE)

              IMS终端用户和IMS AS可以订阅群组管理平台中的XML文档的改变状态，IMS终端用户只能订阅自己有访问权限的文档，IMS AS可以订阅所有的文档信息。

1. 请求

SUBSCRIBE sip:footballteam_group@example.com SIP/2.0

Via: SIP/2.0/UDP user1.example.com;branch=z9hG4bKnashds7

Max-Forwards : 70

From : <sip:user@example.com>;tag=312345

To : <sip:footballteam_group@example.com>

Call-ID : 105637921@example.com

CSeq : 1 SUBSCRIBE

Event: xcap-diff

Expires : 3600

Accept : application/xcap-diff+xml

Contact : <sip:user@example.com>

Content-Length 0

 

2. 响应

SIP/2.0 200 OK

From : <sip:user@example.com>;tag=312345

To : <sip:footballteam_group@example.com>;tag=312349

Call-ID : 105637921@example.com

CSeq : 1 SUBSCRIBE

Contact : <sip:group.example.com>

Expires : 3600

Content-Length : 0

 

5，文档订阅通知

  当订阅者订阅了群组管理平台中的XML文档后，如果被订阅的文档发生了改变，群组管理平台将对订阅者进行通知。

1.请求

NOTIFY sip:user@example.com SIP/2.0

Via: SIP/2.0/UDP group.example.com:5062;branch =  z9hG4bKnashds7.1

From: <sip:footballteam_group@example.com>;tag=312349

To: <sip:user@example.com>;tag=312345

Call-ID: 105637921@example.com

CSeq: 1 NOTIFY

Event: sip-profile

Contact: <sip:group.example.com>

Subscription-State: active;expires=3600

Content-Type: application/public-group+xml  //扩展

Content-Length: …

 

<  xml version="1.0" encoding="UTF-8"  >

<public-group xmlns="com:cmcc:public-group"

              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

      <list name="Football Team" uri="sip:footballteam_group@example.com">

              //群组成员

              <entry uri="sip:user@example.com">

                      <display-name>User</display-name>

                      <info>Forward</info>

              </entry>

              <entry uri="sip:gaoyanfeng@example.com">

                      <display-name>Gao Yan Feng</display-name>

                      <info>Defend</info>

              </entry>

      </list>

</public-group>

 

4，SyncML

    UE通过数据同步接口实现地址簿的上传、下载和数据同步。该接口遵循OMA DS 1.2.1协议。

      该接口应支持如下功能：

                  地址本同步：采用OMA SyncML DS 协议定义的“慢同步(Slow Sync)”、“双向同步（Two-way Sync）”方式实现；

                  地址本备份/恢复：采用OMA SyncML DS 协议定义的“刷新同步(Refresh Sync)”方式实现；

                  地址本自动更新：采用OMA SyncML DS 协议定义的“服务器通知同步（Server Alerted Sync）”与“双向同步(Two-Way Sync)”方式实现；

                  多设备支持：支持在用户的多个终端设备之间保持统一通信录的功能。