2.6 Capability and new user discovery mechanisms / 能力和新用户发现机制

2.6.1 Capability discovery / 能力发现

The capability or service discovery mechanism is a process which enhances service usability by allowing a user to understand the subset of RCS services available to access and/or communicate with their contacts, at certain points in time.
能力或服务发现机制是通过允许用户理解在某些时间点可用于访问和/或与其联系人通信的RCS服务的子集来增强服务可用性的过程。

When available, the RCS specification provides two alternative mechanisms to perform the capability discovery:
当可用时，RCS规范提供两种替代机制来执行能力发现：

• SIP OPTIONS exchange (section 2.6.1.1):
  SIP选项交换（第2.6.1.1节）：

  • The SIP OPTIONS end-to-end message is used both to query the capabilities (services which the other user has available) of the target contact and to pass the information about which capabilities are supported by the requester. Using this method, both users get updated information in a single transaction. However, users are allowed to hide their service capabilities to some undesired contacts. To this end, clients may support a locally stored capability blacklist which could be configured manually by the user or be generated automatically by setting any contacts that do not exist in the user’s address book as the blacklisted contacts. This blacklist is different with the blacklist that is used for chat, file transfer and content share services. If a SIP OPTIONS request is received from a capability blacklisted contact, the client should answer the request with an empty 200 OK which does not include any of the service tags used by RCS services (see Table 21).
    SIP OPTIONS端到端消息用于查询目标联系人的能力（其他用户可用的服务）并且传递关于请求者支持哪些能力的信息。 使用此方法，用户双方可以在单个事务中获取更新的信息。 然而，用户可以针对一些不期望的联系人隐藏他们的服务能力。 为此，客户端可以支持本地存储的能力黑名单，其可以由用户手动配置或者通过将在用户的地址簿中不存在的任何联系人设置为被列入黑名单的联系人来自动生成。 此黑名单与用于聊天，文件传输和内容共享服务的黑名单不同。 如果从列入能力黑名单的联系人接收到SIP OPTIONS请求，则客户端应该使用不包括RCS服务使用的任何服务标签的一个空的200 OK响应来应答该请求（参见表21）。
  • This method requires a specific application server (Options-AS) in the network to provide multidevice support and, potentially, include optimisations.
    该方法需要网络中的特定应用服务器（选项-AS）来提供多设备支持，并且潜在地包括优化。

• Presence (section 2.6.1.2):
  存在（第2.6.1.2节）：

  • In this case, instead of performing an end-to-end transaction, the capabilities are queried against a server using the standard OMA SIMPLE Presence procedures which are described in detail in section 2.6.1.2.
    在这种情况下，不是执行端到端事务，而是使用在2.6.1.2节中详细描述的标准OMA SIMPLE Presence过程来针对服务器查询能力。
  • Consistent with the previous paragraph and the OMA SIMPLE Presence procedures, this method requires both a Presence and a XDM server in the network.
    与前一段落和OMA SIMPLE Presence过程一致，此方法需要网络中的Presence和XDM服务器。

The default discovery mechanism is configured in the device using the configuration parameter CAPABILITY DISCOVERY MECHANISM (see Annex A section A.1.10).
在设备中使用配置参数CAPABILITY DISCOVERY MECHANISM配置默认发现机制（参见附录A A.1.10节）。

In accordance with the principle of interoperability between RCS networks and devices, two mechanisms are provided to secure the interoperability between the mechanisms presented before:
根据RCS网络和设备之间的互操作性原则，提供了两种机制以确保在之前呈现的机制之间的互操作性：

• Co-existence based in a common device stack (section 2.6.1.3):
  在公共设备堆栈中的共存（第2.6.1.3节）：

  • The interoperability is provided via a device implementation and, consequently, no additional network elements are required.
    通过设备实现提供互操作性，因此，不需要额外的网络元件。
  • The principle of interoperability is that all devices support SIP OPTIONS exchange either as a default or a device fall-back mechanism (when the presence query fails for a particular user).
    互操作性的原理是所有设备支持SIP OPTIONS交换作为默认或设备回退机制（当特定用户的存在询问失败时）。

• Coexistence based in network interworking (section 2.6.1.3.3):
  基于网络互通的共存（第2.6.1.3.3节）：

  • Network Interworking is required between Service Providers that do not support SIP OPTIONS exchange (as the default method or as a device fall-back mechanism) and those Service Providers that use SIP OPTIONS as the default discovery mechanism.
    在不支持SIP OPTIONS交换（作为默认方法或作为设备回退机制）的服务提供商和使用SIP OPTIONS作为默认发现机制的那些服务提供商之间需要网络互通。
  • Interoperability is achieved by deploying a network based interworking function which translates requests and responses between the SIP OPTIONS and presence-based capability discovery mechanisms.
    互操作性是通过部署基于网络的互通功能来实现的，该功能在SIP OPTIONS和基于存在的能力发现机制之间转换请求和响应。

To guarantee that Service Providers choosing the network interworking approach do not experience situations whereby the device fall-back mechanism to SIP OPTIONS occurs, a new parameter (CAPABILITY DISCOVERY VIA COMMON STACK) is defined. The device fall-back mechanism only occurs if this parameter is set to 1 (see Annex A sections A.1.10 and A.2.8 for further reference).
为了保证选择网络互通方法的服务提供商不经历发生到SIP OPTIONS的设备回退机制的情况，定义了新的参数（CAPABILITY DISCOVERY VIA COMMON STACK）。 仅当此参数设置为1时才发生设备回退机制（有关进一步参考，请参见附录A A.1.10和A.2.8节）。

2.6.1.1 Capability discovery process through SIP OPTIONS message / 通过SIP OPTIONS消息的能力发现过程

One of the available mechanisms for capability discovery is based on the exchange of a SIP OPTIONS request, a peer-to-peer message exchanged between clients.
用于能力发现的可用机制之一是基于SIP OPTIONS请求（在客户端之间交换的对等消息）的交换。

When a SIP OPTIONS message is sent from User A to User B, User A shall handle the response as described in the following table:
当SIP OPTIONS消息从用户A发送到用户B时，用户A将处理响应，如下表所述：

Table 5: Options response handling / 表5：选项响应处理

In some cases sending an OPTIONS request is not required as the last SIP OPTIONS exchange took place just before the communication was set up (e.g. to send a SMS message, the user went to the address book, selected a user [SIP OPTIONS exchange takes place] and chooses to send a SMS message).
在一些情况下，不需要发送OPTIONS请求，因为在通信建立之前发生最后的SIP OPTIONS交换（例如，发送SMS消息，用户去了地址簿，选择了用户[此时SIP OPTIONS交换发生]并选择发送SMS消息）。

Figure 6: Capabilities discovery via SIP OPTIONS message / 图6：通过SIP OPTIONS消息的能力发现

[4] Note that this means that an AS like the OPTIONS-AS described in section 2.6.1.1.5 would have to include the IM capability in the response if the user has multiple devices sharing the same IMS identity some of which are not RCS capable. When including this tag though in situations where none of the RCS capable devices is online, it shall also include the automata tag defined in [RFC3840] to indicate that this response does not originate from an end user device.
[4] 注意，这意味着，如果用户具有共享相同IMS身份的多个设备，其中一些不具有RCS能力，则类似于第2.6.1.1.5节中描述的OPTIONS-AS的AS必须将IM能力包括在响应中。 当包括此标签时，尽管在没有RCS能力设备在线的情况下，它还应包括[RFC3840]中定义的自动标签，以指示此响应不是源自最终用户设备。

2.6.1.1.1 SIP OPTIONS message extension to support capability discovery / SIP OPTIONS消息扩展以支持能力发现

The RCS (Release 1 to 4) specifications only provide a mechanism to exchange the capability status (based on a SIP OPTIONS exchange) related to the Image and Video Share services during a call (associated with the capability query procedure described in [PRD-IR.74] and [PRD-IR.79]). This mechanism is based on the use of tags transported in the Contact header field for the SIP OPTIONS and its responses:
RCS（版本1至4）规范仅提供在呼叫期间交换与图像和视频共享服务相关的能力状态（基于SIP OPTIONS交换）的机制（与[PRD-IR中描述的能力查询过程 .74]和[PRD-IR.79]）。 此机制基于在SIP选项及其响应的Contact头字段中传输的标签的使用：

• The tags corresponding to the set of functionalities supported by the requesting terminal at the time this request is made are carried in the Contact header field of the SIP OPTIONS message.
  对应于请求终端在做出请求时所支持的功能集合的标签，携带在SIP OPTIONS消息的联系人报头域中。
• The tags corresponding to the subset of the functionalities that are supported by the receiver are included in the Contact header of the 200 OK responses.
  对应于由接收器支持的功能的子集的标签被包括在200OK响应的联系人报头中。

When the SIP OPTIONS is sent as part of an ongoing voice call, as per [PRD-IR.74] and [PRD-IR.79], the Accept-Contact header shall be handled as described in [PRD-IR.74] and [PRD-IR.79].
根据[PRD-IR.74]和[PRD-IR.79]，当SIP OPTIONS作为正在进行的语音呼叫的一部分被发送时，Accept-Contact报头应当如[PRD-IR.74] 和[PRD-IR.79]。

As described in [PRD-IR.74] and [PRD-IR.79], to have a Session Description Protocol (SDP) body in an OPTIONS request message is optional. It is not encouraged behaviour to insert it into this message. In RCS, the SIP OPTIONS request shall NOT contain an SDP body.
如在[PRD-IR.74]和[PRD-IR.79]中所描述的，在OPTIONS请求消息中具有会话描述协议（SDP）主体是可选的。 不鼓励将行为插入到此消息中。 在RCS中，SIP OPTIONS请求不应包含SDP主体。

The mechanism described above is extended to be used not only for the exchange of capabilities for real-time services but also to query in real time to exchange the capabilities/services supported by both the requester and the receiver.
上述机制被扩展以用于不仅用于实时服务的能力的交换，而且还用于实时查询以交换请求者和接收者所支持的能力/服务。

When the Service Provider disables the capability discovery mechanism the network shall return a SIP 200 OK including any of the agreed interworking service tags which are supported by User B as described in Table 21. If User B is currently not registered or is not a RCS user, the network shall respond in accordance with section 2.6.2.1 Discovery via OPTIONS message.
当服务提供商禁用能力发现机制时，网络将返回SIP 200 OK，包括由用户B支持的任何已约定的互通服务标签，如表21所述。如果用户B当前未注册或不是RCS用户 ，网络应根据第2.6.2.1节通过OPTIONS消息发现进行响应。

2.6.1.1.2 Extensions to the existing tags / 现有标签的扩展

Consequently, with the RCS Release 1-4 specifications, the following tags can be employed to identify Image and Video Share service capabilities during a call:
因此，使用RCS Release 1-4规范，可以使用以下标记来标识呼叫期间的图像和视频共享服务功能：

Table 6: Standard RCS Release 1-4 SIP OPTIONS tags / 表6：标准RCS发行版1-4 SIP选项标签

When used in SIP OPTIONS exchanges these Image and Video Share capabilities can only be sent during an active call and are included only if the exchange takes place between the users in the active call. However, Broadband Access devices should include these capabilities in an OPTIONS response even if they are not in an active call.
当在SIP OPTIONS交换中使用时，这些图像和视频共享功能只能在活动呼叫期间发送，并且仅当在活动呼叫中的用户之间进行交换时才包括。 然而，宽带接入设备应该在OPTIONS响应中包括这些能力，即使它们不在活动呼叫中。

To support the full service discovery functionality presented in this document, it is necessary to extend the tag mechanism by adding the following service tags:
为了支持本文档中提供的完整服务发现功能，有必要通过添加以下服务标签来扩展标记机制：

• As interoperability between the different technical implementations for Chat and File Transfer services is assumed, the following tags are employed for the Chat and File Transfer services:
  假设聊天和文件传输服务的不同技术实现之间的互操作性，聊天和文件传输服务采用以下标签：

Table 7: SIP OPTIONS tags for Chat and File Transfer / 表7：用于聊天和文件传输的SIP OPTIONS标记

[5] The urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb IARI is included to provide backwards compatibility towards older versions of RCS
[5] 包括urn％3Aurn-7％3A3gpp-application.ims.iari.rcs.fitthumb IARI以向旧版本的RCS提供向后兼容性

The File Transfer via MSRP Store and Forward capability shall only be provided when File Transfer via MSRP is enabled through the PROVIDE FT configuration parameter described in section A.1.5 and the Chat Technology is set to OMA CPM using the CHAT MESSAGING TECHNOLOGY configuration parameter defined in section A.1.4.3.
通过MSRP存储和转发功能的文件传输只有在通过A.2.5节中描述的PROVIDE FT配置参数启用通过MSRP的文件传输，并且使用在CHAT中定义的CHAT消息传送技术配置参数将聊天技术设置为OMA CPM时，才能提供 A.1.4.3节。

• Add a tag for IP based standalone text and multimedia messaging:
  为基于IP的独立文本和多媒体消息添加标签：

Table 8: SIP OPTIONS tag for standalone messaging / 表8：独立消息传递的SIP OPTIONS标记

• Add a tag for Social Presence Information:
  为社交场所信息添加标签：

Table 9: SIP OPTIONS tag for Social Presence Information / 表9：社交呈现信息的SIP OPTIONS标记

• Add tags for IP Voice and Video Call services:
  为IP语音和视频呼叫服务添加标签：

Table 10: SIP OPTIONS tags for IP Voice and Video Call / 表10：IP语音和视频呼叫的SIP OPTIONS标记

NOTE1: When a device supports both IP Voice Call and IP Video Call, the feature tags +g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel" and +g.gsma.rcs.ipcall are only included once in the OPTIONS request/response.
注1：当设备同时支持IP语音呼叫和IP视频呼叫时，特征标签 + g.3gpp.icsi-ref =“urn：urn-7：3gpp-service.ims.icsi.mmtel”和 + g .gsma.rcs.ipcall 只在OPTIONS请求/响应中包含一次。

A device shall provide in the SIP OPTIONS requests and responses only one of the RCS IP Voice Call, RCS IP Video Call and RCS IP Video Call where video media cannot be removed capabilities depending on whether according to the PROVIDE RCS IP VOICE CALL and PROVIDE RCS IP VIDEO CALL configuration parameters defined in section A.1.12 in the currently used radio technology respectively only RCS IP Voice Calls, both RCS IP Voice Calls and RCS IP Video Calls or only RCS IP Video Calls are allowed. Due the combining of the capabilities of different devices (see section 2.6.1.1.5), it may happen though that multiple of those capabilities are received. If the RCS IP Video Call where video media cannot be removed capability is received in combination with the RCS IP Video Call and/or the RCS IP Voice Call capability, towards that contact both RCS IP Voice Call and RCS IP Video Calls may be successfully initiated as described in sections 3.8 and 3.9 when those services are allowed according to the local configuration and used radio technology.
设备应在SIP OPTIONS请求和响应中仅提供RCS IP语音呼叫，RCS IP视频呼叫和视频媒体不能被移除的RCS IP视频呼叫中的一个能力，这依赖于根据在第A.1.12节定义的PROVIDE RCS IP VOICE CALL和PROVIDE RCS IP VIDEO CALL配置参数完成，这两个参数在当前使用的无线电技术中分别对应三种能力：仅允许RCS IP语音呼叫，RCS IP语音呼叫和视频呼叫并存，或仅RCS IP视频呼叫。由于不同设备的能力的组合（参见第2.6.1.1.5节），可能发生收到这些多个能力的参数的情况。如果收到了“视频媒体不能被移除的RCS IP视频呼叫”能力，同时又收到“RCS IP视频呼叫”和/或“RCS IP 语音呼叫”能力，那么根据本地配置和使用的无线电技术，如果本地允许这些服务，则如第3.8节和第3.9节所述，向该联系人可以成功地发起RCS IP语音呼叫和RCS IP视频呼叫。

NOTE2: RCS IP Calls and IP Calls per MMTEL can technically interoperate. Therefore, an RCS IP Call client is allowed to answer an incoming IP Call (and vice versa), and shall process the received capability information accordingly.
注2：每个MMTEL的RCS IP呼叫和IP呼叫在技术上可以互操作。 因此，RCS IP呼叫客户端被允许应答呼入的IP呼叫（反之亦然），并且将相应地处理所接收的能力信息。

If the device is configured to support only the RCS IP Video Call services as described in section A.1.12 (i.e. RCS IP Voice Call initiation is not allowed and a downgrade by the user of an RCS IP Video Call to an RCS IP Voice Call is not allowed), it shall include the +g.gsma.rcs.ipvideocallonly tag described in section 2.4.4 in the OPTIONS exchanges when in coverage where RCS IP Video Calls are supported.
如果设备被配置为仅支持RCS IP视频呼叫服务，如第A.1.12节所述（即不允许RCS IP语音呼叫发起，并且RCS IP视频呼叫的用户对RCS IP语音呼叫的降级是 不允许），它应包括在支持RCS IP视频呼叫的覆盖范围内的OPTIONS交换机中的2.4.4节中描述的 + g.gsma.rcs.ipvideocallonly 标签。

The applicable RCS IP Call feature tags are only included in the OPTIONS exchanges when the device is in coverage where it is configured to support RCS IP Voice and Video Calls.
当设备处于配置为支持RCS IP语音和视频呼叫的覆盖范围内时，适用的RCS IP呼叫功能标记仅包含在OPTIONS交换过程中。

NOTE3: In case of interworking between two Service Providers, the validity of the IP Video Call capability tag highly depends on the end-to-end interconnection chain.
注3：在两个服务提供商之间交互的情况下，IP视频呼叫能力标签的有效性主要取决于端到端互连链。

• Add tags for the Geolocation services:
  为地理位置服务添加标签：

Table 11: SIP OPTIONS tags for geolocation services / 表11：地理位置服务的SIP OPTIONS标记

• To support the service functionality presented in [PRD-RCC.20] it is necessary to extend the tag mechanism by adding the following service tags:
  为了支持[PRD-RCC.20]中提供的服务功能，有必要通过添加以下服务标签来扩展标记机制：
  • Add a tag for Call composer service:
    为Call composer服务添加标签：

Table 12: SIP OPTIONS tags for call composer / 表12：呼叫编辑器的SIP OPTIONS标记

• • Add a tag for Post-call service:
    为点击后服务添加标签：

Table 13: SIP OPTIONS tags for Post-call / 表13：用于后调用的SIP OPTIONS标记

• • Add a tag for Shared Map service:
    为共享地图服务添加标记：

Table 14: SIP OPTIONS tags for Shared Map / 表14：用于共享映射的SIP OPTIONS标记

When used in SIP OPTIONS exchanges this Shared Map capability can only be sent during an active call and is included only if the exchange takes place between the users in the active call.
当在SIP OPTIONS交换中使用时，此共享映射功能只能在活动呼叫期间发送，并且仅当在活动呼叫中的用户之间进行交换时才包括在内。

• • Add a tag for Shared Sketch service:
    为共享草图服务添加标记：

Table 15: SIP OPTIONS tags for Shared Sketch / 表15：用于共享草图的SIP OPTIONS标记

When used in SIP OPTIONS exchanges this Shared Sketch capability can only be sent during an active call and is included only if the exchange takes place between the users in the active call.
在SIP OPTIONS交换中使用时，此共享草图功能只能在活动呼叫期间发送，并且仅当在活动呼叫中的用户之间进行交换时才包括此功能。

Unless specified in other sections (e.g. section 2.4.4), the new tags defined in this section are defined for use in SIP OPTIONS exchanges only and the standard tags defined in the supporting PRDs and endorsement documents shall be used to identify the services in the rest of relevant SIP transactions (e.g. +g.oma.sip-im for Chat implementation based on OMA SIMPLE IM as per [RCS-SIMPLEIM-ENDORS]). It should also be noted that in some cases, the tags employed in the SIP OPTIONS exchange match the standard tags.
除非在其他部分（例如第2.4.4节）中另有规定，本节中定义的新标签仅定义用于SIP OPTIONS交换，并且在支持PRD和背书文件中定义的标准标签应用于识别剩余的相关SIP事务（例如 + g.oma.sip-im ，用于基于根据[RCS-SIMPLEIM-ENDORS]的OMA SIMPLE IM的聊天实现）。 还应注意，在一些情况下，在SIP OPTIONS交换中采用的标签与标准标签匹配。

A device should also add to the Contact header field the same feature tags used at SIP Registration if not already included in the OPTIONS request/response for capability exchange and if they are part of the capabilities supported by the device at this time. This mainly applies to the +g.oma.sip-im feature tag which is used at SIP Registration and in SIP transactions but not used to identify a service capability.
如果尚未包括在用于能力交换的OPTIONS请求/响应中，并且如果它们是设备此时支持的能力的一部分，则设备还应当向联系人报头字段添加在SIP注册时使用的相同特征标签。 这主要适用于在SIP注册和SIP事务中使用的+ g.oma.sip-im要素标记，但不用于标识服务能力。

Finally, it should be taken into account that when several IMS Application Reference Identifier (IARI) tags or several ICSI tags are included in an OPTIONS request, consistently with [RFC3840], IARI tags or ICSI tags shall be concatenated using commas as described in the example below:
最后，应当考虑，当在OPTIONS请求中包括与[RFC3840]一致的多个IMS应用参考标识符（IARI）标签或几个ICSI标签时，应当使用逗号来连接IARI标签或ICSI标签，如在下面的例子中所描述：

    +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft"

Table 16: IARI tag concatenation format example / 表16：IARI标记连接格式示例

2.6.1.1.3 Future extensions to the mechanism / 未来扩展的机制

In addition to the aforementioned additions and to allow:
除了上述添加和允许：

• A Service Provider (or group of Service Providers) to deploy additional services which can benefit from the RCS discovery mechanism, an additional tag format is defined:
  服务提供商（或服务提供商组）部署可受益于RCS发现机制的附加服务，定义了附加标签格式：
  
  • +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp- application.ims.iari.rcs.mnc.mcc."
  • Valid examples are: / 有效示例是：
    • +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp- application.ims.iari.rcs.mnc001.mcc214.serviceA"
    • +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari rcs.mnc680.mcc310.serviceB"

The service name is decided by the each Service Provider. The only requirement for a Service Provider following this approach is to include these tags in the relevant interoperability agreements with other Service Providers.
服务名称由每个服务提供商决定。 服务提供商遵循此方法的唯一要求是将这些标记包含在与其他服务提供商的相关互操作性协议中。

• A third-party to deploy an Extension (e.g. through device API as per [PRD-RCC.53]) which can benefit from the RCS discovery mechanism, an additional tag format is defined:
  要从RCS发现机制中受益的第三方部署扩展（例如通过根据[PRD-RCC.53]的设备API），定义了附加的标记格式：
  • +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ext."
    • Where is an identifier (encoded in base64 as per [RFC4648]) uniquely identifying the application. The way the system ensures uniqueness of the value of the identifier is out of scope of this specification. The length of this field shall not exceed 64 bytes.
      其中是唯一标识应用程序的标识符（按照[RFC4648]在base64中编码）。 系统确保标识符的值的唯一性的方式超出了本规范的范围。 此字段的长度不得超过64字节。
  • A valid example is: / 一个有效的例子是：
    • +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp- application.ims.iari.rcs.ext.A5TgS99bJloIUIh1209SJ82B21m87S1B87SBqfS8 71BS8787SBXBA3P45wjp63tk”

NOTE: A Service Provider may deploy Extensions as a third-party.
注意：服务提供商可能会将扩展程序部署为第三方。

The use of those Extensions for actual third-party usages requires a full functioning framework, including a secure management of the Extensions on the devices. If this framework is not in place, Clients shall not enable third parties to use this tag.
将这些扩展用于实际的第三方使用需要一个完整的功能框架，包括设备上扩展的安全管理。 如果此框架不到位，客户不得允许第三方使用此标记。

These IARIs are only exchanged in capability discovery and updates when the Extensions make use of the RCS infrastructure to communicate (as per section 3.12.4.2).
这些IRAI仅在扩展使用RCS基础设施进行通信时进行能力发现和更新（根据第3.12.4.2节）。

Table 17: SIP OPTIONS tag proposal for future lines of work / 表17：未来工作线的SIP OPTIONS标签提议

2.6.1.1.4 UI integration optimisations / UI集成优化

In addition to the optimisations to minimise the traffic generated by the SIP OPTIONS exchanges when possible, there are two additional optimisations related to the discovery mechanism integration on the UI that should be taken into account:
除了在可能的情况下最小化由SIP OPTIONS交换产生的流量的优化之外，还有两个与UI上的发现机制集成相关的其他优化应予以考虑：

• The round trip time for a SIP OPTIONS exchange (send and receive response) is expected to range between under 1-2 seconds. Taking this into account, the UI has to be optimised to minimise the impact of this exchange delay.
  SIP OPTIONS交换（发送和接收响应）的往返时间预计在1-2秒之间。 考虑到这一点，UI必须被优化以最小化这种交换延迟的影响。
• When sending the SIP OPTIONS messages to several users (for example, during first time registration or when polling), it is recommended to employ a non-aggressive strategy and allow time between each exchange to:
  当向多个用户发送SIP OPTIONS消息时（例如，在首次注册或轮询期间），建议采用非攻击性策略，并在每次交换之间允许时间：
  • Minimise potential network impact
    尽量减少潜在的网络影响
  • Avoid any impact on the user experience (for example a slower UI, blockings and so on)
    避免对用户体验的任何影响（例如，较慢的UI，阻止等）

NOTE: In this case this specification does not specify the specific mechanisms which should be implemented leaving space to Original Equipment Manufacturers (OEMs) and third parties to drive innovative and differentiated solutions, which distinguish their products from competitors.
注意：在这种情况下，本规范没有指定应实施的具体机制，为原始设备制造商（OEM）和第三方留下空间，以推动创新和差异化解决方案，从而将其产品与竞争对手区分开来。

2.6.1.1.5 Multidevice support: Options-AS / 多设备支持：Options与应用服务器

Ultimately, the choice of supporting multiple devices for a single user is decided by each Service Provider. The considerations contained in this section will only apply to those Service Providers willing to include RCS multidevice support in their networks.
最终，为单个用户支持多个设备的选择由每个服务提供商决定。 本节中包含的注意事项仅适用于愿意在其网络中包含RCS多设备支持的服务提供商。

In a multidevice scenario, when the user is registered to the IMS CORE with various devices using the same URI (that is the same implicit registration set), the OPTIONS exchange will return incomplete information:
在多设备场景中，当用户使用相同的URI（即相同的隐式注册集）向各种设备注册IMS CORE时，OPTIONS交换将返回不完整的信息：

• The capabilities contained in the OPTIONS message refer only to the originating device (that is the originating user may be logged in with the same URI in several devices).
  OPTIONS消息中包含的能力仅指发端设备（即，发起用户可以在几个设备中使用相同的URI登录）。
• The IMS Core, depending on the configuration, either sends the OPTIONS message to the device that first registered to the IMS CORE or forks the OPTIONS to all of the registered devices. In any case, only the first response is passed back to the requester, discarding the others. In other words, the capabilities returned in the OPTIONS response will be from only one of the user’s devices.
  IMS Core根据配置向首先注册到IMS CORE的设备发送OPTIONS消息，或将OPTIONS分配给所有注册的设备。 在任何情况下，只有第一个响应被传递回请求者，丢弃其他响应。 换句话说，OPTIONS响应中返回的能力将只来自用户的一个设备。

The preferred implementation for handling the OPTIONS in a multidevice environment is left to the Service Provider’s discretion. The only requirement is that it should not impact the terminal side (that is there will be no changes on the client side). A possible solution for extending the OPTIONS mechanism to a multidevice scenario is to include a custom AS implementing the following logic:
在多设备环境中处理OPTIONS的优选实现由服务提供者自行决定。 唯一的要求是它不应该影响终端侧（即在客户端没有改变）。 将OPTIONS机制扩展到多设备场景的一种可能的解决方案是包括实现以下逻辑的自定义AS：

• A trigger will be setup in the IMS CORE to send all of the OPTIONS from an RCS user to the AS.
  将在IMS CORE中设置触发器，以将所有选项从RCS用户发送到AS。
• The AS will fork the OPTIONS request to all of the RCS user’s registered devices and will aggregate all of the capabilities returned into one OPTIONS response if the forking is not already implemented by the IMS core network.
  AS将把OPTIONS请求分配给所有RCS用户的注册设备，并且如果IMS核心网络尚未实现分支，则AS将将所有返回的能力聚合到一个OPTIONS响应中。
• Once the responses from the different devices are received, the AS will aggregate all the capabilities from the replies and send them back to the caller.
  一旦接收到来自不同设备的响应，AS将聚合来自答复的所有能力，并将它们发送回呼叫者。
• Even if not all of the replies have been received in less than a configurable amount of time, the AS will return the aggregated information received so far.
  即使不是在小于可配置的时间量内接收到所有答复，美国将返回到目前为止接收的聚合信息。

NOTE: the recommendation is to set the value to optimise the UX on the terminal.
注意：建议设置该值以优化终端上的USE。

• Capabilities shall be aggregated to provide the response to an incoming SIP OPTIONS request. For outgoing requests, it is up to the Service Provider’s policy to aggregate the capabilities.
  能力应被聚合以提供对输入SIP OPTIONS请求的响应。 对于传出请求，由服务提供者的策略来聚合能力。

NOTE: Similar procedures may at the service provider’s discretion also be applied at originating side to aggregate the capabilities of all the user’s devices in the OPTIONS request.
注意：类似的过程可能由服务提供商自行决定在源端应用以聚合OPTIONS请求中所有用户设备的能力。

To implement this feature, an application server should be able to uniquely identify each user device to perform the forking of the OPTIONS message and to intercept and process the responses. The mechanism to have these individual identities (a GRUU or sip.instance feature tag) is covered in section 2.11.2.
为了实现该特征，应用服务器应该能够唯一地识别每个用户设备以执行OPTIONS消息的分支，并且拦截和处理响应。 具有这些个体标识（GRUU或sip.instance特征标签）的机制在2.11.2节中讨论。

While multidevice support is an option for each Service Provider to decide whether or not it is supported, the RCS capability discovery mechanism based on the SIP OPTIONS message is a mandatory requirement and the behaviour will be the one specified previously to ensure seamless interworking between Service Providers.
虽然多设备支持是由每个服务提供商来决定它是否支持的选项，但是基于SIP OPTIONS消息的RCS能力发现机制是一个强制性的要求，且其行为如先前所指定的一样，以确保服务供应商之间的无缝互通 。

Figure 7: Options application server: Capability aggregation on SIP OPTIONS request / 图7：选项应用程序服务器：SIP OPTIONS请求上的能力聚合

2.6.1.2 Capability discovery via presence / 通过存在的能力发现

2.6.1.2.1 General Overview / 总体概述

As an alternative to the SIP OPTIONS-based mechanism presented in the previous section, a Service Provider deploying a Presence Server may provide the capability discovery mechanism via presence. The service capabilities are then realised using the “Service” part of the Presence Data Model. This part is described in section 2.6.1.2.5.
作为在前一部分中呈现的基于SIP OPTIONS的机制的替代，部署存在服务器的服务提供者可以通过存在来提供能力发现机制。 然后使用存在数据模型的“服务”部分实现服务能力。 这一部分在2.6.1.2.5节中描述。

2.6.1.2.2 Publication of the Service Capabilities / 服务能力的发布

The capabilities are announced in a Presence document that is published by using the SIP PUBLISH method as defined in [Presence]. When the terminal is started, the client then sends a SIP PUBLISH request containing the capabilities (see section 2.6.1.2.5). This SIP PUBLISH request shall not include an Expires header field.
这些功能在使用在[Presence]中定义的SIP PUBLISH方法发布的Presence文档中公布。 当终端启动时，客户端然后发送包含能力的SIP PUBLISH请求（见第2.6.1.2.5节）。 此SIP PUBLISH请求不应包含Expires头字段。

The publication is maintained in the Presence Server whenever the application is running by sending a refresh request before it expires.
只要应用程序正在运行，就会通过在Presence服务器过期之前发送刷新请求来维护该发布。

If changes are required in the published capabilities (for example, due to the behaviour specified in sections 2.6.2 and 2.6.3), a presence modify request is sent using the ‘Sip-If- Match’ header according to [Presence]. When the client/device is switched off, it shall remove the published capabilities before unregistering according to the procedure defined in [RFC3903] (i.e. by sending a SIP PUBLISH request without a body including the ‘Sip-If- Match’ header and an Expires header set to 0).
如果在已发布的功能中需要更改（例如，由于第2.6.2节和第2.6.3节中指定的行为），将根据[Presence]使用“Sip-If-Match”头发送存在修改请求。 当客户端/设备关闭时，它将根据[RFC3903]中定义的过程（即通过发送没有包括“Sip-If-Match”报头的主体的SIP PUBLISH请求，并且Expires 标题设置为0）。

2.6.1.2.3 Service Capabilities Retrieval / 服务能力检索

Service capabilities of an RCS user can be retrieved by another RCS user via a presence subscription issued by their client, providing the pertaining Presence Authorisation rules allow him to do so. The templates provided in sections 2.14.1 and 3.7.4.5.2 allow this for the authorised users. An RCS user is, therefore, allowed to retrieve the service capabilities of contacts when they have an established Social Presence relationship.
RCS用户的服务能力可以由另一RCS用户经由其客户端发布的存在订阅检索，提供相关存在授权规则允许他这样做。 第2.14.1和3.7.4.5.2节中提供的模板允许授权用户使用。 因此，当RCS用户具有建立的社交呈现关系时，允许RCS用户检索联系人的服务能力。

RCS users may also retrieve the service capability information of contacts with which they have not established a Social Presence relationship by means of Anonymous Fetch operations issued by their client (as described in section 7.1 of [PRESENCE]). This will result in a single NOTIFY request indicating the service capabilities of that contact. This information shall then be cached in the client as described in section 2.6.4. The Anonymous Fetch operation shall be supported in clients.
RCS用户还可以通过其客户端发出的匿名获取操作（如[PRESENCE]的第7.1节所述）检索他们尚未与之建立社会存在关系的联系人的服务能力信息。 这将导致单个NOTIFY请求指示该联系人的服务能力。 然后该信息将被缓存在客户端中，如第2.6.4节所述。 客户端应支持匿名提取操作。

If an RLS-URI (Resource List Server URI, see Annex A section A.1.2.1) has been provisioned, a client shall use an Anonymous Fetch request using a request-contained list if the client has to query the capabilities of multiple users at once (e.g. during a poll). In this case it shall do so according to section 5.2.1.2.2 of [Presence2.0_TS].
如果已经提供了RLS-URI（资源列表服务器URI，参见附件A部分A.1.2.1），如果客户端必须查询多个用户的能力，则客户端将使用使用请求包含的列表的匿名获取请求 （例如在轮询期间）。 在这种情况下，它将根据[Presence2.0_TS]的5.2.1.2.2节这样做。

If only a single contact needs to be queried, an individual fetch shall be done instead even if an RLS-URI has been configured.
如果只需要查询一个联系人，即使已经配置了RLS-URI，也应该进行单独的提取。

2.6.1.2.3.1 General Processing Rules to Ensure Backwards Compatibility / 确保向后兼容性的一般处理规则

To maintain enough flexibility and not to impose potentially sub-optimal technical choices on future RCS versions, the parsing of the capabilities in an RCS client should be sufficiently robust. First the watcher should apply the processing rules defined in [Presence2.0_DDS] and if then there are still multiple elements the watcher shall follow the guidelines in the RCS presence parsing presented below:
为了保持足够的灵活性并且不在未来的RCS版本上施加潜在的次优技术选择，在RCS客户端中的能力的解析应足够鲁棒。 首先观察者应该应用[Presence2.0_DDS]中定义的处理规则，如果接下来仍然有多个元素，观察者应遵循下面呈现的RCS存在解析中的指导：

• Unknown or unsupported elements and tuples could be present in the document. In that case they should be ignored.
  文档中可能存在未知或不受支持的元素和元组。 在这种情况下，应该忽略它们。
• Unknown service identifiers (Service-Id) could be present in the document. Tuples containing those should be ignored.
  文档中可能存在未知的服务标识符（Service-Id）。 包含这些的元组应该被忽略。
• Unknown service versions of known services could be present in the presence document. Tuples containing those should be ignored.
  存在文档中可能存在未知服务版本的已知服务。 包含这些的元组应该被忽略。
• The same service could occur multiple times in the presence document with different contact addresses. To cope with this case, the following behaviour shall be used for displaying and using the tuples:
  相同的服务可能在具有不同联系人地址的在线状态文档中多次发生。 为了应对这种情况，应该使用以下行为来显示和使用元组：
  • If one of the tuples contains a contact address that corresponds to the presentity about which the presence document was received, all others shall be ignored.
    如果元组中的一个包含与接收到存在文档的呈现相对应的联系地址，则所有其它的将被忽略。
  • Tuples that contain a contact (address) element which corresponds to another presentity (that is another contact in the contact-list of the user or another tel URI) shall be ignored.
    包含对应于另一个表示（即在用户的联系人列表中的另一个联系人或另一个tel URI）的联系人（地址）元素的元组将被忽略。
  • Tuples containing contact elements with types of addresses that are not supported by the client for that service shall be ignored (for example messaging using an e-mail address while e-mail is not supported by the client).
    包含具有该服务的客户端不支持的地址类型的联系人元素的元组将被忽略（例如，使用电子邮件地址的消息传递，而客户端不支持电子邮件）。
  • If after applying the above rules, there are still multiple non-ignored tuples remaining for the service, all but the first shall be ignored.
    如果在应用上述规则之后，对于服务仍然存在多个不被忽略的元组，则除了第一个之外的所有元组都将被忽略。
  • If after applying the above rules, there is a non-ignored tuple remaining, the service behaviour shall be as follows
    如果在应用上述规则之后，还有一个非忽略元组剩余，则服务行为如下
    • The capability to use the service for communication with the contact shall be announced to the user
      使用服务与联系人通信的能力应向用户公布
    • If the remaining tuple contained no contact address or it matched the one of the presentity, the presentity’s address will be used for setting up communication using that service
      如果剩余的元组不包含联系地址或者它与存在体中的一个相匹配，则演示的地址将被用于使用该服务建立通信
    • Otherwise the address contained in the contact element will be used for setting up the corresponding service
      否则，包含在联系人元素中的地址将用于设置相应的服务
• The Watcher shall follow the procedures defined in section 6.2 "Default Watcher Processing" of [Presence2.0_DDS].
  观察者应遵循[Presence 2.0 DDS]的第6.2节“默认观察者处理”中定义的过程。

Regarding the use of the address provided in the contact, the communication addresses (contact) part of service tuples shall not be:
关于使用在联系人中提供的地址，服务元组的通信地址（联系）部分不应是：

• Shown to the end-user, these addresses are handled locally by the terminal;
  对终端用户显示，这些地址由终端本地处理;
• Used to request presence subscription, an RCS client is NOT supposed to subscribe to the contact associated with a service capability tuple received in a presence document.
  用于请求存在订阅，RCS客户端不应该预订与在存在文档中接收的服务能力元组相关联的联系人。

2.6.1.2.4 Authorisation for capabilities retrieval / 能力检索的授权

To provide authorisation to retrieve the capabilities using an Anonymous Fetch request, an RCS client supporting the capability exchange using presence shall set the presence rules document in the presence XDMS as follows:
为了提供授权以使用匿名获取请求来检索能力，支持使用存在的能力交换的RCS客户端应在存在XDMS中设置存在规则文档，如下：

Presence XDMS:
AUID: org.openmobilealliance.pres-rules
Document name / 文档名: pres-rules
Template / 模板

<?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset
  xmlns:ocp="urn:oma:xml:xdm:common-policy"
  xmlns:op="urn:oma:xml:prs:pres-rules"
  xmlns:pr="urn:ietf:params:xml:ns:pres-rules" 
  xmlns:cr="urn:ietf:params:xml:ns:common-policy">

  <! -- This rule allows all service capabilities to be sent for anonymous requests -->
  <! -- To realize the service capabilities to all requirement -->
  <! -- This rule replaces the default “wp_prs_block_anonymous” rule -->
  <! -- NOTE: May be modified to only allow RCS specified services -->
  <cr:rule id="rcs_allow_services_anonymous">
    <cr:conditions>
      <ocp:anonymous-request/>
    </cr:conditions>
    <cr:actions>
      <pr:sub-handling>allow</pr:sub-handling>
    </cr:actions>
    <cr:transformations>
      <pr:provide-services>
        <pr:all-services/>
        </pr:provide-services>
      <pr:provide-all-attributes/>
    </cr:transformations>
  </cr:rule>
</cr:ruleset>

Table 18: Presence XDMS template / 表18：Presence XDMS模板

If social presence is supported (see section 3.7), the pres-rules document should be set to contain both “rcs_allow_services_anonymous” described in this section and the rules provided in the template described in section 3.7.4.5.2.
如果支持社交网络的存在（见第3.7节），预设规则文档应设置为包含本节中描述的“rcs_allow_services_anonymous”和第3.7.4.5.2节中描述的模板中提供的规则。

Handling of this template shall be done as described in section 2.14.2.
该模板的处理应按第2.14.2节所述进行。

2.6.1.2.5 Service part of the presence Data Model / 服务部分的存在数据模型

A service capability is provided according to the model described in Table 19:
服务能力是根据表19中描述的模型提供的：

Table 19: Attributes of the Presence Service element / 表19：Presence服务元素的属性

2.6.1.2.5.1 Service-descriptions for the Selected RCS Services / 所选RCS服务的服务描述

Service capabilities publication through OMA Presence Enabler [Presence2.0_TS] or [Presence] must follow [PDE_13] rules.
通过OMA Presence启动器[Presence 2.0_TS]或[Presence]发布的服务功能必须遵循[PDE_13]规则。

The RCS registered Service-description values are listed in OMNA Presence <service-description> Registry at:
RCS注册的服务描述值列在OMAN存在<service-description>注册表中，注册表在：
http://www.openmobilealliance.org/Tech/omna/omna-prs-PidfSvcDesc-registry.aspx

The following <service-description> child elements, will be used in the presence document:
以下<service-description>子元素将用于在线状态文档：

Standalone Messaging / 独立消息
Service-id: org.openmobilealliance:StandaloneMsg
Version: 2
Contact address type: tel / SIP URI

Session Mode Messaging / 会话模式消息
Service-id: org.openmobilealliance:IM-session
Version: 1.0
Contact address type: tel / SIP URI

Or / 或

Service-id: org.openmobilealliance:ChatSession
Version: 2
Contact address type: tel / SIP URI

File Transfer via MSRP without Store and Forward / 文件传输通过MSRP无存储和转发
Service-id: org.openmobilealliance:File-Transfer
Version: 1.0
Contact address type: tel / SIP URI

This capability shall only be provided when File Transfer via MSRP is enabled through the PROVIDE FT configuration parameter described in section A.1.5 and the Chat Technology is set to OMA SIMPLE IM using the CHAT MESSAGING TECHNOLOGY configuration parameter defined in section A.1.4.3.
仅当通过A.2.5中描述的PROVIDE FT配置参数启用通过MSRP的文件传输，并且使用A.1.4.3节中定义的CHAT消息传送技术配置参数将聊天技术设置为OMA SIMPLE IM时，才提供此功能 。

File Transfer with Store and Forward / 存储和转发文件传输
Service-id: org.openmobilealliance:File-Transfer
Version: 2
Contact address type: tel / SIP URI

This capability shall only be provided when File Transfer via MSRP is enabled through the PROVIDE FT configuration parameter described in section A.1.5 and the Chat Technology is set to OMA CPM using the CHAT MESSAGING TECHNOLOGY configuration parameter defined in section A.1.4.3.
仅当通过A.2.5中描述的PROVIDE FT配置参数启用通过MSRP的文件传输，并且使用A.1.4.3节中定义的CHAT消息传送技术配置参数将聊天技术设置为OMA CPM时，才提供此功能。

File Transfer Thumbnail / 文件传输缩略图
Service-id: org.openmobilealliance:File-Transfer-thumb
Version: 2
Contact address type: tel / SIP URI

This capability shall be provided when File Transfer via MSRP is enabled through the PROVIDE FT configuration parameter described in section A.1.5.
当通过MSRP启用文件传输时，应通过第A.1.5节中描述的PROVIDE FT配置参数启用此功能。

File Transfer via HTTP / 通过HTTP进行文件传输
Service-id: org.openmobilealliance:File-Transfer-HTTP
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

Video Share during a call / 在通话期间分享视频
Service-id: org.gsma.videoshare
Version: 1.0
Contact address type: tel / SIP URI

Social presence information / 社交呈现信息
Service-id: org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcse.sp
Version: 1.0
Contact address type: tel / SIP URI

Capability discovery via presence / 通过存在发现能力
Service-id: org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcse.dp
Version: 1.0
Contact address type: tel / SIP URI

IP Voice Call (IR.92) / IP语音通话（IR.92）
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
Version: 1.0
Media capabilities: audio, duplex
Contact address type: tel / SIP URI

IP Video Call (IR.94) / IP视频通话（IR.94）
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
Version: 1.0
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI

NOTE1: A single device supporting both IP Voice Call (IR.92) and IP Video Call (IR.94) shall publish a single tuple containing the common MMTel service id and both audio and video servcaps elements. Separate tuples are not required.
注1：支持IP语音呼叫（IR.92）和IP视频呼叫（IR.94）的单个设备应公布包含公共MMTel服务id和音频和视频服务器元素的单个元组。 不需要单独的元组。

RCS IP Voice Call (strong preference for no breakout (IP end to end)) / RCS IP语音呼叫（强烈偏好无中断（IP端到端））
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall
Version: 1.0
Media capabilities: audio, duplex
Contact address type: tel / SIP URI

RCS IP Video Call (strong preference for no breakout (IP end to end)) / RCS IP视频呼叫（强烈偏好无中断（IP端到端））
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall
Version: 1.0
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI

NOTE2: A single device supporting both RCS IP Voice Call and RCS IP Video Call with a strong preference for no breakout shall publish a single tuple containing the org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall service-id and both audio and video servcaps elements. Separate tuples are not required.
注2：支持RCS IP语音呼叫和RCS IP视频呼叫的单个设备，如果没有中断，则应该发布一个包含org.3gpp.urn：urn-7：3gpp-service.ims.icsi.mmtel的单个元组。 gsma.ipcall service-id和音频和视频服务器元素。 不需要单独的元组。

RCS IP Video Call (strong preference for no breakout (IP end to end) and video media cannot be dropped) / RCS IP视频呼叫（无优先级的无中断（IP端到端）和视频媒体不能删除）
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall.ipvideocallonly
Version: 1.0
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI

NOTE3: A device shall provide in the published capabilities only one of the RCS IP Voice Call, RCS IP Video Call and RCS IP Video Call where video media cannot be removed capabilities depending on whether according to the PROVIDE RCS IP VOICE CALL and PROVIDE RCS IP VIDEO CALL configuration parameters defined in section A.1.12 in the currently used radio technology respectively only RCS IP Voice Calls, both RCS IP Voice Calls and RCS IP Video Calls or only RCS IP Video Calls are allowed. Due the combining of the capabilities of different devices (i.e. the Presence Composition policy), it may happen though that multiple of those capabilities are received by a watcher. If the RCS IP Video Call where video media cannot be removed capability is received in combination with the RCS IP Video Call and/or the RCS IP Voice Call capability, towards that contact both RCS IP Voice Call and RCS IP Video Calls may be successfully initiated as described in sections 3.8 and 3.9 when those services are allowed according to the local configuration and used radio technology.
注3：在公布的功能中，设备应仅提供RCS IP语音呼叫，RCS IP视频呼叫和视频媒体不能被移除的RCS IP视频呼叫中的一个，这依赖于根据在第A.1.12节定义的PROVIDE RCS IP VOICE CALL和PROVIDE RCS IP VIDEO CALL配置参数完成，这两个参数在当前使用的无线电技术中分别对应三种能力：仅允许RCS IP语音呼叫，RCS IP语音呼叫和视频呼叫并存，或仅RCS IP视频呼叫。由于不同设备的能力的组合（即，存在组合策略），可能发生观察者接收到多种能力组合的情况。如果收到了“视频媒体不能被移除的RCS IP视频呼叫”能力，同时又收到“RCS IP视频呼叫”和/或“RCS IP 语音呼叫”能力，那么根据本地配置和使用的无线电技术，如果本地允许这些服务，则如第3.8节和第3.9节所述，向该联系人可以成功地发起RCS IP语音呼叫和RCS IP视频呼叫。

NOTE4: RCS IP Calls and IP Calls per IR.92/IR.94 can technically interoperate. Therefore, an RCS IP Call client is allowed to answer an incoming IP Call (and vice versa), and shall process the received capability information accordingly.
注4：每个IR.92 / IR.94的RCS IP呼叫和IP呼叫在技术上可以互操作。 因此，RCS IP呼叫客户端被允许应答呼入的IP呼叫（反之亦然），并且将相应地处理所接收的能力信息。

Geolocation PUSH / 地理位置PUSH
Service-id: org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcs.geopush
Version: 1.0
Contact address type: tel/ SIP URI

Geolocation PULL / 地理位置PULL
Service-id: org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcs.geopullft
Version: 1.0
Contact address type: tel/ SIP URI

NOTE5: An RCS client shall include both the Video Share 2.0 and the Video Share 1.0 capabilities to indicate backwards compatibility with earlier RCS clients.
注5：RCS客户端应包括视频共享2.0和视频共享1.0功能，以指示与早期RCS客户端的向后兼容性。

Call composer / 呼叫创作者
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.gsma.callcomposer
Version: 1.0
Contact address type: tel / SIP URI

Post-call / 呼叫后
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.gsma.callunanswered
Version: 1.0
Contact address type: tel / SIP URI

Shared Map / 共享地图
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.gsma.sharedmap
Version: 1.0
Contact address type: tel / SIP URI

Shared Sketch / 共享素描
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.gsma.sharedsketch
Version: 1.0
Contact address type: tel / SIP URI

The service capability information that is the object of a SIP PUBLISH by the RCS client (service tuple) corresponds to the services supported by the device. For example, a device can indicate its support for RCS IP Voice Calls according to section 3.8 with a service- and media description.
作为由RCS客户端发布的SIP的对象的服务能力信息（服务元组）对应于设备支持的服务。 例如，设备可以根据具有服务和媒体描述的第3.8节来指示其对RCS IP语音呼叫的支持。

The set of services published may be further restricted by some Service Provider settings on the User Equipment (UE, on for example the services that are allowed by the Service Provider in the network) that are described in Annex A.
所公布的服务集合可以由附件A中描述的用户设备（UE，例如网络中的服务提供商所允许的服务）上的一些服务提供商设置进一步限制。

2.6.1.2.6 Future extensions to the mechanism / 未来扩展的机制

Consistently with section 2.6.1.1.3, it is also possible to extend the capability discovery based in presence following the guideline presented in the table below to define new service-IDs:
与第2.6.1.1.3节一致，也可以根据下表中的准则扩展能力发现，以定义新的服务ID：

Table 20: Presence service tuple proposal for future lines of work / 表20：用于未来工作线的存在服务元组提议

Service extension patterns including “mnc.mcc” may be registered with OMNA, if a service provider wishes to reserve the values in order to avoid any future collisions with new services (extensions, or new OMA services).
如果服务提供商希望保留这些值以避免与新服务（扩展或新的OMA服务）的任何未来冲突，则可以向OMNA注册包括“mnc.mcc”的服务扩展模式。

Example of the reserved service extension patterns that may be registered is:
可以注册的预留服务扩展模式的示例是：
org.openmobilealliance:ChatSession.mnc072.mcc01

Examples of service extensions:
服务扩展的示例：

• Service-id extension(s) for Group Chat with store and forward:
  用于存储和转发的组聊天的服务标识扩展：
  org.openmobilealliance:ChatSession.mnc072.mcc01
  OR
  org.openmobilealliance:ChatSession.mnc072.mcc01.myGCFlavor1 AND org.openmobilealliance:ChatSession.mnc072.mcc01.myGCFlavor2
• Using IARI:
• org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcs.mnc01.mcc072.sfgroupchatMyFlavor

The use of the Third-Party specific services requires a full functioning framework, including a secure management of the Extensions on the devices. If this framework is not in place, Clients shall not enable third parties to use this service.
使用第三方特定服务需要一个完整的功能框架，包括设备上扩展的安全管理。 如果此框架不到位，客户不得允许第三方使用此服务。

The Third-Party specific services are only exchanged in capability discovery and updates when the Extensions make use of the RCS infrastructure to communicate.
仅当扩展利用RCS基础设施进行通信时，第三方特定服务才在能力发现和更新时进行交换。

2.6.1.3 Coexistence between the discovery mechanisms / 发现机制之间的共存

2.6.1.3.1 Service/capability indicators / 服务/能力指标

The equivalence between presence Service-IDs and SIP OPTIONS tags are presented in the following table:
存在Service-ID和SIP OPTIONS标记之间的等价关系如下表所示：

2.6.1.3.2 Coexistence using a common device stack / 使用公共设备堆栈的共存

As mentioned in section 2.6.1, the principle for interoperability is to have a common stack on devices which is able to:
如第2.6.1节所述，互操作性原则是在设备上有一个共同的栈，它能够：

• Answer a SIP OPTIONS query as per the mechanism presented in section 2.6.1.1 independently on whether the device is configured to use SIP OPTIONS or presence as the default capability exchange mechanism.
  根据第2.6.1.1节中所述的机制，独立地回答SIP OPTIONS查询，无论设备是配置为使用SIP OPTIONS还是存在作为默认能力交换机制。
• If the device is configured to use presence as the default capability exchange mechanism, implement the fallback to SIP OPTIONS procedure.
  如果设备配置为使用Presence作为默认能力交换机制，请实施回退到SIP OPTIONS过程。

2.6.1.3.2.1 Interworking when the request is originated in the Service Provider using presence as the default discovery mechanism / 当请求在服务提供者中使用存在作为默认发现机制发起时进行互通

In this case, the initial capability exchange request is performed using presence (ANONYMOUS SUBSCRIBE), however either the originating or the terminating Service Provider Network detects that this method is not supported for that particular user and returns with one of the following errors:
在这种情况下，使用存在（ANONYMOUS SUBSCRIBE）来执行初始能力交换请求，但是始发或终止服务提供商网络检测到该方法不被该特定用户支持并且返回以下错误之一：

• 405 METHOD NOT ALLOWED
• 501 NOT IMPLEMENTED

As a result, the RCS stack on the UE shall identify that the contact does not support the Presence discovery mechanism. From thereon the OPTIONS-based mechanism (as presented in section 2.6.1.1) shall be used to query that contact’s capabilities.
因此，UE上的RCS栈将标识联系人不支持存在发现机制。 从这里，基于OPTIONS的机制（如第2.6.1.1节所述）将用于查询联系人的能力。

Figure 8: Fallback to SIP-OPTIONS procedure / 图8：回退到SIP-OPTIONS过程

If in the future, the contact is again identified as supporting discovery via presence (i.e. the +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.dp" tag was included either in the OPTIONS request or in its response), then capability discovery via presence (as described in section 2.6.1.2) will be used from there on for that contact.
如果将来，联系人被再次识别为通过存在支持发现（即，在OPTIONS请求中或在其响应中包括+g.3gpp.iari-ref =“urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.dp”标签 ），则从那时起，对于该联系人，将使用通过在线状态的能力发现（如第2.6.1.2节所述）。

2.6.1.3.2.2 Interworking when the request is originated in the Service Provider using SIP OPTIONS as the default discovery mechanism / 当请求在服务提供者中使用SIP OPTIONS作为默认发现机制时的互通

In this case, the SIP OPTIONS message is exchanged end-to-end as described in section 2.6.1.1.1.
在这种情况下，如第2.6.1.1.1节所述，SIP OPTIONS消息是端对端交换的。

Figure 9: Inter-Service Provider SIP OPTIONS exchange for interworking / 图9：用于互通的服务提供商之间的SIP OPTIONS交互

2.6.1.3.3 Coexistence between the discovery mechanisms via network interworking / 通过网络互通在发现机制之间的共存

When Service Providers use presence as the discovery mechanism, there are two ways in which interoperability is achieved between such a Service Provider and those Service Providers who have selected SIP OPTIONS as the default discovery mechanism.
当服务提供商使用存在作为发现机制时，在这样的服务提供商和已经选择SIP OPTIONS作为默认发现机制的那些服务提供商之间，实现互操作性有两种方式。

• Service Provider supports fallback to SIP OPTIONS: Interoperability leverages the common device stack as defined in 2.6.1.3.2 above. In this case, there is no requirement for network based interworking.
  服务提供商支持回退到SIP选项：互操作性利用上面2.6.1.3.2中定义的公共设备堆栈。 在这种情况下，不需要基于网络的互配。
• Service Provider does not support fallback to SIP OPTIONS: Interoperability is provided by network based interworking.
  服务提供商不支持回退到SIP选项：互操作性由基于网络的互通提供。
• Service Provider disables capability discovery: Interoperability is provided by network based interworking.
  服务提供商禁用功能发现：互操作性由基于网络的互通提供。

Refer to the interworking table below to identify specific network based interworking requirements:
参考下面的互通表来识别特定的基于网络的互通要求：

NOTES: / 注：

1. No interworking required; based on common stack approach.
   无需互配; 基于通用堆栈方法。
2. No interworking required; based on common default discovery mode.
   无需互配; 基于公共默认发现模式。
3. Interworking required for SIP OPTIONS conversion to SUBSCRIBE/NOTIFY and vice versa.
   SIP OPTIONS转换为SUBSCRIBE / NOTIFY所需的互通，反之亦然。
4. Interworking required for SIP OPTIONS conversion to SUBSCRIBE/NOTIFY; requirement for conversion from SUBSCRIBE/NOTIFY to SIP OPTIONS contingent upon "SIP OPTIONS default" Service Provider support for Anonymous Fetch at PS.
   SIP OPTIONS转换为SUBSCRIBE / NOTIFY所需的互通; 要求从SUBSCRIBE / NOTIFY转换为SIP选项，取决于“SIP选项默认”服务提供商对PS匿名提取的支持。

Table 22 considers whether a service provider that uses SIP OPTIONS as the default discovery also supports presence or not:
表22考虑了使用SIP OPTIONS作为默认发现的服务提供者是否也支持存在：

• The Presence Server acts as a source for both SPI and capability information. This is addressed in 2.6.1.4 which states that capability exchanges are not required in the case where a social relationship is established.
  存在服务器充当SPI和功能信息的源。 这在2.6.1.4中阐述，其中规定在建立社会关系的情况下不需要能力交换。
• If a Service Provider uses SIP OPTIONS as the default discovery mechanism, and has deployed presence, the Service Provider may implement a policy that allows their Presence Server to respond to presence based discovery (anonymous) requests.
  如果服务提供商使用SIP OPTIONS作为默认发现机制，并且部署了存在，则服务提供商可以实现允许其存在服务器响应基于存在的发现（匿名）请求的策略。
• Such a policy would impact the required interworking architecture; therefore it is addressed in Table 22 above.
  这样的策略将影响所需的互通架构; 因此在上表22中进行了说明。

Specific network interworking function requirements are contingent upon the service discovery modes and policies of each service provider. At the Service Provider’s discretion, an interworking function can be implemented in the network to:
特定网络互通功能需求取决于每个服务提供商的服务发现模式和策略。 在服务提供商的判断下，可以在网络中实现互通功能以：

• Answer incoming SIP OPTIONS requests based on the Presence Server information (Figure 10).
  根据Presence Server信息回答传入的SIP OPTIONS请求（图10）。
• Convert SIP ANONYMOUS SUBSCRIBE requests into SIP OPTIONS requests (Figure 11).
  将SIP ANONYMOUS SUBSCRIBE请求转换为SIP OPTIONS请求（图11）。

Figure 10: Capability interworking via network: Options request / 图10：通过网络的能力互通：选项请求

Figure 11: Capability interworking via network: Presence request / 图11：通过网络的能力互通：存在请求

NOTE: Figure 10 and Figure 11 do not specify whether the IWF is deployed:
注意：图10和图11不指定是否部署IWF：

• In the Originating IMS network or
  在始发IMS网络或
• In the Terminating IMS network or
  在终止IMS网络或
• In the Inter-Network region.
  在网络间区域。

All of the above are valid architectural options. NNI impact is not uniform and is a function of the architecture selected. While the details surrounding the specific architecture and functionality of an IWF are left to the Service Provider, it is recommended that impact at the UNI should be minimal and as transparent as possible.
所有上述都是有效的架构选项。 NNI冲击是不均匀的，并且是所选择的架构的函数。 虽然IWF的具体架构和功能的细节留给了服务提供商，但建议对UNI的影响应尽可能小，并尽可能透明。

The successful deployment of network IWF capabilities must provide an environment where all RCS devices exchange capabilities information without requiring additional functionality or logic at the client (i.e. no UNI impact).
网络IWF能力的成功部署必须提供一种环境，其中所有RCS设备交换能力信息，而不需要客户端处的附加功能或逻辑（即，没有UNI影响）。

The following additional guidelines are provided regarding the implementation of an IWF function:
关于IF功能的实现，提供了以下附加准则：

• If either Service Provider has a heterogeneous network from a capabilities discovery mode perspective, this must be factored into the IWF architecture.
  如果服务提供商从功能发现模式角度来看具有异构网络，则必须将其考虑到IWF架构中。
• The Service Provider implementing an IWF must consider policy aspects of the functionality. This includes any decisions to filter or transform service capabilities across the IWF.
  实现IWF的服务提供商必须考虑该功能的策略方面。 这包括在IWF上过滤或变换服务功能的任何决定。
  • Domain/Service Provider based policies; i.e. specific services are configured to be exposed based on the destination domain.
    基于域/服务提供者的策略; 即特定服务被配置为基于目的地域被暴露。
  • Service level policies: specific services, including Service Provider proprietary or other specialised services that may be filtered from exposure to any external domains.
    服务级别策略：特定服务，包括服务提供商专有或其他专门服务，可能被过滤暴露于任何外部域。
  • User based policy; including privacy or other subscriber level policies.
    基于用户的策略; 包括隐私或其他订户级别策略。

2.6.1.4 Capability discovery and social presence information coexistence / 能力发现和社交呈现信息共存

In the following two cases:
在以下两种情况下：

• The mechanism for capability discovery is performed via SIP OPTIONS and the Service Provider has decided to deploy a Presence Server to provide the SPI service[6].
  用于能力发现的机制通过SIP选项来执行，并且服务提供商决定部署存在服务器以提供SPI服务[6]。
• The discovery mechanism is based on presence
  发现机制基于存在

[6] It may be possible for a Service Provider to always perform service discovery via SIP OPTIONS, but have a policy allowing for remote domain (NNI) support for discovery via presence as discussed in 2.6.1.3.3. This would allow a remote Service Provider that does not support fallback to SIP OPTIONS to obtain capability information using anonymous SUBSCRIBE without traversing a network IWF.
[6] 服务提供商可能总是通过SIP OPTIONS执行服务发现，但是具有允许对于通过存在的发现的远程域（NNI）支持的策略，如2.6.1.3.3中所讨论的。 这将允许不支持回退到SIP OPTIONS的远程服务提供者使用匿名SUBSCRIBE获取能力信息，而无需穿过网络IWF。

Then for those contacts who have a social presence relationship established with the sender, it is not necessary to perform a capability exchange because their capabilities will be updated automatically using the standard SPI mechanisms described in section 3.7.4.
然后，对于与发送者建立了社交呈现关系的那些联系人，没有必要执行能力交换，因为他们的能力将使用第3.7.4节中描述的标准SPI机制自动更新。

2.6.1.5 Capability exchange optimisations / 能力交换优化

To avoid the overhead and increase the efficiency, the client may implement optimisation mechanisms as listed in section 2.6.4.
为了避免开销并提高效率，客户端可以实现2.6.4节中列出的优化机制。

2.6.2 User discovery mechanism / 用户发现机制

With the main aim of optimising, the UX and minimising the unnecessary traffic generated by an RCS client, a set of lists shall be generated and maintained by the UE or client:
为了优化，使用和最小化由RCS客户端生成的不必要的业务的主要目的，应由UE或客户端生成和维持一组列表：

• A list of the RCS enabled users as the list of users which support at least one RCS service and obviously the capability discovery framework. It should be noted that, the first view of the address book shall use this list to clearly identify the RCS capable contacts with a visual RCS flag.
  支持RCS的用户的列表作为支持至少一个RCS服务并且显然支持能力发现框架的用户列表。 应当注意，地址簿的第一视图将使用该列表来清楚地识别具有可视RCS标志的具有RCS能力的联系人。
• One individual list per RCS service of RCS contacts which are enabled to perform that particular service.
  RCS联系人的每个RCS服务的一个单独列表，其被启用以执行该特定服务。

These lists should include both registered and non-registered contacts; in contrast, it does not include non-provisioned contacts.
这些列表应包括已注册和未注册的联系人; 相反，它不包括未配置的联系人。

To keep these lists up-to-date, the UE or client shall use one of the capability discovery mechanisms presented in section 2.6.1 in the following scenarios:
为了保持这些列表是最新的，UE或客户端将在以下场景中使用第2.6.1节中所述的能力发现机制之一：

• When a new contact is added to the phonebook. The new contact may come from different sources and, therefore, the mechanism described in the following sections applies to all the scenarios presented below:
  当新联系人添加到电话簿时。 新联系人可能来自不同来源，因此，以下各节中描述的机制适用于下面列出的所有情况：
  • Contact added manually by the user.
    联系人由用户手动添加。
  • Synchronised via 3rd party servers or PC.
    通过PC的第三方服务器同步。
  • Received via Bluetooth or handling a vCard file received, for example via e-mail.
    通过蓝牙接收或处理接收到的vCard文件，例如通过电子邮件。
  • The first time the user accesses the service from a new device, the whole address book needs to be polled if not disabled through the DISABLE INITIAL ADDRESS BOOK SCAN client configuration parameter (Annex A section A.1.10 for reference).
    第一次用户从新设备访问服务时，如果未通过DISABLE INITIAL ADDRESS BOOK SCAN客户端配置参数（附件A第A.1.10节作为参考）禁用，则需要轮询整个地址簿。
  • Periodically (frequency determined by the POLLING PERIOD parameter described in Annex A section A.1.10) to all the contacts in the phone address book whose capabilities are not available (e.g. non-RCS users) or are expired (see CAPABILITY INFO EXPIRY parameter in Annex A section A.1.10 for reference).
    定期（频率由在附录A的A.1.10节描述的POLLING PERIOD参数确定）检查电话地址簿中的所有能力不可用的（如非RCS用户）或过期（参见附录A的A.1.10节中的CAPABILITY INFO EXPIRY参数）的联系人。
  • When a contact’s details are edited thereby modifying the information which is used to identify the contact as RCS (as described further in section 2.6.2 e.g. the MSISDN is modified or a new MSISDN is added).
    当联系人的细节被编辑，从而修改用于将联系人标识为RCS的信息（如在2.6.2节中进一步描述的，例如MSISDN被修改或添加了新的MSISDN）。

Additionally, it should be noted that if a client is NOT registered at the time the new contact(s) are added, the client should keep the necessary information on the device. In this case the capabilities shall be verified the next time the RCS client completes the registration process.
另外，应当注意，如果在添加新联系人时没有注册客户端，则客户端应当在设备上保留必要的信息。 在这种情况下，在下一次RCS客户端完成注册过程时将验证能力。

2.6.2.1 Discovery via OPTIONS message / 通过OPTIONS消息发现

The SIP OPTIONS message can be employed not only to determine the capabilities but also to identify whether or not a contact is an RCS user; independently from whether the contact is registered at the time the query is performed.
SIP OPTIONS消息不仅可以用于确定能力，而且可以用于识别联系人是否是RCS用户; 而与在执行查询时联系人是否被注册无关。

When a SIP OPTIONS message is sent from User A to User B, User A will learn about user B’s capabilities through one of 6 scenarios:
当SIP OPTIONS消息从用户A发送到用户B时，用户A将通过以下6种情况之一了解用户B的能力：

1. If User B is registered and User A is not in the capability blacklist of User B, then the response from User B’s client will include the CAPABILITY STATUS – the set of services currently available (based on tags as described in section 2.6.1.1.2), else if User B is registered and User A is in its blacklist, it will only answer User A with an empty 200 OK. Please note that regarding the list of RCS users, the contact shall be only considered as an RCS user, if the response (SIP 200 OK) includes any of the tags described in Table 21.
   如果用户B被注册并且用户A不在用户B的能力黑名单中，则来自用户B的客户端的响应将包括能力状态 - 当前可用的服务集合（基于如在第2.6.1.1.2节中描述的标签 ），否则如果用户B被注册并且用户A在其黑名单中，则它将仅以空的200 OK来应答用户A. 请注意，关于RCS用户列表，如果响应（SIP 200 OK）包括表21中描述的任何标记，则该联系人仅被视为RCS用户。
2. If User B is currently not registered (e.g. the device is switched off, out of coverage or roaming with data services disabled), then the network will respond with one of the following error messages: SIP 480 TEMPORARILY UNAVAILABLE (graceful deregistration took place) or SIP 408 REQUEST TIMEOUT. From the new user discovery point of view, this response is ignored because it is inconclusive:
   如果用户B当前未注册（例如，设备已关闭，在禁用数据服务的情况下不在覆盖范围或漫游），则网络将使用以下错误消息之一进行响应：SIP 480 TEMPORARILY UNAVAILABLE（正常注销发生）或 SIP 408请求超时。 从新用户发现的角度来看，此响应被忽略，因为它是不确定的：
   • It does not confirm whether the contact is an RCS user, and,
     它不确认联系人是否是RCS用户，并且，
   • It does not provide any relevant update to the list of RCS contacts capable of a particular service
     它不向能够提供特定服务的RCS联系人列表提供任何相关更新
3. If User B is not provisioned for RCS the network will respond with a message error: SIP 404 NOT FOUND[7]. Therefore, if this message is received, the user is identified as a non-RCS user (removed from the list of RCS users and from the individual list of RCS users capable of a particular service)
   如果没有为RCS配置用户B，网络将回复一个消息错误：SIP 404 NOT FOUND[7]。 因此，如果接收到该消息，则将用户标识为非RCS用户（从RCS用户列表和从能够进行特定服务的RCS用户的单独列表中移除）
4. If User B was previously identified as an RCS user and the response to the OPTIONS message indicates that User B is no longer supporting any RCS services, User B should be identified as a non-RCS user and, consequently, removed from the list of RCS enabled contacts
   如果先前将用户B识别为RCS用户，并且对OPTIONS消息的响应指示用户B不再支持任何RCS服务，则用户B应被识别为非RCS用户，并且因此从RCS启用的联系人列表中移除
5. In addition to this and based on the fact the SIP OPTIONS request contain the list of services supported by the requester, the receiver shall use the SIP OPTIONS message to update both the RCS contact list and the relevant per service lists as per the criteria presented in the previous four scenarios.
   除此之外，并且基于SIP OPTIONS请求包含请求者所支持的服务的列表的事实，接收器将使用SIP OPTIONS消息，根据前四个情景中呈现的标准，来更新RCS联系人列表和相关的每个服务列表。
6. Please note there is a possibility an RCS user who is not within the address book contacts may send OPTIONS messages or responses (e.g. when receiving a call or making a call using a MSISDN not included in the contacts). In this case the capabilities shall be stored temporarily (at least 20 seconds from when OPTIONS is received) in the terminal to:
   请注意，存在这样一种可能性，即不在通讯录联系人中的RCS用户也可能发送OPTIONS消息或响应（例如，当接收呼叫或使用不包括在联系人中的MSISDN进行呼叫时）。在这种情况下，能力应临时存储（从收到OPTIONS起至少20秒）在终端中，以：
   • Keep the service availability updated while a session (Chat, File Transfer, Video/Image Share, IP Voice or Video call, Geolocation PUSH) is still in place, and,
     当会话（聊天，文件传输，视频/图像共享，IP语音或视频呼叫，地理位置PUSH）仍然存在时，保持服务可用性更新，以及，
   • To add the information to the new contact (both the fact that it is an RCS user and the cached capabilities) if the user decides to add a new address book entry following a communication.
     如果用户决定在通信后添加新的地址簿条目，则将信息添加到新联系人（包括它是RCS用户和缓存功能的实际情况）。

To illustrate the behaviour, the following example is provided. User A is registered and decides to add or modify a new contact which results in a new IMS identity for the contact (e.g. new MSISDN which implies a new tel URI). As a consequence, the client is required to verify whether the contact is an RCS user and therefore, add them to the list the terminal maintains.
为了说明行为，提供以下示例。 用户A注册并决定添加或修改导致用于联系人的新IMS标识的新联系人（例如，意味着新的tel URI的新MSISDN）。 因此，需要客户端验证联系人是否是RCS用户，并且因此将它们添加到终端维护的列表中。

Figure 12: Adding/Editing a contact / 图12：添加/编辑联系人

[7] Please note that the response provided may depend on the network configuration. A useful approach for the terminal is to parse the response and if it is not either a 200 OK containing the capabilities as feature tags, a 480 TEMPORARILY UNAVAILABLE or a 408 REQUEST TIMEOUT, the target user should be considered as non-RCS. For simplicity, the present document assumes in The following sections that the response provided by the Service Provider core network is always 404 NOT FOUND, however, the previous statement should be taken into account.
[7] 请注意，提供的响应可能取决于网络配置。 终端的有用方法是解析响应，并且如果它不是包含作为特征标签的能力的200 OK，480 TEMPORARILY UNAVAILABLE或408请求超时，则目标用户应该被认为是非RCS。 为了简单起见，本文档假设在以下部分中，服务提供商核心网络提供的响应始终为404 NOT FOUND，但是，应该考虑上一条语句。

2.6.2.2 Discovery via PRESENCE / 通过PRESENCE发现

The procedure for user discovery using presence is analogous to the capability discovery procedure using presence as described in section 2.6.1.2. However the following additional considerations shall be taken into account:
使用存在的用户发现的过程类似于使用存在的能力发现过程，如第2.6.1.2节所述。 但是，应考虑以下额外的情况：

• When User A queries User B’s capabilities, the response will include the CAPABILITY STATUS – the set of services currently available (based on the service-IDs presented in section 2.6.1.3.1). Please note that regarding the list of RCS users, the contact shall be considered as an RCS user, only if the response includes one of the service-IDs described in Table 21.
  当用户A查询用户B的能力时，响应将包括能力状态 - 当前可用的服务集（基于第2.6.1.3.1节中提供的服务ID）。 请注意，关于RCS用户列表，只有当响应包括表21中描述的服务ID之一时，联系人才被视为RCS用户。

2.6.2.3 Coexistence between user discovery mechanisms / 用户发现机制之间的共存

Please note that the mechanisms described in sections 2.6.1.3 also apply to the user discovery mechanisms co-existence.
请注意，第2.6.1.3节中描述的机制也适用于用户发现机制共存。

2.6.2.4 User discovery and social presence information coexistence / 用户发现和社交呈现信息共存

Please note that the considerations presented in section 2.6.1.4 also apply to the user discovery process.
请注意，第2.6.1.4节中介绍的注意事项也适用于用户发现过程。

2.6.2.5 Capability polling mechanism / 能力轮询机制

To enhance the discovery of new users and, ultimately, keep the list of RCS contacts up to date, this specification provides a mechanism, capability polling, consisting of the polling of the status/capabilities of all the contacts in the address book whose capabilities are not available (such as non-RCS users) or have expired (see CAPABILITY INFO EXPIRY parameter in Annex A section A.1.10 for further reference).
为了增强对新用户的发现并且最终保持RCS联系人的列表是最新的，本规范提供了一种机制，能力轮询，包括对地址簿中的能力不可用（例如非RCS用户）或已过期（参见附件A A.1.10节中的CAPABILITY INFO EXPIRY参数，以供进一步参考）的所有联系人的状态/能力的轮询。

It should be noted that the capability polling mechanism is optional and will be only performed if the related configuration settings have been provisioned (that is if the POLLING PERIOD parameter presented in Annex A section A.1.10 is set to 0, this polling mechanism will not be used).
应该注意的是，能力轮询机制是可选的，并且只有在已经配置相关配置设置时才被执行（即如果附件A部分A.1.10中呈现的POLLING PERIOD参数被设置为0，则该轮询机制将不会使用）。

Assuming the POLLING PERIOD is configured to be greater than 0 and after the polling timer expires, the client will use the following mechanism to update the list of RCS contacts and update their capabilities.
假设将POLLING PERIOD配置为大于0，并且在轮询定时器到期之后，客户端将使用以下机制更新RCS联系人列表并更新其能力。

Please note the capability polling is only performed on:
请注意，能力轮询仅在以下情况下执行：

• Those contacts without capability information (non-RCS users and RCS users with unknown capabilities), and,
  那些没有能力信息的联系人（非RCS用户和RCS用户具有未知的功能）,以及，
• The rest of RCS contacts provided the associated capability information is older than the CAPABILITY INFO EXPIRY parameter (see Annex A section A.1.10 for further reference)[8].
  其余RCS联系人提供的相关能力信息比CAPABILITY INFO EXPIRY参数早（参见附录A A.1.10节的进一步参考）[8]。

[8] Please note this is a traffic optimization to reduce the amount of SIP OPTIONS messages generated by capability polling
[8] 请注意，这是一个流量优化，以减少能力轮询生成的SIP OPTIONS消息量

Figure 13: Capabilities polling via OPTIONS message / 图13：通过OPTIONS消息轮询的能力

When CAPABILITY DISCOVERY MECHANISM is set to presence (see Annex A section A.1.10), the presence based discovery based in the use of SIP ANONYMOUS SUBSCRIBE requests are used for all the contacts except:
当CAPABILITY DISCOVERY MECHANISM设置为存在时（见附件A A.1.10节），使用SIP ANONYMOUS SUBSCRIBE请求的基于存在的发现用于所有联系人，除了：

• If implementing co-existence based on a common device stack, those contacts which are identified as not supporting presence discovery (SIP OPTIONS will be used instead as per the fallback procedure presented in section 2.6.1.3.2.1).
  如果基于通用设备栈实现共存，那些被标识为不支持存在发现的联系人（根据第2.6.1.3.2.1节中提出的回退程序，将使用SIP OPTIONS）。
• Those users with a SPI relationship in place because their capabilities will be updated automatically using the standard SPI mechanisms described in section 3.7.4.
  那些具有SPI关系的用户，因为他们的能力将使用第3.7.4节中描述的标准SPI机制自动更新。

Figure 14: Capabilities polling via anonymous fetch / 图14：通过匿名抓取轮询的能力

NOTE: If an RLS-URI was provisioned (see Annex A Section A.1.2.1) and the capabilities of multiple contacts need to be queried, the capability query could be initiated by the device using a request contained list that is decomposed by the RLS service in the originating network (see section 2.6.1.2.3 for more details). In this case the SIP SUBSCRIBE request shown in Figure 14 would be a back end subscribe issued by the user’s home RLS and should be forwarded to the correct destination Presence Server(s). The RLS will gather the notifications and send aggregated notifications to the device.
注意：如果提供了RLS-URI（见附件A第A.1.2.1节），并且需要查询多个联系人的能力，则能力查询可以由设备使用请求包含列表启动，该列表由 RLS服务（更多详细信息，请参见第2.6.1.2.3节）。 在这种情况下，图14中所示的SIP SUBSCRIBE请求将是由用户的家庭RLS发出的后端订阅，并且应当被转发到正确的目的地存在服务器。 RLS将收集通知并向设备发送聚合通知。

Finally, and as a summary of the capability and new user discovery mechanism composition the following diagram is provided.
最后，作为能力和新用户发现机制组合的总结，提供以下图表。

Figure 15: RCS capability and new user discovery mechanisms / 图15：RCS能力和新用户发现机制

The red boxes represent mandatory procedures. Meanwhile, the clear boxes represent optional procedures.
红色框表示强制性程序。 同时，清除框表示可选过程。

2.6.3 Capability update for services / 服务的能力更新

A capability update shall only be triggered for contacts belonging to
只有属于以下情况的联系人才能触发能力更新

• the list of the RCS enabled users as defined in section 2.6.2, or
  第2.6.2节中定义的启用RCS的用户的列表，或
• the non RCS contacts whose last capability check is older than the NON RCS CAPABILITY INFO EXPIRY configuration parameter value defined in section A.1.10.
  最后一次性能检查的非RCS联系人比第A.1.10节中定义的NON RCS CAPABILITY INFO EXPIRY配置参数值旧。

2.6.3.1 Entry points for capability update / 功能更新的入口点

A capability update is triggered by one of the following activities:
功能更新由以下活动之一触发：

• If not disabled[9], after first time registration to obtain the registration state and default set of capabilities for each contact in the device’s address book (note one capability exchange takes place per IMS identity [that is tel URI/MSISDN or SIP URI] stored in the address book)[10],
  如果未禁用[9]，则在第一次注册之后，获得设备的地址簿中每个联系人的注册状态和默认能力集合（注意，每个IMS身份[即tel URI / MSISDN或SIP URI]存储在地址簿）[10]，
• When checking the available RCS services/capabilities to communicate with another user (e.g. from the address book and call-log)
  当检查可用的RCS服务/能力以与另一用户通信（例如，从地址簿和呼叫日志）时，
• After establishing voice call to obtain the real-time capabilities for the call or Chat session provided this has not been performed before (see previous bullet) or content sharing during a call is supported.
  在建立语音呼叫以获得呼叫或聊天会话的实时能力之后（如果此前没有被执行（见前面的项目符号）或在呼叫期间的内容共享被支持）。
• After the call returns to an active state (e.g. returning from call wait, call on hold or multiparty call).
  在呼叫返回到活动状态（例如，从呼叫等待，呼叫保持或多方通话返回）之后。
• When a communication is active with a user to provide an update when the relevant available capabilities change:
  在下列可用能力改变时，激活与用户的通信以提供更新：
  • When a 1-2-1 Chat session is established and any of the following capabilities change:
    当1-2-1聊天会话建立并且以下任何功能更改时：
    • File Transfer via MSRP / 通过MSRP的文件传输
    • File Transfer via HTTP / 通过HTTP的文件传输
    • Geolocation PUSH / 地理位置PUSH
  • When in an active call with an RCS user and any of the following capabilities change:
    在与RCS用户进行的活动呼叫中，并且以下任何功能发生更改时：
    • Chat / 聊天
    • File Transfer via MSRP / 通过MSRP的文件传输
    • File Transfer via HTTP / 通过HTTP的文件传输
    • Geolocation PUSH / 地理位置PUSH
    • Geolocation PULL / 地理位置PULL
    • Video Share / 视频共享
    • Image Share / 图片共享
    • IP Video Call / IP视频呼叫
    • Shared Sketch / 共享素描
    • Shared Map / 共享地图
  • When an IP call or video call session is in place and any of the following capabilities change:
    当IP呼叫或视频呼叫会话就位，并且以下任何功能更改时：
    • Chat / 聊天
    • File Transfer via MSRP / 通过MSRP的文件传输
    • File Transfer via HTTP / 通过HTTP的文件传输
    • Geolocation PUSH / 地理位置PUSH
    • Geolocation PULL / 地理位置PULL
    • Video Share / 视频共享
    • Image Share / 图片共享
    • IP Video Call / IP视频呼叫
    • Shared Sketch / 共享素描
    • Shared Map / 共享地图
• When there is a communications event (text, email, call or Chat) with another user in the address book, taking into account the optimisations presented in section 2.6.1.5.
  当与地址簿中的另一个用户存在通信事件（文本，电子邮件，呼叫或聊天）时，需考虑到第2.6.1.5节中介绍的优化。
• When performing one of the actions described in section 2.2 of [PRD-RCC.20].
  当执行[PRD-RCC.20]第2.2节中描述的操作之一时。

[9] Through the DISABLE INITIAL ADDRESS BOOK SCAN client configuration parameter
[9] 通过DISABLE INITIAL ADDRESS BOOK SCAN客户端配置参数

[10] Please note a contact may have several MSISDNs or associated SIP URIs. The client will use ALL the MSISDNs/SIP URIs stored for that user to perform the capability exchange. If it is discovered that more than one of the associated tel URIs/SIP URIs are IMS provisioned, each will be treated as a separate RCS user. For example, if displaying the list of RCS contacts, two or more entries for a user will be shown (“John Smith mobile” and “John Smith home”), so the user can choose.
[10] 请注意，联系人可能具有多个MSISDN或关联的SIP URI。 客户端将使用为该用户存储的所有MSISDN / SIP URI来执行能力交换。 如果发现多于一个相关联的tel URI / SIP URI是IMS供应的，则每个将被视为单独的RCS用户。 例如，如果显示RCS联系人的列表，则将显示用于用户的两个或更多个条目（“John Smith mobile”和“John Smith home”），因此用户可以选择。

Actions related to services described above apply only when the corresponding service is authorised by configuration.
与上述服务相关的操作仅在相应服务由配置授权时适用。

2.6.3.1.1 UX guidelines: Access to RCS services through address book and call-log interaction / UX准则：通过地址簿和呼叫日志交互来访问RCS服务

The address book (and by extension the call-log window as an alternative for users who have been recently phoned) is the centrepiece to access all RCS services. From it, the user is able to:
地址簿（以及扩展的呼叫日志窗口作为最近打电话的用户的替代）是访问所有RCS服务的核心。 从中，用户能够：

• Identify which services are available for each contact: When a contact is selected, the capabilities are updated using one of the mechanisms described in section 2.6 (SIP OPTIONS query or PRESENCE), and the result is presented to the user by showing the RCS services which are available to communicate with that particular contact
  识别每个联系人可用的服务：当选中联系人时，使用第2.6节（SIP选项查询或PRESENCE）中描述的机制之一更新联系人能力，并通过显示可用于与该特定联系人通信的RCS服务，将结果显示给用户
  • Please note for those contacts who have a social presence relationship established with the sender, it is not necessary to perform a capability exchange because their capabilities will be updated automatically using the standard SPI mechanisms described in section 3.7.4. Therefore and for those contacts, the capability exchange is not required.
    请注意，对于与发件人建立了社交在线关系的联系人，没有必要执行能力交换，因为他们的能力将使用3.7.4节中描述的标准SPI机制自动更新。 因此，对于那些联系人，不需要能力交换。
• If one or more RCS services are available[11], they can be started from the address book/call log entry. Please note the only exception is for those content sharing services that can be only accessed when during a call. If a contact has more than one RCS capable telephone number assigned a device should either display for each of these individual numbers which services are available or for each RCS Service the individual telephone numbers on which it is available.
  如果一个或多个RCS服务可用[11]，则可以从地址簿/呼叫日志条目启动它们。 请注意，唯一的例外是那些内容共享服务只能在通话期间访问。 如果联系人具有多于一个分配了RCS的电话号码，则设备应该为每个可用服务的每个个人号码显示，或者为每个RCS服务显示其可用的各个电话号码。

In addition to this, the first view of the address book may clearly identify the RCS capable contacts with an icon or flag.
除此之外，地址簿的第一视图可以清楚地标识具有图标或标志的RCS能力联系人。

[11] It should be noted that in this case if IM CAP ALWAYS ON (see Table 75) is enabled, the Chat should still be reported to the user as available even if the other end/user is not registered. It may also be offered if the client is not registered itself. In that case the composed messages should be queued to be sent when the device comes online again. The messages should be sent as described in section 2.7.1.1.
[11] 应当注意，在这种情况下，如果启用IM CAP ALWAYS ON（参见表75），则即使未注册另一端/用户，仍然应该向用户报告聊天。 如果客户端没有注册它自己也可以提供。 在这种情况下，编写的消息应排队等待，当设备再次联机时发送。 消息应按照第2.7.1.1节中的描述发送。

2.6.3.1.1.1 General assumptions / 一般假设

The following sections describe the relevant chat message flows and reference UX. Please note that the following assumption has been made:
以下部分描述相关的聊天消息流和参考UX。 请注意，已做出以下假设：

• For simplicity, the internal mobile network interactions are omitted in the diagrams shown in the following sections.
  为了简单起见，在以下部分中所示的图中省略了内部移动网络交互。

2.6.3.1.1.2 Capability update process / 能力更新过程

The capabilities update process is described in the following diagram. In this case the contact (User B) is an RCS contact which is registered.
功能更新过程如下图所示。 在这种情况下，联系人（用户B）是已注册的RCS联系人。

Figure 16 : Address book and call-log service access: Capabilities update / 图16：地址簿和呼叫日志服务访问：功能更新

NOTE: If User B is either not an RCS user or they are not currently registered, User A’s client may assume that no services are available to communicate with User B.
注意：如果用户B不是RCS用户或者他们当前未注册，则用户A的客户端可以假设没有可用于与用户B通信的服务。

As a general recommendation, when capability discovery is enabled, all the supported RCS services should be displayed providing the user the availability status (e.g. greying out services which are not available).
一般推荐，当启用能力发现时，应当显示所有支持的RCS服务，向用户提供可用性状态（例如，不可用的变灰服务）。

2.6.3.2 Standalone messaging: Text and multimedia messaging

The capability exchange is not required for this service when network interworking to a fall- back technology is available.
当与回退技术的网络互通可用时，该服务不需要能力交换。

2.6.3.3 1-to-1 Chat / 1对1聊天

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

The capability exchange shall take place (when the service capability query is supported by SIP OPTIONS, PRESENCE or when the contact is not a VIP Contact for SPI):
（当以下三种情况支持服务能力查询时，即SIP OPTIONS，PRESENCE或联系人不是SPI的VIP联系人）能力交换应发生：

• Before the initial SIP INVITE is sent to initiate the service to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在发送初始SIP INVITE以发起服务以验证接收器是否准备好服务之前（除非刚刚根据第2.6.3.1节中所述的标准之一进行能力交换，如第2.6.4节所述）
• If an error takes place:
  如果发生错误：
  • After the Chat session is abruptly terminated or irregular signalling behaviour during the establishment of the service is detected.
    在聊天会话突然终止或检测到在服务建立期间的不规则信令行为之后。
  • When there is an update on the available capabilities on either end once the session is established.
    一旦建立会话，当任一端有可用能力的更新时。
• In any of the scenarios described in section 2.6.3.1 which are relevant to the service.
  在第2.6.3.1节中描述的与服务相关的任何场景中。

2.6.3.4 Group Chat / 群聊

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

The capability exchange shall take place (when the service capability query is supported by SIP OPTIONS, PRESENCE or when the contact is not a VIP Contact for SPI):
（当以下三种情况支持服务能力查询时，即SIP OPTIONS，PRESENCE或联系人不是SPI的VIP联系人）能力交换应发生：

• Before the initial SIP INVITE is sent to initiate the service to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在发送初始SIP INVITE以发起服务以验证接收器是否准备好服务之前（除非刚刚根据第2.6.3.1节中所述的标准之一进行能力交换，如第2.6.4节所述）
• If an error takes place:
  如果发生错误：
  • After the Chat session is abruptly terminated or irregular signalling behaviour during the establishment of the service is detected.
    在聊天会话突然终止或检测到在服务建立期间的不规则信令行为之后。
  • When selecting the participants of a Group Chat to verify whether they are available.
    选择群聊的参与者以验证它们是否可用时。

2.6.3.5 File Transfer / 文件传输

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

The capability exchange shall take place (when the service capability query is supported by SIP OPTIONS, PRESENCE or when the contact is not a VIP Contact for SPI):
（当以下三种情况支持服务能力查询时，即SIP OPTIONS，PRESENCE或联系人不是SPI的VIP联系人）能力交换应发生：

• Before the initial SIP INVITE is sent to initiate the service to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在发送初始SIP INVITE以发起服务以验证接收器是否准备好服务之前（除非刚刚根据第2.6.3.1节中所述的标准之一进行能力交换，如第2.6.4节所述）
• If an error takes place:
  如果发生错误：
  • After the service is cancelled either by the sender or receiver.
    发送方或接收方取消服务后。
  • After the file transfer is abnormally interrupted as a result of a failure or irregular signalling behaviour during the establishment of the service is detected.
    在检测到作为在服务建立期间的故障或不规则信令行为的结果的文件传输异常中断之后。

2.6.3.6 Content sharing / 内容共享

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

When enabled, the capability exchange shall take place:
启用时，将进行能力交换：

• Before the initial SIP INVITE is sent to initiate the service to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在发送初始SIP INVITE以发起服务以验证接收器是否准备好服务之前（除非刚刚根据第2.6.3.1节中所述的标准之一进行能力交换，如第2.6.4节所述）
• If an error takes place:
  如果发生错误：
  • After the service is cancelled either by the sender or receiver.
    发送方或接收方取消服务后。
  • After the sharing is abnormally interrupted as a result of a failure or irregular signalling behaviour during the establishment of the service is detected.
    在检测到由于在服务建立期间的故障或不规则信令行为而异常中断共享之后。
  • After the call is no longer active.
    在呼叫不再活动后。
• In any of the scenarios described in section 2.6.3.1 which are relevant to the service.
  在第2.6.3.1节中描述的与服务相关的任何场景中。

Additionally to the previous capabilities query entry point, a client provider may implement additional ones to enhance the user experience. For example, it may be considered to issue a capability exchange when the relevant sensors in a device indicate that the user is likely to interact with the phone keyboard or screen during a call.
除了先前的能力查询入口点，客户端提供商可以实现额外的功能以增强用户体验。 例如，可以考虑当设备中的相关传感器指示用户在呼叫期间可能与电话键盘或屏幕交互时发出能力交换。

2.6.3.7 Social presence / 社交呈现

Information indicating support for social information via presence is expected prior to a user’s attempt to establish a social presence relationship. This supports the “Who Can I Invite” concept; providing the user with a view of the contacts with whom they can attempt to establish a social presence relationship. This information is provided in the following contexts:
在用户尝试建立社交呈现关系之前，期望通过存在来指示对社交信息的支持的信息。 这支持“我可以邀请谁”的概念; 向用户提供与他们可以尝试建立社交存在关系的联系人的视图。 此信息在以下上下文中提供：

• Discovery via SIP OPTIONS.
  通过SIP OPTIONS发现。
• Discovery via Presence
  通过存在发现

Independently of the chosen mechanism,
独立于所选择的机制，

• If capability discovery indicates that both clients support the “social information via presence” functionality, the user is then presented with the possibility of inviting the contact to share the social presence information. This includes invitation of a previously discovered SPI-enabled contact who is temporarily Not Available. If not, the terminal should not present this possibility to the user for that contact.
  如果能力发现指示两个客户端都支持“通过呈现的社交信息”功能，则向用户呈现邀请联系人共享社交呈现信息的可能性。 其中包括以前发现的启用SPI的联系人的邀请，该联系人暂时不可用。 如果不是，则终端不应向用户呈现该联系人的这种可能性。
• For those contacts who have an active social presence relationship established with the sender, it shall not perform a capability exchange if their capabilities are updated automatically using the standard SPI mechanisms described in section 3.7.4.
  对于与发件人建立了积极的社会关系关系的联系人，如果他们的能力使用第3.7.4节中描述的标准SPI机制自动更新，则不应进行能力交换。

2.6.3.7.1 Discovery via SIP OPTIONS / 通过SIP OPTIONS发现

To ensure interoperability[12] and enable those Service Providers implementing an SIP OPTIONS based capability/user discovery mechanism for their RCS deployments but deploying a Presence Server to additionally provide the social profile information (as described in section 3.7.4.2.2) functionality, the UE shall provide the following procedure:
为了确保互操作性[12]，并使那些服务提供商们能够为其RCS部署实现基于SIP OPTIONS的能力/用户发现机制，而不是部署一个存在服务器以额外提供社交简档信息（如第3.7.4.2.2节所述）功能，UE应提供以下程序：

• Prior to being able to send an invitation to a contact (e.g. from the address book), the terminal will use the OPTIONS mechanism to determine if the other end also supports this feature (that is both ends include the “Social Presence Information” SIP OPTIONS tag in the relevant headers).
  在能够向联系人（例如，从地址簿）发送邀请之前，终端将使用OPTIONS机制来确定另一端是否也支持该特征（即，两端都包括“Social Presence Information”SIP OPTIONS标记）。

[12] Please note that the present specification allows the deployment of RCS communication services without the need for a Presence Server and the associated XDM servers, therefore, the present specification provide the necessary guidance to secure interoperability.
[12] 请注意，本说明书允许部署RCS通信服务，而不需要存在服务器和相关联的XDM服务器，因此，本说明书提供了用于确保互操作性的必要指导。

2.6.3.7.2 Discovery via presence / 通过存在发现

Prior to being able to send an invitation to share Social Presence with a contact (e.g. from the address book), the terminal may use the Anonymous Fetch mechanism to determine if the other end also supports this feature (that is both ends include an “open” “Social Presence Information” Presence Service Tuple in the Presence Information Data Format [PIDF]). This includes inviting a contact who has previously been discovered to be Social presence-enabled even when they are currently offline.
在能够发送邀请以与联系人（例如，从地址簿）共享社交呈现之前，终端可以使用匿名获取机制来确定另一端是否也支持该特征（即，两端都包括“开放 “”存在信息数据格式[PIDF]中的“社会存在信息”存在服务元组）。 这包括邀请之前已被发现的联系人启用了社交在线功能，即使他们目前处于离线状态也是如此。

2.6.3.8 IP Voice Call / IP语音呼叫

2.6.3.8.1 IP Voice Call per MMTEL / 每MMTEL的IP语音呼叫

The capability exchange is not required for this service. This capability may be used for network internal use and shall not have an impact on the user experience.
此服务不需要能力交换。 此功能可用于网络内部使用，并且不会对用户体验产生影响。

2.6.3.8.2 RCS IP Voice Call / RCS IP语音呼叫

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

When enabled, the capability exchange shall take place: 启用时，将进行能力交换：

• Before the RCS IP Voice Call is initiated by the sender to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4) 在发送方发起RCS IP语音呼叫之前，验证接收方是否已准备好服务（除非刚刚根据第2.6.3节中所述的标准之一进行能力交换，如第2.6.4节所述）。
• If an error takes place, after the call when the service was abnormally interrupted or irregular signalling behaviour during the establishment of the call is detected. 如果错误发生时，在呼叫之后，当服务异常中断或检测到在建立呼叫期间的不规则信令行为。
• In any of the scenarios described in section 2.6.3.1 which are relevant to the service. 在第2.6.3.1节中描述的与服务相关的任何场景中。

2.6.3.9 IP Video Call / IP视频呼叫

2.6.3.9.1 IP Video Call per MMTEL / 每MMTEL的IP视频呼叫

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

When enabled, the capability exchange shall take place:
启用时，将进行能力交换：

• Before the IP Video Call per MMTEL is initiated by the sender to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在每个MMTEL的IP视频呼叫由发送方发起以验证接收机是否准备好服务之前（除非刚刚根据第2.6.3.1节中所列的标准之一进行能力交换，如第2.6.4节所述。
• If an error takes place, after the call when the service was abnormally interrupted or irregular signalling behaviour during the establishment of the call is detected.
  如果错误发生时，在呼叫之后，当服务异常中断或检测到在建立呼叫期间的不规则信令行为时
• In any of the scenarios described in section 2.6.3.1 which are relevant to the service.
  在第2.6.3.1节中描述的与服务相关的任何场景中。

2.6.3.9.2 RCS IP Video Call / RCS IP视频呼叫

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

When enabled, the capability exchange shall take place:
启用时，将进行能力交换：

• Before the RCS IP Video Call is initiated by the sender to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在发送方发起RCS IP视频呼叫之前，验证接收方是否已准备好服务（除非刚刚根据第2.6.3节中所述的标准之一进行能力交换，如第2.6.4节所述）。
• If an error takes place, after the call when the service was abnormally interrupted or irregular signalling behaviour during the establishment of the call is detected.
  如果错误发生时，在呼叫之后，当服务异常中断或检测到在建立呼叫期间的不规则信令行为时。
• In any of the scenarios described in section 2.6.3.1 which are relevant to the service.
  在第2.6.3.1节中描述的与服务相关的任何场景中。

2.6.3.10 Geolocation PUSH / 地理位置PUSH

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

When enabled, the capability exchange shall take place:
启用时，将进行能力交换：

• Before the initial SIP INVITE is sent to initiate the service to verify if the receiver is ready for the service (unless an exchange of capabilities has just been made based on one of the criteria listed in section 2.6.3.1, as described in section 2.6.4)
  在发送初始SIP INVITE以发起服务以验证接收器是否准备好服务之前（除非刚刚根据第2.6.3.1节中所述的标准之一进行能力交换，如第2.6.4节所述）
• If an error takes place:
  如果发生错误：
  • After the service is cancelled either by the sender or receiver.
    发送方或接收方取消服务后。
  • If an error takes place and as a result the Geolocation PUSH is abnormally interrupted or irregular signalling behaviour during the establishment of the service is detected.
    如果发生错误，并且因此地理定位PUSH被异常中断或检测到在服务建立期间的不规则信令行为。

2.6.3.11 Geolocation PULL / 地理位置PULL

In addition to the general user driven entry points and taking into account:
除了一般的用户驱动的入口点，还应考虑到：

• The optimisations provided in section 2.6.1.5, and,
  第2.6.1.5节中提供的优化，以及，
• The potential impact of having an SPI relationship between sender and receiver as described in section 2.6.2.4.
  如第2.6.2.4节所述的，在发送方和接收方之间具有SPI关系的潜在影响。

When enabled, the capability exchange shall take place:
启用时，将进行能力交换：

• If an error takes place:
  如果发生错误：
  • After the service is cancelled either by the sender or receiver.
    发送方或接收方取消服务后。
  • If an error takes place and as a result the Geolocation PULL is abnormally interrupted or irregular signalling behaviour during the establishment of the service is detected.
    如果发生错误，并且因此地理位置PULL异常中断或检测到在服务建立期间的不规则信令行为。

2.6.4 Capability exchange optimisations / 能力交换优化

Depending on the circumstances and use cases, there could be occasions where the capability exchange may happen relatively often (in case of very frequent bearer changes for instance).
根据情况和使用情况，可能存在能力交换可能相对频繁地发生（例如在非常频繁的载体改变的情况下）的情况。

To avoid the overhead and increase the efficiency, the client may implement a mechanism to reduce the number of requests in situations where the capability exchange is likely to be performed too often. Examples of how this mechanism can be achieved are listed below:
为了避免开销并提高效率，客户端可以实现在可能频繁执行能力交换的情况下减少请求数量的机制。 如何实现该机制的实例如下所列：

• Introduce a degree of hysteresis (that is a capabilities update is sent/requested only when the circumstances which led to the change remain stable for a certain period of time).
  引入一定程度的滞后（即仅当导致改变的情况在一定时间段内保持稳定时才发送/请求能力更新）。
• Implement a validity timer (that is if the latest capabilities we have were fetched less than X seconds ago, they are still considered as valid).
  实现有效性定时器（即如果我们在最近的X秒前获取了最新的功能，它们仍然被认为是有效的）。

Please note that this specification does not describe detailed implementations to leave room for OEMs and third parties to drive innovative and differentiated solutions. This helps to distinguish their products from competitors.
请注意，本规范没有描述具体实施，为OEM和第三方提供创新和差异化解决方案的空间。 这有助于区分他们的产品和竞争对手。

2.6.4.1 Service Provider Controlled Service Capabilities Handling / 服务提供商受控服务能力处理

The following items can be configured subject to the Service Provider’s policies (see section A.1.10):
可以根据服务提供商的策略配置以下项目（请参阅第A.1.10节）：

1. The maximum amount of capability query operations during a certain time period done by a client (that is, for all contacts).
   客户端（即所有联系人）在特定时间段内执行的能力查询操作的最大数量。
2. An expiry of the capabilities for a specific contact.
   特定联系人的功能到期。
3. The Contacts considered for the capability discovery depending on their prefix (see Capability Discovery Allowed Prefixes defined in Table 82 in section A.1.10).
   根据其前缀考虑的能力发现的联系人（请参阅A.1.10中表82中定义的能力发现允许的前缀）。

This will allow to control the maximum time before a client will discover that one of the contacts is now RCS capable
这将允许控制客户端发现其中一个联系人现在具有RCS功能之前的最长时间

NOTE: There might be a conflict between the different provisioning settings controlling the frequency of capability query operations (for example, a too low maximum amount of fetch operation combined with a very low expiry time). In that case, an RCS client will prioritise the maximum amount of fetch operations settings over the expiry. A Service Provider deploying RCS is likely to carefully consider the values of these settings and this is therefore not expected to be an issue in actual deployments.
注意：在控制能力查询操作频率的不同配置设置之间可能存在冲突（例如，获取操作的最大数量过多，过期时间非常短）。 在这种情况下，RCS客户端将在到期时对取回操作设置的最大量进行优先级排序。 部署RCS的服务提供商可能会仔细考虑这些设置的值，因此预计这不会是实际部署中的问题。