xcap

1RCS系统架构

图1RCS网络图

上图描述了了RCS的总体框架图。出于兼容性的目的，RCS基于用户-网络接口（UNI），

网络-网络接口（NNI）来实现，涉及到如下一些规范;

呈现与能力的获取（Discovery）；

视频共享；

图片共享；

消息；

对于UNI和NNI的具体应用关系，参考下图：

图2UNI-NNI关系图

2概述

2.1寻址

联系人SIP请求的接收、发送，其标识是电话号码，接下来讨论的一些寻址的格式，仅

限于RCS服务。对于prencesubscriptions、群组聊天，也适用这种号码格式。

2.1.1设备呼入SIP请求

对于设备呼入SIP请求，联系人的地址依赖于请求的类型。该地址以URI的形式存在，

或者包含在请求体（BodyofRequest）中，或者包含在请求P-Asrted-Identity头及From头

中。如果P-Asrted-Identity头存在，则From头将被忽略。接收方需要按照如下的几个方式

来从URI中提取出电话号码。

TELURI形式，比如：tel:+1234578901，或者

tel:;phone-context=；

SIPURI形式，其中必须包含ur=phone的参数，比如：

sip:+1234578901@;ur=phone，或者

sip:;phone-context=@;ur=phone；

除了这两种形式，不推荐使用其他形式的地址格式。由于与其他基于IMS的服务同网，

可能就会收到其他形式的URI，其处理方式依赖于客户端程序的处理。

2.1.2设备呼出SIP请求

RCS客户端可以使用RCS电话本中的电话号码或者用户输入的数字串作为地址。该地址

用于1对1通信的SIP请求URI（SIPRequestURI）或者TO头中，该地址也用于群组通信的

呼出SIP请求的接收人列表URI。

对于国际号码，RCS设备需要支持TEL-URI形式，比如tel:+，也要支持SIPURI

形式，比如sip:+1234578901@;ur=phone，注意ur参数的值。根据运营商的

需求及国家SIP-SIP互连框架的通用规范要求，这个形式是需要能够在设备端进行动态配置

的。如果并没有强制约束与上述两种形式，推荐使用TELURI的形式，因为SIP-URI的域名并

没有多少意义。

对于非国际号码，RCS客户端需要支持TEL-URI或者SIP-URI（带有ur=phone参数，以

及phone-context值）形式，比如tel:;phone-context=。同

样，根据运营商的需求及国家SIP-SIP互连框架的通用规范要求，这个形式是需要能够在设

备端进行动态配置的。如果并没有强制约束与上述两种形式，推荐使用TELURI的形式。

对网络的自我身份鉴定及被访问的联系人：

被呼叫者能够鉴别呼叫者身份的主要标识就是电话号码，为此，呼叫者应该将其TEL-URI

放在P-Preferred-Identity头中。该TEL-URI可以由呼叫者设备提供，或者在注册时从网络接

收到的P-Associated-URI头中提取。

From头也需要与P-Preferred-Identity头相同的TEL-URI来设置。而且，这个规格也适用

于群组聊天中MSRPSENDS的CPIMFrom头中。

2.2注册

RCS客户端需要注册它所支持的所有服务的特征标签（TAG），这些标签放在SIPREGISTER

信息的contact头中。对于每个特征标签的详细结构，需要参考[VIDEOSHARE]，[IMAGESHARE]

及[IMENDORSE]文档。比如，对于支持消息、视频共享、图片共享的RCS客户端，则其服

务特征标签如下:

+-im

+-voice

+-ref:urn:urn-xxx:-is

2.3会话响应

当一个RCS用户拒绝了一个会话请求，比如聊天、文件传输、视频图片共享等请求，

RCS客户端需要回应一个SIP603响应给请求方。

3呈现及能力发现

3.1架构

图3RCS呈现总体框架图

图4RCS呈现架构

3.2呈现数据模型

3.2.1Person

属性规格注释

Person：

->

RFC4479根据prence框架规范，person相关信息

被模型化为person元素，每个客户只能有

一个person元素；

Willingness:

->

->->Open

OMA呈现终端通过发布Willingness属性来表达

自己是否愿意进行通信。具体如下：

“Open”=Willing

“Clod”=NotWilling

Attributenotprent=Unknown

Icon:

->

RFC4480

Icon作为person的一个动态化身，如果不

设置该属性，则以电话本中的icon来替代。

该图片不能直接包含在prence的请求中，

而是使用HTTPURL的地址方式来表示。

Pr󰀀nceContentXDMS

过程用来上传、发布、提取图片；

FavouriteLink:

->

RFC4482

Homepage元素提供了一个指向个人基本信

息的RUI，比较典型的是一个网页。

Note:

->

RFC4479

person通过一些文本或者表情符号，来呈现

给拥有该联系人的电话本用户。

Timestamp:

->

RFC󰀀4479时间戳，prence信息被发布时的时间。

注意一些地方：

Willingness有时也可以用availability来表示。该属性由用户自主管理，并不表示通

信不能进行，在OMA规范中，这表示个属性表达的意思是Willingness（主动的意愿）。

而availability则是从技术层面上来说的可能性。这两个属性在将来的版本中将会做进一

步的研究。

Willingness如果和具有until属性值的basic->open元素结合,则表示RCS

HyperAvailability信息。如果没有该until值，则不能被解释为HyperAvailability属性。

在prentity一侧，RCS客户通过在当前时间上增加HyperAvailabilityPeriod值来获取

Until值，当前时间值用UTC格式表示。HyperAvailabilityPeriod值由运营商来配置。在RCS

客户端，通过一个标识来告知用户他的HyperAvailability状态在整个HyperAvailabilityPeriod

期间是激活的。在这个期间，用户可以去激活它的HyperAvailability状态，这通过没有

OverridingWillingness元素的发布来实现，相反的，如果要激活，则通过具有Overriding

Willingness元素的发布来实现。

接受到HyperAvailability信息的通知时，拥有该联系人的客户端应该产生一个提示，

同时，在对该用户的联系人显示产生一个明显的变化，比如一个闪烁的图片、动画等，

直到Until时间到。时间到了之后，该用户的界面显示退回到原来的显示模式。此外，在

接受到一个没有OverridingWillingness元素的发布通知时，也要退回到原来的显示模式。

RCS客户端要管理最近HyperAvailability事件的日志，并能够让该用户查看。

3.2.2Service

属性规格注释

Tuple:

->

RFC3863根据规范，rvice按照一个tuple元素的方式

呈现

Status

->->->

Open

RFC3863强制性元素，一旦一个tuple元素被发布，则

值open必须设置。在RCS上下文中，并不代

表特殊的意义。

Service-id

->

->

OMA服务描述元素描述一个服务，通过rvice-id

和版本信息来描述。rvice-id元素是一个字

符串，用来唯一标识一个服务。

Version

->

->

OMA版本元素描述一个服务，是一个具体的数字，

表示该服务的版本，以区别服务的不同版本

（阶段）。

Contact

->

RFC3863

contact元素包含了服务的Prentity通信

地址，contact地址可以是TELURI，

SIPURI的任意一种，具体依赖于使用

的服务。该元素的使用时可选的，非

强制性。在没有改元素的情况下，客

户使用电话本中的URI。

RCSprentity或者插入一个contact元素，

或者不插入任何元素。

Timestamp

->

RFC3863时间戳，prence信息被发布时的时间。

注：

注册的各种服务描述：

CSVoiceCall

Service-id:-speech

Version:1.0

Contactaddresstype:TELURI

CSVideoCall

Service-id:-videotelephony

Version:1.0

Contactaddresstype:TELURI

VideoShare

Service-id:hare

Version:1.0

Contactaddresstype:TEL/SIPURI

ImageShare

Service-id:hare

Version:1.0

Contactaddresstype:TEL/SIPURI

SessionModeMessaging

Service-id:bilealliance:IM-Session

Version:1.0

Contactaddresstype:TEL/SIPURI

FileTransfer

Service-id:bilealliance:File-Transfer

Version:1.0

Contactaddresstype:TEL/SIPURI

3.2.3Device

RCSR1版本不包含该项，后续版本再讨论。

3.2.4示例

<?xmlversion=”1.0”encoding=”UTF-8”?>

xmlns:op=”urn:oma:xml:prs:pidf:oma-pres”

xmlns:opd=”urn:oma:xml:pde:pidf:ext”

xmlns:c=”urn:ietf:params:xml:ns:pidf:cipid”

xmlns:pdm=”urn:ietf:params:xml:ns:pidf:data-model”

xmlns:rpid=”urn:ietf:params:xml:ns:pidf:rpid"

entity=”tel:+1234578901”>

open

-speech

1.0

tel:+1234578901

open

-videotelephony

1.0

tel:+1234578901

open

hare

1.0

tel:+1234578901

open

bilealliance:IM-Session

1.0

tel:+1234578901

open

opd:etag="26362">/xcap-aprvice/-

content/urs/sip:1234578901@/oma_status-icon/rcs_status_icon

tus-icon>

/~alice

I'llbePAG

从这个示例可以看出，该规范文档具有4个tuple标签，一个person标签。

3.3确保向后兼容的规则

为了确保足够的灵活性，不影响将来RCS版本技术选择，RCSR1版本的prence解析

应该要足够的健壮！因此，在prence解析时需要考虑一下几个方面的事项：

出现在prence文档中的不明确和不支持的原素和tuples，应该被忽略掉。

Tuples中包含的不明确的rvice-id元素，需要忽略；

Tuples中包含的不明确的rvice版本元素，需要忽略；

具有不同联系人地址的相同rvice可以出现多次，对于这种情况，按照如下几个

要点来处理：

如果其中一个tuple包含该prence文档发送方联系人地址，则其他的相同

tuple都被忽略掉；

Tuples中如果包含了代表其他实体（prentity，位于用户contact-list或者其他

TEL-URI的联系人）的联系人元素，需要被忽略；

Tulpes中如果包含了该服务不支持的其他类型地址元素（比如email地址），

需要被忽略；

如果通过上述三种方式处理后，仍然还有相同rvice的tuple出现，则保留地

一个，忽略其他所有的tuple；

通过上述4个处理后，则最后剩余的一个tuple具有如下一些行为：

使用该服务与对应联系人进行的该通信的能力（capability），需要向用户

声明；

如果该tuple没有联系人地址，或者他匹配一个prentity，则使用该

prentity的地址发起该服务对应的通信；

另外，contact元素中包含的地址，将被用来发起对应的服务；

如果接受到的文档中包含多个person标签，则保留timestamp最近的person，忽

略其他person；

当使用RLSsubscriptions时，informationcouldbecontainedonprentitiesthatwere

notknowntobepartoftheprencelist(ethelistwasupdatedbyanother

clientorapplication).Iftheunexpectedprentityisaknowncontact,itisadvidthat

theclientstartstreatingthiscontactasbeingprenceenabledandtriestoretrievean

updatedprencelistfromthenetwork.

注意，使用contact中提供的地址时，rvicetuple中的联系人地址要满足：

不要显示给终端用户，这些地址被终端内部处理；

不要用来请求prencesubscription，一个RCS客户端，aRCSclientisNOTsuppod

tosubscribetothecontactassociatedwitharvicecapabilitytuplereceivedina

prencedocument

3.4订阅及授权

3.4.1概述

当终端请求查看某个联系人的prence信息时，则发起一个SUBSCRIBE请求，我们称

该终端为“watcher”。watcher能够通过TELURI的方式来标识一个prentity实体。

对于客户端和服务器端来说，对RLS的支持是强制性的，具体请参考协议

《PrenceSIMPLESpecification,1.1,》。具体来说，客户端需要遵循《Prence

SIMPLESpecification,1.1,》的5.2.2.1节，《ImplementationGuidelinesforOMA

PrenceSIMPLEv1.1Prence》的5.7.1和5.8章节，《ImplementationGuidelines

forOMAXDMv1.1》的5.1章节，《ResourceListServer(RLS)XDMSpecification

ApprovedVersion1.1–27Jun2008》协议的5.1.6章节。XML文档需要遵循后续章节

将要介绍的模板。

Prence请求是通过鉴权来确保用户的安全。通过鉴权，被邀请用户可以接受、阻塞、

忽略对方建立Prence关系的请求。

Prence鉴权是相互的，请求用户同时能够自动鉴权被请求用户，通过鉴权的方式来允

许对方查看自己的prence信息。

RCS实体要能够配置Prence鉴权的规则，规则要求RCS客户端和服务端都能支持。RCS

客户端需要存储Prence鉴权文档和规则模板。

为了RCS实体能够准许一个watcher预订自己的Prence信息，实体需要知道是那些

watcher在尝试预订自己的Prence信息。RCS客户端和服务端需要支持《PrenceSIMPLE

Specification,1.1》的5.3.1和5.4.4章节。

当预订被成功通过后，Prence服务端发送RCS实体的Prence文档给该watcher，并

通过Prence通知事件来通知该watcher。Prence通知事件的格式在后续的章节中将要进

行详细介绍。

3.4.2XML文档结构

3.4.2.1PrenceXDMS：

PrenceXDMS需要包含如下一些鉴权规则：

“allowown”规则，允许预订prence信息；

“confirmunlisted”规则，对于unallowed的或者阻塞的contact，允许其再次进行

鉴权操作；

“grantedcontacts”规则，包含那些自己请求预订prence信息的contacts；

“blockedcontacts”规则，包含那些被自己放入黑名单的contacts；

AUID:-rules

Documentname:pres-rules

Template:

<?xmlversion="1.0"encoding="UTF-8"?>

xmlns:ocp="urn:oma:xml:xdm:common-policy"

xmlns:pr="urn:ietf:params:xml:ns:pres-rules"

xmlns:cr="urn:ietf:params:xml:ns:common-policy">

allow

allow

confirm

anc="/resource-lists/urs/sip:1234578901@/index/~~/resource-lists/li

st%5B@name=%22oma_grantedcontacts%22%5D"/>

allow

anc="/resource-lists/urs/sip:1234578901@/index/~~/resource-lists/li

st%5B@name=%22oma_blockedcontacts%22%5D"/>

block

3.4.2.2RLSXDMS：

对于RCS用户来说，RLSXDMS需要包含对sharedXDMS中rcs的引用。

AUID:rls-rvices

Documentname:index

Template:

<?xmlversion="1.0"encoding="UTF-8"?>

/rvices/resource-lists/urs/sip:1234578901@/i

ndex/~~/resource-lists/list%5B@name=%22rcs%22%5D

prence

3.4.2.3SharedXDMS：

SharedXDMS需要包含RCS客户端提供并管理的一些列表：

“rcs”列表，该列表包含所有与之具有SPR关系的联系人。一般在buddylist和

grantedcontacts列表中被引用为所有能够允许查看你的Prence信息的伙伴。

“oma_buddylist”列表，包含对rcs列表的引用，该列表一般不被使用，为将来兼

容及扩展用。

“oma_grantedcontacts”列表，该列表包含所有你已经授权查看自己Prence信息

的联系人。包含一个对rcs列表的引用。

“oma_blockedcontacts”列表，该列表包含对“rcs_blockedcontacts”列表和

“rcs_revokedcontacts”列表的引用。前者包含所有被永久阻塞的联系人，后者则

包含被revoke并被暂时阻塞的联系人。

“rcs_blockedcontacts”列表，包含所有被永久阻塞的联系人。

“rcs_revokedcontacts”列表，包含当前被revoke并被暂时阻塞的联系人。

注：“rcs_revokedcontacts”列表不能显示给终端用户，它被系统自动管理。

注：oma_grantedcontacts”列表和“oma_buddylist”列表包含相同的内容。

AUID:resource-lists

Documentname:index

Template:

<?xmlversion="1.0"encoding="UTF-8"?>

xmlns:xd="urn:oma:xml:xdm:xcap-directory"

xmlns:xsi="/2001/XMLSchema-instance">

anchor="/resource-lists/urs/sip:1234578901@/index/~~/resource-lis

ts/list%5B@name=%22rcs%22%5D"/>

anchor="/resource-lists/urs/sip:1234578901@/index/~~/resource-lis

ts/list%5B@name=%22rcs%22%5D"/>

anchor="/resource-lists/urs/sip:1234578901@/index/~~/resource-lis

ts/list%5B@name=%22rcs_blockedcontacts%22%5D"/>

anchor="/resource-lists/urs/sip:1234578901@/index/~~/resource-lis

ts/list%5B@name=%22rcs_revokedcontacts%22%5D"/>

Myprencebuddies

Myblockedcontacts

Myrevokedcontacts

3.4.3客户流程初始化Prence共享

当初始化一个Prence共享请求时，邀请用户的RCS客户端添加被邀请用户的URI到

SharedXDMS的rcs列表中。具体步骤参考【Shared-XDM】文档。

注意：当添加被邀请用户的URI到rcs列表中时，RCS客户端需要检查该URI是否包含

在“rcs_blockedcontacts”列表和“rcs_revokedcontacts”列表中，如果如此，该URI需要从

他们中移除。

当被邀请用户接收到建立SPR关系的通知时，用户可以选择如下操作：

a）接受请求，则被邀请用户的RCS客户端将邀请用户的URI加入到其SharedXDMS中

的rcs列表中，具体流程参考【Shared-XDM】。关于该信令流程的示例，参考附录

B.1。

b）阻塞请求，则被邀请用户的RCS客户端将邀请用户的URI加入到其SharedXDMS中

的rcs_blockedcontacts列表中，具体流程参考【Shared-XDM】。关于该信令流程的示

例，参考附录B.2。

c）忽略请求，则被邀请用户的RCS客户端将移除该Prence共享请求。关于该信令流

程的示例，参考附录B.3。

d）闲置请求，Prence共享请求则处于挂起状态，直到用户采用了上述三种操作方式。

在信令处理上，该流程与“忽略请求”是一样的。

3.4.4客户流程移除Prence共享

当用户决定跟某个联系人的SPR关系时，需要采用revoke选项来处理。这将触发一个

通知，让用户来确认是否这么做。如果用户选择确认，则客户端将该联系人的URI放入

rcs_revokedcontacts列表中，然后将用户从rcs列表中移除，并且从缓冲中移除该用户的SPI

（参加4.5节）。把某个联系人放入rcs_revokedcontacts列表中，需要更新其最新更新日期

属性（也就是当前时间UTC）。

当一个客户注意到自己被某个与自己有SPR关系的联系人给阻塞时，该客户系统需要将

该联系人从自己的rcs列表中移除，并且移除缓冲中的改用户的SPI。

所有的客户端都需要定期的处理自己的rcs_revokedcontacts列表，移除那些有足够长时

间的联系人。为了实现这个目的，需要比较该条目的上次修改时间与当前时间。对于其中的

定期检查时间，以及联系人在其中的存留时长，都需要能够被运营商配置。

3.4.5授权XCAP请求

XCAP请求需要能够被XDMS授权。该授权依赖于对该请求的请求者标识的判断。

包含XCAP请求的请求者宣称的标识的HTTP头（“X-XCAP-Asrted-Identity”和

“X-3GPP-Asrted-Identity”）可能会依赖于某些操作条件（如终端使用的接入方式，运营商

策略等），例如，不同的运营商可能会使用不同的算法来判断XCAP请求的请求者标识。因

此，对于被XDMS执行的任何授权检查，“X-XCAP-Asrted-Identity”和

“X-3GPP-Asrted-Identity”头都会被接受为一个运营商范围内包含XCAP请求的请求者标识的

有效头。

为了提供一个为统一的运营商间的接口，“X-3GPP-Asrted-Identity”则会在两个运营商

间、NNI接口上传递信息。

对一个watcher请求的终端，通过XDM/XCAP，一些与某个Prence文档实体有联系到

的内容（比如status-icon），实体的XDMS会检查是否该watcher具有访问这些内容的权利，

具体参考《Prentity'sPrenceSubscriptionRules》。就像3.4.2节，rcs列表就授权有这个权

利。

rcs列表中可以包含运营商范围内的已授权watcher的SIPURI和TELURI两种地址。为

了确保这两种情况，在NNI接口层，XCAP请求的发起者的“X-3GPP-Asrted-Identity”头中需

要包含该用户的这两种地址。

3.5缓存SPI

缓存SPI是客户端的一个过程。RCS客户端要能本地存储所有联系人的最近SPI信息，

在用户关机并重新开机后，这些信息需要一直保存。

如果已经存在SPR关系的联系人，如果watcher在SIP通知中接收到一个空的prence

文档，客户端需要使用已经保存该联系人的SPI来取得该空文档。

3.6发布

Prence文档通过PUBLISH方法（PRESENCE文档中定义）来发布出去。Prence通知

的格式已经在前章节Prence数据模型中定义。

当应用程序（RCS客户端）启动时，客户端需要发送PUBLISH请求（Prence数据模型

中定义）。

只要应用程序（RCS客户端）在运行，在该发布会一直保留在Prence服务端，在该发

布要到期时，会发出一个refresh的请求（服务端发送该请求？）。

Prence修改请求依据【PRESENCE】使用Sip-If-Match头来发送。

3.7存储SIP-Etag值，PrenceSource设备开关

这一部分，主要说明支持一种发布的长时间延迟机制。

一般，Prence源设备会在没有取消自己在服务端发布状态的情况下关机，因此，他的

SPI会在该设备关机后，仍然能够被持续的传送到watcher端，直到超时。

例如，一个长时间没有登录的watcher开机，就会得到该prence实体的最近的SPI信

息（前提是该SPI在服务端还没有超时），而此时，该prence实体可能并没有开机。

Prence源依据[PRESENCEIG]5.2.2节的推荐值，来设置条件发布的发布生命周期。

通过这种方式，prence实体可以操作之前的发布事件状态。而不是在prence服务

端创建一个新的发布事件状态。

3.8状态图标处理

3.8.1Prence实体侧

依据[OMAPrence及XDM2.0procedures]，状态图标需要能够被存储、更新、删除

及获取等操作。对于存储来说，需要使用[Prence_Content]中定义的PrenceContent

XDMS，包括其中介绍的应用用途，文档类型等。RCS图标状态的存储，只使用prence

contentXDMS就可以了。因此，[Prence_Content]的5.1.12.1章节以及其所包含的所有

的限制就是我们需要使用的。在存储、更新、删除图标后，Prence实体客户端需要发

布一个被更新的prence文档，其中包括status-icon元素中的etag属性（参考

[Prence2.0_DDS]中的7.11.1.3和7.20章节）。

图标及图标文档需要满足如下一些特征：

文档名称rcs_status_icon

Iconaspect_ratio(width:height)3:4or4:3

Iconmaximumdimensions240x320

Iconminimumdimensions60x80

Iconfiletypegif(bothstaticandanimated),jpegorpng

Documentmaximumsize200kB

注1：将图报的名称固定死，可以确保在网络侧只保留一个文件，不需要保存多个文件。

总之，用一个固定的名称，是最简单的。

注2：200KB不是强制性的大小，这里只是定义了一个最大值，小于这个值得也可以接

受的。

其他的都是固定的。

3.8.2watcher侧

Prence文档中的状态图标链接，依据[Prence2.0_TS]5.2.5.3章节来处理即可。当

状态图标元素的etag属性与缓存的图标不匹配时，客户端需要下载更新的图标。因此，

需要如此处理：用自己的XCAP根替换连接中的XCAP根部分。下载icon后，RCS客户端

需要缓存icon及etag，目的是为了处理将来联系人状态的通知（[Prence2.0_TS]5.2.5.3

章节）。

3.8.3网络侧处理