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網絡側處理