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

3.3.1 Feature description / 功能描述

3.3.1.1 General / 一般

The Chat service enables users to exchange messages between two users instantly. The following RCS 1-to-1 Chat features are described:
聊天服务使用户能够在两个用户之间交换即时消息。 RCS 1对1聊天功能如下所述：

Store and forward / 存储和转发
This feature requires a Messaging Server to store messages and notifications (delivery and display) when the destination user is not online and deliver them to the user when he comes online again (i.e. store and forward).
此功能需要消息服务器在目标用户未联机时存储消息和通知（传送和显示），并在他再次联机（即存储和转发）时将消息和通知传送给用户。
Interworking of Chat to SMS/MMS / 聊天与短信/彩信的互通
This feature requires a Messaging Server to interwork the messages to and from SMS or MMS.
此功能需要消息服务器将消息与SMS或MMS进行交互。
Message revocation request of Chat messages / 聊天消息的消息撤销请求
This feature allows a client or originating Messaging Server to request for an undelivered Chat message to be revoked.
此功能允许客户端或始发消息服务器请求撤消未传递的聊天消息。
The revocation process is not user driven but a technical enabler for clients or the Messaging Server on the originating network.
撤销过程不是用户驱动的，而是客户端或发起网络上的消息传递服务器的技术启用者。
Message revocation processing of Chat messages / 聊天消息的消息撤销处理
This feature requires a Messaging Server to process MessageRevoke requests and respond with a MessageRevokeResponse request based on the chat message delivery status.
此功能需要消息服务器处理消息撤消请求，并基于聊天消息传递状态使用消息撤消响应请求进行响应。
"Delivered" message notification / “Delivered”消息通知
This allows the sender of a message to be notified when their message has been delivered to the recipient.
此功能允许消息的发送者在消息已经被递送到接收者时得到通知。
"Displayed" message notification / “Displayed”消息通知
This allows the sender of a message to be notified when their message has been displayed on one of the recipient’s devices. Note that this notification cannot certify that the recipient has actually read the message. It can only indicate that the message has been displayed on the recipient's terminal User Interface (UI).
此功能允许消息的发件人在消息已经在接收者的设备之一上显示时得到通知。请注意，此通知无法证明收件人实际上已阅读邮件。它只能指示消息已显示在收件人的终端用户界面（UI）上。
Delivery of notifications (delivered and displayed) outside a session / 在会话外传递通知（已传递和已显示）
It should be possible to deliver notifications independently of whether a 1-to-1 chat is established or not.
应该可以独立传递通知，而不管1对1聊天是否建立。
IsComposing indications / IsComposing指示
This allows a user in a chat conversation to see when another user is typing a new message/reaction.
这允许聊天对话中的用户查看另一个用户正在键入新消息/反应。
Local Black List / 本地黑名单
The terminal/client may support a locally stored Black List to handle incoming chat requests. Users are allowed to qualify undesired incoming chat as spam. This prevents subsequent messages from those originators to be shown or even notified to the user. Also, this undesired traffic will not be acknowledged to have been read. The Black List behaviour applies not only to Chat but also to File Transfer.
终端/客户端可以支持本地存储的黑名单以处理传入的聊天请求。用户可以将不受欢迎的来电聊天视为垃圾邮件。这防止来自那些发起者的后续消息被显示或甚至被通知给用户。此外，这个不期望的业务将不被确认已经被读取。黑名单行为不仅适用于聊天，还适用于文件传输。
PNB
The PNBs stored in the network and set by the RCS user contains the lists of URIs for contacts (or lists), that an RCS user has set for blocking purposes. The BPEF uses the PNB lists for chat incoming and outgoing traffic blocking.
存储在网络中并由RCS用户设置的PNB包含RCS用户为阻止目的而设置的联系人（或列表）的URI列表。 BPEF使用PNB列表进行聊天传入和传出流量阻止。
Local Conversation History / 本地会话历史
The terminal/client supports a locally stored conversation.
终端/客户端支持本地存储的会话。
Support for the Common Message Store / 支持公共消息存储
The Common Message Store may be used to synchronise chat messages between devices. It also allows the user to keep a back-up of important conversations in the network.
公共消息存储可以用于在设备之间同步聊天消息。它还允许用户保持网络中的重要对话的备份。
In the device, alignment is expected between the local Conversation History and the synchronisation with the Common Message Store.
在设备中，预期在本地对话历史记录和与公共消息存储库同步之间进行对齐。
User Alias (Display Name) / 用户别名（显示名称）
A user defined display name may be sent when initiating a communication with another user.
当发起与另一用户的通信时，可以发送用户定义的显示名称。
Multimedia during a chat conversation / 在聊天对话期间的多媒体
Multimedia exchange during a chat conversation is always provided via File Transfer as per section 3.5.
根据3.5节，在聊天对话期间的多媒体交换总是通过文件传输提供。

3.3.2 Interaction with other RCS features / 与其他RCS功能的交互

3.3.2.1 Switching to Group Chat / 切换到群聊

A Group Chat can only be initiated from a user on a Service Provider which has deployed a Messaging Server. It is optional for a Service Provider to provide the Group Chat functionality. Therefore, from the terminal perspective, if the configuration parameter GROUP CHAT AUTH (see Table 75) is configured to disable Group Chat, the terminal should not allow the user to add additional parties to the chat or start a Group Chat.
组聊天只能从部署了消息服务器的服务提供商的用户启动。而服务提供者提供群聊功能是可选的。因此，从终端的角度来看，如果配置参数GROUP CHAT AUTH（参见表75）被配置为禁用群组聊天，则终端不应允许用户向聊天添加另外的参与方或开始群聊。

A 1-to-1 Chat can be converted into a Group Chat by either of the two Users A and B by adding new users to it. User A and User B are given the option in their UI to add one or more chat partners to the conversation. A user may be limited to the contacts known by their devices to be RCS users. Otherwise the originating user's Messaging Server needs to be prepared to potentially interwork messages to non-RCS Users via SMS or MMS.
1对1聊天可以通过向两个用户A和B中的任一用户添加新用户而被转换成群组聊天。用户A和用户B在其UI中被给予添加一个或多个聊天合作伙伴到对话中的选项。用户可以被限制为由他们的设备已知为RCS用户的联系人。否则，始发用户的消息传递服务器需要准备好通过SMS或MMS潜在地与非RCS用户交互消息。

A real time check of contacts capabilities may be performed when initiating a Group Chat (section 3.3.6.3). A new Group Chat composing window is created in the initiating device, for example, User A’s device, and the result of this check is visible here.
在发起群聊（3.3.6.3节）时，可以执行联系人能力的实时检查。当发起设备（例如，用户A的设备）创建一个新的参加群聊窗口时，该检查的结果可以在这里看到。

When User A sends the first message a new Group Chat is opened between all the selected users, and User A and User B as described in section 3.3.6.3.
当用户A发送第一条消息时，在所有选择的用户，以及用户A和用户B之间打开一个新的群聊，如第3.3.6.3节所述。

For User B a new Group Chat composing window is created in the user’s device.
对于用户B，在用户的设备中创建新的群组聊天参与窗口。

3.3.2.2 File Transfer within 1-to-1 chat and interaction with the blacklist / 在1对1聊天和与黑名单交互中的文件传输

NOTE: In the present section, the BPEF as described in section 2.15.1 may be provided by the Messaging Server.
注意：在本节中，第2.15.1节中描述的BPEF可以由消息传递服务器提供。

During a 1-to-1 chat, either user is able to initiate a File Transfer from the chat composing window towards the other user. The File Transfer is established using a new SIP session and is carried in a new MSRP session which is different from the one used for the chat session.
在1对1聊天期间，任一用户能够从聊天撰写窗口向其他用户发起文件传输。文件传输使用新的SIP会话建立，并且可以在不同于该聊天会话的新的MSRP会话中传递。

If PNB is supported, the handling by the BPEF is same as in section 3.5.4.5. Note that in the case of File Transfer during chat, the sender of the file transfer needs to be checked again but against the FT blacklist this time ‘rcs_pnb_ft_blockedusers’.
如果支持PNB，则BPEF的处理与3.5.4.5节相同。请注意，在聊天期间的文件传输的情况下，文件传输的发送者需要再次检查，但这次针对FT黑名单即'rcs_pnb_ft_blockedusers'中的用户则无需如此。

On the device involved in the chat, the receiving user receives the File Transfer invitation inside the chat window with the sending user and is able to accept or decline it from that window. In a multidevice environment, the File Transfer invitation is also shown on the other devices of the user allowing them to accept or decline the invitation also from those devices.
在聊天中涉及的设备上，接收用户在与发送用户的聊天窗口内接收文件传输邀请，并且能够从该窗口接受或拒绝它。在多设备环境中，文件传输邀请也显示在用户的其他设备上，允许他们也从那些设备接受或拒绝邀请。

If the user accepts the File Transfer, the terminal will either ask the user the location to store the file or use a default directory. Once received, the user can open the file from the chat composing window.
如果用户接受文件传输，终端将询问用户存储文件的位置或使用默认目录。一旦收到，用户可以从聊天撰写窗口打开文件。

Please note that the spam/blacklist behaviour applies to File Transfer, and not only to Chat messages. If an invitation to receive a file is received from a blacklisted user, the client/device implementation should, from the UI point of view, not notify the user on receipt of a File Transfer invitation from a blacklisted sender. Instead it should log the event in the spam folder (e.g. “User A tried to send a file on TIME/DATE”).
请注意，垃圾邮件/黑名单行为适用于文件传输，而不仅适用于聊天消息。如果从黑名单用户接收到接收文件的邀请，则从UI的角度来看，客户端/设备实现应当在从黑名单发送者接收到文件传送邀请时不通知用户。相反，它应该将事件记录在垃圾邮件文件夹中（例如“用户A试图在TIME / DATE发送文件”）。

See section 3.5 for more details on File Transfer.
有关文件传输的更多详细信息，请参阅第3.5节。

3.3.3 High Level Requirements / 高级别要求

The following list of high level requirements applies to 1-to-1 chat: 以下高级别要求列表适用于1对1聊天：

Clients/devices:
客户端/设备：
3-3-1 "Delivered" message notification request and response
3-3-1 “已传递”消息通知请求和响应
3-3-2 "Displayed" message notification request and response
3-3-2 “显示”消息通知请求和响应

NOTE: The client device should allow the user to enable or disable the displayed notifications request and response.
注意：客户端设备应允许用户启用或禁用显示通知请求和响应。

3-3-3 Delivery of notifications (delivered and displayed) outside a session
3-3-3 在会话外传递通知（已传递和已显示）
3-3-4 IsComposing indications
3-3-4 IsComposing指示
3-3-5 Procedures associated with the store and forward of both messages and notifications performed by the Messaging Server
3-3-5 与消息传递服务器执行的消息和通知的存储和转发相关联的过程
3-3-6 Sending MessageRevoke requests
3-3-6 发送信息撤销请求
Messaging Server: In addition to the requirements presented above.
消息服务器：对上面提出的需求的补充。
3-3-7 Store and forward of both messages and notifications
3-3-7 存储和转发消息和通知
Please note this is a function which is provided on the terminating Service Provider’s network, however, a Messaging Server may additionally provide originating store and forward to avoid dependencies with another Service Provider network’s implementations.
请注意，这是在接收端服务提供商的网络上提供的功能，然而，消息服务器可以另外提供始发存储和转发以避免与另一服务提供商网络的实现的依赖。
3-3-8 Interworking of Chat to SMS/MMS
3-3-8 聊天与短信/彩信的互通
3-3-9 Sending MessageRevoke requests
3-3-9 发送消息撤销请求
3-3-10 Handling of MessageRevoke requests
3-3-10 处理消息撤销请求

3.3.4 Technical Realisation / 技术实现

Two different technical realisations of 1-to-1 chat are available: OMA SIMPLE IM as described in [RCS-SIMPLEIM-ENDORS] or OMA CPM as described in [RCS-CPM- CONVFUNC-ENDORS]. The first sub-section describes the features that are common to both technical realisations, while the following two sub-sections describe what is unique to the individual technical realisations. The CHAT MESSAGING TECHNOLOGY configuration parameter defined in Table 75 determines the technical realisation used for 1-to-1 Chat.
可以使用1对1聊天的两种不同的技术实现：如在[RCS-SIMPLEIM-ENDORS]中描述的OMA SIMPLE IM或如在[RCS-CPM-CONVFUNC-ENDORS]中描述的OMA CPM。第一个子部分描述了两种技术实现共有的特征，而以下两个子部分描述了各个技术实现所独有的特征。表75中定义的CHAT消息传送技术配置参数确定了用于1对1聊天的技术实现。

3.3.4.1 Technical Realisation of 1-to-1 Chat features common to both OMA SIMPLE IM and OMA CPM / OMA SIMPLE IM和OMA CPM共有的1对1聊天功能的技术实现

At a technical level, the Chat service implemented using OMA SIMPLE IM or OMA CPM relies on the following concepts:
在技术层面，使用OMA SIMPLE IM或OMA CPM实现的聊天服务依赖于以下概念：

SIP procedures for the setup of sessions using MSRP for the message exchange;
SIP过程，用于使用MSRP建立会话以进行消息交换;
In the SDP of the SIP INVITE request and response, the a=accept-types attribute shall include only message/cpim and application/im-iscomposing+xml, i.e., “a=accept-types:message/cpim application/im-iscomposing+xml”.
在SIP INVITE请求和响应的SDP中，a=accept-types属性应仅包括message/cpim和application/im-iscomposing+xml，即“a=accept-types:message/cpim application/im-iscomposing+xml”。
When a session is set up, messages are transported in the MSRP session. Each MSRP SEND request contains a request to receive an Instant Messaging Disposition Notification (IMDN) ‘delivery’ notification, and possibly a request to receive an IMDN ‘display’ notification. A client should, therefore, always include “positive-delivery” in the value for the CPIM/IMDN Disposition-Notification header field. That means that the value of the header field is either “positive-delivery” or “positive-delivery,display” depending on whether display notifications were requested. The value of “negative- delivery” is not used in RCS for 1-to-1 Chat.
当会话建立时，消息在MSRP会话中传输。每个MSRP SEND请求包含接收即时消息处理通知（IMDN）的“delivery”通知的请求，以及可能的接收IMDN“display”通知的请求。因此，客户端应始终在CPIM/IMDN Disposition-Notification头字段的值中包括“positive-delivery”。这意味着，根据是否请求显示通知，头域的值是“positive-delvery”或“positive-delivery,display”。 RCS中的“1对1聊天”不使用“negative-delivery”的值。
The receiving devices must generate an MSRP SEND request containing the IMDN status when the user message is delivered and if requested, another MSRP SEND request when the message is displayed.
接收设备必须在发送用户消息时生成包含IMDN状态的MSRP SEND请求，如果请求，则在显示消息时生成另一个MSRP SEND请求。

NOTE: If there is not an already established MSRP session between sender and receiver, the Pager Mode (i.e. SIP MESSAGE) is used to transport IMDNs (delivery notification, display notifications)
注意：如果发送方和接收方之间没有已经建立的MSRP会话，则使用寻呼方式（即SIP MESSAGE）来传送IMDN（传送通知，显示通知）
In normal circumstances between two users at most only a single session is active at a time. A client shall, therefore, not initiate a new Chat session towards a user with whom there is already an established Chat session.
在正常情况下，两个用户之间最多只有单个会话一次处于活动状态。因此，客户端不应当向已经与其建立聊天会话的用户发起新的聊天会话。
IMDN [RFC5438]: RCS relies on the support of IMDN as defined in [RFC5438] and [RFC5438Errata] to request and forward disposition notifications of all the exchanged messages (See also section C.2 for the errata mentioned in [RFC5438Errata]).
IMDN [RFC5438]：RCS依赖于[RFC5438]和[RFC5438Errata]中定义的IMDN的支持，请求和转发所有已交换消息的处置通知（另请参见第[C.2节]中提及的勘误表[RFC5438Errata]）。
In MSRP requests, the client shall set both the CPIM From and CPIM To headers to sip:[email protected] to prevent revealing the user’s identity when transmitted over unprotected links. A client receiving a CPIM message in a one-to- one Chat should, therefore, ignore the identity indicated in the CPIM headers.
在MSRP请求中，客户端应将CPIM From和CPIM To标头设置为sip：[email protected]，以防止在通过不受保护的链接传输时暴露用户身份。因此，在一对一聊天中接收CPIM消息的客户端应该忽略CPIM头部中指示的身份。
The CPIM/IMDN wrapper shall be UTF-8 encoded to avoid any potential internationalisation issues.
CPIM / IMDN包装器应进行UTF-8编码，以避免任何潜在的国际化问题。
IMDN message identification for all messages (including those conveyed in the SIP INVITE and notifications delivered via SIP MESSAGE) as defined in [RFC5438].
IMDN消息标识，如[RFC5438]中定义的所有消息（包括在SIP INVITE中传达的消息和通过SIP MESSAGE传递的通知）。
The originating Messaging Server shall always set the CPIM DateTime header in the chat messages and notifications it receives by overwriting the value provided by the client. A client receiving these requests should, therefore, rely on these headers rather than on locally available time information.
始发消息服务器应始终通过覆盖客户端提供的值来在聊天消息和其接收的通知中设置CPIM日期时间标头。因此，接收这些请求的客户端应该依赖于这些头部而不是本地可用的时间信息。
Both the Originating and the Terminating function shall ensure that messages are received in correct order by the RCS client regardless if the messages are store and forwarded or not.
始发和终止功能应确保由RCS客户端以正确的顺序接收消息，而不管消息是存储还是转发。
- To achieve this, the terminating side shall wait for the delivery notification or 180 ringing response until a new message is sent if the message is carried in the INVITE.
  为了实现这一点，终端侧将等待递送通知或180振铃响应，直到如果在INVITE中携带该消息，则发送新消息。
- As in the case for messages composed while offline (see section 2.7.1.1) when a message is carried in the INVITE request, the client shall wait for a provisional response before sending a new message.
  与在INVITE请求中携带消息时离线组成的消息（参见第2.7.1.1节）一样，客户端在发送新消息之前应等待临时响应。
For network optimisation purposes, the aggregation of IMDNs as specified in [RFC5438] may be supported for network initiated IMDNs:
为了网络优化的目的，可以为网络发起的IMDN支持如[RFC5438]中所规定的IMDN的聚合：
- Within the Service Provider’s own network, the aggregation of IMDN may be supported (per local policy).
  在服务提供商自己的网络内，可以支持IMDN的聚合（根据本地策略）。
- For inter-Service Provider interoperability, the individual IMDN will always be sent to the target network, where the aggregation of IMDN is up to the target network (per local policy). That is, if the aggregated IMDNs received by the Messaging Server contain IMDNs that need to be sent to another network, the Messaging Server will repackage the aggregated IMDNs accordingly before sending them to the Chat message sender on the other network.
  对于服务提供商之间的互操作性，单个IMDN将始终发送到目标网络，其中IMDN的聚合达到目标网络（根据本地策略）。也就是说，如果消息服务器接收的聚合IMDN包含需要发送到另一网络的IMDN，则消息服务器将在将聚合IMDN发送到另一网络上的聊天消息发送者之前相应地重新打包该聚合IMDN。
- If the aggregated IMDNs received by the Messaging Server contain both in- network and inter-Service Provider Chat message senders, the Messaging Server will repackage the aggregated IMDNs according to in-network Chat message senders and inter-Service Provider Chat Message senders.
  如果消息传递服务器收到的聚合IMDN同时包含网络内和跨服务供应商的聊天消息发送者，则消息传递服务器将根据网络内和跨服务提供者聊天消息发送者重新打包聚合的IMDN。
Auto-acceptance of store and forward Messaging Server PUSH of stored notifications.
存储和转发消息服务器存储的通知的PUSH的自动接收。
Store and forward Messaging Server PUSH of stored messages.
存储和转发消息服务器存储的消息PUSH。
Chat inactivity timeout: When a device or the network detects that there was no activity in a chat for IM SESSION TIMER, a configurable period of time (see Table 75), it will close the established Chat session.
聊天不活动超时：当设备或网络检测到聊天中经过IM SESSION TIMER，一个可配置的时间段（见表75），而没有活动时，它将关闭已建立的聊天会话。
When reopening an older chat on the device, that contains messages for which a “display” notification should be sent, these notifications shall be sent as follows:
当在设备上重新打开较早的聊天时，包含应发送“display”通知的消息，这些通知应发送如下：
- If there is no session established with the sender, the device will send the notifications outside a session (since there is no current session to send them to) using SIP MESSAGE;
  如果没有与发送方建立的会话，则设备将使用SIP MESSAGE在会话之外发送通知（因为没有当前会话要发送给它们）。
- If there is an active session but that session is with a device of the sender other than the one that was used to send the message to which this notification relates, the Messaging Server will ensure that these notifications are delivered outside of that session;
  如果存在活动会话，但该会话与发送方的设备（而不是用于发送与此通知相关的消息的设备）不同，则消息传递服务器将确保这些通知在该会话之外传递;
The "IsComposing" notification is generated and processed according to the rules and procedure of [RCS-SIMPLEIM-ENDORS] and [RCS-CPM-CONVFUNC- ENDORS]. Consequently, the ‘IsComposing’ notification is not sent with CPIM headers, and as such a delivery and/or displayed notification cannot be requested.
“IsComposing”通知是根据[RCS-SIMPLEIM-ENDORS]和[RCS-CPM-CONVFUNC-ENDORS]的规则和过程生成并处理的。因此，'IsComposing'通知不与CPIM报头一起发送，并且因此不能请求递送和/或显示的通知。
The transfer of files while a Chat session is taking place shall at protocol level be performed in a separate session. From the user experience perspective, they should be able to transfer files whilst in chat. Messages over a maximum size (MAX SIZE IM in section A.1.4.3) should be transferred using File Transfer. All multimedia content shall be transferred using File Transfer.
在聊天会话正在进行时文件的传送应在协议级别在单独的会话中执行。从用户体验的角度来看，他们应该能够在聊天时传输文件。应使用文件传输传输最大大小的消息（MAX SIZE IM在A.1.4.3节）。所有多媒体内容应使用文件传输传输。

3.3.4.1.1 Client Side Spam/Black List Handling / 客户端垃圾邮件/黑名单处理

When receiving a message from a sender included in the Black List (i.e. a spam sender) the receiving client’s/device’s implementation shall:
当从包括在黑名单中的发送者（即垃圾发送者）接收到消息时，接收客户端/设备的实现应当：

Terminate the transaction with a 486 BUSY HERE sent back to the sender.
终止交互，将486 BUSY HERE发送回发件人。
The receiver will still issue a delivery notification with status “delivered” which will be sent back to the sender.
接收者仍将发出具有状态“已传递”的递送通知，其将被发送回发送者。
From the UI point of view, the receiver should not be notified on the reception of a message from a blacklisted sender and the message should be copied to the spam filter.
从UI的角度来看，不应该通知接收者来自黑名单发送者的消息的接收，并且该消息应该被复制到垃圾邮件过滤器。

3.3.4.1.2 Personal Network Blacklists handling / 个人网络黑名单处理

NOTE: In the present section, the BPEF as described in section 2.15.1 may be provided by the Messaging Server itself.
注意：在本节中，第2.15.1节中描述的BPEF可以由消息传递服务器本身提供。

When supported and enabled, the PNB described in section 2.15 are applied by the BPEF at both origination and termination of 1-to-1 chat invitation requests.
当支持和启用时，BPEF在1对1聊天邀请请求的发起和终止时应用部分2.15中描述的PNB。

The following resource-lists from Shared XDMS are checked by the BPEF by comparing the URI values used in the request and in the list:
来自Shared XDMS的以下资源列表由BPEF通过比较请求中和列表中使用的URI值进行检查：

On origination:
在发起端：
- a) Upon initiation of the 1-to-1 chat, the BPEF of the originator checks the ‘rcs_pnb_outchat_blockedusers’ list to verify that the recipient is not among the blocked users for this request by comparing URIs contained in the list with the URI value of the Request URI of the SIP request.
  a) 在开始1对1聊天时，发起者的BPEF将检查'rcs_pnb_outchat_blockedusers'列表，通过将列表中包含的URI与SIP请求的URI值进行比较，以验证接收者不在该请求的阻止用户之中。
- b) If found, the BPEF shall reject the chat with a 403 Forbidden with a warning header set to “122 Function not allowed” towards the user without forwarding the SIP INVITE to the recipient’s network.
  b) 如果找到，BPEF将丢弃与该用户的聊天，向其发送一个403禁止消息，该消息带有一个警告头，设置为“122 Function not allowed”，而不转发SIP INVITE到接收者的网络。
On termination:
在接收端：
- a) The BPEF checks the ‘rcs_pnb_chat_blockedusers’ list, to verify if the originator of the chat is among the blacklisted users by comparing the URIs contained in the list with the URI values of the P-Asserted-Identity header field of the SIP request.
  a) BPEF检查“rcs_pnb_chat_blockedusers”列表，以通过将列表中包含的URI与SIP请求的P-Asserted-Identity头字段的URI值进行比较来验证聊天的发起者是否在黑名单用户之中。
- b) If the sender is among the blacklisted users, the BPEF returns a 403 Forbidden with a warning header set to “122 Function not allowed” to the originator’s network, without forwarding the SIP INVITE to the recipient.
  b) 如果发送方在黑名单用户之中，则BPEF向发起方的网络返回403 Forbidden，其具有设置为“122 Function not allowed”的警告标头，而不向接收方转发SIP INVITE。
- c) If the Common Message Store feature is supported, it stores the Session History folder data as defined in [RCS-CPM-MSGSTOR-ENDORS] for the blocked chat invite event.
  c) 如果支持公共消息存储功能，它会存储被阻止的聊天邀请事件到的[RCS-CPM-MSGSTOR-ENDORS]中定义的会话历史文件夹数据。

3.3.4.1.3 Chat abnormal interruption / 聊天异常中断

If a device in a chat suffers an abnormal termination of the Chat session, for example, loss of coverage, the “Send” button may be disabled. If the device determines that a message could not be sent (e.g. failed response or received no response), it shall inform the user that the chat message was not sent. If the TCP connection is lost, the client should re-send it in a new chat session once re-registered.
如果聊天中的设备遭遇聊天会话的异常终止，例如，覆盖丢失，则可以禁用“发送”按钮。如果设备确定不能发送消息（例如，失败的响应或没有接收到响应），则它应通知用户聊天消息未被发送。如果TCP连接丢失，客户端应在重新注册后在一个新的聊天会话中重新发送它。

NOTE1: If the Messaging Servers involved in the chat have implemented store and forward functionality, then the Messaging Servers shall be responsible for storing any messages received while a chat has been abnormally interrupted.
注1：如果聊天中涉及的消息服务器实现了存储和转发功能，则消息服务器应负责存储聊天异常中断时收到的任何消息。

NOTE2: In temporary interruption cases, for example, a device was out of network coverage but is now again within network coverage, the chat can be continued from the same conversation window. In this case a new session has to be established with a SIP INVITE request.
注2：在临时中断情况下，例如，设备不在网络覆盖范围内，但现在又在网络覆盖范围内，可以从同一对话窗口继续聊天。在这种情况下，必须使用SIP INVITE请求来建立新的会话。

3.3.4.1.4 Store and Forward Mode / 存储和转发模式

The store and forward functionality in the network is optional and it is up to each Service Provider to decide whether to deploy it.
网络中的存储和转发功能是可选的，由每个服务提供商决定是否部署它。

The store and forward functionality requires a Messaging Server. There are three possible scenarios to fulfil the requirement for store and forward functionality:
存储和转发功能需要消息传递服务器。有三种可能的情况来满足存储和转发功能的要求：

Sender and receiver are on networks with a Messaging Server supporting store and forward: In this case, the receiver’s side Messaging Server has the responsibility to store and forward IMs which are not delivered. The sender’s side Messaging Server has the responsibility of storing the delivered/displayed notifications if the sender is offline.
发送者和接收者在具有支持存储和转发的消息传送服务器的网络上：在这种情况下，接收者侧消息传送服务器有责任存储和转发未传送的IM。如果发件人离线，则发件人端消息服务器有责任存储已发送/显示的通知。
Only the sender is on a network with a Messaging Server supporting store and forward: The sender’s side Messaging Server has the responsibility to store and forward Chat messages and/or delivered/displayed notifications if immediate delivery was not possible. As it is in the sender’s network, the Messaging Server will not have information on when the receiver is online; therefore a retry mechanism is used. Note that it is the Service Provider’s decision whether they provide store and forward for chat messages on behalf of the receiver who is in a different network that does not support store and forward.
只有发送方位于具有支持存储和转发的消息传递服务器的网络上：如果不能立即传递，则发送方的消息传递服务器有责任存储和转发聊天消息和/或传递/显示的通知。由于它在发送者的网络中，消息服务器将不具有关于接收者何时在线的信息; 因此使用重试机制。注意，服务提供商的决定是否代表处于不支持存储和转发的不同网络中的接收者提供聊天消息的存储和转发。
Only the receiver is on a network with a Messaging Server supporting store and forward: The receiver’s side Messaging Server has the responsibility to store and forward Chat messages and/or delivered/displayed notifications if they cannot be delivered. As it is at the receiver’s side, that Messaging Server will not have information on when the sender is online. Therefore, a retry mechanism is used to store and forward notifications that could not be delivered right away.
只有接收器位于具有支持存储和转发的消息传送服务器的网络上：如果无法传送，则接收方的消息传送服务器有责任存储和转发聊天消息和/或传送/显示的通知。由于它在接收方，消息服务器将不会有关于发送方何时在线的信息。因此，重试机制用于存储和转发不能立即传递的通知。

NOTE: Whether a Service Provider provides store and forward for delivered/ displayed notifications on behalf of the sender who is in a different network that does not support store and forward is optional.
注意：服务提供商是否为代表处于不支持存储和转发的不同网络中的发送方提供传送/显示通知的存储和转发是可选的。

With the introduction of application messages making use of the chat session (see section 3.5.4.8 and 3.10.4), the store and forward functionality for chat will have to deal with those content types. That shall be done as follows:
随着使用聊天会话的应用消息的引入（参见第3.5.4.8和3.10.4节），聊天的存储和转发功能将必须处理这些内容类型。应做到如下：

When accepting a Chat session on behalf of a user, a Messaging Server shall indicate support for the application message content types that it supports (e.g. in the a=accept-wrapped-types SDP attribute that it provides in the SIP 200 OK Response.
当代表用户接受聊天会话时，消息服务器应该指示对其支持的应用消息内容类型的支持（例如，在它在SIP 200 OK响应中提供的a=accept-wrapped-types SDP属性中）。
Storage of such content shall be as any other message content.
这种内容的存储应与任何其他消息内容一样。
When a client comes online, forwarding shall be as follows:
当客户上线时，转发如下：
- When included as a body of a SIP INVITE request, for non-text content a dedicated Accept-Contact header field shall be added to the INVITE request carrying the IARI defined for the service corresponding to the included content type in section 2.6.1.1.2 with the require and explicit parameters.
  当作为SIP INVITE请求的主体被包括时，对于非文本内容，应当将专用的Accept-Contact报头字段添加到INVITE请求中，该INVITE请求需携带为在2.6.1.1.2节中包括的内容类型对应的服务定义的IARI，并带有必需和显式的参数。
- If delivery fails with a SIP 480 response, the Messaging Server shall store the original message and forward it later (again including an Accept-Contact header field as for the initial forward) when another device of the user comes online.
  如果使用SIP 480响应传递失败，则消息服务器将存储原始消息并在用户的另一设备上线时稍后转发（再次包括用于初始转发的Accept-Contact首部字段）。
- The message shall also remain stored for later delivery to another device if when the application message needs to be forwarded in a session that is already established and the a=accept-wrapped-types attribute provided by the client that accepted the session didn’t include support for the corresponding MIME type.
  在已经建立的会话中，如果当应用消息需要被转发，并且由接受会话的客户端提供的a=accept-wrapped-types属性不包括对于该消息对应的MIME类型的支持时，该消息也将保持存储以便稍后传递到另一个设备。

The Messaging Server stores undelivered messages for a period that is determined by local server policy. If at the end of this period the messages have not been delivered, the Messaging Server discards them. This applies to notifications as well as messages.
消息服务器在由本地服务器策略确定的时间段内存储未传递的邮件。如果在此时间段结束时消息尚未传送，消息传递服务器将丢弃它们。和消息相同，这也适用于通知。

A dedicated configuration setting (IM CAP ALWAYS ON, see Table 75 in Annex A for further reference) is used to configure the client to allow sending messages to offline users.
专用配置设置（IM CAP ALWAYS ON，请参见附录A中的表75以供进一步参考）用于将客户端配置为允许向离线用户发送消息。

NOTE: The procedure for Messaging Server to store the chat message when the participant is temporarily unavailable is described in [RCS-SIMPLEIM- ENDORS] or [RCS-CPM-CONVFUNC-ENDORS] based on the CHAT MESSAGING TECHNOLOGY configuration parameter defined in Table 75.
注意：当参加者临时不可用时，消息服务器存储聊天消息的过程在[RCS-SIMPLEIM- ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]中描述，基于表75中定义的CHAT MESSAGING TECHNOLOGY配置参数。

3.3.4.1.5 Delivering stored disposition notifications / 传送存储的处置通知

To be able to deliver delivered/displayed notifications via store and forward to a sender’s device that has come online again, without disrupting the user experience, the Messaging Server supporting the store and forward functionality shall initiate a special session for the purpose of delivering these notifications. This special session shall be automatically accepted by the device. It is recognized by the device by means of the well-known username part of the URI (rcse-standfw@) uniquely identifying the store and forward service identity that is provided in the P-Asserted-Identity header field. Optionally an operator can disable the delivering of the stored notifications when the RCS user is roaming in a foreign network.
为了能够通过存储并转发到已再次联机的发送者设备来递送所已发送/已显示的通知，而不中断用户体验，支持存储和转发功能的消息服务器应当发起特殊会话以递送这些通知。此特殊会话将由设备自动接受。它由设备通过唯一地标识在P-Asserted-Identity头部字段中提供的存储和转发服务标识的URI的公知的用户名部分（rcse-standfw@）来识别。可选地，当RCS用户在外地网络中漫游时，运营商可以禁用所存储的通知的递送。

NOTE1: The Messaging Server may also use Pager Mode messaging to deliver stored delivery and displayed notifications.
注1：消息传递服务器还可以使用寻呼模式消息传递来传递存储的传递和显示的通知。

The Messaging Server supporting the store and forward functionality is required to send the delivered/displayed notifications when the first device of the user comes online.
当用户的第一设备上线时，需要支持存储和转发功能的消息传送服务器来发送已传送/已显示的通知。

NOTE2: The procedure for Messaging Server to deliver the stored chat messages and associated disposition notifications are described in [RCS-SIMPLEIM- ENDORS] or [RCS-CPM-CONVFUNC-ENDORS] based on the CHAT MESSAGING TECHNOLOGY configuration parameter defined in Table 75.
注2：根据表75中定义的CHAT MESSAGING TECHNOLOGY配置参数，在[RCS-SIMPLEIM- ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]中描述了消息传递服务器传递存储的聊天消息和关联的处置通知的过程。

3.3.4.1.5 Interworking towards SMS/MMS / 与短信/彩信互通

The functionality for interworking of the chat service to SMS/MMS is optional and it is the decision of each Service Provider whether to deploy it. This deployment involves:
用于将聊天服务互通到SMS/MMS的功能是可选的，并且每个服务提供商决定是否部署它。此部署涉及：

The Messaging Server described in [RCS-SIMPLEIM-ENDORS] or [RCS-CPM-CONVFUNC-ENDORS].
在[RCS-SIMPLEIM-ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]中描述的消息服务器。
The ISF described in [RCS-CPM-IW-ENDORS] which is responsible for selecting the appropriate interworking function for a new session.
在[RCS-CPM-IW-ENDORS]中描述的ISF，其负责为新会话选择适当的互通功能。
The IWF for SMS and MMS described in respectively [RCS-3GPP-SMSIW- ENDORS] and [RCS-CPM-IW-ENDORS] which are responsible for doing the actual interworking (that is the protocol conversions) between RCS based chat and SMS or MMS.
分别负责在基于RCS的聊天和SMS或MMS之间进行实际互配（即协议转换）的[RCS-3GPP-SMSIW-ENDORS]和[RCS-CPM-IW-ENDORS]中描述的SMS和MMS的IWF。

Based on service-level agreements (SLAs), interworking of chat may occur on the originating side or the terminating side, the same circumstances as for interworking of messages with SMS/MMS described in section 3.2.4.6. In brief, the interworking is initiated by the Messaging Server either based on local information it may have about the recipient, or when it receives one of the following error responses on the INVITE request that indicate that the recipient is not an RCS contact:
基于服务级别协议（SLA），聊天的互通可以发生在发起侧或终止侧，与在3.2.4.6中描述的具有SMS / MMS的消息的互通相同的情况。简而言之，交互是由消息传递服务器基于关于接收者的本地信息或者当它在INVITE请求上接收到指示接收者不是RCS联系人的以下错误响应之一时发起的：

404 Not Found;
405 Method Not Allowed;
410 Gone;
414 Request URI Too Long;
415 Unsupported Media Type;
416 Unsupported URI Scheme;
488 Not Acceptable Here;
606 Not Acceptable.

3.3.4.1.6.1 Interworking at Originating Side / 在发起侧的互通

When a Chat session invitation needs to be interworked on the originating side, the CPM Participating Function will route the invitation to the ISF, which will select either SMS or MMS interworking based on applicable service provider policy. The ISF will then route the message to the selected IWF, which will either accept the chat invitation automatically on behalf of the SMS/MMS user, or will convert the chat invitation to an SMS/MMS invitation message and deliver it to the terminating network using the appropriate SMS/MMS NNI. The response to the chat invitation from the SMS/MMS user must be received through the same SMS/MMS interface to associate correctly the response with the earlier invitation. The SMS/MMS response (either accept or decline) to the invitation is converted to the appropriate SIP response and conveyed back to the RCS user.
当聊天会话邀请需要在始发侧互通时，CPM参与功能将邀请发送到ISF，ISF将基于适用的服务提供商策略选择SMS或MMS互配。 ISF然后将消息路由到所选择的IWF，该IWF将代表SMS / MMS用户自动接受聊天邀请，或者将聊天邀请转换为SMS / MMS邀请消息并且使用适当的SMS / MMS NNI。必须通过相同的SMS / MMS接口接收来自SMS / MMS用户的对聊天邀请的响应，以将响应正确地与较早的邀请相关联。邀请的SMS / MMS响应（接受或拒绝）转换为适当的SIP响应，并传回RCS用户。

3.3.4.1.6.2 Interworking at Terminating Side / 在接收侧的互通

When a Chat session invitation needs to be interworked on the terminating side, the invitation will be first routed to the terminating network as described in previous sub- sections, and then the same procedures as for interworking of chat invitations on the originating side will apply.
当聊天会话邀请需要在接收侧互通时，如先前子部分中所描述的，邀请将首先被路由到接收端网络，然后与用于在发起侧上的聊天邀请的互通相同的过程将被应用。

3.3.4.1.7 Multidevice handling / 多设备处理

Multidevice handling occurs when a user has more than one device (e.g., PC and mobile).
当用户具有多于一个设备（例如，PC和移动设备）时，发生多设备处理。

When a new 1-to-1 chat is initiated and a message is sent from User A to a User B with User B having multiple devices registered at the same time, the network or Messaging Server forks the Chat session invitation to the different devices. Forking on the Messaging Server is further elaborated in section 3.3.4.1.7.1.
当发起新的1对1聊天并且从用户A向用户B发送消息时，用户B具有同时注册的多个设备，网络或消息服务器将聊天会话邀请分派到不同的设备。在3.3.4.1.7.1节中进一步详细说明了分组服务器上的分支。

NOTE: It is assumed that the originating user uses one device per session.
注意：假设始发用户每个会话使用一个设备。

Each of User B’s devices that receive the session invitation with a message in the INVITE generates a SIP MESSAGE request to carry the delivered IMDN. In a multidevice scenario, if a sender receives more than one IMDN for a sent message, it shall discard all copies except the first one it receives.
接收具有INVITE中的消息的会话邀请的用户B的设备中的每一个生成用于携带所递送的IMDN的SIP MESSAGE请求。在多设备场景中，如果发送方为发送的消息接收到多个IMDN，则它将丢弃除了接收的第一个副本之外的所有副本。

User B is able to respond to the chat from any of their devices. When they answer and send a message from one of the devices, that device (B1) becomes the only active device for User B and all the Chat sessions towards the other devices are terminated.
用户B能够从他们的任何设备响应聊天。当他们回答并从一个设备发送消息时，该设备（B1）成为用户B的唯一活动设备，并且朝向其他设备的所有聊天会话被终止。

Once the user has answered the chat from device B1, all the subsequent messages sent to User B are received only by the active device B1 using the already established Chat session.
一旦用户已经回答了来自设备B1的聊天，发送到用户B的所有后续消息仅由主动设备B1使用已经建立的聊天会话接收。

Device switching:
设备切换：

If User B closes the Chat session from the active device (either by closing the chat conversation from the chat window or due to an abnormal termination), any new messages sent by User A through the chat will make the Messaging Server establish the chat again using one Chat session per connected device of User B and send the message to them all.
如果用户B关闭来自活动设备的聊天会话（通过从聊天窗口关闭聊天对话或由于异常终止），则用户A通过聊天发送的任何新消息将使消息服务器再次建立聊天用户B的每个连接的设备的一个聊天会话并且向他们发送消息。
If User B changes from one device B1 to another B2 by sending a new message to the chat from the new device B2, B2 will send a new INVITE request that will go to User A’s device. When User A’s device detects a new INVITE request from User B which already has an established session with User A’s device it shall end that session and accept the new one. All subsequent messages are received only by device B2. Device B2 must then store the received messages and display them appropriately.
如果用户B通过从新设备B2向聊天发送新消息而从一个设备B1改变到另一个B2，则B2将发送新的INVITE请求，该请求将去往用户A的设备。当用户A的设备检测到来自用户B的已经与用户A的设备已经建立了会话的新的INVITE请求时，它将结束该会话并接受新的会话。所有后续消息仅由设备B2接收。设备B2必须存储接收的消息并适当地显示它们。

3.3.4.1.7.1 Forking on the Messaging Server / 在消息服务器上分叉

Forking to registered online devices in case that there is no message in the incoming INVITE request shall be achieved by using the forking capability at the Messaging Server. In case there is a message in the incoming INVITE request, forking to registered online devices may be achieved by using the forking capability at the Messaging Server according to Service Provider policy. This capability shall be implemented on the terminating Participating Function. 如果在传入的INVITE请求中没有消息，则通过在消息服务器处使用分叉能力来实现分支到注册的在线设备。在传入的INVITE请求中存在消息的情况下，可以通过根据服务提供商策略在消息服务器处使用分叉能力来实现对注册的在线设备的分叉。该能力应在终止参与功能上实施。

As described in section 3.3.4.1.7, in case of an incoming INVITE request, User B is able to respond to the chat from any of their devices. When User B responds from one of the devices, that device becomes the only “active” device (i.e. ‘is composing’ notifications or messages originated from that device) for that user and, consequently, the terminating Participating Function shall tear down all other chat sessions towards the other devices under the same chat session identity by sending a SIP BYE request including a Reason header field with the protocol set to SIP and the protocol-cause set to 200 along with an optional protocol-text (e.g. SIP;cause=200;text="Call completed elsewhere"). A client may use this information to update its representation in the UI. 如第3.3.4.1.7节所述，在来电INVITE请求的情况下，用户B能够从任何他们的设备响应聊天。当用户B从设备中的一个响应时，该设备成为该用户的唯一“活动”设备（即“is composing”通知或消息从该设备发起），因此，针对相同聊天会话标识下的其他设备，通过发送一个包含一个Reason头域的SIP BYE请求，该头域中protocol设置为SIP且protocol-cause设置为200，并带有一个可选的protocol-text（例如，SIP;cause=200;text="Call completed elsewhere"）；终止参与功能将拆除所有其他聊天会话。客户端可以使用该信息来更新其在UI中的表示。

When a device belonging to User B registers in IMS and provided there is no other active device, the terminating Participating Function shall send an INVITE request for that chat session to the newly registered device. 当属于用户B的设备在IMS中注册并且没有其他活动设备时，终止参与功能将向该新注册的设备发送针对该聊天会话的INVITE请求。

3.3.4.1.8 Emoticons / 表情符号

Selected emoticons are displayed graphically but sent and received as text. The list of supported emoticons is defined in [RCS-SIMPLEIM-ENDORS] Appendix N.
所选的表情符号以图形方式显示，但作为文本发送和接收。支持的表情符列表在[RCS-SIMPLEIM-ENDORS]附录N中定义。

3.3.4.1.9 Chat message size limitations / 聊天消息大小限制

The maximum size is controlled through the MAX SIZE IM configuration parameter defined in Table 75. Messages that are larger than the maximum size indicated in the MAX SIZE IM configuration parameter can be delivered either using File Transfer or a Large Message Mode standalone message.
最大大小通过表75中定义的MAX SIZE IM配置参数来控制。大于MAX SIZE IM配置参数中指示的最大大小的消息可以使用文件传输或大消息模式独立消息传递。

3.3.4.1.10 Message Revocation

Message revocation is a feature that allows a client or Messaging Server to request for a chat message to be revoked by the recipient’s Messaging Server. The recipient’s Messaging Server processes MessageRevoke requests and responds with a Message Revoke Response request based on the chat message delivery status.
消息撤销是一种功能，允许客户端或消息传递服务器请求聊天消息被接收方的消息传递服务器撤销。接收方的消息传递服务器处理MessageRevoke请求，并基于聊天消息传递状态使用消息撤消响应请求进行响应。

3.3.4.1.10.1 Generating Chat Message Revoke Requests / 聊天消息撤消请求的生成

The MessageRevoke request is generated by either the client or the Messaging Server of the message sender, depending on the Service Provider policy. The MessageRevoke request is carried in the body of a SIP MESSAGE request that includes the same imdn.message-ID value of the chat message that is intended to be revoked (as described in section 3.3.4.1.10.4).
MessageRevoke请求由消息发送者的客户端或消息传递服务器生成，具体取决于服务提供者策略。 MessageRevoke请求在SIP MESSAGE请求的主体中携带，该请求包含要撤消的聊天消息的相同imdn.message-ID值（如第3.3.4.1.10.4节所述）。

MessageRevoke requests shall be generated only towards networks where their Messaging Server can handle them as described in section 3.3.4.1.10.2 and are not meant to reach other clients. MessageRevoke requests shall not be generated in case the delivery notification pertaining to the original message has been received.
MessageRevoke请求应仅向其消息传递服务器可以处理它们的网络生成，如第3.3.4.1.10.2节所述，并且不打算到达其他客户端。在已经接收到与原始消息有关的递送通知的情况下，不会生成消息撤消请求。

NOTE: Given that a revoke may be sent only if support has been indicated by the terminating network, it cannot be initiated when the INVITE transaction is still pending.
注意：考虑到只有当终端网络指示了支持时才可以发送撤销，所以当INVITE事务仍然处于挂起状态时，无法发起撤销。

3.3.4.1.10.1.1 Message Revoke Requests by the Client / 消息撤销客户端的请求

When message revocation is enabled (CHAT REVOKE TIMER, see section A.1.4.3), the client can generate MessageRevoke requests once the timer is expired. In order for the MessageRevoke requests to be transmitted, the client shall have data connectivity.
当启用消息撤销时（CHAT REVOKE TIMER，请参见第A.1.4.3节），一旦定时器到期，客户端可以生成MessageRevoke请求。为了发送MessageRevoke请求，客户端应具有数据连接性。

MessageRevoke requests shall be generated only if support for MessageRevoke requests has been indicated in the Contact header of the SIP INVITE request or in the response to the SIP INVITE request of the session to which the message intended to be revoked belongs. Specifically, this indication is in the form of a feature tag in the Contact header of the SIP INVITE request or response that is defined in section 3.3.4.1.10.3. For session initiation scenarios that result in SIP 486 Busy Here responses from the terminating Messaging Server, a feature tag cannot be included by the terminating network since according to [RFC3261] a Contact header is not present in such responses. However, depending on Service Provider policy a MessageRevoke request may be generated (for the case where a first message is included in the SIP INVITE request). In that case, this MessageRevoke request might be blocked on the NNI if not supported by the terminating network (see section 3.3.5.3).
只有在SIP INVITE请求的Contact头中，或在对要被撤销的消息所属的会话的SIP INVITE请求的响应中指示了对MessageRevoke请求的支持时，才应生成MessageRevoke请求。具体来说，该指示是在第3.3.4.1.10.3节中定义的SIP INVITE请求或响应的联系头中的特征标签的形式。对于来自终止消息服务器的导致SIP 486 Busy Here响应的会话发起场景，终端网络不能包括特征标签，因为根据[RFC3261]，在这样的响应中不存在联系头部。然而，根据服务提供商策略，可以生成MessageRevoke请求（对于第一消息包括在SIP INVITE请求中的情况）。在这种情况下，如果终端网络不支持，则可能在NNI上阻止此MessageRevoke请求（请参见第3.3.5.3节）。

When a message is to be revoked, the client shall include an Accept-Contact header field with either the CPM ICSI for Session Mode Messaging, or the OMA SIMPLE IM feature tag (depending on the value of the CHAT MESSAGING TECHNOLOGY configuration parameter defined in Table 75), as is already the case for IMDNs carried in SIP MESSAGE requests, and shall add a dedicated Accept-Contact header field carrying the Message Revoke feature tag defined in section 3.3.4.1.10.3 along with the require and explicit parameters. The client shall also include the message revocation content-type including the value of the imdn.message-ID of the original message that is requested to be revoked, as described in section 3.3.4.1.10.4. The Request-URI of the MessageRevoke request shall be set to the address of the target contact of the message that is requested to be revoked. The body of the MessageRevoke request, as described in section 3.3.4.1.10.4, shall have:
当要撤消消息时，客户端将包括具有用于会话模式消息的CPM ICSI或OMA SIMPLE IM特征标签的Accept-Contact报头字段（取决于在表格中定义的CHAT消息传送技术配置参数的值 75），如在SIP MESSAGE请求中携带的IMDN的情况一样，并且将添加专用的Accept-Contact首部字段，其携带第3.3.4.1.10.3节中定义的消息撤销特征标签以及require和显式参数。客户端还应包括消息撤销内容类型，包括请求撤销的原始消息的imdn.message-ID的值，如第3.3.4.1.10.4节所述。 MessageRevoke请求的Request-URI应设置为请求撤消的消息的目标联系人的地址。 MessageRevoke请求的主体，如第3.3.4.1.10.4节所述，应具有：

The element set to the value of the imdn.message-ID of the original message that is requested to be revoked,
设置为请求撤销的原始消息的imdn.message-ID的值的元素，
The element set to the URI of the sender of the message,
元素设置为消息发送者的URI，
The element set to the URI of the recipient of the message.
元素设置为消息的收件人的URI。

3.3.4.1.10.1.2 Message Revoke Requests by the Messaging Server / 消息撤销消息服务器的请求

Similarly to section 3.3.4.1.10.1.1, MessageRevoke requests shall be generated only if support for MessageRevoke requests has been indicated in the Contact header of the SIP INVITE request or in the response to the SIP INVITE request of the session to which the message intended to be revoked belongs. Specifically, this indication is in the form of a feature tag in the Contact header of the SIP INVITE request or response. For session initiation scenarios that result in SIP 486 Busy Here responses from the terminating Messaging Server, a feature tag cannot be included by the terminating network. However, depending on Service Provider Policy, a Message Revoke request may be generated (for the case where a first message is included in the SIP INVITE request). In that case, this MessageRevoke request might be blocked on the NNI if not supported by the terminating network (see section 3.3.5.3).
类似于第3.3.4.1.10.1.1节，只有在SIP INVITE请求的Contact头中，或者在对该意图被撤销的消息所属于的会话的SIP INVITE请求的响应中，指示了对MessageRevoke请求的支持，才应该生成MessageRevoke请求。具体地，该指示的格式是SIP INVITE请求或响应的联系报头中的特征标签的形式。对于终止消息服务器的导致SIP 486 Busy Here响应的会话启动场景，终端网络不能包括功能标记。然而，根据服务提供商策略，可以生成消息撤销请求（对于第一消息被包括在SIP INVITE请求中的情况）。在这种情况下，如果终端网络不支持，则可能在NNI上阻止此MessageRevoke请求（请参见第3.3.5.3节）。

The format of the MessageRevoke request generated by the Messaging Server is the same as described for the MessageRevoke requests by the Client in section 3.3.4.1.10.1.1.
消息服务器生成的MessageRevoke请求的格式与客户端在第3.3.4.1.10.1.1节中针对MessageRevoke请求所述的格式相同。

3.3.4.1.10.2 Handling MessageRevoke Requests / 处理MessageRevoke请求

For a network, handling of MessageRevoke requests goes along with having the functionality to generate MessageRevoke requests (either by the client or by the Messaging Server) and vice versa.
对于网络，处理MessageRevoke请求的同时具有生成MessageRevoke请求的功能（由客户端或消息服务器生成），反之亦然。

The MessageRevokeResponse request shall indicate the result of the MessageRevoke request that can be either successful or failed. Similarly to the MessageRevoke request, the MessageRevokeResponse request include an Accept-Contact header field with either the CPM ICSI for Session Mode Messaging, or the OMA SIMPLE IM feature tag (depending on the value of the CHAT MESSAGING TECHNOLOGY configuration parameter defined in Table 75), as it is already the case for IMDNs carried in SIP MESSAGE requests, and shall add a dedicated Accept-Contact header field carrying the Message Revoke feature tag defined in section 3.3.4.1.10.3 without the require and explicit parameters. The Messaging Server handling the MessageRevoke request shall also include the message revocation content-type including the value of the imdn.message-ID of the original message that was requested to be revoked, and the revoke result parameter as described in section 3.3.4.1.10.4. The MessageRevokeResponse request shall include the device identifier (GRUU or sip.instance feature tag) as specified in section 2.11.2 based on the device identifier included upon chat session establishment. The Request-URI of the MessageRevokeResponse request shall be set to the address of the contact that sent the message that is requested to be revoked.
MessageRevokeResponse请求应该指示MessageRevoke请求的结果，它可以是成功的或失败的。类似于MessageRevoke请求，MessageRevokeResponse请求包括具有用于会话模式消息的CPM ICSI或OMA SIMPLE IM特征标签（取决于表75中定义的CHAT消息传送技术配置参数的值）的Accept-Contact报头字段，，因为在SIP MESSAGE请求中携带的IMDN已经是这种情况，并且应该添加一个专用的Accept-Contact首部字段，该字段携带第3.3.4.1.10.3节中定义的消息撤销功能标记，不带require和explicit参数。处理MessageRevoke请求的消息服务器还应包括消息撤销内容类型，包括请求撤消的原始消息的imdn.message-ID的值，以及撤销结果参数，如第3.3.4.1.10.4节所述。 MessageRevokeResponse请求应包括根据聊天会话建立时包含的设备标识符在2.11.2节中指定的设备标识符（GRUU或sip.instance feature tag）。 MessageRevokeResponse请求的Request-URI应设置为发送请求撤消的消息的联系人的地址。

The MessageRevokeResponse request shall be indicated as successful when the message to be revoked is removed from the deferred storage and will therefore not be delivered to the client.
当要从撤销的存储中删除要撤消的消息并且因此不会将其传递到客户端时，MessageRevokeResponse请求将被指示为成功。

The MessageRevokeResponse request shall be indicated as failed when any of the following conditions is met:
当满足以下任何条件时，MessageRevokeResponse请求将被指示为失败：

Interworking towards SMS/MMS has occurred at originating or terminating side
与SMS/MMS的互通已经在发起端或接收端发生
A successful delivery notification for which the MessageRevoke request has been generated has been received by the originating or terminating Messaging Server;
一个关于MessageRevoke请求已生成的成功的传递通知已由发起或接收消息传递服务器接收;
Message revocation is not performed successfully by the terminating Messaging Server (e.g., due to Messaging Server failures);
消息撤销未由终止消息服务器成功执行（例如，由于消息服务器故障）;
The message that the intended MessageRevoke request has been generated for is stored at the terminating side in the Common Message Store.
已经为其生成了预期的MessageRevoke请求的消息存储在公共消息存储中的接收侧。

MessageRevoke requests shall never be forwarded to the client and shall be processed right after being received by the Messaging Server.
MessageRevoke请求永远不会转发到客户端，并且应在消息服务器接收到之后立即处理。

3.3.4.1.10.3 Message Revoke feature tag / 消息撤消功能标记

RCS defines a Message Revoke feature tag to indicate support of the message revocation feature. The RCS Client and originating Messaging Server shall make use of the message revocation feature only when the terminating Messaging Server has indicated its support through the Message Revoke feature tag. It can be used to indicate support for revoking of any message identified with a CPIM Message-ID. However, this release of RCS only allows it for chat messages.
RCS定义消息撤消特征标签以指示对消息撤销特征的支持。 RCS客户端和始发消息服务器将仅在终止消息服务器通过消息撤消特征标签指示其支持时使用消息撤销功能。它可以用于指示支持撤消用CPIM消息ID标识的任何消息。然而，这个版本的RCS只允许它聊天消息。

The feature tag is set in the Contact header of the SIP INVITE request or response used to set up a 1-to-1 chat session and it is always attached by the Messaging Server that supports Message revocation feature. The client shall only include this feature tag in the MessageRevoke request.
在用于建立1对1聊天会话的SIP INVITE请求或响应的联系人报头中设置功能标记，并且它始终由支持消息撤消功能的消息传递服务器附加。客户端只应在MessageRevoke请求中包含此功能标记。

The feature tag is defined as +g.gsma.rcs.msgrevoke.
特征标记定义为+g.gsma.rcs.msgrevoke。

3.3.4.1.10.4 Message Revoke content-type / 消息撤消内容类型

The Message Revoke XML schema is defined as shown on Table 30.
消息撤消XML模式的定义如表30所示。

The associated MIME content type is application/vnd.gsma.rcsrevoke+xml.
相关的MIME内容类型是application/vnd.gsma.rcsrevoke+xml。

This content type used in both the MessageRevoke request and in the MessageRevokeResponse request.
此内容类型在MessageRevoke请求和MessageRevokeResponse请求中使用。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:gsma:params:xml:ns:rcs:rcs:rcsrevoke" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:gsma:params:xml:ns:rcs:rcs:rcsrevoke" elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="imRevoke">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Message-ID" >
          <xs:simpleType>
            <xs:restriction base="xs:token"/>
          </xs:simpleType>
        </xs:element>
        <xs:element name="result" minOccurs="0" maxOccurs="1">
          <xs:simpleType>
            <xs:restriction base="xs:string">
              <xs:enumeration value="success"/>
              <xs:enumeration value="failure"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
        <xs:element name="From">
          <xs:simpleType>
            <xs:restriction base="xs:anyURI"/>
          </xs:simpleType>
        </xs:element>
        <xs:element name="To">
          <xs:simpleType>
            <xs:restriction base="xs:anyURI"/>
          </xs:simpleType>
        </xs:element>
        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Table 30: RCS Revoke and RevokeResponse message body schema / 表30：RCS修改和撤消响应消息体模式

The following is an example of the body of a SIP MESSAGE requesting that a specific chat message be revoked. In order to know whether the revoke was successful or not, the MessageRevoke request sender checks the result field in incoming MessageRevokeResponse requests.
以下是请求撤消特定聊天消息的SIP MESSAGE主体的示例。为了知道撤消是否成功，MessageRevoke请求发送器检查传入的MessageRevokeResponse请求中的结果字段。

Example of a MessageRevoke request:
MessageRevoke请求的示例：

Content-type: application/vnd.gsma.rcsrevoke+xml
Content-length: ...

<?xml version="1.0" encoding="UTF-8"?>
<imRevoke xmlns="urn:gsma:params:xml:ns:rcs:rcs:rcsrevoke">
<Message-ID>23499fuq34fu</Message-ID>
<From>tel:+1234578901</From>
<To>tel:+1234578902</To>
</imRevoke>

NOTE: The Message-ID, "23499fuq34fu", in the XML body refers to the CPIM Message-ID of the message to be revoked.
注意：XML主体中的消息ID“23499fuq34fu”是指要撤销的消息的CPIM消息ID。

Example of a MessageRevokeResponse request where the revoke succeeded. If it had failed, the value of result would be “failed”:
撤销成功的MessageRevokeResponse请求示例。如果它失败，result的值将是“failed”：

Content-type: application/vnd.gsma.rcsrevoke+xml
Content-length: ...

<?xml version="1.0" encoding="UTF-8"?>
<imRevoke xmlns="urn:gsma:params:xml:ns:rcs:rcs:rcsrevoke">
<Message-ID>23499fuq34fu</Message-ID>
<result>success</result>
<From>tel:+1234578901</From>
<To>tel:+1234578902</To>
</imRevoke>

NOTE: The Message-ID, "23499fuq34fu", in the XML body refers to the CPIM Message-ID of the message that was revoked.
注意：XML主体中的消息ID“23499fuq34fu”指的是已撤销的消息的CPIM消息ID。

3.3.4.1.11 1-to-1 Chat Service Identification / 1对1聊天服务标识

The RCS client shall populate the P-Preferred-Service header field in all CPM and SIMPLE IM requests with the CPM Feature tag defined for the service, as described in [RCS-CPM- CONVFUNC-ENDORS]. The S-CSCF or AS that performs the service assertion in the originating network shall add the P-Asserted-Service header field set to the value of the asserted CPM service ICSI (i.e. “urn:urn-7:3gpp-service.ims.icsi.oma.cpm.session” for CPM chat, or “urn:urn-7:3gpp-service.ims.icsi.oma.cpm.deferred” for deferred delivery done as part of the Store and forward realization) and remove the P-Preferred-Service header field before further routing the request.
如[RCS-CPM-CONVFUNC-ENDORS]中所述，RCS客户端将使用为该服务定义的CPM特征标记来填充所有CPM和SIMPLE IM请求中的P-Preferred-Service报头字段。在始发网络中执行服务断言的S-CSCF或AS将添加P-Asserted-Service头域，并设置其值为断言的CPM服务的ICSI值（即用于CPM聊天的“urn:urn-7:3gpp-service.ims.icsi.oma.cpm.session”，或者用于作为存储和转发实现的一部分的延迟交付的“urn:urn-7:3gpp-service.ims.icsi.oma.cpm.deferred”），并删除 P-Preferred-Service报头字段，然后进一步路由请求。

NOTE: During a transition period towards full compliance, the network support for asserting the service is recommended but not mandatory.
注意：在向完整兼容性过渡的时期，对服务断言的网络支持是推荐但非强制性的。

A receiving network element and RCS client should ignore any SIP header fields that they do not understand (e.g. P-Preferred-Service, or P-Asserted-Service header fields).
接收网络元件和RCS客户端应该忽略他们不理解的任何SIP报头字段（例如，P-Preferred-Service或P-Asserted-Service报头字段）。

3.3.4.2 Technical Realisation of 1-to-1 Chat features when using OMA SIMPLE IM / 使用OMA SIMPLE IM时的1对1聊天功能的技术实现

At the technical level, the 1-to-1 Chat service implemented using OMA SIMPLE IM extends the concepts described in section 3.3.4.1 with the following concepts:
在技术层面上，使用OMA SIMPLE IM实现的1对1聊天服务扩展了第3.3.4.1节中描述的概念，具有以下概念：

For OMA SIMPLE IM, first message is always included in a CPIM/IMDN wrapper carried in the SIP INVITE request. A client should always include “positive-delivery” in the value for the Disposition-Notification header field in that message. That means that the value of the header field is either “positive-delivery” or “positive- delivery,display” depending on whether display notifications were requested. The value of “negative-delivery” is not used in RCS for 1-to-1 Chat. SIP INVITE requests for a one-to-one session that carry a message in CPIM/IMDN wrapper shall be rejected by the server unless they carry a Disposition-Notification header that at least includes “positive-delivery”.
对于OMA SIMPLE IM，第一个消息总是包含在SIP INVITE请求中携带的CPIM/IMDN包装中。客户端应始终在该消息中的Disposition-Notification头字段的值中包括“positive-delivery”。这意味着，根据是否请求显示通知，头字段的值是“positive-delivery”或“positive-delivery,display”。 RCS中的“1对1聊天”不使用“negative-delivery”的值。在CPIM/IMDN包装器中携带消息的一对一会话的SIP INVITE请求将被服务器拒绝，除非它们携带至少包括“positive-delivery”的Disposition-Notification报头。
If auto-accept is not used, then the devices each send a SIP 180 response toward A.
如果不使用auto-accept，则设备各自向A发送SIP 180响应。
The received Chat session invitation contains an IMDN requesting 'delivery' notification. So each receiving device sends back a SIP MESSAGE request containing the IMDN indicating successful delivery of the original message sent by A.
收到的聊天会话邀请包含请求“delivery”通知的IMDN。因此，每个接收设备发送回一个SIP MESSAGE请求，其包含指示由A发送的原始消息的成功传递的IMDN。
The receiving clients each send a 486 BUSY HERE response to the outstanding INVITE when a new INVITE arrives from the same user so that there is not more than one outstanding INVITE from one user. The IMDN for 'delivery' notification is requested and sent in the same way as described above.
当新的INVITE从同一用户到达时，接收客户端各自发送486 BUSY HERE对未完成的INVITE的响应，使得来自一个用户的不超过一个未完成的INVITE。用于“delivery”通知的IMDN以与上述相同的方式被请求和发送。
No support for exchanging multimedia content within a chat. Therefore, in the SDP of the SIP INVITE request and response, the a=accept-wrapped-types attribute shall only include text/plain and message/imdn+xml. If File Transfer using HTTP is supported (see section 3.5.4.8) then the a=accept-wrapped-types attribute shall also include application/vnd.gsma.rcs-ft-http+xml. If Geolocation PUSH is supported (see section 3.10.4.1.2), then the a=accept-wrapped-types attribute shall also include application/vnd.gsma.rcspushlocation+xml. To transfer multimedia content during a chat, File Transfer is used.
不支持在聊天中交换多媒体内容。因此，在SIP INVITE请求和响应的SDP中，a=accept-wrapped-types属性将只包括text/plain和message/imdn+xml。如果支持使用HTTP的文件传输（见第3.5.4.8节），那么a=accept-wrapped-types属性还应包括application/vnd.gsma.rcs-ft-http+xml。如果支持Geolocation PUSH（见3.10.4.1.2节），那么a=accept-wrapped-types属性也应该包括application/vnd.gsma.rcspushlocation+xml。要在聊天期间传输多媒体内容，请使用文件传输。
When one of User B's devices detects user activity relevant to the consumption of the message contained in the invitation (e.g. click on a pop-up to go to the Chat window) a 1-to-1 chat session is established according to the following possible criteria:
当用户B的设备之一检测到与邀请中包含的消息的消费相关的用户活动时（例如，点击弹出窗口以进入聊天窗口），根据以下可能的标准，建立1对1聊天会话：
- a) The respective client returns a 200 OK response, signalling the initiation of the remaining procedures to establish the chat when User B reacts to the notification by opening the chat window. This is the default criteria for RCS and, consequently, all the diagrams shown in this document reflect this behaviour.
  a) 当用户B通过打开聊天窗口对通知做出反应时，相应的客户端返回200OK响应，用信号通知启动剩余过程以建立聊天。这是RCS的默认标准，因此，本文档中显示的所有图都反映了此行为。
- b) The 200 OK response is sent when User B starts to type a message, or
  b) 当用户B开始键入消息时，发送200 OK响应，或者
- c) The 200 OK response is sent when User B sends a message. Please note that in this case User B’s message will not generate an invite but is buffered in the client until the MSRP session is successfully established.
  c) 当用户B发送消息时，发送200 OK响应。请注意，在这种情况下，用户B的消息不会生成邀请，但缓冲在客户端中，直到成功建立MSRP会话。
- d) The 200 OK response is sent immediately since the devices receiving the invitation are configured to auto-accept the session invitations (IM SESSION AUTO ACCEPT configuration parameter defined in Table 75).
  d) 在接收邀请的设备被配置为自动接受会话邀请（表75中定义的IM SESSION AUTO ACCEPT配置参数）之后，会立即发送200 OK响应。
- Please note that:
  请注意：
  - The behaviour for criteria a), b) and c) is configured via the IM SESSION START parameter as defined in Table 75. The behaviour for criteria d) is configured via the IM SESSION AUTO ACCEPT configuration parameter defined in Table 75.
    通过表75中定义的IM SESSION START参数来配置标准a），b）和c）的行为。通过表75中定义的IM SESSION AUTO ACCEPT配置参数来配置标准d）的行为。
  - For a), b) and c), the 200 OK is sent if the chat invitation has not expired. Otherwise, User B's message shall be sent in a new invitation (from User B to User A).
    对于a），b）和c），如果聊天邀请尚未过期，则发送200OK。否则，用户B的消息将在新的邀请（从用户B到用户A）中发送。
- If the Chat session invitation from User A contained an IMDN Disposition-Notification header requesting a 'display' notification and if the privacy settings allow it, the device User B is using shall generate an MSRP SEND request toward User A that contains the IMDN 'display' status for the message received from User A.
  如果来自用户A的聊天会话邀请包含请求“display”通知的IMDN Disposition-Notification标题，并且如果隐私设置允许，则用户B正在使用的设备将向用户A生成包含用户A发出的信息中的IMDN 'display'状态的MSRP SEND请求。
- It may be the case that multiple Chat sessions from User A are pending on User B's side, that is the last received Chat session is established and the other pending sessions are answered with a 486 BUSY HERE response. In such cases, if the Chat session invitations from User A contained a IMDN Disposition-Notification header requesting a 'display' notification, the device of User B that accepted the SIP INVITE generates an MSRP SEND request toward User A that contains the IMDN 'display' status for each message received from User A.
  可能的情况是，来自用户A的多个聊天会话在用户B侧待决，即，最后接收的聊天会话被建立，并且其他待决会话由486 BUSY HERE响应来应答。在这种情况下，如果来自用户A的聊天会话邀请包含请求“display”通知的IMDN Disposition-Notification头部，则接受SIP INVITE的用户B的设备向用户A生成包含从用户A收到的每条消息的IMDN 'display'状态的MSRP SEND请求。
- NOTE: The statement in section 3.3.4.1 that the CPIM/IMDN wrapper shall be UTF-8 encoded to avoid any potential internationalization issues also applies to the IMDN requested in the SIP INVITE request.
  注：第3.3.4.1节中的CPIM/IMDN包装器应进行UTF-8编码，以避免任何潜在的国际化问题，这一声明也适用于SIP INVITE请求中请求的IMDN。
A Messaging Server supporting store and forward behaves as a back-to-back user agent handling the SIP INVITE requests that are used to establish the chat session. While doing this it may have to return a different response to the INVITE request on the originating leg than the one it received on the INVITE request on the terminating leg. The mappings shown in Table 31 will be applied:
支持存储和转发的消息传递服务器作为处理用于建立聊天会话的SIP INVITE请求的背对背用户代理。当这样做时，它可能必须返回对发起分支上的INVITE请求的不同响应，而不是在终止分支上的INVITE请求上接收的响应。将应用表31中所示的映射：

Response received on terminating leg	Response sent on originating leg	Store the message
480 Temporarily unavailable	200 OK	Y
408 Request Timeout	486 Busy Here	Y
487 Request Terminated	486 Busy Here	Y
500 Server Internal Error	486 Busy Here	Y
503 Service Unavailable	486 Busy Here	Y
504 Server Timeout	486 Busy Here	Y
600 Busy Everywhere	486 Busy Here	Y
603 Decline	486 Busy Here	Y
Any other response (including 404 Not Found and 200 OK)	Received response (that is no mapping is done)	N

Table 31: Mapping of received Error Responses by the Messaging Server / 表31：消息传递服务器收到的错误响应的映射

To reduce the complexity at protocol level and avoid potential TCP switchover(s), it is recommended to limit the maximum size of a chat message (see section 3.3.4.1.9) to avoid the SIP INVITE request to be longer than the path MTU (e.g., 1300 bytes) and, consequently, trigger the TCP switchover. The maximum size controlled through the MAX SIZE IM configuration parameter defined in Table 75 applies to both the first message in the INVITE and to messages sent via MSRP. If the user attempts to send a first or subsequent chat message larger than this limit (counting the size of the CPIM body only, that is CPIM headers are not included in the count), then the user shall be notified that the message is too large.
为了降低协议级别的复杂性并避免潜在的TCP切换，建议限制聊天消息的最大大小（请参阅第3.3.4.1.9节），以避免SIP INVITE请求长于路径MTU （例如，1300字节），并且因此触发TCP切换。通过表75中定义的MAX SIZE IM配置参数控制的最大大小适用于INVITE中的第一条消息和通过MSRP发送的消息。如果用户尝试发送大于此限制的第一或后续聊天消息（仅计数CPIM主体的大小，即，计数中不包括CPIM头），则应通知用户该消息太大。
In the first message in the INVITE, the client shall set both the CPIM From and CPIM To headers to sip:[email protected] to prevent revealing the user’s identity when transmitted over unprotected links. A client receiving a CPIM message in a one-to-one Chat should therefore ignore the identity indicated in the CPIM headers.
在INVITE中的第一个消息中，客户端应将CPIM From和CPIM To标头设置为sip:[email protected]，以防止在通过不受保护的链接传输时暴露用户身份。因此，在一对一聊天中接收CPIM消息的客户端应该忽略CPIM头部中指示的身份。

3.3.4.2.1 Clarifications on Chat race conditions / 澄清聊天条件

Two simultaneous invites. Though unlikely, it may be possible that two users decide to invite each other simultaneously for a chat. In this situation the behaviour of the clients should be the following:
两个同时邀请。虽然不太可能，但是两个用户可能决定同时邀请对方聊天。在这种情况下，客户端的行为应该是以下：
- User A sends an invite to User B for Chat
  用户A向用户B发送邀请以进行聊天
- Before a final response for that invite is received, User A receives an invite from User B for Chat
  在接收到针对该邀请的最终响应之前，用户A从用户B接收用于聊天的邀请
- User A will send a 486 BUSY HERE response to User B. In addition to this, User A will send the correspondent delivery and read notification using SIP MESSAGE.
  用户A将向用户B发送486 BUSY HERE响应。除此之外，用户A将使用SIP MESSAGE发送对应的传送和读取通知。
- From the UX point of view, the message sent by B will be displayed as received.
  从UX的角度看，B发送的消息将显示为已接收。
- User B will behave as user A, potentially resulting in both session invitations being turned down with a SIP 486 BUSY HERE response. Users will have to retry session setup until successful.
  用户B将与用户A表现相同，潜在地导致两个会话邀请通过SIP 486 BUSY HERE响应被拒绝。用户必须重试会话设置，直到成功。
New invite sent after a previous invite has been accepted. Though unlikely, the following scenario can take place:
在接受上一个邀请后发送的新邀请。虽然不太可能，可能会发生以下情况：
- User A sends an invite for chat to User B,
  用户A向用户B发送聊天邀请，
- User B accepts the chat a 200 OK response is sent back to User A,
  用户B接受聊天，将200 OK响应发送回用户A，
- In parallel and before receiving the 200 OK response, User A sends a new invite with a new message.
  在并行和接收到200 OK响应之前，用户A通过一个新的消息发送一个新的邀请。
To resolve the race condition:
为了解决竞争条件：
- When User B receives the new invitation, it should terminate the current MSRP session (if established) by sending a SIP BYE.
  当用户B收到新的邀请时，应该通过发送SIP BYE来终止当前MSRP会话（如果已建立）。
- Once the initial session is terminated, a new 200 OK response should be issued which will trigger the establishment of a new MSRP session.
  一旦初始会话终止，应当发出新的200 OK响应，其将触发新的MSRP会话的建立。

For additional clarification, explanatory diagrams have been included in Annex B, sections B.1.9 and B.1.10.
为了进一步澄清，附件B，B.1.9节和B.1.10节中包括了说明图。

3.3.4.3 Technical Realisation of 1-to-1 Chat features when using OMA CPM / 使用OMA CPM时的1对1聊天功能的技术实现

At a technical level the Chat service implemented using OMA CPM extends the concepts described in section 3.3.4.1 with the following concepts:
在技术层面，使用OMA CPM实现的聊天服务扩展了第3.3.4.1节中描述的概念，具有以下概念：

If auto-accept is not used, then the devices send a SIP 180 response toward A.
如果不使用自动接受，则设备向A发送SIP 180响应。
When users are allowed to have multiple devices and those devices are configured to auto-accept (IM SESSION AUTO ACCEPT set to 1, as defined in section A.1.4.3), the Messaging Server is required to be able to fork the incoming 1-to-1 Chat session request to each of the receiving user's devices to set up an MSRP session with each of them.
当允许用户拥有多个设备并且这些设备配置为自动接受（IM SESSION AUTO ACCEPT设置为1，如A.1.4.3节中定义）时，消息传递服务器需要能够将呼入的1对1的聊天会话请求分叉给对每个接收用户设备，以建立与它们中的每一个的MSRP会话。
The receiving clients (or their Participating Function on their behalf) each send a 486 BUSY HERE response to the outstanding INVITE request when a new INVITE request arrives from the same user so there is not more than one outstanding INVITE request from one user.
当来自相同用户的新的INVITE请求到达时，接收客户端（或它们行为所选择的参与功能）对每个未完成的INVITE请求发送486 BUSY HERE响应，因此，来自单一用户的未完成的INVITE请求将不超过一个。
Multimedia content within a Chat session is not permitted. Therefore, in the SDP of the SIP INVITE request and response, the a=accept-wrapped-types attribute shall only include text/plain and message/imdn+xml and if File Transfer using HTTP or Geolocation PUSH is supported (see sections 3.5.4.8 and 3.10.4.1.2) application/vnd.gsma.rcs-ft-http+xml and application/vnd.gsma.rcspushlocation+xml respectively, e.g., a=accept-wrapped-types:text/plain message/imdn+xml. To transfer multimedia content during a chat, File Transfer is used.
不允许聊天会话中的多媒体内容。因此，在SIP INVITE请求和响应的SDP中，a=accept-wrapped-types属性只应包括text/plain和message/imdn+xml，如果支持使用HTTP或Geolocation PUSH的文件传输（见第3.5.4.8和3.10.4.1.2节），则分别包括application/vnd.gsma.rcs-ft-http+xml和application/vnd.gsma.rcspushlocation+xml，例如a=accept-wrapped-types:text/plain message/imdn+xml。要在聊天期间传输多媒体内容，请使用文件传输。
When one of User B's devices detects user activity relevant to the consumption of Chat session invitation (e.g. click on a pop-up to go to the Chat window) a 1-to-1 chat session is established according to the following possible criteria:
当用户B的设备之一检测到与聊天会话邀请的消费相关的用户活动（例如，点击弹出窗口转去聊天窗口）时，根据以下可能的标准建立1对1聊天会话：
- a) The respective client returns a 200 OK response, signalling the initiation of the remaining procedures to establish the chat when User B reacts to the notification by opening the chat window. This is the default criteria for RCS and, consequently, all the diagrams shown in this document reflect this behaviour.
  a) 当用户B通过打开聊天窗口对通知做出反应时，相应的客户端返回200 OK响应，用信号通知启动剩余过程以建立聊天。这是RCS的默认标准，因此，本文档中显示的所有图都反映了此行为。
- b) The 200 OK response is sent when User B starts to type a message, or
  b) 当用户B开始键入消息时，发送200 OK响应，或者
- c) The 200 OK response is sent when User B sends a message. User B’s message is buffered in the client until the MSRP session is successfully established.
  c) 当用户B发送消息时，发送200 OK响应。用户B的消息缓存在客户端中，直到成功建立MSRP会话。
- d) The 200 OK response is sent immediately if the devices receiving the invitation are configured to auto-accept[28] the session invitations (IM SESSION AUTO ACCEPT configuration parameter defined in Table 75).
  d) 如果接收邀请的设备被配置为自动接受[28]会话邀请（表75中定义的IM SESSION AUTO ACCEPT配置参数），则立即发送200 OK响应。
- Please note that the behaviour for criteria a), b) and c) is configured via the IM SESSION START parameter as defined in Table 75. The behaviour for criteria d) is configured via the IM SESSION AUTO ACCEPT configuration parameter defined in Table 75.
  请注意，标准a），b）和c）的行为是通过表75中定义的IM SESSION START参数配置的。标准d）的行为通过表75中定义的IM SESSION AUTO ACCEPT配置参数配置。

NOTE: Unlike the realisation with OMA SIMPLE IM described in section 3.3.4.2, the realisation of the 1-to-1 Chat service based on OMA CPM does not allow to carry the first Chat message in the SIP INVITE request as per [RCS-CPM- CONVFUNC-ENDORS].
注意：与第3.3.4.2节中描述的OMA SIMPLE IM的实现不同，基于OMA CPM的1对1聊天服务的实现不允许在SIP INVITE请求中携带第一聊天消息，如[RCS-CPM-CONVFUNC-ENDORS]。

[28] Note that the Service Provider multidevice policy has to be consistent with Chat auto-acceptance policy.
[28] 请注意，服务提供商的多设备策略必须与聊天自动接受策略一致。

3.3.5 NNI and IOT considerations / NNI和IOT考虑

3.3.5.1 Chat session interworking when one side carries a message in the INVITE request / 当一端在INVITE请求中携带消息时的聊天会话互通

Interworking from a Chat session with a chat message in the INVITE request to a Chat session where the INVITE request does not carry any chat message requires that the Messaging Server (or a separate network entity) performing the interworking store the message in the INVITE until the Chat session without first message in INVITE is set up. If multiple Chat session INVITEs with chat messages arrive before the Chat session on the other side is set up, multiple chat messages are stored, however it is recommended that the Messaging Server automatically accept the session on behalf of a user in a network not supporting first message in the INVITE request. If no Chat session is set up on the other side, the chat messages are kept and delivery is attempted at a later time in the same way as already specified in section 3.3.4.1.4 when chat messages are stored on the originating side.
从聊天会话与INVITE请求中的聊天消息的交互到INVITE请求不携带任何聊天消息的聊天会话要求执行交互工作的消息收发服务器（或单独的网络实体）将该消息存储在INVITE中，直到设置了INVITE中没有第一条消息的聊天会话。如果具有聊天消息的多个聊天会话INVITE在另一侧的聊天会话建立之前到达，则存储多个聊天消息，然而建议消息服务器代表不支持第一的网络中的用户自动接受会话消息。如果在另一侧没有设置聊天会话，则聊天消息被保留，并且在聊天消息被存储在始发侧时，以与在第3.3.4.1.4节中已经指定的相同的方式尝试传送。

Interworking from a Chat session without first message in INVITE to a Chat session with a message in the INVITE requires that the Messaging Server accept the Chat session without any message on behalf of the recipient user and once the first chat message is received via MSRP, initiate an INVITE towards the recipient, including the first chat message as a CPIM body in the INVITE. Providing the recipient, or the recipient’s Messaging Server on behalf of the recipient, does not set up a session, the Messaging Server performing the interworking continues to generate INVITEs towards the recipient for each new chat message received.
从在INVITE中没有第一消息的聊天会话到具有INVITE中的消息的聊天会话的交互需要消息服务器代表接收用户接受聊天会话而没有任何消息，并且一旦经由MSRP接收到第一聊天消息，向接收者的INVITE，包括作为INVITE中的CPIM主体的第一聊天消息。提供接收者或代表接收者的接收者的消息传递服务器不建立会话，执行交互操作的消息传递服务器继续针对接收的每个新聊天消息向接收者生成INVITE。

See the flows in Annex B for more information.
有关更多信息，请参阅附件B中的流程。

3.3.5.2 SIMPLE IM session and CPM session interworking of feature tags / 特征标签的SIMPLE IM会话和CPM会话互配

The mapping of the appropriate SIMPLE IM session feature tags is done as per Appendix G in [RCS-CPM-CONVFUNC-ENDORS] when it is determined that the remote network requires such interworking. Also once a session is set up with the recipient, the Messaging Server or a separate network entity performing the interworking ensures that messages exchanged via MSRP are sent end to end.
当确定远程网络需要这样的互通时，根据[RCS-CPM-CONVFUNC-ENDORS]中的附录G来完成适当的SIMPLE IM会话特征标签的映射。此外，一旦与接收者建立会话，消息服务器或执行互配的单独的网络实体确保经由MSRP交换的消息被端对端地发送。

See the flows in Annex B for more information.
有关更多信息，请参阅附件B中的流程。

3.3.5.3 Interworking between a service provider that supports “Message Revocation” and a service provider that does not support / 支持“消息撤销”的服务提供商与不支持的服务提供商之间的互通

To prevent the MessageRevoke request being leaked to the service provider’s side that does not support message revocation, leading to unwanted user experience and possible undesired charging implication, the service provider that implements the message revocation shall make sure that the MessageRevoke requests are only sent to the service providers that also implement the message revocation when interworking.
为了防止MessageRevoke请求泄漏到不支持消息撤销的服务提供商端，导致不想要的用户体验和可能的不希望的计费含义，实现消息撤销的服务提供商应确保互通时MessageRevoke请求仅被发送到也实现了消息撤销的服务提供商。

3.3.6 Implementation guidelines and examples / 实施指南和示例

Please note that where the specification describes the user interface, it should be taken as guidance.
请注意，在规范描述用户界面的地方，应该将其作为指导。

3.3.6.1 General / 综述

End to end flows for store and forward 1-to-1 chat with notifications can be found in Annex B.
用于存储和转发与通知的1对1聊天的端到端流可在附件B中找到。

The following sections show the relevant chat message flows and reference user experience. Please note that the following assumptions have been made:
以下部分显示相关聊天消息流和参考用户体验。请注意，已做出以下假设：

For simplicity, the internal mobile network interactions are omitted in the diagrams shown in the following sections.
为了简单起见，在以下部分中所示的图中省略了内部移动网络交互。
Each Service Provider may deploy a Messaging Server (that is the use of a Messaging Server is optional in RCS deployments), to manage all messages from its customers.
每个服务提供商可以部署消息传递服务器（即在RCS部署中使用消息传递服务器是可选的），以管理来自其客户的所有消息。
Prior to the chat, the user will have accessed their address book or Chat application to start the communication. As described previously, while these actions are performed an OPTIONS or Presence request is sent to verify the available capabilities. In the following diagrams it is assumed that this exchange (OPTIONS/Presence request and response) has already taken place, and therefore, both ends are aware of the capabilities and the available RCS services of the other side. If that is not the case, the OPTIONS (or Presence) request should be sent at the same time the chat is being set up.
在聊天之前，用户将已经访问他们的地址簿或聊天应用以开始通信。如前所述，当执行这些动作时，发送OPTIONS或Presence请求以验证可用能力。在下面的图中，假设这个交换（OPTIONS / Presence请求和响应）已经发生，因此，两端都知道另一方的能力和可用的RCS服务。如果不是这样，则应该在设置聊天的同时发送OPTIONS（或者在线状态）请求。

Service Provider support of the store and forward functionality is optional in RCS. To allow a Service Provider to provide store and forward functionality to its customers even in cases where the Chat session is established towards a user of a Service Provider that does not support store and forward, the messages can optionally be stored and forwarded from the sender’s Messaging Server, based on operator's policy.
服务提供商对存储和转发功能的支持在RCS中是可选的。为了允许服务提供商向其客户提供存储和转发功能，即使在向不支持存储和转发的服务提供商的用户建立聊天会话的情况下，基于运营商的策略，消息也可以可选地从发送者的消息服务器被存储和转发。

3.3.6.2 Entry points to the chat service / 聊天服务的入口点

From the UX perspective there are three possible entry points to this service:
从UX角度来看，有三个可能的切入点：

Address book/Call-log: Chat can be initiated to any RCS contact with Chat capability as described in section 2.6.
地址簿/呼叫记录：可以向任何具有聊天功能的RCS联系人发起聊天，如第2.6节所述。

Figure 26: Reference UX for accessing chat from address book/call-log / 图26：用于从通讯录/呼叫日志访问聊天的参考UX
Chat application: There should be a dedicated Chat application entry point in the device menu, task oriented initiation. This application will provide access to the chat history and gives the possibility to start a new chat.
聊天应用：在设备菜单中应该有一个专用的聊天应用入口点，面向任务的启动。此应用程序将提供对聊天记录的访问权限，并提供开始新聊天的可能性。

Figure 27: Reference UX for starting a chat from the Chat application / 图27：用于从聊天应用程序开始聊天的参考UX
Once the Chat application is opened, the user is presented with the complete list of RCS contacts with Chat capability. Whether or not contacts which are currently not registered are shown depends on the Chat store and forward policy (see IM CAP ALWAYS ON in Table 75) chosen by the Service Provider.
一旦聊天应用程序打开，向用户呈现具有聊天功能的RCS联系人的完整列表。是否显示当前未注册的联系人取决于由服务提供商选择的聊天存储和转发策略（参见表75中的IM CAP ALWAYS ON）。
In addition to the “start a new chat” functionality, the Chat application allows the user to browse the Chat History, both 1-to-1 and Group Chat sessions:
除了“开始新的聊天”功能之外，聊天应用程序允许用户浏览聊天记录，包括1对1和群聊会话：

Figure 28: Reference UX for starting chat from the Chat application history / 图28：从聊天应用程序历史记录开始聊天的参考UX
In this case, when the chat is started the last messages exchanged with that contact (or group of contacts) are shown even though the conversation might have been from another device. In the chat history, the user can also browse through chat sessions that he has selected for permanent storage (if the Common Message Store feature is available for the user) and start a conversation from those. The context of the past chat is not relayed to the other party/parties.
在这种情况下，当开始聊天时，即使会话可能来自另一设备，也显示与该联系人（或联系人组）交换的最后消息。在聊天历史中，用户还可以浏览他为了永久存储而选择的聊天会话（如果公共消息存储特征对用户可用），并从那里开始会话。过去聊天的上下文不被中继到其他方/各方。
File Transfer (receiver): When transferring a file and with the aim of establishing a communication context for the transfer (the receiver may want to know for instance why the sender is sharing that file), after the transfer has been accepted the file transfer is presented to the receiver as a chat UX with a file being transferred.
文件传输（接收者）：当传输文件并且为了建立传输的通信上下文（接收者可能想知道例如发送者为什么共享该文件）的目的，在传输被接受之后，文件传输作为与正被传送的文件的聊天UX被呈现给接收者。
NOTE: At the time the File Transfer request is presented, the chat session is not started; the chat session will only start when/if the receiver sends a chat message back to the sender.
注意：在显示文件传输请求时，聊天会话不会启动; 聊天会话将仅在/如果接收者向发送者发送聊天消息时开始。

Figure 29: Reference UX for File Transfer on the receiver side / 图29：接收方文件传输的参考UX

From the UX point of view the requirements are summarised below:
从UX的角度来看，要求总结如下：

The user shall not be aware of the solution which is being used to transfer the file both at originator and terminating side.
用户不应知道用于在始发端和终端端传输文件的解决方案。
- Sender: There is no difference from a UX point of view between an accepted transfer and the upload to the HTTP content server. A progress bar is shown to track the progress.
  发件人：从接受的传输和上传到HTTP内容服务器之间的UX角度没有区别。将显示一个进度条以跟踪进度。
- Recipient: There is also no difference from a UX point of view in terms that the accept button is shown and if pressed the file is either downloaded from the sender (accepting the SIP INVITE) or from the content server (via HTTP/HTTPS)
  收件人：从UX的角度来看，当接受按钮显示和按下后，文件从发件人（接受SIP INVITE）或从内容服务器（通过HTTP / HTTPS）下载也是没有区别的。
The only addition to the experience is the delivery notification that shall show the user when the file has been received by the other party (not stored in a middle-man server). In terms of UI, it is recommended to reuse the approach that is already in place for chat notifications so the UX is consistent among services.
这种体验的唯一补充是交付通知，当文件已被另一方接收（不存储在中间人服务器中）时，交付通知应显示用户。在UI方面，建议重用已经用于聊天通知的方法，以便UX在服务之间保持一致。

Please refer to section 3.5 which covers the RCS File Transfer service in detail.
请参阅详细介绍RCS文件传输服务的第3.5节。

3.3.6.3 Initiating a chat / 发起聊天

RCS User A initiates a chat by selecting one of his contacts User B from the address book, contact list or Chat application in one of his devices.
RCS用户A通过从他的一个设备的通讯录，联系人列表或聊天应用程序中选择他的一个联系人用户B来发起聊天。

The device of User A determines whether User B is available to use the Chat service at that time, using one of the methods in section 2.6.
用户A的设备使用第2.6节中的方法之一来确定用户B是否可用于使用聊天服务。

If User B is not available and there is no Chat store and forward Server on User A's side nor on User B's side, or no chat interworking to SMS/MMS, or if an answer to the query is not received in less than a time lapse (left to OEM User Experience criteria), then the contact is shown as ‘Not available for a Chat session’, and the SMS/MMS service or CPM Standalone Messaging service could be offered as a messaging option. Once the availability of the chat service is ensured end-to-end and User A performs the appropriate UI actions on the device, a message composer and an empty chat window are opened.
如果用户B不可用，并且在用户A侧上或在用户B侧上没有聊天存储和转发服务器，或者没有与SMS / MMS的聊天互通，或者如果在小于时间间隔内未接收到对查询的回答（离开OEM用户体验标准），则联系人显示为“不可用于聊天会话”，并且SMS / MMS服务或CPM独立消息服务可以作为消息传递选项提供。一旦确保聊天服务的可用性是端到端的，并且用户A在设备上执行适当的UI动作，则打开消息编辑器和空闲聊天窗口。

When User A types the first message and presses the “Send” button, device A will initiate a Chat session invitation toward B (for the multidevice scenario see multidevice handling in section 3.3.4.1.7).
当用户A键入第一消息并按下“发送”按钮时，设备A将向B发起聊天会话邀请（对于多设备情形，参见第3.3.4.1.7节中的多设备处理）。

The one or more devices of User B receiving a Chat session invitation, may either all be configured to auto-accept the invitation, or the devices may wait for user action before accepting the invitation. If a spam filter or a black list is implemented on any one of User B’s receiving devices and User A is in the black list, the invitation is terminated following the procedure described in section 3.3.4.1.1.
用户B接收聊天会话邀请的一个或多个设备可以或者全部被配置为自动接受邀请，或者设备可以在接受邀请之前等待用户动作。如果在用户B的任何一个接收设备上实现垃圾邮件过滤器或黑名单，并且用户A在黑名单中，则按照第3.3.4.1.1节中描述的过程终止邀请。

On the User B side, a notification (UI dependent) is displayed on each receiving device to inform the user about the incoming message. The user is able to read the message and go to the chat window to answer the message on the device of his choice.
在用户B侧，在每个接收设备上显示通知（UI依赖）以通知用户关于传入消息。用户能够读取消息并转到聊天窗口以在他选择的设备上回答消息。

User A can type additional messages before the chat is answered, that is before the Chat session is established. On User B's side, a notification may be displayed for each received message (UI dependent). The sender’s device may buffer the messages if the device is configured to wait for a Chat session to be set up before sending messages.
用户A可以在聊天被应答之前，即在建立聊天会话之前键入附加消息。在用户B的一侧，可以为每个接收的消息显示通知（取决于UI）。如果设备被配置为在发送消息之前等待聊天会话被建立，则发送者的设备可以缓冲消息。

3.3.6.4 Answering a chat / 回答聊天

There may or may not be an explicit acceptance of the user to answer a chat.
可以明确或不明确接受用户回答聊天。

3.3.6.5 Messages exchanged in an established chat / 在已建立的聊天中交换的消息

Providing a Chat session is established, messages are exchanged between User A and User B. A delivery notification is requested for each message and a display notification is optionally requested.
当提供聊天会话被建立，消息将在用户A和用户B之间被交换。此时针对每个消息将请求递送通知，并且请求显示通知是可选的。

The recommendation is to show the information received in the delivery and display notifications only within the Chat window without the need for a pop-up or information message when the user is outside of the Chat application.
建议只在聊天窗口内显示传送和显示通知时收到的信息，而用户在聊天应用程序之外时不需要弹出或信息消息。

3.3.6.6 Message display and message store / 消息显示和消息存储

All messages are stored in the participating devices, together with a time indication and an appropriate indication of the sender and the receiver of each message. This time indication shall be obtained from the CPIM DateTime header for received messages. Since according to section 3.3.4.1 these values should be set by the Messaging Server, this allows for a correct time based indication for those messages without depending on the device’s own clock which may not have been set correctly. For sent messages however the only clock available at transmission time is the device’s own clock.
所有消息与每个消息的发送者和接收者的时间指示和适当指示一起存储在参与设备中。此时间指示应从接收到的消息的CPIM DateTime头中获取。因为根据第3.3.4.1节，这些值应该由消息传递服务器设置，这允许对这些消息的正确的基于时间的指示，而不取决于设备自己的时钟，可能没有被正确地设置。然而，对于发送的消息，在传输时间可用的唯一时钟是设备自己的时钟。

However, it is Messaging Server responsibility to deliver messages in the correct order, so the RCS Client is able to rely on the reception order to interleave the incoming and outgoing messages. Please note that the shown message time at the UX should be based on the network time (i.e. the CPIM DateTime header, when available) in order to correctly display the time of store and forwarded messages.
但是，消息服务器负责以正确的顺序传递消息，因此RCS客户端能够依赖接收顺序交织传入和传出的消息。请注意，UX上显示的消息时间应基于网络时间（即CPIM DateTime头，如果可用），以便正确显示存储和转发消息的时间。

When a Common Message Store is available for the user, the messages are synchronised with the Message Store Server as specified in section 4.1.
当公共消息存储可用于用户时，消息将与消息存储服务器同步，如第4.1节中所述。

When the storage limit is reached, deletion might occur on a first in/first out (FIFO) queue policy. It is open to OEM criteria how to implement other opt-in deletion mechanisms (e.g., ask always, delete always, delete any conversation/message from specific contacts, etc.).
达到存储限制时，可能会在先进先出（FIFO）队列策略中进行删除。它对OEM标准如何实现其他选择删除机制（例如，总是询问，总是删除，从特定联系人删除任何对话/消息等）是开放的。

3.3.6.7 Leaving the chat composing window / 离开聊天撰写窗口

Once a 1-to-1 chat is established any of the two users can leave the composing window without closing the chat. For example, a user could move to his mobile home screen to check an incoming email, or make a phone call.
一旦建立1对1聊天，两个用户中的任何一个可以离开撰写窗口而不关闭聊天。例如，用户可以移动到他的移动主屏幕以检查传入的电子邮件或打电话。

While the chat composing window is not shown (i.e. it is not the foreground window) any incoming message belonging to that chat will trigger a status notification (UI dependent) so the user is aware of the new message and may return to the chat composing window to answer it.
虽然没有示出聊天撰写窗口（即，它不是前台窗口），但属于该聊天的任何传入消息将触发状态通知（取决于UI），因此用户知道新消息并且可以返回聊天撰写窗口回答。

Also, the user could decide to return to the chat composing window and send a new message without receiving one. The user would be able to achieve this via the Chat application, which will display the ongoing chats, or via the address book by clicking on the contact with whom he is involved in the chat session.
此外，用户可以决定返回聊天撰写窗口并发送新消息而不接收一个消息。用户将能够通过聊天应用来实现这一点，其将显示正在进行的聊天，或者通过地址簿点击与他参与聊天会话的联系人。

In both cases, when the user returns to the chat composing window, all the messages are displayed.
在这两种情况下，当用户返回聊天撰写窗口时，将显示所有消息。

3.3.6.8 ‘IsComposing’ notification / 'IsComposing'通知

When a user starts typing in the chat composition window and privacy settings allow it, an ‘IsComposing’ notification is sent to the other user. That user’s UI will then display an indication in the chat composing window to indicate it (UI dependent).
当用户开始在聊天撰写窗口中键入并且隐私设置允许它时，向其他用户发送“IsComposing”通知。该用户的UI然后将在聊天组合窗口中显示指示以指示它（取决于UI）。

The recommendation is to show the information received in the ‘IsComposing’ notification only within the Chat window without the need for a pop-up or information message when the user is outside of the Chat application.
建议只在聊天窗口中显示“IsComposing”通知中收到的信息，而用户在聊天应用程序之外时不需要弹出或信息消息。

The ‘IsComposing’ indication is removed from the UI when a new message is received, when a timeout occurs without receiving a new message, or when a new ‘IsComposing’ notification arrives.
当接收到新消息时，当发生超时而没有接收到新消息时，或当新的“IsComposing”通知到达时，从UI中移除“IsComposing”指示。

3.3.6.9 Closing a chat/Re-opening a chat / 关闭聊天/重新打开聊天

Any of the two users can close the Chat session. This can be achieved from the chat composing window or from the Chat application.
这两个用户中的任何一个都可以关闭聊天会话。这可以从聊天组合窗口或从聊天应用程序实现。

The user should be able to re-open the chat. However, the resulting action at protocol level would depend on whether the Chat session is still open or not.
用户应该能够重新打开聊天。然而，在协议级的结果动作将取决于聊天会话是否仍然打开。

Closing the Chat session may not be notified to the remote user in the chat. At protocol level, the session is terminated. Therefore, if the remote user sends a message, a process similar to the initiation of a Chat session is performed as described in 3.3.6.3.
关闭聊天会话可能不会在聊天中通知远程用户。在协议级别，会话终止。因此，如果远程用户发送消息，则如3.3.6.3中所述执行类似于聊天会话的发起的处理。

3.3.6.10 Re-Opening an older chat / 重新打开旧聊天

An old chat conversation can be re-opened. From the user perspective, it is the same procedure as for initiating a chat (see section 3.3.6.3), except that when a message is sent, a new Chat session is established.
可以重新打开一个旧的聊天对话。从用户的角度来看，它与启动聊天的过程相同（参见第3.3.6.3节），但发送消息时，会建立一个新的聊天会话。

The device will then display the previously stored conversations with that contact preceding the current active one. If any displayed notifications still need to be generated, they are sent towards the original message sender.
然后，设备将在当前活动的会话之前显示先前存储的与该联系人的会话。如果仍然需要生成任何显示的通知，则将它们发送到原始消息发送者。

3.3.6.11 User experience regarding notifications when several store and forward messages arrive in a short period of time / 关于在短时间内几个存储和转发消息到达时的通知的用户体验

If a user has several chat messages waiting in storage in the Messaging Server to be delivered, the UX may be impacted if many Chat message notifications appear at the sender’s device when the messages are delivered to the receiver after the receiving user gets registered again.
如果用户有几个聊天消息在消息传递服务器中存储中待传递，则如果在接收用户再次注册之后当消息被传递到接收者时，许多聊天消息通知出现在发送者的设备上，则UX可能受影响。

To avoid this situation and, specifically, when receiving stored and forwarded messages, the suggested experience follows:
为了避免这种情况，具体来说，当接收存储和转发的邮件时，建议的体验如下：

Only the delivery and/or display of the first message is shown in a notification to the sending user. The remaining store and forward messages are delivered but they do not cause a notification to be shown to the message sender.
在向发送用户的通知中仅示出第一消息的递送和/或显示。剩余的存储和转发消息被传递，但它们不会导致向消息发送者显示通知。
If messages from several sending users are received, only one message notification per user containing the first delivered message per sender is shown to the recipient user.
如果接收到来自几个发送用户的消息，则向接收用户仅显示每个用户包含每个发送者的第一个递送消息的一个消息通知。

As mentioned previously this is a suggested guide and not mandated behaviour.
如前所述，这是一个建议的指南，而不是强制行为。

NOTE: The described behaviour refers to notifications shown on screen to the message recipient and does not affect the behaviour with regard to the sending of delivery notifications. Those are still sent for all received messages for which such a notification was requested.
注意：所述行为是指屏幕上向消息收件人显示的通知，并且不会影响发送传递通知的行为。对于请求了这样的通知的所有接收的消息，仍然发送这些消息。