2.7 Capability values and status / 能力值和状态
The RCS capabilities represent the list of services that an RCS user/client can access at a certain point in time. The capabilities depend on four factors:
RCS能力表示RCS用户/客户端在某个时间点可以访问的服务的列表。 能力取决于四个因素:
- User Service Provider provisioning status: A Service Provider may choose to limit service to customers depending on subscription status (e.g. chat and file share, but not video).
用户服务提供商配置状态:服务提供商可以根据订阅状态(例如聊天和文件共享,但不是视频)选择限制服务给客户。 - The terminal hardware (HW): A terminal with limited HW (i.e. no capability to process video) may not be able to access all the RCS Services.
终端硬件(HW):具有有限HW(即,无能力处理视频)的终端可能不能访问所有RCS服务。 - The terminal status: Even if a terminal HW supports all the services, it could be that the device status introduces a limitation (e.g. receiving files is not possible when the file storage is full).
终端状态:即使终端HW支持所有服务,也可能是设备状态引入了限制(例如,当文件存储已满时,无法接收文件)。 - Connectivity status: Some services may require a certain level of network Quality of Service (QoS). For example, streaming video over a 2G GPRS does not provide an adequate UX.
连接状态:某些服务可能需要一定级别的网络服务质量(QoS)。 例如,通过2G GPRS的流视频不提供足够的UX。
In addition to the factors presented above and as presented in Annex A section A.1, it is possible for a Service Provider to select which services are available for a particular user. Therefore, the previous considerations shall only be taken into account assuming that the relevant RCS services are enabled via configuration and consequently, Table 23 assumes that all the user’s devices have been configured with all the RCS services enabled.
除了上面提出的和附件A A.1节所述的因素之外,服务提供商可以选择哪些服务可用于特定用户。 因此,前面的考虑只应该考虑假设通过配置启用相关的RCS服务,因此,表23假定所有用户的设备已经配置了所有启用的RCS服务。
As a summary, please find the table below (note that it is assumed the client/terminal and the network supports each of the services as a precondition and that the client/terminal is provisioned to support all the services[13]):
作为总结,请找到下表(注意,假设客户端/终端和网络支持每个服务作为前提条件,并且客户端/终端被配置为支持所有服务[13]):
[13] As presented in Annex A section A.1, it is possible for a Service Provider to select which services are available for a particular user.
[13] 如附件A A.1节所述,服务提供商可以选择哪些服务可用于特定用户。
Service | TERMINAL and STATUS REQUIREMENTS | Data Bearer | |||||
---|---|---|---|---|---|---|---|
2G | EDGE | 3G | HSPA | LTE | Wi-Fi | ||
Standalone messaging | None | Y | Y | Y | Y | Y | Y |
Chat (1-to-1 or group) | None | Y | Y | Y | Y | Y | Y |
File Transfer via MSRP[14] | Minimum threshold of free space to store files | Y | Y | Y | Y | Y | Y |
File Transfer via HTTP | The relevant configuration parameters are correctly set | Y | Y | Y | Y | Y | Y |
Content share: Image Share | Minimum threshold of free space to store files. The terminal should be on an active call[15] with the user the image is willing to be shared with. Not available in multiparty calls. | Y[16] | Y[16] | Y | Y | Y | Y |
Content share: Video Share (IR.74) | Support video profile (encoding/decoding). The terminal should be on an active call15 with the user the video is willing to be shared with. It is not available in multiparty calls. | N | N | Y One Way Only[17] | Y[18] | Y[18] Higher video profile | Y[18] |
SPI | N/A | Y | Y | Y | Y | Y | Y |
IP Voice Call [PRD-IR.92]/[PRD-IR.51] | N/A | N | N | N | N | Y (IR.92) | Y (IR.51) |
IP Video Call [PRD-IR.94] | Support video profile (encoding/decoding). | N | N | N | N | Y (IR.94) | Y (IR.51/I R.94) |
RCS IP Voice Call | N/A | N | N | Y[19] | Y[19] | Y[19] | Y19 |
RCS IP Video Call | Support video profile (encoding/decoding). | N | N | Y[19] | Y[19] | Y[19] | Y[19] |
Geolocation PUSH | Minimum threshold of free space to store files From the capability exchange point of view there are no additional terminal requirements however on the sender the service shall be only available if the terminal (UE) provides a mean to access the location information required for the service. | Y | Y | Y | Y | Y | Y |
Geolocation PULL | Primary device with capability for locating | Y | Y | Y | Y | Y | Y |
Call Composer | The relevant configuration parameters are correctly set The terminal (UE) provides a mean to access the location information required for the service. The terminal (UE) provides a mean to insert subject. The terminal (UE) provides a mean to insert importance. | Y[16] | Y[16] | Y | Y | Y | Y |
Post-Call Support | audio message profile (encoding /decoding). | Y | Y | Y | Y | Y | Y |
Shared Map | The terminal should be on an active call[15] with the user the map is willing to be shared with. It is not available in multiparty calls. | Y[16] | Y[16] | Y | Y | Y | Y |
Shared Sketch | The terminal should be on an active call[15] with the user the canvas is willing to be shared with. It is not available in multiparty calls. | Y[16] | Y[16] | Y | Y | Y | Y |
[14] When the Chat Messaging Technology is set to OMA CPM using the CHAT MESSAGING TECHNOLOGY configuration parameter defined in section A.1.4.3, the client shall indicate both the File Transfer and File Transfer Store and Forward capability as described in section 2.6.1.3.1
[14] 当使用在A.1.4.3节中定义的CHAT消息技术配置参数将聊天消息技术设置为OMA CPM时,客户端将指示文件传输和文件传输存储以及转发能力,如第2.6.1.3.1节所述[15] In this context, the term active call is used to indicate that a voice call is taking place with the user the content is shared with and that this call is not on-hold, waiting or forwarded/diverted. This limitation is not applicable for broadband access devices for the handling of a received capability request or an incoming invitation. The restrictions fully apply for outgoing requests.
[15] 在本上下文中,术语活动呼叫用于指示与用户共享内容的用户正在进行语音呼叫,并且该呼叫不是保持,等待或转发/转移。 此限制不适用于用于处理所接收的能力请求或传入邀请的宽带接入设备。 这些限制完全适用于传出请求。[16] Note that it is only possible if device and the cellular network support Dual-Transfer Mode (DTM)
[16] 注意,只有设备和蜂窝网络支持双传输模式(DTM)[17] If on the current bearer sharing is supported one way only and a Video Share session is initiated by the device, a capability exchange should be performed to the other end to indicate that Video Share is no longer available. When the session is terminated or the bearer changes to one supporting bidirectional Video Share, the Video Share capability should again be announced.
[17] 如果在当前承载共享仅被单向支持并且视频共享会话由设备发起,则应该对另一端执行能力交换以指示视频共享不再可用。 当会话终止或承载改变为支持双向视频共享的承载时,视频共享能力应再次被宣布。[18] In this case both ends may share video simultaneously meaning that there is a possibility to have a bidirectional flow of video (see the other party’s video while I am also sharing video with him/her). The meaning is that if a user is already sharing video with the other end, the other user may decide to also share video simultaneously, not that the two-ways Video Share can start simultaneously.
[18] 在这种情况下,两端可以同时共享视频,意味着存在双向的视频流的可能性(参见另一方的视频,而我也与他/她共享视频)。 意思是如果用户已经与另一端共享视频,则另一用户可以决定同时共享视频,而不是双向视频共享可以同时开始。[19] Only for devices not enabled for VoLTE or VoWiFi and depending on Service Provider Policy
[19] 仅适用于未启用VoLTE或VoWiFi的设备,并且取决于服务提供商策略
2.7.1 Additional considerations for specific RCS services / 特定RCS服务的其他注意事项
2.7.1.1 Chat store and forward: Impact in the capability exchange / 聊天存储和转发:在能力交换中的影响
As presented in section A.1.4.3 (IM CAP ALWAYS ON), there is the possibility to configure the client to assume that the Service Provider will be providing the Chat store and forward functionality, which consists of storing messages which are sent to users who are offline (i.e. no data connectivity or device off) at the time the chat message is sent.
如A.1.4.3节(IM CAP ALWAYS ON)中所示,有可能配置客户端假设服务提供商将提供聊天存储和转发功能,其包括在发送聊天消息时,存储发送给离线(即没有数据连接或设备关闭)用户的消息。
If this parameter is enabled, there is an impact from the Chat capability which is presented to the user.
如果启用此参数,则会向用户显示聊天功能的影响。
As a consequence, we have four different types of contacts for Chat capability:
因此,我们有四种不同类型的聊天功能的联系人:
ID | Targeted contact is RCS Chat capable? | Originating Service Provider supports Store&Forward? | Targeted contact is connected to the network? | Impact on starting Chat |
---|---|---|---|---|
1 | NO | N/A | N/A | Chat with that contact is only possible if interworking is provided (see IM CAP NON RCS in Table 75) |
2 | YES | NO | NO | Not possible to start a Chat at that time |
3 | YES | YES | NO | Possible to send a Chat message that will be delivered later by the Store and Forward server as soon as the Contact is connected |
4 | YES | Not Relevant | YES | Chat is possible and messages are immediately delivered |
Table 24: Store and forward possible scenarios / 表24:存储和转发可能的方案
The Chat behaviour on the client is controlled by the IM CAP ALWAYS ON configuration parameter (see Annex A for further information): When a Service Provider implements store and forward, they may choose to provision all the RCS users with the IM CAP ALWAYS ON configuration parameter set to enabled. This means that all RCS contacts (currently registered or not) are presented with the Chat service as available (3 and 4 according to Table 24). This may also be the case when the device is offline itself. In that case, the composed messages should be queued and sent as soon as the device registers with the service again. When the messages are included in the SIP INVITE request (see section 3.3.4) a provisional response (including 100 Trying) should be received on the SIP INVITE request before sending a subsequent queued message. If a session is established (i.e. a 200 OK response is received on the SIP INVITE request that may or may not have included a message), the remaining queued messages targeted at that contact shall be sent in the established MSRP session where a following queued message should be sent as soon as a MSRP 200 OK has been received on the last one.
客户端的聊天行为由IM CAP ALWAYS ON配置参数控制(有关更多信息,请参见附录A):当服务提供商实现存储和转发时,他们可以选择为所有RCS用户配置IM CAP ALWAYS ON配置参数设置为启用。这意味着所有RCS联系人(当前注册或未注册)都显示为可用的聊天服务(根据表24为3和4)。这也可以是设备本身离线时的情况。在这种情况下,编写的消息应该排队,并且一旦设备再次注册该服务就发送。当消息包括在SIP INVITE请求中(参见第3.3.4节)时,应在SIP INVITE请求上接收到临时响应(包括100 Trying),然后再发送后续的排队消息。如果建立了会话(即,在可以或可以不包括消息的SIP INVITE请求上接收到200OK响应),则针对该联系的剩余的排队消息将在所建立的MSRP会话中发送,其中,以下排队的消息应在最后一次收到MSRP 200 OK时立即发送。
When a Service Provider prefers that the RCS user does not use Chat when an RCS contact is not currently registered in IMS, it sets the IM CAP ALWAYS ON configuration parameter to disabled.
当服务提供商优选当RCS联系人当前未在IMS中注册时,RCS用户不使用聊天,它将将IM CAP ALWAYS ON配置参数设置为已禁用。
When store and forward is not implemented by the Service Provider, all its RCS customers will have the IM CAP ALWAYS ON configuration parameter set to disabled (2 and 4 according to Table 24).
当服务提供商未实现存储和转发时,其所有RCS客户将使IM CAP ALWAYS ON配置参数设置为禁用(根据表24为2和4)。
When interworking of chat to SMS/MMS is available for users, the IM CAP NON RCS parameter can be used in a similar way. More information can be found in section A.1.4.3.
当向用户提供聊天与SMS / MMS的互通时,可以以类似的方式使用IM CAP NON RCS参数。 更多信息,请参见第A.1.4.3节。
2.7.1.2 Video and Image Share additional considerations / 视频和图像共享其他注意事项
2.7.1.2.1 Bi-directional Video Share / 双向视频共享
Bi-directional Video Share means that once User A is sharing a video with User B and providing the right coverage conditions are in place, User B could also start to share a video with User A simultaneously. In this case, each Video Share session is independent and is handled separately. When a device moves from a bearer that supports this bi-directional Video Share to a bearer that only supports one way sharing (e.g. from HSPA to 3G) and there is an active Video Share session in each direction, the device that changed bearers shall terminate the Video Share session that it initiated itself.
双向视频共享意味着一旦用户A与用户B共享视频并提供正确的覆盖条件,用户B也可以开始与用户A同时共享视频。 在这种情况下,每个视频共享会话是独立的,并单独处理。 当设备从支持该双向视频共享的承载移动到仅支持单向共享(例如从HSPA到3G)的承载并且在每个方向上存在活动的视频共享会话时,改变承载的设备将终止自己发起的视频共享会话。
For clarification purposes, the following assumptions are made for the Image and Video Share cases:
为了说明的目的,对图像和视频共享情况做出以下假设:
- Both the sharing and receiving end are in a call (that may for instance be CS) between them
共享和接收端都在它们之间的呼叫(例如可以是CS)中 - The call is not a multiparty call
该呼叫不是多方呼叫 - The call is not on hold
呼叫未暂停 - The call is not waiting
呼叫不在等待 - A call forward or divert is not in place
呼叫转移或转移不到位
Meaning the relevant Image and Video Share tags described in section 2.6.1.1.2 shall be included only if:
仅在以下情况下才应包含2.6.1.1.2节中所述的相关图像和视频共享标签的含义:
- The OPTIONS exchange happens when the user is on an active call, and,
当用户处于活动呼叫时,OPTIONS交换发生, - The destination (sending OPTIONS) or the requester (receiving an OPTIONS message which has to be replied with a response) is on the other end of the active call, and,
目的地(发送OPTIONS)或请求者(接收必须用响应答复的OPTIONS消息)在活动呼叫的另一端, - Network coverage supports sharing (see section 2.7), and,
网络覆盖支持共享(参见第2.7节) - Either bi-directional sharing is supported or the device has not initiated a sharing session itself.
支持双向共享或设备本身尚未发起共享会话。
Also for clarification, provided other RCS services (e.g., Standalone Messaging, Chat, File Transfer) are available (e.g. the conditions of coverage and space are met and the device UI supports these services simultaneously with the call), the relevant service capability tags should be included with the Image and Video Share tags.
另外为了说明,如果其他RCS服务(例如,独立消息,聊天,文件传输)可用(例如,满足覆盖和空间的条件并且设备UI与呼叫同时支持这些服务),则相关服务能力标签 包含在图片和视频分享标签中。
NOTE: While capability exchange is reciprocal, User A and User B’s capabilities may be different and services shall be made available accordingly (e.g. User A may support video encode and User B may support decode, but both need to be under 3G or better data coverage for the service to operate).
注意:虽然能力交换是相反的,但是用户A和用户B的能力可以是不同的,并且服务应当相应地可用(例如,用户A可以支持视频编码,用户B可以支持解码,但是两者都需要在3G或更好的数据覆盖 为服务操作)。
In addition to the information presented above, it should also be taken into account that some terminals do not support 2G DTM (Dual-Transfer Mode). When such devices are within a 2G data coverage (meaning that no services are available during the call), the PS connection will automatically drop once they engage in a CS call.
除了上述信息之外,还应考虑到一些终端不支持2G DTM(双传输模式)。 当这样的设备在2G数据覆盖(意味着在呼叫期间没有服务可用)时,一旦它们参与CS呼叫,PS连接将自动丢弃。
NOTE: Information on codec support for Video Share is covered in section 3.6.
注意:有关视频共享的编解码器支持的信息,请参见第3.6节。