3.4 Group Chat / 群聊
3.4.1 Feature description / 功能描述
The Group Chat service enables users to exchange messages between many users instantly.
群聊服务使用户能够即时在多个用户之间交换消息。
The following RCS features are described:
描述了以下RCS功能：
- Interworking of participants in a Group Chat to SMS/MMS
将群聊中的参与者互通到SMS / MMS
This feature requires a Messaging Server to interwork the messages for participants without an RCS device to and from SMS or MMS.
此功能需要消息服务器将没有RCS设备的参与者的消息互通到SMS和MMS。 - "Delivered" message disposition
“已传递”消息处置
This allows the sender of a message to be notified when a message has been delivered to the recipient. These can be delivered inside and outside of the group chat.
这允许当消息被递送到接收者时通知消息的发送者。 这些可以在群聊内部和外部交付。 - "Displayed" message disposition
“已显示”消息处置
This allows the sender of a message to be notified when a message has been displayed on one of the recipient’s devices.
这允许在消息已经在接收者的设备之一上显示时通知消息的发送者。NOTE: 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). These can be delivered inside and outside of the group chat.
注意：此通知无法证明收件人实际上已阅读邮件。 它只能指示消息已显示在收件人的终端用户界面（UI）上。 这些可以在群聊内部和外部交付。 - IsComposing indications
IsComposing指示
This allows a user in a Group 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 Group Chat requests. Users are allowed to qualify undesired incoming Group Chat requests 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 Group Chat but also to Chat and to File Transfer.
终端/客户端可以支持本地存储的黑名单来处理传入的组聊天请求。 用户可以将不需要的来电群聊请求归类为垃圾邮件。 这防止来自那些发起者的后续消息被显示或甚至被通知给用户。 此外，这个不期望的业务将不被确认已经被读取。 黑名单行为不仅适用于群聊，还适用于聊天和文件传输。 - 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 synchronize the 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 synchronization with the Message Store Server.
在设备中，预期在本地对话历史记录和与消息存储服务器同步之间进行对齐。 - User Alias (Display Name)
用户别名（显示名称）
A user defined display name can be sent when initiating a communication with another user.
可以在启动与另一个用户的通信时发送用户定义的显示名称。 - Long lived Group Chat
长时间群聊
Once a user initiates a RCS Group Chat, any remaining participant shall be able to restart it, even if the Group Chat had been torn down by the Messaging Server because of inactivity.
一旦用户启动RCS群聊，任何剩余的参与者都将能够重新启动它，即使群聊由于不活动已被邮件服务器拆除。 - Store and Forward feature
存储和转发功能
Messages missed because a participant has not yet joined the Group Chat or who was offline when the Group Chat started are stored and delivered when the participant becomes available or joins.
由于参与者尚未加入群聊，或者当群聊开始时处于离线状态，因此在参与者可用或加入时存储和传递错过的消息。 - Closed Group Chat
封闭的群聊
A user initiating a Group Chat or Messaging Server can specify that a Group Chat shall be closed, meaning that no one is permitted to add participants to the Group Chat.
发起群聊或消息服务器的用户可以指定群聊应被关闭，意味着没有人被允许将参与者添加到群聊。 - Leaving a Group Chat
离开群聊
For a Closed Group Chat, a user who explicitly leaves cannot rejoin.
对于已关闭的组聊天，显式离开的用户无法重新加入。
For a regular Group Chat, once that Group Chat terminates because of inactivity, a participant who explicitly left cannot rejoin or restart unless he is added by another participant, since that user is no longer on the latest participant list. If the Group Chat session is still ongoing, the user may rejoin even after he explicitly left.
对于常规群聊，一旦群聊由于不活动而终止，则除非由另一个参与者添加，否则显式离开的参与者不能重新加入或重新启动，因为该用户不再在最近的参与者列表上。 如果群聊会话仍在进行，则即使在他明确离开后，用户也可以重新加入。
A Group Chat can only be initiated by a user belonging to a Service Provider which has deployed a Messaging Server.
群聊只能由属于已部署消息传递服务器的服务提供商的用户启动。
A Service Provider may disable the whole Group Chat functionality via the GROUP CHAT AUTH configuration parameter (see Table 75 in Annex A). In case Group Chat is disabled, the client shall not be able to either initiate or participate in a group chat session and reject any group chat session invitation that it receives.
服务提供商可以通过GROUP CHAT AUTH配置参数禁用整个群聊功能（参见附录A中的表75）。 在禁用群聊的情况下，客户端不能启动或参与群聊会话，并拒绝其接收的任何群聊会话邀请。
A Closed Group Chat can be set up meaning no new participants may be added. If a Group Chat is closed, the Messaging Server indicates to all group participants that it is closed. A Service Provider may offer the choice to the user, or may only offer either one type of Group Chat or the other.
可以设置关闭的组聊天，意味着不可以添加新的参与者。 如果组聊天关闭，则消息服务器向所有组参与者指示它已关闭。 服务提供商可以向用户提供选择，或者可以仅提供一种类型的群组聊天或另一种类型。
Once a participant explicitly leaves a Closed Group Chat by sending a SIP BYE request, it is not possible to rejoin since by definition it is not possible to add participants to a Closed Group Chat.
一旦参与者通过发送SIP BYE请求显式地离开封闭群组聊天，则不可能重新加入，因为根据定义，不可能将参与者添加到封闭群组聊天。
There is one type of Store and Forward for Group Chat. The Store and Forward feature, where messages are stored for a participant if he joins late, or never joins the group chat while it is ongoing, as well as if that participant has connectivity problems.
有一种类型的存储和转发群聊。 存储和转发功能，如果参加者加入迟到，或在参加者正在进行时从不加入群聊，以及如果该参与者具有连接问题，则为参加者存储消息。
The Store and Forward feature for Group Chat is only available for a participant when his Service Provider deploys a Messaging Server.
群聊的存储和转发功能仅在参与者的服务提供商部署邮件服务器时可用。
Stored messages are delivered to the participant as follows:
存储的邮件将按如下方式发送给与会者：
- When the user sends a request to rejoin the Group Chat. The Messaging Server will deliver the stored messages whether or not the Group Chat is still ongoing.
当用户发送请求重新加入群聊时。 消息服务器将传送存储的消息，无论群聊是否仍在进行。 - When the user accepts an invitation to join a Group Chat for which there are stored messages.
当用户接受加入已存储消息的群聊的邀请时。NOTE: If the user rejects a Group Chat invitation, all stored messages for that Group Chat are deleted.
注意：如果用户拒绝群聊聊天邀请，则该群聊的所有存储的邮件都将被删除。 - Once the Group Chat is over or inactive and the Messaging Server knows the user is registered in IMS, or once the Messaging Server Participating Function receives an indication that the user has registered in IMS, the Messaging Server sends an invitation to the participant to deliver the Group Chat messages. If this invitation is not answered then further delivery attempts will be made based on local Service Provider policy. If none of the delivery attempts succeeds and the messages are not delivered, they will expire after an amount of time configured by the Service Provider. If the user rejects the invitation, all stored messages for that Group Chat are deleted.
一旦群聊已结束或不活动，并且消息收发服务器知道用户在IMS中注册，或者一旦消息收发服务器参与功能接收到用户已在IMS中注册的指示，则消息服务器向参与者发送邀请以递送 群聊消息。 如果未回答此邀请，则将根据本地服务提供商政策进行进一步递送尝试。 如果没有传递尝试成功，并且消息未传递，则它们将在由服务提供商配置的时间量后过期。 如果用户拒绝邀请，则删除该群聊的所有存储的消息。
3.4.2 Interaction with other RCS features / 与其他RCS功能的交互
Interaction of Group Chat with other RCS features is described in section 3.3.2.
群聊与其他RCS功能的交互在3.3.2节中描述。
If the user wishes to transfer a file to Group Chat participants, this can be done using the procedure in section 3.5.4.2 when supported by the conference focus or in section 3.5.4.8. Otherwise the user’s device must do this by sending the file one by one to each Group Chat participant, and it may or may not appear in the Group Chat window.
如果用户希望将文件传输到群聊参与者，当会议焦点或第3.5.4.8节支持时，可以使用第3.5.4.2节中的过程完成。 否则，用户的设备必须通过将文件逐个发送到每个组聊天参与者来执行此操作，并且它可以或不可以出现在组聊天窗口中。
3.4.3 High Level Requirements / 高级别要求
The following list of high level requirements applies to Group Chat:
以下高级别要求列表适用于群聊：
- Client devices:
客户端设备：
3-4-1 "Delivered" notification request and response
3-4-1 “已传递”通知请求和响应
3-4-2 "Displayed" notification request and response
3-4-2 “已显示”通知请求和响应
NOTE: The client device should allow the user to enable or disable the displayed notifications request and response.
注意：客户端设备应允许用户启用或禁用已显示的通知请求和响应。
3-4-3 Delivery of notifications (delivered and displayed) outside a session
3-4-3 在会话之外传送通知（已传送和已显示）
3-4-4 IsComposing indications
3-4-4 IsComposing指示
3-4-5 Procedures associated to the store and forward of both messages and notifications performed by the Messaging Server
3-4-5 与消息传递服务器执行的消息和通知的存储和转发相关联的过程
3-4-6 Ability to request a regular Group Chat or a closed Group Chat
3-4-6 能够请求常规群聊或封闭群聊
3-4-7 Ability to restart a Group Chat conversation that is idle
3-4-7 可以重新启动闲置的群聊聊天 - Messaging Server: In addition to the above requirements:
消息服务器：除了上述要求：
3-4-8 The Messaging Server may provide interworking of Group Chat to SMS/MMS
3-4-8 消息服务器可以提供群聊对SMS/MMS的互通
3-4-9 The Messaging Server shall provide store and forward of both messages and notifications
3-4-9 消息服务器应提供消息和通知的存储和转发
3-4-10 Store and forward is a function which is provided on the terminating MNO network.
3-4-10 存储和转发是在接收端MNO网络上提供的功能。
3-4-11 A Messaging Server hosting the conference focus shall be able to put the Group Chat in an idle state after a Service Provider’s defined inactivity period. When closing a Group Chat session because it is idle a Messaging Server hosting the conference focus shall store the session identity and the current participant list of the chat allowing participants to restart the conversation.
3-4-11 承载会议焦点的消息服务器应能够在服务提供者定义的不活动时段之后将群聊置于空闲状态。 当关闭群聊会话时，因为它是空闲的，承载会议焦点的消息服务器将存储会话身份和聊天的当前参与者列表，允许参与者重新开始会话。
3-4-12 The Messaging Server may provide the ability to set up a regular Group Chat or a closed Group Chat and shall indicate to all the participants whether the Group Chat is closed or not
3-4-12 消息服务器可以提供建立常规群聊或封闭群聊的能力，并且向所有参与者指示群聊是否被关闭
3-4-13 A Messaging Server hosting the conference focus shall allow any participant in the stored participant list to restart an idle Group Chat. The restarted Group Chat shall keep the same session identity and the same participant list.
3-4-13 承载会议焦点的消息服务器应允许存储的参与者列表中的任何参与者重新启动空闲的组聊天。 重新启动的群聊将保持相同的会话标识和相同的参与者列表。
3.4.4 Technical Realisation / 技术实现
Group Chat technical realisation is based on the “Ad-Hoc Session Mode messaging” as described in [RCS-SIMPLEIM-ENDORS] and in [RCS-CPM-CONVFUNC-ENDORS], (depending on the setting for CHAT MESSAGING TECHNOLOGY defined in Table 75 in Annex A).
群聊技术实现基于如在[RCS-SIMPLEIM-ENDORS]和[RCS-CPM-CONVFUNC-ENDORS]中描述的“Ad-Hoc会话模式消息传递”，（取决于附件A中的表75中定义的CHAT MESSAGING TECHNOLOGY的设置）。
Support for delivery and display notifications within a Group Chat is added to the functionality endorsed in [RCS-SIMPLEIM-ENDORS] and [RCS-CPM-CONVFUNC- ENDORS]. For OMA CPM, also the functionality to support sending “IsComposing” messages within a Group Chat is added.
在[RCS-SIMPLEIM-ENDORS]和[RCS-CPM-CONVFUNC-ENDORS]中所支持的功能中添加了对群聊中的传递和显示通知的支持。 对于OMA CPM，还添加了用于支持在群聊中发送“IsComposing”消息的功能。
The Closed Group Chat feature is provided by a Messaging Server, and all participants in such a Group Chat are made aware that it is closed.
闭合群聊功能由消息服务器提供，并且此群聊中的所有参与者都知道它已关闭。
The Store and Forward feature for Group Chat is provided by each Group Chat participant’s own Messaging Server.
群聊的存储和转发功能由每个群聊参与者自己的邮件服务器提供。
To prevent revealing the user identity when transmitted over unprotected links, the client should set the CPIM To header of a Message exchanged in a Group Chat to sip:[email protected]. For Delivery and Display notifications, it will be set as described in section 3.4.4.1.5. As the CPIM From header is needed to identify the sender of the message the user’s identity will be provided there and include the display name.
为了防止在通过不受保护的链接传输时暴露用户身份，客户端应将在群聊中交换的消息的CPIM To标头设置为sip:[email protected]。 对于传递和显示通知，将按照第3.4.4.1.5节中所述设置。 由于需要CPIM From头来识别消息的发送者，所以将在那里提供用户的身份，并且包括显示名称。
The originating Messaging Server shall always set the CPIM DateTime header in the chat messages it receives. The originating Messaging Server shall also set the CPIM DateTime header and IMDN DateTime element in notifications. In both cases, the Messaging Server shall overwrite any DateTime information provided by the client. A client receiving these requests should therefore rely on these headers containing the correct time rather than on locally available time information.
始发消息服务器应始终在其接收的聊天消息中设置CPIM日期时间标头。 原始消息服务器还应在通知中设置CPIM DateTime标头和IMDN DateTime元素。 在这两种情况下，消息服务器将覆盖客户端提供的任何DateTime信息。 因此，接收这些请求的客户端应该依赖于包含正确时间的这些头部，而不是本地可用时间信息。
To allow a user to rejoin or restart a Group Chat, the user’s client is required to know the actual focus Session Identity created by the Messaging Server when the Group Chat was initiated. The recommended approach is that any SIP proxy (e.g. Interworking Call Session Control Function [I-CSCF], P-CSCF, IMS-ALG, Session Border Controller [SBC], NAT) in the path between the Messaging Server and the client transparently forwards a received Contact header field from the network being sent towards the UE when the Contact header field contains the “isfocus” feature tag. This is as specified in sections 5.2.7.2, 5.2.7.3, 5.7.5.1 and 5.10.5, of [3GPP TS 24.229].
要允许用户重新加入或重新启动组聊天，用户的客户端需要知道在启动组聊天时由消息传递服务器创建的实际焦点会话标识。 推荐的方法是消息服务器和客户端之间的路径中的任何SIP代理（例如，互通呼叫会话控制功能[I-CSCF]，P-CSCF，IMS-ALG，会话边界控制器[SBC]，NAT） 当联系人报头字段包含“isfocus”特征标记时，从网络接收的联系人报头字段正向UE发送。 这是在[3GPP TS 24.229]的第5.2.7.2,5.2.7.3,5.7.5.1和5.10.5节中规定的。
In normal circumstances, for a given RCS Group Chat ID there is at most only a single session is active at a time for an RCS user. In the OMA CPM realisation, as detailed in [RCS-CPM-CONVFUNC-ENDORS], only one Group Chat is supported within a given CPM Conversation.
在正常情况下，对于给定的RCS群组聊天ID，RCS用户最多只有一个活动的会话。 在OMA CPM实现中，如在[RCS-CPM-CONVFUNC-ENDORS]中详细描述的，在给定的CPM会话内仅支持一个群聊。
3.4.4.1 Technical Realisation of Group Chat with Delivery and Display Notifications / 带有交付和显示通知的群聊的技术实现
3.4.4.1.1 Initiating a Group Chat / 启动群聊
User A initiates a chat by selecting some of his contacts (Users B, C and so on, up to a limit set by the OMA SIMPLE IM parameter MAX_AD-HOC_GROUP_SIZE – see Annex A) from the address book or from the Chat application in his device, or from the Contact List from the Broadband Access PC client. This choice may be offered only among the contacts known by his devices to be RCS users with Chat capability. It may be offered for all contacts if a Group Chat interworking service to SMS/MMS is available from the Service Provider (See configuration parameters IM CAP NON RCS GROUP CHAT, IM CAP NON RCS LIMIT GROUP CHAT and GROUP CHAT BREAKOUT ALLOWED PREFIXES, in Table 75 in Annex A).
用户A通过从地址簿或他的聊天应用程序中选择一些他的联系人（用户B，C等等，直到由OMA SIMPLE IM参数MAX_AD-HOC_GROUP_SIZE设置的限制 - 见附件A）来发起聊天 设备，或从宽带接入PC客户端的联系人列表。 该选择可以仅在他的设备已知的具有聊天能力的RCS用户的联系人中提供。 如果从服务提供商获得到SMS/MMS的群聊交互服务，则可以为所有联系人提供它（参见附件A表格75中的配置参数IM CAP NON RCS GROUP CHAT，IM CAP NON RCS LIMIT GROUP CHAT和GROUP CHAT BREAKOUT ALLOWED PREFIXES）。
If the IM CAP NON RCS GROUP CHAT is disabled, then the device recognises whether the Group Chat service is available for a particular contact by using the service capability exchange via Presence or OPTIONS as described in of section 2.6.
如果禁用IM CAP NON RCS GROUP CHAT，则设备通过使用通过在场或OPTIONS的服务能力交换来识别特定联系人的群聊服务是否可用，如第2.6节所述。
When initiating a Group Chat User A may first provide a subject for the conversation that will be provided to all invitees of the group chat. To provide a good user experience, it is recommended to provide it even to those that are invited later when the chat is ongoing. When User A presses the “Send” button, device A initiates a Chat session with the Messaging Server by sending a SIP INVITE request to the conference factory (carrying the subject in the Subject header if one was provided) with a new RCS Group Chat ID. The Messaging Server sends SIP INVITE requests to the other participant users indicated in a recipient-list body in the INVITE request received from User A. The list of invited participants is sent in the Group Chat invitation, and is also sent out to all invited participants.
当发起群聊时，用户A可以首先提供将被提供给群聊的所有被邀请者的对话的主题。 为了提供良好的用户体验，建议您在聊天正在进行时提供给稍后邀请的用户。 当用户A按下“发送”按钮时，设备A通过向会议工厂发送SIP INVITE请求（携带在主题报头中的主题（如果提供的话））与新的RCS群组聊天ID发起与消息服务器的聊天会话 。 消息服务器向在从用户A接收的INVITE请求中的接收者列表主体中指示的其他参与者发送SIP INVITE请求。在群聊邀请中发送被邀请的参与者的列表，并且还将其发送到所有被邀请的参与者 。
When a user’s client receives a Group Chat invitation from the Messaging Server, the user may accept or reject the invitation. Alternatively the user’s client may auto-accept[29] a Group Chat invitation, depending on a configuration parameter IM SESSION AUTO ACCEPT GROUP CHAT as defined in Annex A. A client on which Group Chat has been disabled via the GROUP CHAT AUTH configuration parameter (see section A.1.4.3) shall not notify the user and automatically reject any received SIP INVITE request for a Group Chat with a SIP 488 NOT ACCEPTABLE HERE response.
当用户的客户端从消息传送服务器接收到群聊邀请时，用户可以接受或拒绝邀请。 或者，用户的客户端可以自动接受[29]群聊邀请，这取决于附件A中定义的配置参数IM SESSION AUTO ACCEPT GROUP CHAT。已经通过GROUP CHAT AUTH配置参数（参见A.1.4.3节）禁用群聊的客户端不应通知用户，并自动拒绝任何接收到的SIP INVITE请求，用于与SIP 488 NOT ACCEPTABLE HERE响应的组聊天。
[29] Note that the Service Provider multidevice policy has to be consistent with the Group Chat auto-acceptance policy.
[29] 请注意，服务提供商多设备策略必须与群聊自动接受策略一致。
When at least one invited participant accepts the invitation, the 200 OK response is sent back to User A and the Group Chat is set up. At that moment, User A (or the user that accepted) can write a first message in the chat. Any messages sent to the focus during this start up phase before a final response is received from each invited participant are temporarily queued in the Messaging Server Controlling Function until there is a final response from all invited participants. Depending on each participant’s response:
当至少一个被邀请的参与者接受邀请时，200 OK响应被发送回用户A，并且建立群聊。 在那一刻，用户A（或接受的用户）可以在聊天中写第一消息。 在从每个被邀请的参与者接收到最终响应之前的这个启动阶段期间发送到焦点的任何消息在消息服务器控制功能中临时排队，直到存在来自所有被邀请的参与者的最终响应。 根据每个参与者的响应：
- A 200 OK is received, the focus will send all the messages temporarily queued; When all the final responses have been received, the focus will stop queuing messages.
接收到200 OK，焦点将发送所有临时排队的消息; 当接收到所有最终响应时，焦点将停止排队消息。
After acceptance, the client shall subscribe to the conference event package to retrieve the list and status of the users in the Group Chat.
接受后，客户端应订阅会议事件包，以检索群聊中用户的列表和状态。
User A’s device shall also subscribe to the conference event package. The SUBSCRIBE request shall be routed to the Messaging Server Participating Function to allow it to participate in the dialog. When the client receives the resulting SIP NOTIFY requests carrying the conference state information, the identity of each user shall be matched against the Contact List in the device to present a user friendly name. If a user is not found in the Contact List, the display name provided in the conference state, if any, for that user should be used. As a complement to [RCS-SIMPLEIM-ENDORS] and [RCS-CPM-CONVFUNC- ENDORS], the notifications pertaining to the conference event package should convey information about the pending participants (i.e. the “pending” state is used in the
用户A的设备还应订阅会议事件包。SUBSCRIBE请求将被路由到消息服务器参与功能，使其能够参加在对话框中。当客户端收到所得SIP NOTIFY携带会议状态信息的请求，每个用户的身份应针对联系人列表中的设备相匹配的呈现用户友好名称。如果在联系人列表中没有找到用户，显示名称在会议状态下提供，如果有的话，该用户应该使用。作为[RCS-SIMPLEIM-ENDORS]和[RCS-CPM-CONVFUNC- ENDORS]的补充，与会议事件包相关的通知应该传达有关未决参与者的信息（即“pending”状态在相应端点的
NOTE: To avoid sending notifications to participants twice in short succession, the conference focus shall briefly delay notifying the existing participants of the “pending” state of the newly added participant to allow for automatic acceptance of the Chat (e.g. because of Store and Forward as described in section 3.4.4.3). In that case the participant’s state will change to “active” almost immediately.
注意：为了避免短时间连续两次向参与者发送通知，会议焦点将暂时延迟通知现有参与者新加入的参与者的“pending”状态，以允许自动接受聊天（例如，由于3.4.4.3节所述的存储和转发）。 在这种情况下，参与者的状态几乎立即改变为“active”。
The Messaging Server will open sessions to Users A, B, C and so on, up to a configured limit which should be set to the same OMA SIMPLE IM parameter value configured in the clients, i.e. MAX_AD-HOC_GROUP_SIZE.
消息服务器将打开到用户A，B，C等的会话，直到配置的限制，该限制应该被设置为在客户端中配置的相同的OMA SIMPLE IM参数值，即MAX_AD-HOC_GROUP_SIZE。
In the user interfaces of the receivers’ client on which the GROUP CHAT AUTH configuration parameter is enabled (see section A.1.4.3), a notification (UI dependent) shall be displayed to inform the user about the incoming invitation. This notification should clearly state that it is an invitation to a Group Chat making the users aware of this fact and should take into account the IM SESSION AUTO ACCEPT GROUP CHAT configuration parameter defined in section A.1.4.3. This notification can also indicate the other users that were invited as well as the subject of the conversation if one was provided.
在启用GROUP CHAT AUTH配置参数的接收方客户端的用户界面（参见第A.1.4.3节）中，将显示通知（依赖于UI），以通知用户有关传入邀请。 此通知应清楚地说明它是对群聊的邀请，使用户意识到这一事实，并应考虑在A.1.4.3节中定义的IM SESSION AUTO ACCEPT GROUP CHAT配置参数。 此通知还可以指示被邀请的其他用户以及对话的主题（如果会话提供了主题）。
The supported content types in the SDP exchanged in the SIP INVITE request and the associated 200 OK response shall be indicated as follows:
在SIP INVITE请求和相关联的200 OK响应中交换的SDP中支持的内容类型应如下指示：
- In the SDP of the SIP INVITE request and response, the a=accept-types attribute shall include only message/cpim, i.e., “a=accept-types:message/cpim”.
在SIP INVITE请求和响应的SDP中，a=accept-types属性应仅包括message/cpim，即“a=accept-types:message/cpim”。 - 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, message/imdn+xml and application/im-iscomposing+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和application/im-iscomposing+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。 要在聊天期间传输多媒体内容，请使用文件传输。
NOTE: During session setup the client and the conference focus shall also take into account the procedures described in section 3.5.4.2 and when they support File Transfer via HTTP in the Group Chat also those in section 3.5.4.8.1. When they support Geolocation PUSH in the Group Chat they shall also take into account the procedures in section 3.10.4.1.2.
注意：在会话建立期间，客户端和会议焦点还应考虑3.5.4.2节中描述的过程，以及他们在群聊中支持通过HTTP进行文件传输的情况，以及3.5.4.8.1节。 当他们在群聊中支持地理位置推送时，他们还应考虑3.10.4.1.2节中的过程。
Once the Group Chat has been initiated, the focus Session Identity uniquely identifying that Group Chat may be kept by the original initiator’s Messaging Server Controlling Function either for an amount of time configurable by the Service Provider, or until the original initiator’s Messaging Server Controlling Function no longer authorises other users to restart this Group Chat (e.g. because of a Service Provider policy when the initiator explicitly left the chat). Depending upon service provider policies, this focus Session Identity can then be used by any of the participants in the Group Chat to restart it by simply attempting to rejoin the Group Chat as described in section 3.4.4.1.7.
一旦群聊被启动，唯一地标识群聊的焦点会话标识可以由原始发起者的消息收发服务器控制功能保持由服务提供商配置的时间量，或者直到原始发起者的消息服务器控制功能无 更长时间授权其他用户重新启动此群组聊天（例如，由于启动器显式离开聊天时的服务提供者策略）。 根据服务提供商策略，此聚焦会话标识可以由群聊中的任何参与者使用，通过简单地尝试重新加入群聊来重新启动它，如第3.4.4.1.7节所述。
3.4.4.1.2 Adding participants to a Group Chat / 将参与者添加到群聊
Once a Group Chat is established, the local Service Provider policy decides whether only the initiator is allowed to add participants to the Group Chat or whether any participant is allowed to add more participants. A Service Provider may choose to have a local policy that allows participants that are their own subscribers to add participants, but participants from other Service Providers would not be allowed.
一旦建立了群聊，本地服务提供商策略决定是否仅允许启动者向群聊中添加参与者，或者是否允许任何参与者添加更多参与者。 服务提供商可以选择具有允许作为其自己的订户的参与者添加参与者的本地策略，但是不允许来自其他服务提供商的参与者。
The maximum number of participants allowed and the current user count for a running group chat is notified by the focus in the maximum-user-count and user-count elements as defined in [RFC4575] when the client subscribes to the conference event package. Participants may be added provided the maximum-user-count is not reached or the focus’s Service Provider policy allows it. If these values are not present in the conference event package then that the MAX_AD-HOC_GROUP_SIZE configuration parameter may be used instead.
当客户端订阅会议事件包时，由[RFC4575]中定义的最大用户数和用户计数元素的焦点通知允许的参与者的最大数量和正在运行的组聊天的当前用户数。 如果未达到最大用户数或焦点的服务提供商策略允许，可以添加参与者。 如果这些值不存在于会议事件包中，那么可以改为使用MAX_AD-HOC_GROUP_SIZE配置参数。
Participants on the participant list can be added again (re-invited), provided that they are not in the active or pending state or have left the chat involuntarily. This way participants that have not accepted the INVITE request before it has timed out, or participants that left the chat voluntarily (see section 3.4.4.1.3.1) can be added again.
可以再次添加（重新邀请）参与者列表中的参与者，前提是他们不处于活动或待决状态或者不随意地离开聊天。 这样，在INVITE请求超时之前没有接受INVITE请求的参与者或者自愿离开聊天的参与者（见第3.4.4.1.3.1节）可以再次添加。
For a Closed Group Chat (see section 3.4.4.2), no one can add participants. If the Group Chat is a Closed Group Chat, the Messaging Server will return an error response to the SIP REFER request. If adding participants fails because of one of the reasons above, it is expected that the Messaging Server’s error response include a Warning header and appropriate explanatory text as per the [RCS-SIMPLEIM-ENDORS] or [RCS-CPM- CONVFUNC-ENDORS] (depending on the setting for CHAT MESSAGING TECHNOLOGY see Table 75 in Annex A).
对于封闭群聊（见第3.4.4.2节），没有人可以添加参与者。 如果群聊是封闭群聊，则邮件服务器将返回对SIP REFER请求的错误响应。 如果添加参与者由于上述原因之一而失败，则预期消息服务器的错误响应包括一个警告标题和依据[RCS-SIMPLEIM-ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]（取决于CHAT MESSAGING TECHNOLOGY的设置，见附件A中的表75）形成的正确的解释文本。
When adding participants, as a clarification to [RCS-SIMPLEIM-ENDORS] or [RCS-CPM-CONVFUNC-ENDORS] (depending on the setting for CHAT MESSAGING TECHNOLOGY see Table 75 in Annex A), the client shall :
当添加参与者时，作为[RCS-SIMPLEIM-ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]的澄清（取决于CHAT MESSAGING TECHNOLOGY的设置，见附件A中的表75），客户应：
- Include an RCS Group Chat ID in the REFER request set to the RCS Group Chat ID of the pertaining Group Chat,
在设置为RCS的REFER请求中包含RCS组聊天ID组相关组聊天的聊天ID， - Include a Subject header in the REFER request set to the pertaining Group Chat subject, if the pertaining Group Chat was created with a subject.
如果使用主题创建了相关的组聊天，请在对相关的组聊天主题设置的REFER请求中包含主题标题。
3.4.4.1.3 Closing Group Chat / 关闭群聊
A SIP/MSRP session established between one of the user’s devices and the network allowing a user to participate in a Group Chat will be closed for either one of the following reasons:
在用户的设备之一与允许用户参与群聊的网络之间建立的SIP/MSRP会话将由于以下原因之一而关闭：
- The user explicitly indicates that he’s not willing to take part in the Group Chat anymore (see section 3.4.4.1.3.1),
用户明确表示他不愿意参加群聊（见3.4.4.1.3.1节）， - An error condition occurs preventing a particular device from further maintaining an active session that allows a user to participate in a Group Chat (see section 3.4.4.1.3.2),
发生错误情况阻止特定设备进一步维持允许用户参与群聊的活动会话（参见第3.4.4.1.3.2节） - Based on local service provider policies, the Controlling Function no longer wishes to maintain the active sessions of an ongoing Group Chat and therefore, forces the closing of the remaining active sessions (see section 3.4.4.1.3.3).
基于本地服务提供商策略，控制功能不再希望保持正在进行的群组聊天的活动会话，因此强制关闭剩余的活动会话（参见第3.4.4.1.3.3节）。
3.4.4.1.3.1 Explicit Departure / 显式离开
Any of the participants can voluntarily leave the Chat. When leaving voluntarily, a conversation history will exist in the user’s device history with the messages associated with the chat up to the point the user left.
任何参与者都可以自愿离开聊天。 当自愿离开时，对话历史将存在于用户的设备历史中，具有与聊天相关联的消息直到用户离开的时间点。
When a participant indicates their desire to voluntarily leave the Group Chat session their device shall send a SIP BYE request that includes a Reason Header field (as defined in [RFC3326]) with the protocol set to SIP and the protocol-cause set to 200 (e.g. SIP;cause=200;text="Call completed"). In addition, the client shall unsubscribe from receiving the Chat participant information. When it receives a SIP BYE request the Controlling Function will convey with a new conference state event package notification to the remaining participants and in case of voluntary departure, remove the user from the participant list. In this new conference state event package notification the Controlling Function shall include additional elements and values defined in [RFC4575] to indicate why the participant is not taking part in the conversation any longer. If the participant left voluntarily (that is, the SIP BYE request included a Reason header field with the protocol set to SIP and the protocol-cause set to 200), the conference focus shall indicate the departed participant‘s status as “disconnected” and include a disconnection-method element the value of which shall be set to “departed”.
当参与者表示他们愿意自愿离开群聊会话时，他们的设备将发送SIP BYE请求，其包括具有设置为SIP的协议的原因报头字段（如[RFC3326]中定义的），并且协议原因被设置为200（例如：SIP;cause=200;text=“Call completed”）。此外，客户端应取消订阅接收聊天参与者信息。当它接收到SIP BYE请求时，控制功能将向剩余的参与者传达具有新的会议状态事件包通知，并且在自愿离开的情况下，将用户从参与者列表中移除。在这个新的会议状态事件包通知中，控制功能应包括在[RFC4575]中定义的附加元素和值，以指示参与者为什么不再参与会话。如果参与者自愿离开（即，SIP BYE请求包括原因报头字段，protocol设置为SIP并且protocol-cause设置为200），会议焦点将指示离开的参与者的状态为“disconnected”，并且包括disconnection-method元素，其值应被设置为“departed”。
When the chat is (re)started, any participant can also leave or decline the Group Chat by rejecting the Group Chat invitation with a 603 Decline response. When receiving a SIP 603 Decline response to a SIP INVITE request for a Group Chat, the Controlling Function will remove the participant that declined from the participant list and convey a new conference state event package notification to the remaining participants. In this new conference state event package notification, the controlling function shall set the departed participant’s status to “disconnected” and include the disconnection-method element set to a value of “failed” with a reason sub-element set to code 603 (e.g.
当聊天（重新）开始时，任何参与者还可以通过拒绝具有603拒绝响应的群聊聊天邀请来离开或拒绝群聊。 当接收到针对群聊的SIP INVITE请求的SIP 603拒绝响应时，控制功能将移除从参与者列表拒绝的参与者，并向剩余的参与者传达新的会议状态事件包通知。 在该新的会议状态事件包通知中，控制功能应将离开的参与者的状态设置为“disconnected”，并且将disconnection-method元素设置为值“failed”，reason子元素设置为代码603（例如，
NOTE: When the user explicitly leaves a regular Group Chat (i.e. as opposed to a Closed Group Chat as defined in section 3.4.4.2), their client may store the Group Chat’s IM Session identity for some time to offer the user the option to rejoin. If the user makes use of this option the device shall handle this according to the procedures described in [RCS-SIMPLEIM-ENDORS] or [RCS-CPM-CONVFUNC-ENDORS]. Once that Group Chat terminates because of inactivity, that participant who explicitly left cannot rejoin or restart unless he is added by another participant, since that user is no longer on the latest participant list. When an attempt to rejoin results in a SIP 404 Not Found response, the chat should be considered to be no longer active.
注意：当用户显式离开正常的群聊（即与第3.4.4.2节中定义的封闭群聊相反）时，他们的客户端可以存储群聊的IM会话身份一段时间，以向用户提供重新加入的选项 。 如果用户使用此选项，设备将根据[RCS-SIMPLEIM-ENDORS]或[RCS-CPM-CONVFUNC-ENDORS]中描述的过程处理此事件。 一旦群聊由于不活动而终止，则除非由另一个参与者添加，否则显式离开的参与者不能重新加入或重新启动，因为该用户不再在最近的参与者列表上。 当尝试重新加入会导致SIP 404“未找到”响应时，该聊天应被视为不再活动。
In case the user wants to leave a Group Chat at a time where the Group Chat is idle, the RCS client shall restart the Group Chat using the procedure in section 3.4.4.1.7 and shall send a SIP BYE request that includes a Reason Header field (as defined in [RFC3326]) with the protocol set to SIP and the protocol-cause set to 200 (e.g. SIP;cause=200;text="Call completed"). In this case, the client shall not subscribe for receiving the Group Chat participant information.
如果用户想要在群组聊天空闲时离开群组聊天，则RCS客户端将使用第3.4.4.1.7节中的过程重新启动群聊，并且将发送一个SIP BYE请求，该请求包含一个Reason头域（如[RFC3326]中定义），其protocol设置为SIP，protocol-cause设置为200（例如：SIP;cause=200;text=“Call completed”）。在这种情况下，客户端不应订阅接收群聊参与者信息。
When User C leaves the Group Chat voluntarily, the other users that have subscribed to the conference focus will be notified in the chat through a predefined indication “User C has left the conversation,” and their devices will remove him from the displayed participants.
当用户C自愿离开群组聊天时，将通过预定义的指示“用户C已离开对话”在聊天中通知订阅了会议聚焦的其他用户，并且他们的设备将从所显示的参与者中移除他。
An RCS client receiving a notification of a participant leaving the Group Chat voluntarily, either by closing (i.e. using a SIP BYE request that includes a Reason header field with the protocol set to SIP and the protocol-cause set to 200) or rejecting the Group Chat session invitation with a SIP 603 Decline response shall remove the participant from the locally stored participant list associated with the Group Chat.
当RCS客户端收到一个参与者自愿离开群聊的通知时，通过关闭（即，使用一个SIP BYE请求，该请求包含一个Reason头域，其protocol设置为SIP，protocol-cause设置为200），或通过一个SIP 603 Decline响应来丢弃群聊会话邀请，RCS客户端将从与群聊相关联的本地存储的参与者列表中移除该参与者。
A participant voluntarily leaving the Chat is removed from the Group Chat participant list used for restarting the chat as specified in section 3.4.4.1.7 by both the Controlling Function and the clients receiving a notification indicating this voluntary departure.
自愿离开聊天的参与者从控制功能和接收指示此自愿离开的通知的客户端的用于重新开始聊天的参与者列表中被移除，如3.4.4.1.7节所述。
A participant of a Group Chat for whom the service provider removes the IMS identity and profile should depart from the Group Chat. In absence of triggers from the Participating Function in this case, the Controlling Function shall implement the following procedure. If the Controlling Function re-starts a Group Chat as defined in section 3.4.4.1.7 and it receives a SIP 404 Not Found response to the INVITE sent to a participant, it shall remove the corresponding participant from the participant list. The clients of the other participants in the Group Chat are informed via the notification of conference events within their subscription to the conference event package.
服务提供商删除IMS身份和配置文件的群聊的参与者应离开群聊。 在这种情况下没有来自参与功能的触发，控制功能将实现以下过程。 如果控制功能重新启动第3.4.4.1.7节中定义的组聊天，并且它接收到发送到参与者的INVITE的SIP 404 Not Found响应，它将从参与者列表中删除相应的参与者。 在群聊中的其他参与者的客户端在他们对会议事件包的订阅中通过会议事件的通知来通知。
The elements of the removed participant's user endpoint in the conference event package shall be set as follows:
会议事件包中已删除的参与者用户端点的元素应设置如下：
- Status of the user endpoint element is set to "disconnected",
用户端点元素的状态设置为“disconnected”， - Disconnection-method of the user endpoint element is set to "departed".
用户端点元素的Disconnect-method设置为“departed”。
3.4.4.1.3.2 Involuntary departure / 非自愿离开
A user can also leave the session involuntarily (e.g. due to loss of connectivity or other error situations). In this case, if it is still capable of doing so, the client or otherwise, the network element detecting the error situation should generate a SIP BYE request that includes a Reason Header field with the protocol-cause set to a value other than 200 (i.e. the protocol- cause must not be the value used for voluntary departure in section 3.4.4.1.3.1). It is recommended to use a Reason header field with the protocol set to SIP and the protocol- cause set to 503 (e.g. SIP;cause=503;text=”Service Unavailable”) as was defined in [3GPP TS 24.229] for bearer loss detected by the P-CSCF also for other network elements.
用户也可以被动地离开会话（例如，由于连接丢失或其他错误情况）。 在这种情况下，如果它仍然能够这样做，客户端或其他，则检测错误情况的网络元件应当生成SIP BYE请求，其包括Reason报头字段，其中protocol-cause被设置为除了200之外的值（即protocol-cause不得是第3.4.4.1.3.1节中用于自愿离开的值）。 建议使用如在[3GPP TS 24.229]中定义的Reason报头字段，其中protocol设置为SIP，protocol-cause设置为503（例如，SIP;cause=503;text="Service Unavailable"），以便由P-CSCF检测到承载丢失，也用于其他网络元件。
When a SIP BYE request carrying a Reason header field with a protocol-cause other than 200 is received by the Participating Function, the Participating Function will not forward the SIP BYE to the Controlling Function. The disconnection is transparent to Controlling Function and the participants.
当参与功能接收到携带具有除了200之外的协议原因的Reason报头字段的SIP BYE请求时，参与功能将不将SIP BYE转发到控制功能。 断开对控制功能和参与者是透明的。
NOTE: As it cannot be guaranteed in general that all network elements detecting an error situation will include a Reason header field nor that there are no legacy clients connecting to the network that do not include a Reason header field, it is recommended that the Messaging Server allows for a Service Provider policy controlling whether a received SIP BYE request without Reason header field is handled as a voluntary or involuntary departure. If such a policy is not provided, it is left to implementation.
注意：由于通常不能保证所有检测到错误情况的网络元素都会包括Reason报头字段，也不能保证绝对没有那些连接到网络的旧客户端不包括Reason报头字段，因此建议消息服务器允许服务提供商策略控制是否将没有Reason报头字段的接收到的SIP BYE请求作为自愿或非自愿离开进行处理。 如果不提供这样的政策，就留待实施。
3.4.4.1.3.3 Closing of the Group Chat / 关闭群聊
The remaining sessions for a Group Chat are closed by the Controlling Function amongst others when in following cases:
在以下情况下，群聊的其余会话由控制功能关闭：
- Less than the minimum number of active participants as defined in the Messaging Server, for a Group Chat remain in the Group Chat, or
仍保留在群聊中的人数小于消息服务器中定义的活动参与者的最小数量，或者 - When a chat inactivity timeout expires, or
当聊天闲置超时过期时，或 - Based on local policy in the Messaging Server, e.g. if the originator leaves the Group Chat.
基于消息服务器中的本地策略，例如 如果发起方离开组聊天。
NOTE: The active participants are the ones in “connected” state or in the “pending” state (i.e. the ones from which a final response has not yet been received).
注意：活动参与者是处于“connected”状态或处于“pending”状态（即尚未从其接收到最终响应的状态）的参与者。
When closing these sessions, a conference focus shall keep the focus Session Identity and associated information (e.g. participant list) in following cases:
当关闭这些会话时，在以下情况下，会议焦点应保持焦点会话标识和相关信息（例如参与者列表）：
- Case 1 above, when there are users on the participant list that have left involuntarily (see section 3.4.4.1.3.2).
上述情况1，当参与者列表上的用户非主动离开时（见第3.4.4.1.3.2节）。 - Case 2 above.
上述情况2。
The conference focus shall maintain the information for at least one month.
会议重点应保持信息至少一个月。
NOTE: It is recommended that the Participating Function providing store and forward functionality for Group Chats as described in section 3.4.4.3 stores deferred Group Chat messages for at most one month to ensure that the original focus can be used should there be a need to restart the session as a consequence of the forwarding of the deferred messages.
注意：建议如第3.4.4.3节所述，为群聊提供存储和转发功能的参与功能存储延迟群聊消息至多一个月，以确保在需要重新启动会话时原始焦点可以使用，该会话是转发延迟消息的结果。
The Messaging Server shall keep the focus Session Identity. This allows any of the participants that still were in the Group Chat when the session was closed to send a rejoin request that will result in the Group Chat being restarted. In that case, the Messaging Server also keeps the type of Group Chat (e.g. Closed) and the list of participants that were present when the Group Chat was torn down, and uses that list to check who is authorised to restart the Group Chat, and then to invite those participants when it receives the rejoin request from an authorised participant as described in section 3.4.4.1.7. When the Session Identity is maintained in case 2 above or in case 1 above for the situation where some of the participants left the session involuntarily or didn’t explicitly accept or reject the invitation, the Controlling Function shall include a Reason header field with the protocol set to SIP and the protocol-cause set to 480 (e.g. SIP;cause=480;text=”Bearer unavailable”) in the SIP BYE request that it sends to the remaining participants. In other scenarios where the messaging server keeps the focus Session Identity, it shall include a Reason header field, but that may relay different values.
消息服务器应保持焦点会话标识。这允许在会话关闭时仍在群组聊天中的任何参与者发送重新加入请求，这将导致重新启动群聊。在这种情况下，消息服务器还保留群聊（例如，已关闭）的类型和群聊期间出现的参与者列表，并使用该列表检查谁被授权重新启动群聊，以及然后在收到来自授权参与者的重新加入请求时邀请这些参与者，如第3.4.4.1.7节所述。当在以上情况2或在情况1中情况2中保持会话标识，其中一些参与者非自愿地离开会话或没有明确接受或拒绝邀请的情况时，控制功能将包括具有协议的原因报头字段设置为SIP并且协议原因在其发送给剩余参与者的SIP BYE请求中被设置为480（例如，SIP;cause=480;text=“Bearer unavailable”）。在消息服务器保持焦点会话标识的其他情况下，它应包括原因报头字段，但是可以中继不同的值。
For other cases where the Messaging Server no longer keeps the focus Session Identity for the Group Chat, any future attempt by a user to join or restart the Group Chat identified by the focus Session Identity will fail. The Controlling Function shall indicate this by including a Reason header field with the protocol set to SIP and the protocol-cause set to 410 (e.g. SIP;cause=410;text=”Gone”) in the SIP BYE request that it sends to the remaining participants. A client receiving a SIP BYE request including a Reason header field with the protocol set to SIP and the protocol-cause set to 410 may take this into account when restarting the Group Chat (see section 3.4.4.1.7) and avoid sending a rejoin request to the focus Session Identity.
对于消息服务器不再保持群聊的焦点会话标识的其他情况，用户以后尝试加入或重新启动焦点会话标识所标识的群聊将会失败。 控制功能应该通过在SIP BYE请求中包括具有protocol设置为SIP和protocol-cause和被设置为410的Reason头域（例如，SIP;cause=410;text="Gone"）并发送给剩余参与者来指示该失败。 接收到包括具有protocol为SIP且protocol-cause为410的Reason头域的SIP BYE请求的客户端，可以在重新启动群聊（参见第3.4.4.1.7节）时考虑到这一点，并且避免给焦点会话标识发送重新加入请求。
Even if the focus indicated that it keeps the Session Identity and the participant list (i.e. the BYE request received by the clients included a Reason header with the protocol set to SIP and the protocol-cause set to a value different than 410), the clients participating in a Group Chat shall also keep the latest participant list. If a rejoin to an inactive Group Chat fails (e.g. because the Group Chat has been inactive for a very long time), the client can then restart the Group Chat as a new Group Chat using this latest participant list from the last Group Chat as described in section 3.4.4.1.7.
即使焦点指示它保持会话标识和参与者列表（即，由客户端接收的BYE请求包括protocol为SIP且protocol-cause为不同于410的值的Reason头域），参加群聊的客户端 也应保留最新的参加者名单。 如果重新加入到非活动群组聊天失败（例如，因为群聊已经非活动很长时间），则如3.4.4.1.7节所述，客户端然后可以使用来自上述群聊的最近参与者列表作为新的群聊重新开始群聊 。
To avoid that users are removed from an ongoing session, the idle time during a Group Chat should be monitored by the Controlling Function ensuring that the session is torn down for all users at the same time. Unlike the situation for a 1-to-1 Chat where the Participating Function may tear down the session also in normal circumstances, any idle session monitoring on the Participating Function, if provided, shall therefore use timeouts that are significantly larger than the timers used in the controlling function. To allow configuring these Participating Function timers for intervening in error situations (e.g. loss of connectivity between the Participating and the Controlling Function), the maximum allowed idle time on the Controlling Function shall not be larger than 300 sec (i.e. 5 min). Because they are not relayed to all Participating Functions involved in the Chat, the Controlling Function shall not take the messages relayed over MSRP for delivering disposition notifications into account when monitoring the idle time.
为了避免用户从正在进行的会话中被移除，群聊期间的空闲时间应由控制功能监控，确保同时为所有用户删除会话。不同于1对1聊天的情况，其中参与功能也可以在正常情况下拆除会话，所以参与功能上的任何空闲会话监视（如果提供的话）将因此使用超时，该超时显着大于在控制功能。为了允许配置这些参与功能定时器以用于插入错误情况（例如，参与和控制功能之间的连接性丧失），控制功能上的最大允许空闲时间不应大于300秒（即5分钟）。因为它们不被中继到聊天中涉及的所有参与功能，所以当监视空闲时间时，控制功能不会考虑通过MSRP中继以传送处置通知的消息。
NOTE: Whether to provide idle time monitoring of a Group Chat in the participating function for intervening in error situations is an implementation decision.
注意：是否在参与功能中为群聊提供空闲时间监视以便干预错误情况是一个实现决策。
3.4.4.1.4 Chat message size limitations / 聊天消息大小限制
This maximum size is controlled through the MAX SIZE IM configuration parameter defined in Table 75. Endpoints and the Messaging Server are expected to make use of the SDP attribute a=max-size to indicate the maximum message size to participants during session negotiation.
此最大字数通过表75中定义的MAX SIZE IM配置参数控制。端点和消息传递服务器应使用SDP属性a=max-size来指示在会话协商期间参与者的最大消息字数。
From the user experience perspective and assuming that the message size limitation is in enabled (i.e. the negotiated values are non-zero):
从用户体验的角度来看，假设消息大小限制已启用（即协商的值不为零）：
- For originated chat message the client shall not send the message bigger than the negotiated max-size value.
对于发起的聊天消息，客户端不应发送大于协商的最大大小值的消息。 - If the user attempts to send a message larger than the negotiated limit, the message is not sent, and the user should be informed that messages of that size cannot be sent in the Group Chat session.
如果用户尝试发送大于协商限制的消息，则不发送消息，并且应通知用户该组大小的消息不能在组聊天会话中发送。
3.4.4.1.5 Delivery and Display notifications within Group Chat / 群聊中的递送和显示通知
Each message sent within a Group Chat may request a delivery notification and may request a display notification, similar to the previously described 1-to-1 chat (see section 3.3.4.1).
在群聊中发送的每个消息可以请求传送通知，并且可以请求显示通知，类似于先前描述的1对1聊天（参见第3.3.4.1节）。
The recipient client generates the delivery or display notifications as described for 1-to-1 chat (see section 3.3.4.1), with the difference that the CPIM To header shall be set to the identity of the sender of the message, found in the CPIM From header of the incoming message, instead of to an anonymous URI. The identity to be used from the CPIM From header is the URI for the sender.
接收方客户端生成交付或显示通知，如1对1聊天中所述（参见第3.3.4.1节），区别在于CPIM To头应设置为消息发送方的身份，位于 CPIM From传入消息的头，而不是匿名URI。 从CPIM From头使用的标识是发送者的URI。
This requires that the Messaging Server support Private Messages within Group Chat.
这要求消息服务器支持群聊中的私人消息。
If there is no on-going Group Chat in which to send these notifications, they shall be sent using SIP MESSAGE.
如果没有正在进行的群聊以发送这些通知，则应使用SIP MESSAGE发送。
3.4.4.1.6 Interworking to SMS/MMS / 与SMS/MMS的互通
For a Group Chat the behaviour for interworking to SMS/MMS is similar to interworking of a 1-to-1 Chat described in section 3.3.4.1.6 with the same entities being involved. The only difference being that the decision to interwork may be taken by the Controlling Function of the Messaging Server based on the same criteria used by the Participating Function for the case of a 1-to-1 session (e.g., based upon error), or by the terminating Participating Function (e.g. based upon error or Service Provider policy). Furthermore, as described in [RCS-CPM-IW-ENDORS] and [RCS-3GPP-SMSIW-ENDORS], the IWF will subscribe to the participant information and use that information to inform the SMS or MMS user of who also is taking part in the Group Chat.
对于群聊，与SMS/MMS的互通的行为类似于在3.3.4.1.6中描述的1对1聊天的交互，涉及相同的实体。 唯一的区别是，交互决定可以由消息服务器的控制功能基于由参与功能针对1对1会话的情况（例如，基于错误）使用的相同标准来进行，或者 由终止参与功能（例如，基于错误或服务提供商策略）。 此外，如[RCS-CPM-IW-ENDORS]和[RCS-3GPP-SMSIW-ENDORS]中所描述的，IWF将订阅参与者信息，并且使用该信息来通知SMS或MMS用户谁也在参与在群聊中。
NOTE: Messages sent during any interval that a participant becomes unavailable or loses connectivity during the Group Chat will only be stored for that participant due to the Store and Forward feature being available for that participant. See section 3.4.4.3 for more information on the Group Chat Store and Forward feature.
注意：由于参与者的存储和转发功能可用，因此在参加者变为不可用或在群聊期间失去连接的任何间隔期间发送的消息将仅存储给该参与者。 有关组聊天存储和转发功能的更多信息，请参阅第3.4.4.3节。
3.4.4.1.7 Restarting a Group Chat / 重新启动群聊
When a Group Chat has been closed due to inactivity, it may be restarted at any time by any of the participants. A client shall not restart an already established Group Chat.
当群聊由于不活动而关闭时，可以由任何参与者随时重新启动。 客户端不应重新启动已经建立的群聊。
In order to restart a Group Chat, the RCS client shall try to rejoin using the focus Session Identity and same RCS Group Chat ID of the previous Group Chat session.
为了重新启动群聊，RCS客户端将尝试使用焦点会话标识和先前群聊会话的相同RCS群聊ID重新加入。
When the Messaging Server Controlling Function receives an incoming SIP INVITE request with a focus Session Identity for a Group Chat that is not in progress, it checks whether it still has the focus Session Identity along with the last participant list. If so, it checks whether the user is authorised to restart the Group Chat identified by the focus Session Identity in the SIP INVITE request, and if so, restarts the Group Chat using the associated participant list and as a Closed or regular Group Chat depending on the type it was before.
当消息服务器控制功能接收到具有用于不在进行的群聊的焦点会话标识的进入SIP INVITE请求时，它检查它是否仍然具有焦点会话标识以及最后的参与者列表。 如果是，则检查用户是否被授权重新启动由SIP INVITE请求中的焦点会话标识标识的群聊，如果是，则使用相关联的参与者列表重新开始群聊，以及作为关闭或常规群聊，取决于 它之前的类型。
The participant list shall include the active participants (i.e. the list shall also include the participants in the pending state).
参与者列表应包括活动参与者（即，列表还应包括处于待决状态的参与者）。
If the Messaging Server Controlling Function does not recognize the focus Session Identity, it shall return a SIP 404 error response. In this case, the RCS client shall initiate a new Group Chat as per section 3.4.4.1.1 re-using the same RCS Group Chat ID and with the latest participant list it has available for the Group Chat.
如果消息服务器控制功能不能识别焦点会话标识，它将返回SIP 404错误响应。 在这种情况下，RCS客户端将根据第3.4.4.1.1节重新使用相同的RCS群聊ID以及可用于群聊的最新参与者列表，发起新的群聊。
If the focus Session Identity is available but the user is not authorised to restart the Group Chat, the Messaging Server shall return a SIP 403 error response including a warning header set to “127 Service not authorized”. In this case, the RCS client shall initiate a new Group Chat as per section 3.4.4.1.1, using the last participant list it has stored to build the URI-list in the SIP INVITE request.
如果焦点会话标识可用，但用户没有授权重新启动群聊，则邮件服务器将返回SIP 403错误响应，其中包括设置为“127 Service not authorized”的警告标头。 在这种情况下，RCS客户端将使用其存储的最后一个参与者列表，在SIP INVITE请求中构建URI列表，根据第3.4.4.1.1节启动新的群聊。
NOTE1: No specific handling for Group Chat restarts is required for non-2xx SIP responses other than those mentioned in this section.
注1：除本节中提及的非2xx SIP响应外，不需要为组聊天重新启动的特定处理。
For clients re-invited to an existing Group Chat the following procedures apply:
对于重新邀请加入现有群聊的客户，适用以下过程：
- If the client receives a Group Chat invitation with an RCS Group Chat ID the client has left voluntarily or it has been closed before, it shall apply the procedure for a new Group Chat invitation as defined in section 3.4.4.1.1.
如果客户端接收到具有RCS组聊天ID的群聊邀请，客户端已自愿离开或之前已关闭，则它将应用第3.4.4.1.1节中定义的新的群聊邀请的过程。 - If a Group Chat invitation is received with the same RCS Group Chat ID of an already established Group Chat, the RCS device will auto accept the new Group Chat session.
如果接收到具有已经建立的群聊的相同RCS群聊聊ID的群聊邀请，则RCS设备将自动接受新的群聊会话。
3.4.4.1.7.1 Race conditions / 竞争条件
Since a Group Chat can be restarted by two participants simultaneously, race-conditions exist between rejoin requests coming from the client and SIP INVITE request originated by the Controlling Function. As the middle element, most of these situations will be detected by the Messaging Server Participating Function that shall handle these situations as follows:
由于群聊可以由两个参与者同时重新启动，所以在来自客户端的重新加入请求和由控制功能发起的SIP INVITE请求之间存在竞争条件。 作为中间元素，这些情况中的大多数将由将处理这些情况的消息服务器参与功能检测，如下：
For the case where the Messaging Server Participating Function receives an incoming SIP INVITE request from the client for a Group Chat for which a SIP INVITE request was already sent (matching shall be done based on the focus Session Identity or the RCS Group Chat ID) (i.e. the INVITE requests have crossed between the client and the Participating Function):
针对已经发送了SIP INVITE请求的群聊，对于消息服务器参与功能从客户端接收到该群聊的SIP INVITE请求的情况（将基于焦点会话标识或RCS群组聊天ID进行匹配）（ 即INVITE请求已经跨越了客户端和参与功能）：
a) If no session is established yet with the Controlling Function (see also section 3.4.4.3), the Messaging Server Participating Function shall forward this INVITE request from the client to the conference focus and handle the SIP INVITE request from the client as a regular B2BUA with this session setup to the Controlling Function.
a) 如果尚未使用控制功能（也参见第3.4.4.3节）建立会话，则消息服务器参与功能应将该INVITE请求从客户端转发到会议焦点，并将来自客户端的SIP INVITE请求作为常规B2BUA处理，并将此会话设置为控制功能。
b) Otherwise the Messaging Server Participating Function shall accept the SIP INVITE request from the client, establish the MSRP channel and forward any messages and notifications received from the client in the already established MSRP session with the Controlling Function.
b) 否则，消息服务器参与功能将接受来自客户端的SIP INVITE请求，建立MSRP信道并且在已经建立的与控制功能的MSRP会话中转发从客户端接收的任何消息和通知。Messages and notifications received from the Controlling Function shall only be forwarded in the MSRP channel to the client that was last to be established. Based on local policy, the Messaging Server Participating Function shall terminate the unused session by sending in the corresponding SIP dialog a SIP BYE request carrying a Reason header field with the protocol set to SIP and the protocol_cause set to 480 (e.g. SIP;cause=480;text=”bearer unavailable”).
从控制功能接收的消息和通知只能在MSRP信道中转发到最后建立的客户端。 基于本地策略，消息服务器参与功能将通过在相应的SIP对话中发送携带具有protocol为SIP且protocol_cause为480的Reason报头字段的SIP BYE请求来终止未使用的会话（例如，SIP;cause=480;text=“bearer unavailable”）。This means, that in all cases where such a race condition occurs temporarily, two sessions are established between the client and the Participating Function and only one between the Controlling Function and the Participating Function. Between the client and Participating Function only the MSRP session that was last to be established shall be used.
这意味着，在这种竞争条件临时发生的所有情况下，在客户端和参与功能之间建立两个会话，并且在控制功能和参与功能之间仅建立一个会话。 在客户端和参与功能之间，只使用最后要建立的MSRP会话。For the case where the Messaging Server Participating Function receives an incoming SIP INVITE request from the Controlling Function for a Group Chat for which a SIP INVITE request was already sent (matching shall be done based on the focus Session Identity or the RCS Group Chat ID) to the Controlling Function (i.e. the INVITE requests have crossed between the Controlling Function and the Participating Function), the Messaging Server Participating Function may either
对于消息服务器参与功能从已经发送了SIP INVITE请求的组聊天的控制功能接收到传入SIP INVITE请求的情况（将基于焦点会话标识或RCS组聊天ID进行匹配） 到控制功能（即INVITE请求在控制功能和参与功能之间交叉），消息服务器参与功能可以
a) Forward this INVITE request to the client, or
a) 将此INVITE请求转发给客户端，或
b) Accept both the session from the Controlling Function and the rejoin request from the client and link both dialogs as a B2BUA. In that case when the Controlling Function accepts the INVITE request, the Participating Function shall establish the MSRP session and only use the last MSRP channel to be established until either the Controlling Function closes one of the sessions, closes the entire chat or the user leaves the Chat. In the last case the Messaging Server Participating Function shall send the corresponding SIP BYE request in both sessions.
b) 接受来自控制功能的会话和来自客户端的重新加入请求，并将两个对话框链接为B2BUA。 在这种情况下，当控制功能接受INVITE请求时，参与功能将建立MSRP会话，并且仅使用最后建立的MSRP信道，直到控制功能关闭其中一个会话，关闭整个聊天或用户离开 聊天。 在最后一种情况下，消息服务器参与功能将在两个会话中发送相应的SIP BYE请求。
Also, the Controlling Function shall accept a rejoin request received from a participant for which there was an outstanding INVITE request. It shall ensure that only one session is used and that messages from the participant are not returned in the other session. To achieve this, it is recommended to only send messages in the last MSRP channel to be established. Once it has received messages or notifications over that connection it may close the other session by sending in the corresponding SIP dialog a SIP BYE request carrying a Reason header field with the protocol set to SIP and the protocol_cause set to 480 (e.g. SIP;cause=480;text=”bearer unavailable”).
此外，控制功能应接受从存在未完成的INVITE请求的参与者接收的重新加入请求。 它应确保仅使用一个会话，并且在其他会话中不返回来自参与者的消息。 为了实现这一点，建议仅在要建立的最后一个MSRP信道中发送消息。 一旦它通过该连接接收到消息或通知，它可以通过在相应的SIP对话中发送携带具有protocol为SIP且protocol_cause为480的Reason报头字段的SIP BYE请求来关闭另一会话（例如，SIP;cause=480;text=“bearer unavailable”）。
3.4.4.1.8 Multidevice handling and the Common Message Store / 多设备处理和公共消息存储
Multidevice handling occurs when a user has more than one device (e.g., PC and mobile). When a new Group Chat is initiated and an invited user, User B, has multiple devices registered at the same time, the Group Chat session request shall be forked to each device for that user by the terminating Messaging Server Participating Function. Forking at the Messaging Server is further described in 3.4.4.1.8.1.
当用户具有多于一个设备（例如，PC和移动设备）时，发生多设备处理。 当发起新的群聊并且被邀请的用户（用户B）具有在同一时间注册的多个设备时，群聊会话请求将由终止消息服务器参与功能分派给该用户的每个设备。 在3.4.4.1.8.1中进一步描述了在消息传递服务器上的分岔。
When a user wishes to restart a chat on a different device, it may not have the latest information on the Group Chat. In particular, it will not have the focus Session Identity for the Group Chat if it did not receive the initial SIP INVITE request. This would occur if the device had not been registered in IMS when the initial INVITE request was sent out.
当用户希望在不同的设备上重新开始聊天时，其可能不具有关于群聊的最新信息。 特别地，如果它没有接收到初始SIP INVITE请求，它将不具有用于群聊的焦点会话标识。 如果在发送初始INVITE请求时设备未在IMS中注册，则会发生这种情况。
When a Common Message Store is available for the user, the Group Chat messages are stored in the Common Message Store as they pass through the user’s Participating Function. If a network initiated SIP BYE request is received, then in addition to storing the Conversation-ID (if present) and Contribution-ID, the focus Session Identity for the Group Chat, whether it was closed or regular, and a message containing the current list of participants need to be stored. This implies that the Messaging Server Participating Function is required to keep track of the list of participants for the Group Chat by subscribing to the participant information and keeping the relevant information received in the corresponding SIP NOTIFY requests. The messages are synchronised with the Message Store Server as specified in [RCS-CPM-MSGSTOR-ENDORS].
当公共消息存储可用于用户时，群聊消息在它们通过用户的参与功能时存储在公共消息存储中。 如果接收到网络发起的SIP BYE请求，则除了存储对话ID（如果存在）和贡献ID之外，用于群聊的焦点会话标识（无论其是关闭的还是正常的）以及包含当前 参与者列表需要存储。 这意味着消息服务器参与功能需要通过订阅参与者信息并保持在相应的SIP NOTIFY请求中接收的相关信息来跟踪用于群聊的参与者列表。 消息与[RCS-CPM-MSGSTOR-ENDORS]中指定的消息存储服务器同步。
3.4.4.1.8.1 Forking on the Messaging Servers / 在消息服务器上分岔
The forking procedures for Group Chat are the same as those described for 1-to-1 chat in section 3.3.4.1.7.1.
群聊的分叉过程与第3.3.4.1.7.1节中为1对1聊天描述的相同。
Additionally, each device shall subscribe to the conference state event package, once it accepts the INVITE. The Participating Function serving that user shall make sure that there is only one subscription maintained per user towards the Controlling Function.
另外，一旦它接受INVITE，每个设备将订阅会议状态事件包。 为该用户服务的参与功能应确保每个用户只有一个针对控制功能维护的预订。
If a client indicates voluntary departure from the Group Chat when there is no active device as per section 3.4.4.1.3.1, the terminating Participating Function shall close the session towards the other clients and indicate to the Controlling Function that the user has left the group chat.
如果客户端在根据第3.4.4.1.3.1节没有活动设备时自愿离开群聊时，终止参与功能将关闭向其他客户端的会话，并向控制功能指示用户已离开群聊。
If a client leaves a Group Chat involuntarily from one of their devices as per section 3.4.4.1.3.2 and there is no user device that has accepted the Group Chat, the Messaging Server shall continue forking incoming messages to the rest of the user devices.
如果客户端根据第3.4.4.1.3.2节从其设备之一不注意地离开群聊，并且没有用户设备已接受群聊，则消息传递服务器应继续将传入消息分岔到其余用户设备。
3.4.4.1.9 Group Chat Service Identification / 群聊服务标识
The RCS client shall populate the P-Preferred-Service header field in all CPM or 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.group” for Group Chat, or “urn:urn-7:3gpp-service.ims.icsi.oma.cpm.deferred” for deferred delivery done as part of the Store and forward realisation) 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将添加设置为断言的CPM服务ICSI的值（即用于群聊的“urn:urn-7:3gpp-service.ims.icsi.oma.cpm.session.group”或者用于延迟传输完成的”urn:urn-7:3gpp-service.ims.icsi.oma.cpm.deferred“）的P-Asserted-Service头域，）作为存储和转发实现的一部分，并在进一步路由请求之前删除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.4.4.2 Technical Realisation of a Closed Group Chat / 关闭群聊的技术实现
In order for a device to request that a particular group chat remain closed to the addition of new participants, the device sets the a=chatroom attribute defined in [RFC7701] in the SDP of the SIP INVITE request with the CPM reserved chat-token value, as described in [RCS- CPM-CONVFUNC-ENDORS], to indicate the RCS Closed Group Session in the SIP INVITE. The SDP attribute value shall be: a=chatroom:org.openmobilealliance.groupchat.closed;
为了使设备请求特定群组聊天对于添加新的参与者保持关闭，设备将具有CPM预留聊天记号值的SIP INVITE请求的SDP中的[RFC7701]中定义的a=chatroom属性 ，如[RCS-CPM-CONVFUNC-ENDORS]中所描述的，以指示SIP INVITE中的RCS封闭组会话。 SDP属性值应为：a=chatroom:org.openmobilealliance.groupchat.closed;
If a Service Provider only wishes to provide Group Chats that are closed, then even if the SDP offer did not include the a=chatroom attribute, a Closed Group Chat is created and the a=chatroom attribute is returned to the sender in the SDP answer in the 200 OK to the Group Chat initiator.
如果服务提供商仅希望提供关闭的群聊，则即使SDP要约中不包括a=chatroom属性，对于群聊启动者，也会创建封闭群聊，并通过200 OK将a=chatroom属性返回给SDP应答中的发起者。
For a Closed Group Chat, the a=chatroom attribute (i.e. “a=chatroom:org.openmobilealliance.groupchat.closed”) is placed in the SDP offer in the SIP INVITE request sent to invited participants:
对于封闭群组聊天，将a=chatroom属性（即，“a=chatroom:org.openmobilealliance.groupchat.closed”）放置在发送给被邀请的参与者的SIP INVITE请求中的SDP要约中：
A device recognising this attribute may disable the possibility of adding participants to the Group Chat. A device not recognizing this attribute shall ignore it, but any attempt by the device to add participants will result in an error being returned from the Messaging Server.
识别此属性的设备可以禁止将参与者添加到群聊的可能性。 不识别此属性的设备将忽略它，但设备添加参与者的任何尝试将导致从消息传递服务器返回错误。
3.4.4.3 Technical Realisation of Store and Forward functionality for a Group Chat Participant / 群聊参与者的存储和转发功能的技术实现
A Messaging Server may provide Store and Forward functionality for users participating in Group Chat. This feature applies no matter whether this Service Provider or another Service Provider is hosting the Group Chat.
消息服务器可以为参与群组聊天的用户提供存储和转发功能。 无论此服务提供商或其他服务提供商是否主持群组聊天，此功能都适用。
3.4.4.3.1 Initiating a chat / 发起聊天
Section 3.4.4.1.1 applies. When a user who is offline is invited to a group chat or a user does not respond to a SIP INVITE request for a group chat (i.e. the request times out), the participating function will accept the group chat on behalf of the user and subscribe to the conference state information for that chat session. If it can handle File Transfer via HTTP, the participating function shall include the File Transfer via HTTP IARI in the Contact Header of the SIP 200 OK response sent when accepting the session and if no wildcard was used, also the application/vnd.gsma.rcs-ft-http+xml shall be included in the a=accept- wrapped-types SDP attribute that is included in that SIP 200 OK response. If it can handle Geolocation PUSH content, the participating function shall include the Geolocation PUSH IARI in the Contact Header of the SIP 200 OK response sent when accepting the session and if no wildcard was used, also the application/vnd.gsma.rcspushlocation+xml shall be included in the a=accept-wrapped-types SDP attribute that is included in that SIP 200 OK response.
第3.4.4.1.1节适用。当离线的用户被邀请进行群组聊天或者用户没有响应用于群组聊天的SIP INVITE请求（即，请求超时）时，参与功能将代表用户接受群组聊天并订阅到该聊天会话的会议状态信息。如果它可以处理通过HTTP的文件传输，参与功能将包括通过HTTP IARI的文件传输在接受会话时发送的SIP 200 OK响应的联系头中，并且如果没有使用通配符，也包括application/vnd.gsma.rcs-ft-http+xml应包含在包含在该SIP 200 OK响应中的a=accept-wrapped-types SDP属性中。如果它可以处理地理位置PUSH内容，则参与功能将在接受会话时发送的SIP 200 OK响应的联系头中包括地理位置推送IARI，并且如果没有使用通配符，则application/vnd.gsma.rcspushlocation+xml应包括在包含在该SIP 200 OK响应中的a=accept-wrapped-types SDP属性中。
Given that unless the user declines the Chat a Messaging Server Participating Function will accept the session, the Messaging Server Participating Function should anticipate to this and immediately accept the session from the controlling function without waiting for client’s final response first. This behaviour will ensure that all messages sent in the Group Chat will ultimately reach the user also in exceptional circumstances where the Chat is closed by the Controlling Function before a final response was received from the user. When accepting the session before there is a final response from the user, the Messaging Server Participating Function shall in case a SIP 603 Decline response is received from the user terminate the session by sending a SIP BYE request to the Controlling Function carrying a Reason Header Field with the protocol set to SIP and the protocol cause code set to 200 (e.g. SIP;cause=200;text="Call completed").
假设除非用户拒绝聊天，消息服务器参与功能将接受会话，消息服务器参与功能应当预期到并且立即从控制功能接受会话，而不首先等待客户端的最终响应。 这种行为将确保在从用户接收到最终响应之前在控制功能关闭聊天的特殊情况下，在群聊中发送的所有消息也将最终到达用户。 当在来自用户的最终响应之前接受会话时，消息服务器参与功能将在从用户接收到SIP 603拒绝响应的情况下通过向控制功能发送SIP BYE请求来终止会话，该控制功能携带Reason报头字段，其protocol设置为SIP，并且protocol cause代码设置为200（例如，SIP;cause=200;text=“Call completed”）。
3.4.4.3.2 Adding Participants to a Group Chat / 将与会者添加到群聊
The text in section 3.4.4.1.2 applies. If the Group Chat is a Closed Group Chat, the Messaging Server will return an error response to the SIP INVITE request.
第3.4.4.1.2节的内容适用。 如果群聊是封闭群聊，则邮件服务器将返回对SIP INVITE请求的错误响应。
Messages exchanged in the Group Chat before the new participant is invited are not subject to the Store and Forward functionality for that participant.
在邀请新参与者之前在群聊中交换的消息不受该参与者的存储和转发功能的约束。
3.4.4.3.3 Closing Group Chat / 关闭群聊
The text in section 3.4.4.1.3 applies.
第3.4.4.1.3节的内容适用。
When the user explicitly leaves the Group Chat, the Messaging Server Participating Function shall, as well as the forwarding of this action to the Controlling Function (as described in section 3.4.4.1.3), also discard any remaining messages and notifications related to this Group Chat that were stored for delivery to that user.
当用户显式地离开群聊时，消息服务器参与功能以及将该动作转发到控制功能（如在3.4.4.1.3中所描述的），还丢弃与存储用于传递给该用户的群聊相关的任何剩余消息和通知。
3.4.4.3.4 Chat messages size limitations / 聊天消息大小限制
The text in section 3.4.4.1.4 applies.
第3.4.4.1.4节中的内容适用。
3.4.4.3.5 Delivery and Display notifications within Group Chat / 群聊中的递送和显示通知
The text in section 3.4.4.1.5 applies.
第3.4.4.1.5节中的内容适用。
3.4.4.3.6 Interworking to SMS/MMS / 与SMS/MMS的互通
The text in section 3.4.4.1.6 applies.
第3.4.4.1.6节中的内容适用。
3.4.4.3.7 Restarting a Group Chat / 重新启动组聊天
The text in section 3.4.4.1.7 applies.
第3.4.4.1.7节中的内容适用。
3.4.4.3.8 Storing messages for a participant who loses connectivity / 为失去连接的与会者存储消息
If a Messaging Server implements the Group Chat Store and Forward feature, then if a Messaging Server Participating Function serving a Group Chat participant detects that the participant is unreachable (e.g. loss of network coverage), it becomes an endpoint for the Group Chat. In this case, it shall store any messages and disposition notifications (but not isComposing Notifications) received for that participant and keep the dialogs for the Chat session alive by sending timely refresh requests as defined in [RFC4028]. This way, the conference focus continues to keep the participant in the participant list for the Group Chat. Furthermore the Messaging Server Participating Function shall ensure that it has a subscription to the conference state for the duration of the Group Chat, or until the user re-joins.
如果消息服务器实现了群组聊天存储和转发功能，则如果服务群组聊天参与者的消息服务器参与功能检测到参与者不可达（例如，网络覆盖损失），则它成为群聊的端点。 在这种情况下，它将存储为该参与者接收的任何消息和处置通知（但不是isComposing通知），并通过发送[RFC4028]中定义的及时刷新请求来保持聊天会话的对话。 这样，会议焦点继续保持参与者在群聊的参与者列表中。 此外，消息服务器参与功能应确保其在群聊期间具有对会议状态的预订，或直到用户重新加入。
A Messaging Server knows a participant has lost connectivity if it does not receive a SIP BYE request from that user, but it notices TCP or MSRP connectivity issues with that participant, or receives a SIP BYE request from client side indicating involuntary departure as specified in section 3.4.4.1.3.2 (e.g. containing a Reason header field set to response code 503 (Service Unavailable), as specified in section 5.2.8.1.2 of [3GPP TS 24.229]).
如果参与者没有收到来自该用户的SIP BYE请求，则消息服务器知道参与者已失去连接，但是它注意到该参与者的TCP或MSRP连接问题，或者从客户端接收到指示如3.4.4.1.3.2节中指定的非自愿离开的SIP BYE请求 （例如，如[3GPP TS 24.229]的第5.2.8.1.2节中所规定的，包含被设置为响应代码503（服务不可用）的原因报头字段）。
3.4.4.3.9 Re-joining a Group Chat after temporary disconnection, Group Chat is still ongoing / 在临时断开连接后重新加入群聊，群聊仍在进行
When a Messaging Server Participating Function detects that one of its users’ devices is attempting to rejoin an ongoing Group Chat, it will deliver any stored messages and the notifications pertaining to this user’s device, and connect the user’s session with the ongoing session that the Messaging Server Participating Function controls on behalf of the user.
当消息服务器参与功能检测到其用户的设备之一正试图重新加入正在进行的群聊时，它将传送任何存储的消息和关于该用户设备的通知，并将用户的会话与正在进行的会话连接， 服务器参与功能控件代表用户。
The user is made aware of the current list of participants in the Group Chat once he has joined successfully and issues a SUBSCRIBE to the conference state for the Group Chat. All participants with any one of these
用户在成功加入群组聊天后知道群组聊天的当前列表，并向群聊的会议状态发出SUBSCRIBE。 具有这些
3.4.4.3.10 Rejoining a Group Chat after temporary disconnection, Group Chat is over / 在临时断开连接后重新加入群组聊天，群聊已结束
When a Messaging Server Participating Function detects that a user’s device is attempting to rejoin an ongoing Group Chat which is no longer active, it will forward the rejoin request to the Controlling Function and deliver any stored messages and the notifications pertaining to this user (see Annex B.1.16), and when no Group Chat session was established during forwarding, terminate the session to the client immediately after delivering the last stored message or notification.
当消息服务器参与功能检测到用户的设备正在尝试重新加入不再活动的正在进行的群聊时，它将向控制功能转发重新加入请求，并传递任何存储的消息和关于该用户的通知（见附件 B.1.16），并且当在转发期间没有建立群聊会话时，在递送最后存储的消息或通知之后立即终止对客户端的会话。
As for the case of a 1-to-1 session described in section 3.3.4.1.4, when stored application messages need to be forwarded this will only be done in case the client that accepted supports the application service as indicated in the a=accept-wrapped-types SDP attribute and the Contact header field that the client provided in the SIP INVITE request when re- joining the session. Otherwise, according to the operator local policy the messages related to the application shall either remain stored until another client comes online or be converted by the Messaging Server Participating Function into a format that is supported by the client (e.g. a plain text message carrying a link or a descriptive text of the application message’s content).
对于在3.3.4.1.4节中描述的1对1会话的情况，当存储的应用消息需要被转发时，这将仅在接受的客户端支持应用服务的情况下进行，如a=accept-wrapped-types SDP属性和客户端在重新加入会话时在SIP INVITE请求中提供的Contact头字段。 否则，根据运营商本地策略，与应用相关的消息应保持存储，直到另一个客户端变为在线或由消息服务器参与功能转换为客户端支持的格式（例如，携带链接的明文消息或应用消息的内容的描述文本）。
When the receiving RCS Client sends any messages, explicitly leaves the Chat (as described in section 3.4.4.1.3.1) or adds a new participant (as described in section 3.4.4.1.2), the Messaging Server Participating Function shall ensure that the Group Chat is restarted on behalf of the user using the procedure described in section 3.4.4.1.7 and forward the message or action from the user in this session. For notifications sent by the receiving client, the Messaging Server Participating Function shall either send them in a restarted Group Chat session or as SIP MESSAGE requests. In the latter case, these SIP MESSAGE requests shall carry the same RCS Group Chat ID as the Group Chat so that the receiving user can associate them with the Group Chat instead of to a 1-to-1 Chat. The Messaging Server Participating Function should close the delivery session as soon as all stored messages are delivered.
当接收RCS客户端发送任何消息时，显式离开聊天（如第3.4.4.1.3.1节所述）或添加一个新的参与者（如第3.4.4.1.2节所述），消息服务器参与功能应确保 组聊天代表用户使用第3.4.4.1.7节中描述的过程重新启动，并转发来自此会话中用户的消息或操作。 对于由接收客户端发送的通知，消息服务器参与功能将在重新启动的群聊会话或作为SIP MESSAGE请求中发送它们。 在后一种情况下，这些SIP MESSAGE请求应携带与群聊相同的RCS群组聊天ID，以便接收用户可以将它们与群聊相关联，而不是1对1聊天。 消息服务器参与功能应当在传送所有存储的消息时立即关闭传送会话。
NOTE: When the client subscribes to the conference state event package and the Group Chat is not active (i.e. there is no session between Participating and Controlling Function), as an optimisation this subscription can be accepted by the Messaging Server Participating Function that will consequently generate a SIP NOTIFY request including the last known participant information. In this case the Messaging Server Participating Function shall have to subscribe to the conference state event package when the Group Chat is restarted and link this subscription with the one from the client as a B2BUA. If the client’s SIP SUBSCRIBE request is received in a Group Chat that was restarted, it shall be handled as described in section 3.4.4.1.1.
注意：当客户端订阅会议状态事件包并且群聊不活动（即，在参与和控制功能之间没有会话）时，作为优化，消息服务器参与功能可以接受消息服务器参与功能， 包括最后知道的参与者信息的SIP NOTIFY请求。 在这种情况下，当重新启动群聊时，消息服务器参与功能必须订阅会议状态事件包，并将该订阅与来自客户端的订阅作为B2BUA链接。 如果在重新启动的组聊天中接收到客户端的SIP SUBSCRIBE请求，则应按第3.4.4.1.1节中所述处理客户端的SIP SUBSCRIBE请求。
3.4.4.3.11 Storing messages for a participant who has not yet accepted the invitation / 存储尚未接受邀请的与会者的消息
The text in section 3.4.4.3.8 applies with the difference that the Messaging Server Participating Function has been storing messages ever since the SIP INVITE request to the participant timed out and it became an endpoint on behalf of that participant by sending a 200 OK.
第3.4.4.3.8节中的内容适用，区别在于自从对参与者的SIP INVITE请求超时以来，消息服务器参与功能一直存储消息，并且它通过发送200 OK而成为代表该参与者的端点。
3.4.4.3.12 Joining and delivering messages for a participant who joins late, Group Chat is still ongoing / 为加入迟到的参与者加入和传送邮件，群聊仍在进行
When the Messaging Server Participating Function detects that a recipient user’s device is now available in IMS and the session with the Controlling Function is still active, stored chat messages and notifications[30] are delivered as described in section 3.4.4.3.13 with the Messaging Server Participating Function’s B2BUA linking the session towards the client with the one that was established with the Controlling Function. The Messaging Server Participating Function shall either forward the subscription to conference state request from the client to the Controlling Function after terminating the own subscription or link this subscription from the client to its own subscription as a B2BUA.
当消息服务器参与功能检测到接收方用户的设备现在在IMS中可用并且与控制功能的会话仍然活动时，存储的聊天消息和通知[30]如部分3.4.4.3.13中所述被递送，消息服务器参与功能 B2BUA将会话连接到使用控制功能建立的会话。 消息服务器参与功能应当在终止自己的订阅之后将预订从会话状态请求转发到控制功能，或者将该订阅从客户端作为B2BUA链接到其自己的订阅。
3.4.4.3.13 Joining and delivering messages for a participant who joins late, Group Chat is over / 加入和传递加入延迟的参与者的消息，群聊结束了
When the Messaging Server Participating Function detects that a recipient user’s device is now available in IMS, stored chat messages and the notifications[30] targeting this device are delivered as described in section 3.3.4.1.4, with following differences (see Annex B.1.17):
当消息服务器参与功能检测到接收方用户的设备现在在IMS中可用时，存储的聊天消息和针对该设备的通知[30]如部分3.3.4.1.4中所述被递送，具有以下差异（见附件B.1.17）：
- The P-Asserted-Identity and Contact headers shall include the same values of the corresponding headers in the latest received Group Chat invitation and
P-Asserted-Identity和Contact报头应包括最近接收的群聊邀请中的相应报头的相同值，并且包括 - The Referred-By header value shall contain the address of the user who initiated the Group Chat.
Referred-By标头值应包含发起群聊的用户的地址。
NOTE: Whether the Messaging Server Participating Function initiates this action immediately or only after a timeout when it can be assumed that the client will not send an automatic rejoin, is left as an implementation decision. In both cases, the Messaging Server Participating Function should be prepared to handle a race condition between the INVITE request that it sends and a rejoin sent from the client. By delaying the INVITE request, that scenario becomes more unlikely though.
注意：无论消息服务器参与功能是立即启动此操作还是仅在可以假定客户端不会发送自动重新加入的超时后才启动此操作，将留作实施决策。 在这两种情况下，消息服务器参与功能应该准备处理它发送的INVITE请求和从客户端发送的重新加入之间的竞争条件。 通过延迟INVITE请求，这种情况变得更不可能了。
When the receiving RCS Client sends any messages, explicitly leaves the Chat (as described in section 3.4.4.1.3.1) or adds a new participant (as described in section 3.4.4.1.2), the Messaging Server Participating Function shall ensure that the Group Chat is restarted on behalf of the user using the procedure described in section 3.4.4.1.7 and forward the message or action from the user in this session. For notifications sent by the receiving client, the Messaging Server Participating Function shall either send them in a restarted Group Chat session or as SIP MESSAGE requests. In the latter case, these SIP MESSAGE requests shall carry the same RCS Group Chat ID as the Group Chat so that the receiving user can associate them with the Group Chat instead of to a 1-to-1 Chat. The Messaging Server Participating Function shall close the delivery session as soon as all stored messages are delivered. When the user explicitly leaves the session the Messaging Server Participating Function shall next to the forwarding of this action also discard any remaining stored messages.
当接收RCS客户端发送任何消息时，显式离开聊天（如第3.4.4.1.3.1节所述）或添加一个新的参与者（如第3.4.4.1.2节所述），消息服务器参与功能应确保组聊天代表用户使用第3.4.4.1.7节中描述的过程重新启动，并转发来自此会话中用户的消息或操作。对于由接收客户端发送的通知，消息服务器参与功能将在重新启动的群聊会话或作为SIP MESSAGE请求中发送它们。在后一种情况下，这些SIP MESSAGE请求应携带与群聊相同的RCS群组聊天ID，以便接收用户可以将它们与群聊相关联，而不是1对1聊天。消息服务器参与功能应当在所有存储的消息被递送时立即关闭传送会话。当用户显式离开会话时，消息服务器参与功能将在该动作的转发之后还丢弃任何剩余的存储消息。
Forwarding of application messages shall be done as specified in section 3.4.4.3.10. If the first message to be delivered in the Chat is an application message (e.g. a File Transfer via HTTP XML body), the messaging server shall include an Accept-Contact header field in the SIP INVITE request carrying the IARI associated to the application service along with require and explicit parameters.
应按第3.4.4.3.10节的规定进行应用消息的转发。 如果在聊天中要传递的第一消息是应用消息（例如，经由HTTP XML主体的文件传输），则消息传递服务器将使用必须和明确的参数，在携带与应用服务相关联的IARI的SIP INVITE请求中包括Accept-Contact头字段。
[30] The Messaging Server Participating Function has been storing messages even if the participant had not joined before.
[30] 消息服务器参与功能已经存储消息，即使参与者之前没有加入。
3.4.4.3.14 Inactive session from Controlling Function activated while forwarding messages / 来自转发消息时激活的控制功能的非活动会话
In case the delivery started without an active session from the Controlling Function and the Group Chat is activated from the same Controlling Function as before (i.e. the session identity matches the one provided to the client), the Messaging Server Participating Function shall accept the session from the Controlling Function and connect it as a B2BUA to the one already established with the client. Furthermore, the Messaging Server Participating Function shall on behalf of the user subscribe to the conference state provided by the Controlling Function and connect this subscription as a B2BUA with the subscription from the client that it terminated.
如果没有来自控制功能的活动会话开始递送，并且来自与之前相同的控制功能（即，会话标识匹配提供给客户端的控制功能）的群组聊天被激活，则消息服务器参与功能将接受会话 控制功能并将其作为B2BUA连接到已经与客户端建立的一个。 此外，消息服务器参与功能将代表用户订阅由控制功能提供的会议状态，并将该订阅作为B2BUA与来自它终止的客户端的订阅连接。
3.4.5 NNI and IOT considerations / NNI和IOT考虑
3.4.5.1 SIMPLE IM Group Chat – CPM Group Chat interworking / SIMPLE IM群聊 - CPM群聊聊天互通
Interworking a participant with SIMPLE IM Group Chat towards a CPM Group Chat server, and a participant with CPM Group Chat towards a SIMPLE IM Group Chat server is done as per the [RCS-CPM-CONVFUNC-ENDORS], via mapping of the appropriate Chat session feature tags when it is determined that the remote network requires such interworking.
在CPM群聊服务器上，将参与者与SIMPLE IM群聊互配；以及在SIMPLE IM群聊服务器上，将参与者与CPM群聊互配；以上操作将按照[RCS-CPM-CONVFUNC-ENDORS]，通过相应聊天会话标签的映射完成，当确定远程网络需要这样的互配时。
3.4.5.2 Messaging Server handling of delivery notifications when not supported by device or terminating network / 消息服务器在设备或终止网络不支持时处理传送通知
For devices or networks (e.g. older RCS versions) that the controlling or participating function of an RCS Messaging Server recognises do not support generation of delivery notifications within a Group Chat, the Messaging Server shall generate them on behalf of the devices if such notifications are requested. As it is related to the deployment environment, the method by which the Messaging Server determines whether a device can generate delivery notifications is considered outside of the scope of this specification. The following may be reliable indications though:
对于RCS消息服务器的控制或参与功能识别不支持在群聊中生成递送通知的设备或网络（例如，旧的RCS版本），消息服务器将代表设备生成它们，如果请求这样的通知 。 由于它与部署环境相关，因此消息传递服务器确定设备是否可以生成传递通知的方法被认为超出了本规范的范围。 以下可能是可靠的指示：
- The device indicates explicitly support for the message/imdn+xml Mime type in the a=accept-wrapped-types SDP attribute.
设备指示明确支持a=accept-wrapped-types SDP属性中的application/imdn+xml Mime类型。 - The device indicates support for File Transfer via HTTP in the Group Chat (see section 3.5.4.8).
设备表示支持在组聊天中通过HTTP进行文件传输（参见第3.5.4.8节）。
A device that does not generate delivery or display notifications should not receive the CPIM IMDN header in an MSRP SEND that is used to request notifications. When sending a message to a device or network that is assumed not to support disposition notifications in Group Chat, the Messaging Server shall remove this header.
不生成传递或显示通知的设备不应在用于请求通知的MSRP SEND中接收CPIM IMDN标题。 当向假定不支持群聊中的处理通知的设备或网络发送消息时，消息传递服务器应删除此标头。
3.4.5.3 Connection Model for Subscriptions from Participating Function to Controlling Function / 从参与功能到控制功能的订阅的连接模型
The Messaging Server Participating Function acts as a subscriber to the conference event package of a Group Chat controlled by the Messaging Server Controlling Function. During an active subscription the Messaging Server Controlling Function notifies the Participating function about changes of the Group State status and participant list.
消息服务器参与功能充当由消息服务器控制功能控制的组聊天的会议事件包的订户。 在活动预订期间，消息服务器控制功能通知参与功能关于组状态状态和参与者列表的改变。
Messaging Server Participating Functions and Controlling Function may reside in different Service Provider networks. The Connection Model applied on the interface between the two functions shall minimise the impact on the Controlling Function coming from the Participating Function Service Provider's network topology and service provisioning. This is achieved by limiting the number of active subscriptions per participant in a given Group Chat to "1" based on the Connection Model below.
消息服务器参与的功能和控制功能可以驻留在不同的服务提供商网络中。 应用在两个功能之间的接口上的连接模型将最小化来自参与功能服务提供商的网络拓扑和服务供应对控制功能的影响。 这是通过基于以下连接模型将每个参与者在给定群聊中的活动订阅的数量限制为“1”来实现的。
If the Participating Function initiates a new subscription for a focus session ID on behalf of a participant the Controlling Function shall accept the request provided that the focus session ID exists and the participant is authorised to subscribe to it, i.e. it is a participant in the Group Chat.
如果参与功能代表参与者发起焦点会话ID的新预订，则控制功能将接受该请求，只要焦点会话ID存在并且参与者被授权订阅它，即它是该群聊中的参与者。
At the time of acceptance, if the Controlling Function has another subscription active for the same focus session identity and participant combination then the older subscription should be terminated as defined in [RFC6665].
在接受时，如果控制功能具有对于相同焦点会话身份和参与者组合活动的另一订阅，则应当如[RFC6665]中所定义终止较早订阅。
The Service Provider of the Participating Function shall ensure that the connection model towards the Controlling Function does not restrict the service provided to its users. For Service Providers offering Group Chat for Multi Devices the application of a Back-to-Back User Agent (B2BUA) for subscriptions in the Messaging Server Participating Function is mandatory.
参与功能的服务提供商应确保控制功能的连接模型不限制向其用户提供的服务。 对于为多设备提供群聊的服务提供商，用于消息服务器参与功能中的订阅的背对背用户代理（B2BUA）的应用是强制性的。
3.4.6 Implementation guidelines and examples / 实施指南和示例
Please note that the following sections propose an experience which is aimed to be employed as a reference for OEM implementations.
请注意，以下部分提出了旨在用作OEM实现的参考的经验。
3.4.6.1 Protocol flow diagrams / 协议流程图
NOTE: To simplify the use cases including the store and forward function the figures and text do not differentiate between different Service Providers and their message servers. These servers are combined to one generic message server function to focus on the client/server communication aspects.
注意：为了简化包括存储和转发功能的用例，数字和文本不区分不同的服务提供商及其消息服务器。 这些服务器被组合到一个通用消息服务器功能以专注于客户端/服务器通信方面。
3.4.6.1.1 Start a Group Chat from the Chat application / 从聊天应用程序启动组聊天
Figure 30: Start a Group Chat from the Chat application / 图30：从聊天应用程序启动组聊天
NOTE: The above flow mentions that OPTIONS is used for service capability exchange, which is the case when the DEFAULT_DISCOVERY_MECHANISM is set to ‘OPTIONS’. When it is set to ‘Presence’, then Presence is used.
注意：上述流程提到OPTIONS用于服务能力交换，这是DEFAULT_DISCOVERY_MECHANISM设置为“OPTIONS”的情况。 当它设置为“Presence”时，将使用在线状态。
The UX associated with an RCS Group Chat should provide the following functionality:
与RCS群组聊天相关联的UX应提供以下功能：
- Displaying the list of participants of the current Group Chat and providing of notifications when a new participant is joining and when a participant is leaving the current Group Chat
显示当前群聊的参与者列表，并在新参与者加入时以及参与者离开当前群聊时提供通知 - When starting a Group Chat session, the invitation shown to the invited users should list the participants invited to the Group Chat before accepting the invitation (e.g. "You're invited to a group chat with A, B & C" instead of "A is inviting you to a group chat")
当启动群聊会话时，向受邀用户显示的邀请应列出邀请加入群聊的参与者，然后接受邀请（例如，“您受邀参加与A，B＆C的群聊”，而不是“A正邀请您加入群组聊天“）
3.4.6.1.2 Start a Group Chat from the Chat composition window / 从聊天输入窗口启动群聊
In this case, Users A and B are in a chat, and User A decides to add a third user (User C) to the chat session. The relevant UX and flow sequence is presented below:
在这种情况下，用户A和B在聊天中，并且用户A决定将第三用户（用户C）添加到聊天会话。 相关UX和流程序列如下：
Figure 31: Group Chat session initiation / 图31：群聊会话初始化
NOTE: The above flow mentions that OPTIONS is used for service capability exchange, which is the case when the DEFAULT_DISCOVERY_MECHANISM is set to ‘OPTIONS’. When it is set to ‘Presence’, then Presence is used.
注意：上述流程提到OPTIONS用于服务能力交换，这是DEFAULT_DISCOVERY_MECHANISM设置为“OPTIONS”的情况。 当它设置为“Presence”时，将使用在线状态。
3.4.6.1.3 Get participants of Group Chat / 获取群聊的参与者
The following flow is complementary to the previous use case as it presents in detail how to get information on the chat participants. Please note that these exchanges were omitted in the previous diagram:
以下流程是对前面的用例的补充，因为它详细地呈现了如何获得关于聊天参与者的信息。 请注意，上图中省略了这些交换：
Figure 32: Group Chat session initiation (II): Get participants / 图32：群聊会话初始化（II）：获得参与者
3.4.6.1.4 Add a participant to an already established Group Chat / 将参与者添加到已经建立的组聊天
Figure 33: Adding new users to a Group Chat / 图33：将新用户添加到组聊天
3.4.6.1.5 Sending a Chat message from the Group Chat window / 从群组聊天窗口发送聊天消息
NOTE: The flow does not show Client B and Client C generating a delivery notification for the received chat message. However, it is expected that they generate one if it was requested.
注意：该流程不会显示客户端B和客户端C为收到的聊天消息生成传送通知。 但是，如果它被请求，它们会生成一个。
Figure 34: Chat message sequence for a Group Chat / 图34：群聊的聊天消息序列
NOTE1: As described in section 3.5.4.8.1, if the message that is exchanged is a File Transfer via HTTP body, the conference focus shall not forward the body to participants that haven’t indicated support for File Transfer via HTTP.
注1：如3.5.4.8.1节所述，如果交换的消息是通过HTTP实体的文件传输，则会议焦点不应将该主体转发给尚未指示支持通过HTTP的文件传输的参与者。NOTE2: As described in section 3.10.4.1.2.2, if the message that is exchanged is a Geolocation PUSH body, the conference focus shall not forward the body to participants that haven’t indicated support for Geolocation PUSH.
注2：如3.10.4.1.2.2节所述，如果交换的消息是地理位置PUSH主体，则会议焦点不应将该主体转发给尚未指示支持地理位置PUSH的参与者。
3.4.6.1.6 Leaving a Group Chat / 离开群聊
In this case User B leaves the chat intentionally:
在这种情况下，用户B有意离开聊天：
Figure 35: Leaving a Group Chat / 图35：离开群聊
3.4.6.1.7 Setting up a Closed Group Chat / 设置关闭的群聊
In the following flow, User A initiates a Closed Group Chat with Users B and C, but does not invite User D;
在下面的流程中，用户A发起与用户B和C的封闭组聊天，但不邀请用户D;
Figure 36: Setting up a Closed Group Chat / 图36：设置封闭的群聊
3.4.6.1.8 Add new participant for a Closed Group Chat / 为封闭的群组聊天添加新参与者
In the same Closed Group Chat as in Figure 36, User B decides to invite User D, selecting from the list of contacts. Since this is a Closed Group Chat, no additional participants can be added and the Messaging Server will return an error:
在与图36相同的封闭组聊天中，用户B决定邀请用户D，从联系人列表中选择。 由于这是封闭的群聊，无法添加其他参与者，并且消息服务器将返回错误：
Figure 37: Add new participant for a Closed Group Chat / 图37：为封闭的群聊添加新的与会者
3.4.6.1.9 Setting up a Group Chat with Store and Forward support / 设置与存储和转发支持的群聊
In the following flow, User A initiates a group chat with Users B, C and D. User B subscribes to Store and Forward with Auto-accept capabilities, but decides to join the group chat later. User C manually accepts the group invitation. User D also subscribes to Store and Forward and joins manually.
在下面的流程中，用户A发起与用户B，C和D的群聊。用户B使用自动接受功能预订存储和转发，但稍后决定加入群聊。 用户C手动接受组邀请。 用户D还订阅存储和转发并手动加入。
Figure 38: Setting up a Group Chat with Store and Forward support / 图38：使用存储和转发支持设置群聊
Figure 39 shows the flow when User B joins the chat:
图39显示了用户B加入聊天时的流程：
Figure 39: User with Store and Forward joins late / 图39：具有存储和转发连接的用户后续加入
3.4.6.1.10 User in a Group Chat goes offline when Messaging Server supports Store and Forward / 消息服务器支持存储和转发时，群聊中的用户脱机
In the following flow, Users B and D are in a chat among others (Group Chat); suddenly Users B and D go offline (due to the loss of the connection to the network for example). Messaging Servers supporting Users B and D store subsequent messages received for Users B and D:
在下面的流程中，用户B和D正在聊天（群聊）; 突然用户B和D离线（例如由于失去与网络的连接）。 消息服务器支持用户B和D存储为用户B和D接收的后续消息：
Figure 40: Users go offline when Messaging Server supports Store and Forward / 图40：当邮件服务器支持存储和转发时，用户脱机
3.4.6.1.11 Re-joining a Group Chat after temporary disconnection, Group Chat is still ongoing / 在临时断开连接后重新加入群聊，群聊仍在进行
In the same Group Chat as in Figure 40, Users B and D are back online and the Messaging Server will deliver the messages it has stored for both users, and the Group Chat is resumed with all original participants:
在与图40中相同的群组聊天中，用户B和D重新联机，并且消息传递服务器将传送其为两个用户存储的消息，并且群聊与所有原始参与者恢复：
Figure 41: Re-joining a Group Chat after temporary disconnection, Group Chat is still ongoing / 图41：在临时断开连接后重新加入群聊，群聊仍在进行