RCS_R1_实现描述_v1_1.docx

1 RCS系统架构图1 RCS网络图上图描述了了RCS的总体框架图。出于兼容性的目的，RCS基于用户-网络接口（UNI），网络-网络接口（NNI）来实现，涉及到如下一些规范;l 呈现与能力的获取（Discovery）；l 视频共享；l 图片共享；l 消息；对于UNI和NNI的具体应用关系，参考下图：图2 UNI-NNI关系图2 概述2.1 寻址联系人SIP请求的接收、发送，其标识是电话号码，接下来讨论的一些寻址的格式，仅限于RCS服务。对于presence subscriptions、群组聊天，也适用这种号码格式。2.1.1 设备呼入SIP请求对于设备呼入SIP请求，联系人的地址依赖于请求的类型。该地址以URI的形式存在，或者包含在请求体（Body of Request）中，或者包含在请求P-Asserted-Identity头及From头中。如果P-Asserted-Identity头存在，则From头将被忽略。接收方需要按照如下的几个方式来从URI中提取出电话号码。l TEL URI形式，比如： tel:+1234578901，或者tel:0234578901;phone-context=；l SIP URI形式，其中必须包含user=phone的参数，比如：sip:+1234578901;user=phone，或者sip:0234578901;phone-context=;user=phone；除了这两种形式，不推荐使用其他形式的地址格式。由于与其他基于IMS的服务同网，可能就会收到其他形式的URI，其处理方式依赖于客户端程序的处理。2.1.2 设备呼出SIP请求RCS客户端可以使用RCS电话本中的电话号码或者用户输入的数字串作为地址。该地址用于1对1通信的SIP请求URI（SIP Request URI）或者TO头中，该地址也用于群组通信的呼出SIP请求的接收人列表URI。对于国际号码，RCS设备需要支持TEL-URI形式，比如tel:+12345678901，也要支持SIP URI形式，比如sip:+1234578901;user=phone，注意user参数的值。根据运营商的需求及国家SIP-SIP互连框架的通用规范要求，这个形式是需要能够在设备端进行动态配置的。如果并没有强制约束与上述两种形式，推荐使用TEL URI的形式，因为SIP-URI的域名并没有多少意义。对于非国际号码，RCS客户端需要支持TEL-URI或者SIP-URI（带有user=phone参数，以及phone-context值）形式，比如tel:0234578901;phone-context=。同样，根据运营商的需求及国家SIP-SIP互连框架的通用规范要求，这个形式是需要能够在设备端进行动态配置的。如果并没有强制约束与上述两种形式，推荐使用TEL URI的形式。对网络的自我身份鉴定及被访问的联系人：被呼叫者能够鉴别呼叫者身份的主要标识就是电话号码，为此，呼叫者应该将其TEL-URI放在P-Preferred-Identity头中。该TEL-URI可以由呼叫者设备提供，或者在注册时从网络接收到的P-Associated-URI头中提取。From头也需要与P-Preferred-Identity头相同的TEL-URI来设置。而且，这个规格也适用于群组聊天中MSRP SENDS 的CPIM From头中。2.2 注册RCS客户端需要注册它所支持的所有服务的特征标签（TAG），这些标签放在SIP REGISTER信息的contact头中。对于每个特征标签的详细结构，需要参考VIDEOSHARE，IMAGESHARE 及 IMENDORSE文档。比如，对于支持消息、视频共享、图片共享的RCS客户端，则其服务特征标签如下:l +g.oma.sip-iml +g.3gpp.cs-voicel +g.3gpp.iari-ref:urn:urn-xxx:3gpp-application.ims.iari.gsma-is2.3会话响应当一个RCS用户拒绝了一个会话请求，比如聊天、文件传输、视频图片共享等请求，RCS客户端需要回应一个SIP 603响应给请求方。3 呈现及能力发现3.1 架构图3 RCS呈现总体框架图图4 RCS呈现架构3.2 呈现数据模型3.2.1 Person属性规格注释Person： - RFC 4479 根据presence框架规范，person相关信息被模型化为person元素，每个客户只能有一个person元素；Willingness: - - - Open OMA 呈现终端通过发布Willingness属性来表达自己是否愿意进行通信。具体如下：“Open” = Willing “Closed” = Not Willing Attribute not present = Unknown Icon: - RFC 4480 Icon作为person的一个动态化身，如果不设置该属性，则以电话本中的icon来替代。该图片不能直接包含在presence的请求中，而是使用HTTP URL的地址方式来表示。Prsence Content XDMS 过程用来上传、发布、提取图片；Favourite Link: - RFC 4482 Homepage元素提供了一个指向个人基本信息的RUI，比较典型的是一个网页。Note: - RFC 4479 person通过一些文本或者表情符号，来呈现给拥有该联系人的电话本用户。Timestamp: - RFC4479 时间戳，presence信息被发布时的时间。注意一些地方：Willingness有时也可以用availability来表示。该属性由用户自主管理，并不表示通信不能进行，在OMA规范中，这表示个属性表达的意思是Willingness（主动的意愿）。而availability则是从技术层面上来说的可能性。这两个属性在将来的版本中将会做进一步的研究。Willingness如果和具有until属性值的basic-open元素结合,则表示RCS HyperAvailability信息。如果没有该until值，则不能被解释为HyperAvailability属性。在presentity一侧，RCS客户通过在当前时间上增加HyperAvailability Period值来获取Until值，当前时间值用UTC格式表示。HyperAvailability Period值由运营商来配置。在RCS客户端，通过一个标识来告知用户他的HyperAvailability状态在整个HyperAvailability Period期间是激活的。在这个期间，用户可以去激活它的HyperAvailability状态，这通过没有Overriding Willingness元素的发布来实现，相反的，如果要激活，则通过具有Overriding Willingness元素的发布来实现。接受到HyperAvailability信息的通知时，拥有该联系人的客户端应该产生一个提示，同时，在对该用户的联系人显示产生一个明显的变化，比如一个闪烁的图片、动画等，直到Until时间到。时间到了之后，该用户的界面显示退回到原来的显示模式。此外，在接受到一个没有Overriding Willingness元素的发布通知时，也要退回到原来的显示模式。RCS客户端要管理最近HyperAvailability事件的日志，并能够让该用户查看。3.2.2 Service属性规格注释Tuple: - RFC 3863 根据规范，service按照一个tuple元素的方式呈现Status - - - Open RFC 3863 强制性元素，一旦一个tuple元素被发布，则值open必须设置。在RCS上下文中，并不代表特殊的意义。Service-id - - OMA 服务描述元素描述一个服务，通过service-id和版本信息来描述。service-id元素是一个字符串，用来唯一标识一个服务。Version - - OMA 版本元素描述一个服务，是一个具体的数字，表示该服务的版本，以区别服务的不同版本（阶段）。Contact - RFC 3863 contact元素包含了服务的Presentity通信地址，contact地址可以是TEL URI，SIP URI的任意一种，具体依赖于使用的服务。该元素的使用时可选的，非强制性。在没有改元素的情况下，客户使用电话本中的URI。RCS presentity或者插入一个contact元素，或者不插入任何元素。Timestamp - RFC 3863 时间戳，presence信息被发布时的时间。注：注册的各种服务描述：CS Voice Call Service-id: org.3gpp.cs-speech Version: 1.0 Contact address type: TEL URI CS Video Call Service-id: org.3gpp.cs-videotelephony Version: 1.0 Contact address type: TEL URI Video Share Service-id: org.gsma.videoshare Version: 1.0 Contact address type: TEL / SIP URI Image Share Service-id: org.gsma.imageshare Version: 1.0 Contact address type: TEL / SIP URI Session Mode Messaging Service-id: org.openmobilealliance:IM-Session Version : 1.0 Contact address type: TEL / SIP URI File Transfer Service-id: org.openmobilealliance:File-Transfer Version : 1.0 Contact address type: TEL / SIP URI3.2.3 DeviceRCS R1版本不包含该项，后续版本再讨论。3.2.4 示例 open org.3gpp.cs-speech 1.0 tel: +1234578901 open org.3gpp.cs-videotelephony 1.0 tel:+1234578901 open org.gsma.videoshare 1.0 tel:+1234578901 open org.openmobilealliance:IM-Session 1.0 tel:+1234578901 open /xcap-ap service/org.openmobilealliance.pres-content/users/sip:1234578901/oma_status-icon/rcs_status_icon /alice Ill be PAG 从这个示例可以看出，该规范文档具有4个tuple标签，一个person标签。3.3 确保向后兼容的规则为了确保足够的灵活性，不影响将来RCS版本技术选择，RCS R1版本的presence解析应该要足够的健壮！因此，在presence解析时需要考虑一下几个方面的事项：l 出现在presence文档中的不明确和不支持的原素和tuples，应该被忽略掉。l Tuples中包含的不明确的service-id元素，需要忽略；l Tuples中包含的不明确的service版本元素，需要忽略；l 具有不同联系人地址的相同service可以出现多次，对于这种情况，按照如下几个要点来处理： 如果其中一个tuple包含该presence文档发送方联系人地址待确认，则其他的相同tuple都被忽略掉； Tuples中如果包含了代表其他实体（presentity，位于用户contact-list或者其他TEL-URI的联系人）的联系人元素，需要被忽略； Tulpes中如果包含了该服务不支持的其他类型地址元素（比如email地址），需要被忽略； 如果通过上述三种方式处理后，仍然还有相同service的tuple出现，则保留地一个，忽略其他所有的tuple； 通过上述4个处理后，则最后剩余的一个tuple具有如下一些行为： 使用该服务与对应联系人进行的该通信的能力（capability），需要向用户声明如何声明？； 如果该tuple没有联系人地址，或者他匹配一个presentity，则使用该presentity的地址发起该服务对应的通信； 另外，contact元素中包含的地址，将被用来发起对应的服务；l 如果接受到的文档中包含多个person标签，则保留timestamp最近的person，忽略其他person；l 当使用RLS subscriptions时，information could be contained on presentities that were not known to be part of the presence list (e.g. because the list was updated by another client or application). If the unexpected presentity is a known contact, it is advised that the client starts treating this contact as being presence enabled and tries to retrieve an updated presence list from the network.注意，使用contact中提供的地址时，service tuple中的联系人地址要满足：l 不要显示给终端用户，这些地址被终端内部处理；l 不要用来请求presence subscription，一个RCS客户端，a RCS client is NOT supposed to subscribe to the contact associated with a service capability tuple received in a presence document3.4 订阅及授权3.4.1 概述当终端请求查看某个联系人的presence信息时，则发起一个SUBSCRIBE请求，我们称该终端为“watcher”。watcher能够通过TEL URI 的方式来标识一个presentity实体。对于客户端和服务器端来说，对RLS的支持是强制性的，具体请参考协议Presence SIMPLE Specification, 1.1,。具体来说，客户端需要遵循Presence SIMPLE Specification, 1.1,的节，Implementation Guidelines for OMA Presence SIMPLE v1.1 Presence的5.7.1和5.8章节， Implementation Guidelines for OMA XDM v1.1的5.1章节， Resource List Server (RLS) XDM Specification Approved Version 1.1 27 Jun 2008协议的5.1.6章节。XML文档需要遵循后续章节将要介绍的模板。Presence请求是通过鉴权来确保用户的安全。通过鉴权，被邀请用户可以接受、阻塞、忽略对方建立Presence关系的请求。Presence鉴权是相互的，请求用户同时能够自动鉴权被请求用户，通过鉴权的方式来允许对方查看自己的presence信息。RCS实体要能够配置Presence鉴权的规则，规则要求RCS客户端和服务端都能支持。RCS客户端需要存储Presence鉴权文档和规则模板。为了RCS实体能够准许一个watcher预订自己的Presence信息，实体需要知道是那些watcher在尝试预订自己的Presence信息。RCS客户端和服务端需要支持Presence SIMPLE Specification, 1.1的5.3.1和5.4.4章节。当预订被成功通过后，Presence服务端发送RCS实体的Presence文档给该watcher，并通过Presence通知事件来通知该watcher。Presence通知事件的格式在后续的章节中将要进行详细介绍。3.4.2 XML文档结构 Presence XDMS：Presence XDMS需要包含如下一些鉴权规则：l “allow own”规则，允许预订presence信息；l “confirm unlisted”规则，对于unallowed的或者阻塞的contact，允许其再次进行鉴权操作；l “granted contacts”规则，包含那些自己请求预订presence信息的contacts；l “blocked contacts”规则，包含那些被自己放入黑名单的contacts；AUID: org.openmobilealliance.pres-rules Document name: pres-rulesTemplate: allow allow confirm allow block RLS XDMS：对于RCS用户来说，RLS XDMS需要包含对shared XDMS中rcs的引用。AUID: rls-services Document name: indexTemplate:/services/resource-lists/users/sip:1234578901/index/resource-lists/list%5Bname=%22rcs%22%5Dpresence Shared XDMS：Shared XDMS需要包含RCS客户端提供并管理的一些列表：l “rcs” 列表，该列表包含所有与之具有SPR关系的联系人。一般在buddylist和granted contacts列表中被引用为所有能够允许查看你的Presence信息的伙伴。l “oma_buddylist”列表，包含对rcs列表的引用，该列表一般不被使用，为将来兼容及扩展用。l “oma_grantedcontacts”列表，该列表包含所有你已经授权查看自己Presence信息的联系人。包含一个对rcs列表的引用。l “oma_blockedcontacts”列表，该列表包含对“rcs_blockedcontacts”列表和“rcs_revokedcontacts”列表的引用。前者包含所有被永久阻塞的联系人，后者则包含被revoke并被暂时阻塞的联系人。l “rcs_blockedcontacts”列表，包含所有被永久阻塞的联系人。l “rcs_revokedcontacts”列表，包含当前被revoke并被暂时阻塞的联系人。注：“rcs_revokedcontacts”列表不能显示给终端用户，它被系统自动管理。注：oma_grantedcontacts”列表和“oma_buddylist”列表包含相同的内容。AUID: resource-lists Document name: index Template: My presence buddiesMy blocked contactsMy revoked contacts3.4.3 客户流程 初始化Presence共享当初始化一个Presence共享请求时，邀请用户的RCS客户端添加被邀请用户的URI到Shared XDMS的rcs 列表中。具体步骤参考【Shared-XDM】文档。注意：当添加被邀请用户的URI到rcs列表中时，RCS客户端需要检查该URI是否包含在“rcs_blockedcontacts”列表和“rcs_revokedcontacts”列表中，如果如此，该URI需要从他们中移除。当被邀请用户接收到建立SPR关系的通知时，用户可以选择如下操作：a） 接受请求，则被邀请用户的RCS客户端将邀请用户的URI加入到其Shared XDMS中的rcs列表中，具体流程参考【Shared-XDM】。关于该信令流程的示例，参考附录B.1。b） 阻塞请求，则被邀请用户的RCS客户端将邀请用户的URI加入到其Shared XDMS中的rcs_blockedcontacts列表中，具体流程参考【Shared-XDM】。关于该信令流程的示例，参考附录B.2。c） 忽略请求，则被邀请用户的RCS客户端将移除该Presence共享请求。关于该信令流程的示例，参考附录B.3。d） 闲置请求，Presence共享请求则处于挂起状态，直到用户采用了上述三种操作方式。在信令处理上，该流程与“忽略请求”是一样的。3.4.4 客户流程 移除Presence共享当用户决定跟某个联系人的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-Asserted-Identity” 和 “X-3GPP-Asserted-Identity”）可能会依赖于某些操作条件（如终端使用的接入方式，运营商策略等），例如，不同的运营商可能会使用不同的算法来判断XCAP请求的请求者标识。因此，对于被XDMS执行的任何授权检查，“X-XCAP-Asserted-Identity” 和 “X-3GPP-Asserted-Identity”头都会被接受为一个运营商范围内包含XCAP请求的请求者标识的有效头。为了提供一个为统一的运营商间的接口，“X-3GPP-Asserted-Identity”则会在两个运营商间、NNI接口上传递信息。对一个watcher请求的终端，通过XDM/XCAP，一些与某个Presence文档实体有联系到的内容（比如status-icon），实体的XDMS会检查是否该watcher具有访问这些内容的权利，具体参考Presentitys Presence Subscription Rules。就像3.4.2节，rcs列表就授权有这个权利。rcs列表中可以包含运营商范围内的已授权watcher的SIP URI和TEL URI两种地址。为了确保这两种情况，在NNI接口层，XCAP请求的发起者的“X-3GPP-Asserted-Identity”头中需要包含该用户的这两种地址。3.5 缓存SPI缓存SPI是客户端的一个过程。RCS客户端要能本地存储所有联系人的最近SPI信息，在用户关机并重新开机后，这些信息需要一直保存。如果已经存在SPR关系的联系人，如果watcher在SIP通知中接收到一个空的presence文档，客户端需要使用已经保存该联系人的SPI来取得该空文档。3.6 发布Presence文档通过PUBLISH方法（PRESENCE文档中定义）来发布出去。Presence通知的格式已经在前章节Presence 数据模型中定义。当应用程序（RCS客户端）启动时，客户端需要发送PUBLISH请求（Presence 数据模型中定义）。只要应用程序（RCS客户端）在运行，在该发布会一直保留在Presence服务端，在该发布要到期时，会发出一个refresh的请求（服务端发送该请求？）。Presence修改请求依据【PRESENCE】使用Sip-If-Match头来发送。3.7 存储SIP-Etag值，Presence Source设备开关这一部分，主要说明支持一种发布的长时间延迟机制。一般，Presence源设备会在没有取消自己在服务端发布状态的情况下关机，因此，