2.11 Multidevice support / 多设备支持

2.11.1 Overview / 概述

As shown in section 2.9.2.2, the use of a broadband access client leads to the possibility of the user having multiple devices that share the same (public) identity, a MSISDN for instance. Depending on the services that are deployed, this multidevice environment allows a user to:
如2.9.2.2节所示，宽带接入客户端的使用导致用户具有共享相同（公共）身份的多个设备（例如MSISDN）的可能性。 根据部署的服务，此多设备环境允许用户：

  • Answer a call or respond to a message from a device/client that suits their purpose.
    接听来电或回应来自适合其目的的装置/用户端的讯息。
  • Have a single buddy list shared between the devices/clients.
    在设备/客户端之间共享单个好友列表。
  • Authorise invitations to share Social Presence Information from every device/client.
    授权邀请以从每个设备/客户端共享社交场所信息。
  • Have a single Social Presence Information that can be seen and maintained from every device/client that is used.
    有一个单一的社交呈现信息，可以被使用的每个设备/客户端看到和维护。

The general communication behaviour in this environment is that when the recipient has multiple devices/clients in use and a call or a message is received every recipient’s device will alert. The recipient may then respond to the call or to the message from any of their devices; whichever device is the best for the current situation. In addition, when the recipient accepts or rejects a call from any of the devices, all the other devices will stop alerting.
在这种环境中的一般通信行为是，当接收者具有使用中的多个设备/客户端并且接收到呼叫或消息时，每个接收者的设备将警告。 然后，接收者可以响应来自他们的任何设备的呼叫或消息; 无论哪种设备对于当前情况是最好的。 此外，当接收者接受或拒绝来自任何设备的呼叫时，所有其他设备将停止报警。

To achieve this, an RCS client shall send a SIP 603 Decline response to the invite request when an RCS User explicitly declines a session invitation for a SIP session based service like for example an IP Voice Call, File Transfer, Video and Image Share. According to [3GPP TS 24.229] and [RFC3261] both such a rejection and an acceptance will result in a SIP CANCEL request sent by the S-CSCF to the other devices of the user that have not yet accepted nor rejected the invitation. In both cases, the requests may carry a Reason header field as specified in [RFC3326] that is populated with the proper SIP response code values (as per [3GPP TS 24.229]), in this case either the cause=200 or cause=603 values.
为了实现这一点，当RCS用户明确地拒绝基于SIP会话的服务（例如IP语音呼叫，文件传输，视频和图像共享）的会话邀请时，RCS客户端将向邀请请求发送SIP 603拒绝响应。 根据[3GPP TS 24.229]和[RFC3261]，这样的拒绝和接受将导致由S-CSCF发送到尚未接受或拒绝邀请的用户的其他设备的SIP取消请求。 在这两种情况下，请求可以携带如在[RFC3326]中指定的Reason报头字段，其填充有适当的SIP响应代码值（根据[3GPP TS 24.229]），在这种情况下是cause=200或 cause=603值。

If the user device has accepted the INVITE with a 200 OK, then the S-CSCF should set the Reason header field with SIP protocol and the protocol-cause set to 200 along with an optional protocol-text (e.g. SIP;cause=200;text="Call completed elsewhere").
如果用户设备已经响应了200 OK来接受INVITE请求，则S-CSCF应当将Reason头域设置为SIP协议，并且将protocol-cause设置为200以及可选的协议文本（例如，SIP;cause=200;text="Call completed elsewhere"）。

In case one device has sent a 603 Decline then the S-CSCF should set the cause=603 along with an optional protocol-text (e.g. SIP;cause=603;text="Decline"), in either SIP CANCEL and/or SIP BYE, towards the remaining user devices.
在一个设备已经发送603拒绝的情况下，则S-CSCF应该在SIP CANCEL和/或SIP BYE消息中，对剩余的用户设备，设置cause=603以及可选的协议文本（例如：SIP;cause=603;text="Decline"）。

When a client receives a SIP CANCEL request containing a Reason Header field with the protocol set to “SIP” and the protocol-cause set to 200, a client may for example use this information to indicate to the user that the session was accepted on another device (rather than as for example a missed call).
当客户端接收到包含设置为“SIP”的带协议的Reason头域，且protocol-cause被设置为200的SIP CANCEL请求时，举例来说，客户端可以使用该信息来向用户指示该会话在另一个设备（而不是像未接来电那样）被接听。

As a fallback for legacy services where this general communication behaviour cannot be realised a call or message might be directed to a certain device.
作为对不能实现这种一般通信行为的遗留服务的回退，可以将呼叫或消息定向到特定设备。

2.11.2 Addressing of individual clients / 单独客户的寻址

Any Application Server (e.g. a Messaging Server or OPTIONS AS) can address an individual RCS client using information received with the third party registration (public GRUU or sip.instance).
任何应用服务器（例如，消息服务器或OPTIONS AS）可以使用与第三方注册（公共GRUU或实例）一起接收的信息来寻址单个RCS客户端。

If a client obtains GRUUs from the registrar as described in section 2.4, the public GRUU shall be used as device identifier. The client shall use the public GRUU as a URI parameter for the client in non-REGISTER requests and responses that it sends, for example, an INVITE request and 200 OK response where the GRUU will be included in the Contact Header.
如果客户端从2.4节中描述的注册器获得GRUU，则公共GRUU将用作设备标识符。 客户端应该使用公共GRUU作为客户端在其发送的非REGISTER请求和响应中的URI参数，例如INVITE请求和200 OK响应，其中GRUU将包括在联系头中。

If a client does not obtain a GRUU from the registrar, the sip.instance feature tag and value shall be used as the device identifier. The client shall include the sip.instance feature tag in the Contact header with the same instance-id value in any non-REGISTER request and responses that it sends.
如果客户端没有从注册器获取GRUU，则应使用sip.instance特征标签和值作为设备标识符。 客户端应在Contact头中包含sip.instance特性标签，并在任何非REGISTER请求和响应中发送相同的instance-id值。

2.11.2.1 Backward compatibility / 向后兼容性

Earlier versions of RCS allowed the RCS client to include its device identifier information in the CPIM From header in a Standalone Message or in an MSRP SEND sent as part of a Group Chat. This is no longer required, so an Application Server may remove this information from the CPIM From header if it is received by an RCS client compliant to an older version of RCS. Of course any IMDNs sent during an ongoing Group Chat will end up arriving at the same device that sent the message.
早期版本的RCS允许RCS客户端将其设备标识符信息包括在独立消息中的CPIM From报头中或作为群聊的一部分发送的MSRP SEND中。 这不再需要，因此，如果应用服务器由符合旧版本的RCS的RCS客户端接收，则应用服务器可以从CPIM从报头中移除该信息。 当然，在正在进行的群聊期间发送的任何IMDN将最终到达发送消息的同一设备。

2.11.3 Routing RCS SIP requests to RCS Clients / 将RCS SIP请求路由到RCS客户端

In the context of multi-client and multi-device deployments, it is possible that the same IMS public user identity (IMPU) is used by the RCS Client and by other IMS Clients (e.g. Voice over LTE client using SMS over IP), but carrying a different instance ID.
在多客户端和多设备部署的上下文中，可能的是，RCS客户端和其他IMS客户端（例如，使用基于IP的SMS的VoLTE客户端）使用相同的IMS公共用户身份（IMPU），但是携带不同的实例ID。

In the messaging case, to ensure that requests are forked only to RCS Clients which have explicitly registered with the required RCS capabilities, the terminating Messaging Server may add a dedicated Accept-Contact header field to each RCS SIP request carrying either a CPM ICSI, or a SIMPLE IM feature tag, with the require and explicit parameters described in [RFC3841]. This applies to the following services:
在消息传递情况下，为了确保请求仅被分配给已经以所需的RCS能力显式注册的RCS客户端，终止消息传递服务器可以向携带CPM ICSI的每个RCS SIP请求添加专用Accept-Contact首部字段，或者 一个SIMPLE IM特征标签，具有[RFC3841]中描述的require和explicit参数。 这适用于下列服务：

  • Chat
    聊天
  • Standalone Messaging (text and multimedia messaging)
    独立消息（文本和多媒体消息）
  • File Transfer
    文件传输

results matching ""

    No results matching ""