Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7702 &yet
Category: Standards Track S. Ibarra
ISSN: 2070-1721 AG Projects
S. Loreto
Ericsson
December 2015
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7702 &yet
Category: Standards Track S. Ibarra
ISSN: 2070-1721 AG Projects
S. Loreto
Ericsson
December 2015
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：Groupchat
Abstract
摘要
This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.
本文档定义了一个双向协议映射，用于在会话发起协议（SIP）用户和可扩展消息和状态协议（XMPP）用户之间的多方聊天会话上下文中交换即时消息。具体来说，本文档定义了基于SIP的消息会话中继协议（MSRP）和XMPP多用户聊天（MUC）扩展之间的映射。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7702.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7702.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Intended Audience ...............................................4
3. Terminology .....................................................5
4. Architectural Assumptions .......................................5
5. Multi-party Messaging Session from XMPP MUC to MSRP .............8
5.1. Enter Room ................................................11
5.2. Set Nickname ..............................................14
5.3. Conference Subscription ...................................14
5.4. Presence Broadcast ........................................15
5.5. Exchange Messages .........................................19
5.5.1. Send a Message to All Occupants ....................19
5.5.2. Send a Private Message .............................21
5.6. Change Nickname ...........................................22
5.7. Invite Another User to a Room .............................23
5.8. Exit Room .................................................25
6. MSRP Multi-party Messaging Session to XMPP MUC .................25
6.1. Enter Room ................................................28
6.2. Presence Broadcast ........................................30
6.3. Exchange Messages .........................................32
6.3.1. Send a Message to All Occupants ....................32
6.3.2. Send a Private Message .............................34
6.4. Change Nickname ...........................................34
6.5. Invite Another User to a Room .............................35
6.6. Exit Room .................................................36
7. Handling of Nicknames and Display Names ........................37
8. Message Size ...................................................38
9. Security Considerations ........................................38
10. References ....................................................39
10.1. Normative References .....................................39
10.2. Informative References ...................................40
Acknowledgements ..................................................42
Authors' Addresses ................................................43
1. Introduction ....................................................4
2. Intended Audience ...............................................4
3. Terminology .....................................................5
4. Architectural Assumptions .......................................5
5. Multi-party Messaging Session from XMPP MUC to MSRP .............8
5.1. Enter Room ................................................11
5.2. Set Nickname ..............................................14
5.3. Conference Subscription ...................................14
5.4. Presence Broadcast ........................................15
5.5. Exchange Messages .........................................19
5.5.1. Send a Message to All Occupants ....................19
5.5.2. Send a Private Message .............................21
5.6. Change Nickname ...........................................22
5.7. Invite Another User to a Room .............................23
5.8. Exit Room .................................................25
6. MSRP Multi-party Messaging Session to XMPP MUC .................25
6.1. Enter Room ................................................28
6.2. Presence Broadcast ........................................30
6.3. Exchange Messages .........................................32
6.3.1. Send a Message to All Occupants ....................32
6.3.2. Send a Private Message .............................34
6.4. Change Nickname ...........................................34
6.5. Invite Another User to a Room .............................35
6.6. Exit Room .................................................36
7. Handling of Nicknames and Display Names ........................37
8. Message Size ...................................................38
9. Security Considerations ........................................38
10. References ....................................................39
10.1. Normative References .....................................39
10.2. Informative References ...................................40
Acknowledgements ..................................................42
Authors' Addresses ................................................43
Both the Session Initiation Protocol (SIP) [RFC3261] and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be used for the purpose of multi-party text chat over the Internet. To ensure interworking between these technologies, it is important to define bidirectional protocol mappings.
会话发起协议（SIP）[RFC3261]和可扩展消息和状态协议（XMPP）[RFC6120]都可用于互联网上的多方文本聊天。为了确保这些技术之间的互通，定义双向协议映射非常重要。
The architectural assumptions underlying such protocol mappings are provided in [RFC7247], including the mapping of addresses and error conditions. This document specifies mappings for multi-party text chat sessions (often called "groupchat"); specifically, this document defines a mapping between the XMPP Multi-User Chat (MUC) extension [XEP-0045] and SIP-based multi-party chat using Message Session Relay Protocol (MSRP) [RFC4975] as specified in [RFC7701].
[RFC7247]中提供了此类协议映射的基础架构假设，包括地址和错误条件的映射。本文档指定多方文本聊天会话（通常称为“groupchat”）的映射；具体而言，本文档定义了XMPP多用户聊天（MUC）扩展[XEP-0045]和基于SIP的多方聊天之间的映射，使用[RFC7701]中指定的消息会话中继协议（MSRP）[RFC4975]。
Both MUC and MSRP contain a large set of features, such as the ability to administer rooms, kick out and ban users, reserve a nickname within a room, change room subject, enable room moderation, and destroy the room. This document covers only a basic subset of groupchat features: joining a room, establishing or changing (but not permanently registering) a room nickname, modifying presence information within the room, sending a message to all participants, sending a private message to a single participant, inviting another user to the room, and leaving the room. Future documents might define mappings for additional features beyond this set.
MUC和MSRP都包含大量功能，例如管理房间、驱逐和禁止用户、在房间内保留昵称、更改房间主题、启用房间调节和销毁房间。本文档仅涵盖groupchat功能的基本子集：加入聊天室、建立或更改（但不是永久注册）聊天室昵称、修改聊天室中的状态信息、向所有参与者发送消息、向单个参与者发送私人消息、邀请其他用户加入聊天室、，然后离开房间。未来的文档可能会定义此集合之外的其他功能的映射。
The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and who would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). We assume that readers are familiar with the core specifications for both SIP [RFC3261] and XMPP [RFC6120], with the base document for this series [RFC7247], and with the following groupchat-related specifications:
本系列中的文档旨在供软件开发人员使用，这些软件开发人员拥有基于其中一种技术（例如SIP）的现有系统，并且希望实现从该现有系统到基于其他技术（例如XMPP）的系统的通信。我们假设读者熟悉SIP[RFC3261]和XMPP[RFC6120]的核心规范、本系列的基础文档[RFC7247]以及以下groupchat相关规范：
o Multi-party Chat Using MSRP [RFC7701]
o 使用MSRP的多方聊天[RFC7701]
o Multi-User Chat [XEP-0045]
o 多用户聊天[XEP-0045]
A number of technical terms used here are defined in [RFC3261], [RFC4975], [RFC6120], and [XEP-0045].
此处使用的许多技术术语在[RFC3261]、[RFC4975]、[RFC6120]和[XEP-0045]中有定义。
In flow diagrams, MSRP traffic is shown using arrows such as "%%%>",
SIP traffic is shown using arrows such as "***>", XMPP traffic is
shown using arrows such as "...>".
In flow diagrams, MSRP traffic is shown using arrows such as "%%%>",
SIP traffic is shown using arrows such as "***>", XMPP traffic is
shown using arrows such as "...>".
In protocol flows and examples, provisional SIP responses have been elided for the sake of brevity.
在协议流和示例中，为了简洁起见，省略了临时SIP响应。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
XMPP and MSRP differ in their assumptions regarding groupchat traffic. In XMPP, a message of type "groupchat" is just another stanza and is handled directly by an XMPP server or routed to an associated server component for multi-user chat. By contrast, sessions (including groupchat sessions) in MSRP are considered to be a type of media (similar to audio/video sessions): signaling to set up, manage, and tear down the session is handled by a "conference focus" [RFC4353] (here we assume via SIP), but the session data itself is handled by a separate entity called an MSRP switch. How the conference focus and MSRP switch communicate is a matter of implementation and deployment.
XMPP和MSRP对群组聊天流量的假设不同。在XMPP中，“groupchat”类型的消息只是另一节，由XMPP服务器直接处理或路由到相关的服务器组件进行多用户聊天。相比之下，MSRP中的会话（包括groupchat会话）被视为一种媒体（类似于音频/视频会话）：设置、管理和中断会话的信令由“会议焦点”[RFC4353]处理（此处我们假设通过SIP），但会话数据本身由称为MSRP交换机的单独实体处理。会议焦点和MSRP交换机如何通信是一个实施和部署问题。
An architectural diagram for a possible gateway deployment is shown below, where the entities have the following significance:
可能的网关部署的架构图如下所示，其中实体具有以下意义：
o romeo@example.org -- a SIP user.
o romeo@example.org--SIP用户。
o romeo@example.org;gr=dr4hcr0st3lup4c -- a particular endpoint associated with the SIP user.
o romeo@example.org;gr=dr4hcr0st3lup4c——与SIP用户关联的特定端点。
o example.org -- a SIP proxy with an associated SIP-to-XMPP gateway ("S2X GW") to XMPP.
o org——一个SIP代理，它具有到XMPP的关联SIP到XMPP网关（“S2X GW”）。
o chat.example.org -- a SIP-based conference focus and MSRP switch with an associated MSRP-to-SIP gateway ("M2X GW") to XMPP.
o chat.example.org——一个基于SIP的会议焦点和MSRP交换机，带有一个关联的MSRP到SIP网关（“M2X GW”）到XMPP。
o montague@chat.example.org -- a conference at an MSRP switch; not shown in diagram.
o montague@chat.example.org--在MSRP交换机召开会议；图中未显示。
o juliet@example.com -- an XMPP user.
o juliet@example.com--一个XMPP用户。
o juliet@example.com/yn0cl4bnw0yr3vym -- a particular endpoint associated with the XMPP user.
o juliet@example.com/yn0cl4bnw0yr3vym——与XMPP用户关联的特定端点。
o example.com -- an XMPP server with an associated XMPP-to-SIP gateway ("X2S GW") to SIP and an XMPP-to-MSRP gateway ("X2M GW") to MSRP.
o example.com--一个XMPP服务器，它具有一个关联到SIP的XMPP到SIP网关（“X2S GW”）和一个关联到MSRP的XMPP到MSRP网关（“X2M GW”）。
o rooms.example.com -- an XMPP MUC service associated with example.com.
o rooms.example.com——与example.com关联的XMPP MUC服务。
o capulet@rooms.example.com -- a chat room at an XMPP MUC service; not shown in diagram.
o capulet@rooms.example.com--XMPP MUC服务的聊天室；图中未显示。
These are logical entities, and several of them might be co-located in the same physical entity. For example, the SIP conference focus and MSRP switch and associated gateways, or the XMPP server and MUC service and associated gateways, might be part of the same deployed code. In addition, it is likely that an XMPP service would not have separate gateways for XMPP-to-SIP translation and XMPP-to-MSRP translation, but would instead have a single gateway.
这些是逻辑实体，其中几个可能位于同一物理实体中。例如，SIP会议焦点和MSRP交换机及相关网关，或XMPP服务器和MUC服务及相关网关，可能是相同部署代码的一部分。此外，XMPP服务可能不会有单独的网关用于XMPP到SIP转换和XMPP到MSRP转换，而是有一个网关。
#####################################################################
# #
# +------------------+ #
# &&&&&&&&&&&&&&&&| chat.example.org |<%%%%%%%%%%% #
# & &&&&| (MSRP switch) +-----+ % #
# & & +---------------| M2X | % #
# & & % | GW | % #
# & & % +-----+ % #
# & & % : % #
# & & % ///////////////////////////////////#
# & & % / : % #
# & & % / : +-----+ #
# & & % / : | X2M | #
# & & % / : +-------| GW |---+ #
# & & % / :.>| +-----+ | #
# & & % / | | #
# & +------------------+ % / +-----+ | #
# & | chat.example.org |<*******/*| X2S | example.com | #
# & | (conference | % **/*| GW | (XMPP server) | #
# & | focus) +-----+ % * / +-----+ | #
# & +------------| S2X | % * / | +-------------------+ #
# & * | GW |......*./....>| | rooms.example.com | #
# & * +-----+ % * / +-----| (MUC service) | #
# & * % * / ^ : +-------------------+ #
# & +---------------+ % * / : : #
# &&| example.org |<********* / : : #
# | (SIP proxy) +-----+ % / : : #
# +-------------| S2X | % / : : #
# * | GW |......./........ : #
# * +-----+ % / : #
# * % / : #
# romeo@example.org / juliet@example.com #
# ;gr=dr4hcr0st3lup4c / /yn0cl4bnw0yr3vym #
# / #
# --SIP/MSRP DOMAIN-- / --XMPP DOMAIN-- #
# / #
#####################################################################
#####################################################################
# #
# +------------------+ #
# &&&&&&&&&&&&&&&&| chat.example.org |<%%%%%%%%%%% #
# & &&&&| (MSRP switch) +-----+ % #
# & & +---------------| M2X | % #
# & & % | GW | % #
# & & % +-----+ % #
# & & % : % #
# & & % ///////////////////////////////////#
# & & % / : % #
# & & % / : +-----+ #
# & & % / : | X2M | #
# & & % / : +-------| GW |---+ #
# & & % / :.>| +-----+ | #
# & & % / | | #
# & +------------------+ % / +-----+ | #
# & | chat.example.org |<*******/*| X2S | example.com | #
# & | (conference | % **/*| GW | (XMPP server) | #
# & | focus) +-----+ % * / +-----+ | #
# & +------------| S2X | % * / | +-------------------+ #
# & * | GW |......*./....>| | rooms.example.com | #
# & * +-----+ % * / +-----| (MUC service) | #
# & * % * / ^ : +-------------------+ #
# & +---------------+ % * / : : #
# &&| example.org |<********* / : : #
# | (SIP proxy) +-----+ % / : : #
# +-------------| S2X | % / : : #
# * | GW |......./........ : #
# * +-----+ % / : #
# * % / : #
# romeo@example.org / juliet@example.com #
# ;gr=dr4hcr0st3lup4c / /yn0cl4bnw0yr3vym #
# / #
# --SIP/MSRP DOMAIN-- / --XMPP DOMAIN-- #
# / #
#####################################################################
Legend:
. = XMPP
% = MSRP
* = SIP
& = unstandardized communication paths
/ = separation of administrative domains
Legend:
. = XMPP
% = MSRP
* = SIP
& = unstandardized communication paths
/ = separation of administrative domains
Figure 1: Logical Deployment Architecture
图1：逻辑部署架构
In SIP, there is no necessity for a SIP user such as romeo@example.org to make use of his SIP proxy in order to join a chat room on the XMPP network; for example, he could try to directly find a SIP service at example.com or independently locate a SIP-to-XMPP gateway. Although, as a simplifying assumption, this document shows the more expected path of using one's "home" SIP proxy and shows gateways as associated with the sending domain, nothing in this document ought to be construed as discouraging other deployment architectures or communication paths (e.g., services hosting their own inbound gateways).
在SIP中，不需要SIP用户，例如romeo@example.org使用他的SIP代理加入XMPP网络上的聊天室；例如，他可以尝试直接在example.com上查找SIP服务，或者独立地定位SIP到XMPP网关。虽然，作为一个简化的假设，本文档显示了使用“主”SIP代理的更预期路径，并显示了与发送域关联的网关，但本文档中的任何内容都不应被解释为阻止其他部署架构或通信路径（例如，承载其自身入站网关的服务）。
This section describes how to map an XMPP MUC session to an MSRP Multi-party Messaging session. The following diagram outlines the overall protocol flow of a sample session, which includes some optional exchanges (such as sending messages, changing a nickname, and inviting another user).
本节介绍如何将XMPP MUC会话映射到MSRP多方消息传递会话。下图概述了示例会话的总体协议流，其中包括一些可选的交换（例如发送消息、更改昵称和邀请其他用户）。
XMPP XMPP SIP MSRP
User Server Conference Switch
| + X2S GW Focus + M2X GW
| & X2M GW + S2X GW |
| | | |
| (F1) XMPP | | |
| enter room | | |
|................>| | |
| | (F2) SIP INVITE | |
| |****************>| |
| | | (F3) |
| | | unstandardized |
| | | interaction |
| | |<&&&&&&&&&&&&&&&>|
| | (F4) SIP 200 OK | |
| |<****************| |
| | (F5) SIP ACK | |
| |****************>| |
| | (F6) MSRP SEND (bodiless) |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F7) MSRP 200 OK |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| | (F8) MSRP NICKNAME |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F9) MSRP 200 OK |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
XMPP XMPP SIP MSRP
User Server Conference Switch
| + X2S GW Focus + M2X GW
| & X2M GW + S2X GW |
| | | |
| (F1) XMPP | | |
| enter room | | |
|................>| | |
| | (F2) SIP INVITE | |
| |****************>| |
| | | (F3) |
| | | unstandardized |
| | | interaction |
| | |<&&&&&&&&&&&&&&&>|
| | (F4) SIP 200 OK | |
| |<****************| |
| | (F5) SIP ACK | |
| |****************>| |
| | (F6) MSRP SEND (bodiless) |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F7) MSRP 200 OK |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| | (F8) MSRP NICKNAME |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F9) MSRP 200 OK |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| | (F10) SIP | |
| | SUBSCRIBE | |
| | Event: | |
| | conference | |
| |****************>| |
| | (F11) SIP 200 OK| |
| |<****************| |
| | (F12) SIP NOTIFY| |
| |<****************| |
| | (F13) SIP 200 OK| |
| |****************>| |
| (F14) XMPP | | |
| presence | | |
|<................| | |
| (F15) XMPP | | |
| MUC subject | | |
|<................| | |
. . . .
. . . .
| (F16) XMPP | | |
| groupchat | | |
| message | | |
|................>| | |
| | (F17) MSRP SEND |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F18) MSRP 200 OK
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| (F19) XMPP | | |
| groupchat | | |
| message | | |
|<................| | |
. . . .
. . . .
| (F20) XMPP | | |
| private | | |
| message | | |
|................>| | |
| | (F21) MSRP SEND |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F22) MSRP 200 OK
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
. . . .
. . . .
| (F23) XMPP | | |
| presence: | | |
| change nick | | |
|................>| | |
| | (F10) SIP | |
| | SUBSCRIBE | |
| | Event: | |
| | conference | |
| |****************>| |
| | (F11) SIP 200 OK| |
| |<****************| |
| | (F12) SIP NOTIFY| |
| |<****************| |
| | (F13) SIP 200 OK| |
| |****************>| |
| (F14) XMPP | | |
| presence | | |
|<................| | |
| (F15) XMPP | | |
| MUC subject | | |
|<................| | |
. . . .
. . . .
| (F16) XMPP | | |
| groupchat | | |
| message | | |
|................>| | |
| | (F17) MSRP SEND |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F18) MSRP 200 OK
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| (F19) XMPP | | |
| groupchat | | |
| message | | |
|<................| | |
. . . .
. . . .
| (F20) XMPP | | |
| private | | |
| message | | |
|................>| | |
| | (F21) MSRP SEND |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F22) MSRP 200 OK
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
. . . .
. . . .
| (F23) XMPP | | |
| presence: | | |
| change nick | | |
|................>| | |
| | (F24) MSRP NICKNAME |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F25) MSRP 425 Error |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| (F26) XMPP | | |
| presence | | |
| error | | |
|<................| | |
. . . .
. . . .
| (F27) XMPP | | |
| message: | | |
| invite | | |
|................>| | |
| | (F28) SIP | |
| | REFER | |
| |****************>| |
| | (F29) SIP | |
| | 200 OK | |
| |<****************| |
| | (F30) SIP | |
| | NOTIFY | |
| |<****************| |
. . . .
. . . .
| (F31) XMPP | | |
| presence: | | |
| exit room | | |
|................>| | |
| | (F32) SIP BYE | |
| |****************>| |
| | (F33) SIP | |
| | 200 OK | |
| |<****************| |
| (F34) XMPP | | |
| presence | | |
| unavailable | | |
|<................| | |
| | | |
| | (F24) MSRP NICKNAME |
| |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>|
| | (F25) MSRP 425 Error |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| (F26) XMPP | | |
| presence | | |
| error | | |
|<................| | |
. . . .
. . . .
| (F27) XMPP | | |
| message: | | |
| invite | | |
|................>| | |
| | (F28) SIP | |
| | REFER | |
| |****************>| |
| | (F29) SIP | |
| | 200 OK | |
| |<****************| |
| | (F30) SIP | |
| | NOTIFY | |
| |<****************| |
. . . .
. . . .
| (F31) XMPP | | |
| presence: | | |
| exit room | | |
|................>| | |
| | (F32) SIP BYE | |
| |****************>| |
| | (F33) SIP | |
| | 200 OK | |
| |<****************| |
| (F34) XMPP | | |
| presence | | |
| unavailable | | |
|<................| | |
| | | |
Detailed protocol flows and mappings are provided in the following sections.
以下部分提供了详细的协议流和映射。
As defined in the XMPP Multi-User Chat (MUC) specification [XEP-0045], when an XMPP user (say, "juliet@example.com") wants to join a groupchat room (say, "montague@chat.example.org"), she sends a directed <presence/> stanza [RFC6121] to that chat room. In her request she also specifies the nickname she wants to use within the room (say, "JuliC"); in XMPP this room nickname is the resourcepart of an occupant JID (thus "montague@chat.example.org/JuliC"). The joining client signals its ability to speak the multi-user chat protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace.
正如XMPP多用户聊天（MUC）规范[XEP-0045]中所定义的，当一个XMPP用户juliet@example.com）想要加入群组聊天室（比如，“montague@chat.example.org）之后，她向该聊天室发送了一个定向的<presence/>节[RFC6121]。在她的请求中，她还指定了她想在房间里使用的昵称（比如“朱利克”）；在XMPP中，这个房间昵称是居住者JID的资源部分（因此”montague@chat.example.org/朱利克”）。加入的客户端通过在初始状态节中包含一个由'http://jabber.org/protocol/muc'名称空间。
Example 1: Juliet Enters Room (F1)
例1：朱丽叶进入房间（F1）
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/JuliC'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| </presence>
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/JuliC'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| </presence>
Upon receiving such a presence stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures discussed in [RFC7247]. Here we assume that the XMPP server has determined the domain is serviced by a SIP server, that it contains or has available to it an XMPP-to-SIP gateway or connection manager (which enables it to speak natively to SIP servers), and that it hands off the presence stanza to the XMPP-to-SIP gateway.
在接收到这样一个状态节时，XMPP服务器需要确定“to”地址中domainpart的标识，这是通过遵循[RFC7247]中讨论的过程来完成的。这里，我们假设XMPP服务器已确定域由SIP服务器提供服务，它包含或具有XMPP-to-SIP网关或连接管理器（使其能够以本机方式与SIP服务器通话），并且它将状态节交给XMPP-to-SIP网关。
Because a multi-user chat service accepts the presence stanza shown above as a request to enter a room, the XMPP-to-SIP gateway transforms it into a SIP INVITE request.
因为多用户聊天服务接受上面显示的状态节作为进入房间的请求，所以XMPP到SIP网关将其转换为SIP INVITE请求。
Example 2: SIP Mapping of Room Join (F2)
示例2：房间连接的SIP映射（F2）
| INVITE sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 1 INVITE
| Content-Type: application/sdp
| Content-Length: ...
|
| c=IN IP4 x2s.example.org
| m=message 7654 TCP/MSRP *
| a=accept-types:text/cpim
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://x2m.example.com:7654/jshA7weztas;tcp
| a=chatroom:nickname private-messages
| INVITE sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 1 INVITE
| Content-Type: application/sdp
| Content-Length: ...
|
| c=IN IP4 x2s.example.org
| m=message 7654 TCP/MSRP *
| a=accept-types:text/cpim
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://x2m.example.com:7654/jshA7weztas;tcp
| a=chatroom:nickname private-messages
Here the Session Description Protocol (SDP) offer specifies the XMPP-to-MSRP gateway on the XMPP side (in the SDP 'path' attribute specified in [RFC4975]) as well as other particulars of the session.
这里，会话描述协议（SDP）提供指定XMPP侧的XMPP到MSRP网关（在[RFC4975]中指定的SDP“path”属性中）以及会话的其他细节。
There is no direct mapping for the MSRP URIs. In fact, an MSRP URI identifies a session of instant messages at a particular device; it is ephemeral and has no meaning outside the scope of that session. The authority component of the MSRP URI here MUST contain the XMPP-to-MSRP gateway hostname or numeric IP address (as well as, in accordance with [RFC4975], an explicit port number).
MSRP URI没有直接映射。事实上，MSRP URI标识特定设备上的即时消息会话；它是短暂的，在该届会议范围之外没有任何意义。此处MSRP URI的授权组件必须包含XMPP到MSRP网关主机名或数字IP地址（以及，根据[RFC4975]，明确的端口号）。
The mapping of XMPP syntax elements to SIP and [RFC4566] syntax elements MUST be as shown in the following table.
XMPP语法元素到SIP和[RFC4566]语法元素的映射必须如下表所示。
Table 1: Message Syntax Mapping from XMPP to SIP/SDP
表1：从XMPP到SIP/SDP的消息语法映射
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | SIP Header or SDP Contents |
+-----------------------------+-----------------------------+
| from | From |
| to (without the /nick) | To |
+-----------------------------+-----------------------------+
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | SIP Header or SDP Contents |
+-----------------------------+-----------------------------+
| from | From |
| to (without the /nick) | To |
+-----------------------------+-----------------------------+
As shown in the foregoing example and described in [RFC7247], the XMPP-to-SIP gateway MUST map the bare JID ("localpart@domainpart") of the XMPP sender to the SIP From header and include the resourcepart of the full JID as the Globally Routable User Agent URI (GRUU)
如上述示例所示并在[RFC7247]中所述，XMPP到SIP网关必须映射裸JID（“localpart@domainpart），并将完整JID的resourcepart包含为全局可路由用户代理URI（GRUU）
portion [RFC5627] of the SIP URI. However, note that a SIP response uses the same From and To as in the SIP request, whereas an XMPP response swaps the from and to attributes.
SIPURI的[RFC5627]部分。但是，请注意，SIP响应使用与SIP请求中相同的From和To，而XMPP响应交换From和To属性。
Here we assume that the SIP conference focus accepts the session establishment. The Contact header field of the SIP 200 OK response includes the 'isfocus' feature tag specified in [RFC4353] along with other relevant feature tags. The conference focus also includes an answer session description that acknowledges the choice of media, specifies the MSRP URI of the switch (in the 'path' attribute specified in [RFC4975]), and contains the extensions specified in [RFC7701].
这里我们假设SIP会议焦点接受会话建立。SIP 200 OK响应的Contact header字段包括[RFC4353]中指定的“isfocus”功能标签以及其他相关功能标签。会议焦点还包括应答会话描述，该描述确认媒体的选择，指定交换机的MSRP URI（在[RFC4975]中指定的“路径”属性中），并包含[RFC7701]中指定的扩展。
Example 3: Chat Room Accepts Session Establishment (F4)
示例3：聊天室接受会话建立（F4）
| SIP/2.0 200 OK
| From: "Juliet" <sip:juliet@example.com>;tag=786
| To: <sip:montague@chat.example.org>;tag=087js
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 1 INVITE
| Contact: <sip:montague@chat.example.org;transport=tcp>;isfocus
| Content-Type: application/sdp
| Content-Length: ...
|
| v=0
| c=IN IP4 example.org
| s=-
| m=message 12763 TCP/MSRP *
| a=accept-types:message/cpim
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| a=chatroom:nickname private-messages
| SIP/2.0 200 OK
| From: "Juliet" <sip:juliet@example.com>;tag=786
| To: <sip:montague@chat.example.org>;tag=087js
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 1 INVITE
| Contact: <sip:montague@chat.example.org;transport=tcp>;isfocus
| Content-Type: application/sdp
| Content-Length: ...
|
| v=0
| c=IN IP4 example.org
| s=-
| m=message 12763 TCP/MSRP *
| a=accept-types:message/cpim
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| a=chatroom:nickname private-messages
Upon receiving such a response, the XMPP-to-SIP gateway sends a SIP ACK to the conference focus on behalf of the joining user.
在接收到这样的响应时，XMPP-to-SIP网关代表加入用户向会议焦点发送SIP ACK。
Example 4: Gateway Sends ACK to Conference Focus (F5)
示例4：网关向会议焦点发送ACK（F5）
| ACK sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>;tag=087js
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 2 ACK
| ACK sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>;tag=087js
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 2 ACK
In accordance with [RFC4975], the gateway sends a bodiless MSRP message (F6) to the switch immediately upon establishing the connection, and the switch acknowledges that message (F7).
根据[RFC4975]，网关在建立连接后立即向交换机发送一条无主体MSRP消息（F6），交换机确认该消息（F7）。
If the chat room server accepted the session, the XMPP-to-MSRP gateway sets up the nickname as received in the presence stanza (i.e., the resourcepart of the 'to' address, such as "JuliC" in "montague@chat.example.org/JuliC"). This is done using the extension specified in [RFC7701].
如果聊天室服务器接受了会话，XMPP-to-MSRP网关会设置在状态节中接收到的昵称（即“to”地址的resourcepart，例如“JuliC”in）montague@chat.example.org/朱利克”）。这是使用[RFC7701]中指定的扩展来完成的。
Example 5: Gateway Sets Up Nickname (F8)
示例5：网关设置昵称（F8）
| MSRP a786hjs2 NICKNAME
| To-Path: msrp://montague@chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Use-Nickname: "JuliC"
| -------a786hjs2
| MSRP a786hjs2 NICKNAME
| To-Path: msrp://montague@chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Use-Nickname: "JuliC"
| -------a786hjs2
The MSRP switch analyzes the existing allocation of nicknames, accepts the nickname proposal, and answers with a 200 response.
MSRP交换机分析昵称的现有分配，接受昵称建议，并以200回答。
Example 6: MSRP Switch Accepts Nickname Proposal (F9)
示例6:MSRP交换机接受昵称建议（F9）
| MSRP a786hjs2 200 OK
| To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| From-Path: msrp://montague@chat.example.org:12763/kjhd37s2s20w2a
| ;tcp
| -------a786hjs2
| MSRP a786hjs2 200 OK
| To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| From-Path: msrp://montague@chat.example.org:12763/kjhd37s2s20w2a
| ;tcp
| -------a786hjs2
This section assumes that the nickname request is successful. The error flow resulting from a nickname conflict is described under Section 5.6.
本节假设昵称请求成功。昵称冲突导致的错误流如第5.6节所述。
As mentioned in [RFC7701], the joining user will typically also subscribe to a conference event package (see [RFC4575] and [RFC6502]) at the focus. Although such a subscription is not required by [RFC7701] in practice the temporary and context-dependent presence subscriptions and room rosters involved in joining an XMPP MUC room are best mapped to the conference event package.
如[RFC7701]中所述，加入用户通常也会在焦点处订阅会议事件包（参见[RFC4575]和[RFC6502]）。尽管[RFC7701]在实践中不需要此类订阅，但加入XMPP MUC会议室所涉及的临时和上下文相关的状态订阅和会议室名册最好映射到会议事件包。
Example 7: Gateway Subscribes to the Conference (F10)
示例7：网关订阅会议（F10）
| SUBSCRIBE sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>;tag=087js
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 3 SUBSCRIBE
| Event: conference
| Expires: 600
| Accept: application/conference-info+xml
| Allow-Events: conference
| Content-Length: 0
| SUBSCRIBE sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>;tag=087js
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 3 SUBSCRIBE
| Event: conference
| Expires: 600
| Accept: application/conference-info+xml
| Allow-Events: conference
| Content-Length: 0
The focus will accept or reject the request based on local policy.
焦点将根据本地策略接受或拒绝请求。
Example 8: Focus Accepts Subscription Request (F11)
示例8:Focus接受订阅请求（F11）
| SIP/2.0 200 OK
| To: <sip:montague@chat.example.org>;tag=087js
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 3 SUBSCRIBE
| Contact: <sip:montague@chat.example.org;transport=tcp>;isfocus
| Expires: 600
| Content-Length: 0
| SIP/2.0 200 OK
| To: <sip:montague@chat.example.org>;tag=087js
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 3 SUBSCRIBE
| Contact: <sip:montague@chat.example.org;transport=tcp>;isfocus
| Expires: 600
| Content-Length: 0
If the conference focus accepts the request to enter a room, the XMPP user expects to receive back presence information from all the existing occupants of the room. To make this happen, the XMPP-to-SIP gateway subscribes to the conference event package [RFC4575] at the focus.
如果conference focus接受进入房间的请求，则XMPP用户希望从房间的所有现有占用者处接收返回状态信息。为了实现这一点，XMPP-To-SIP网关在焦点处订阅会议事件包[RFC4575]。
When the conference event package subscription is completed, the focus sends to the XMPP-to-SIP gateway a NOTIFY request containing the presence information of all the existing occupants, represented using the format defined in [RFC4575].
会议事件包订阅完成后，focus向XMPP to SIP网关发送一个NOTIFY请求，其中包含所有现有占用者的状态信息，使用[RFC4575]中定义的格式表示。
Example 9: Conference Focus Sends Presence Information (F12)
示例9：会议焦点发送状态信息（F12）
| NOTIFY sip:montague@chat.example.org SIP/2.0
| To: "Juliet" <sip:juliet@example.com>;tag=786
| From: <sip:montague@chat.example.org>;tag=087js
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 4 NOTIFY
| Event: conference
| Subscription-State: active;expires=3600
| Content-Type: application/conference-info+xml
| Content-Length: ...
|
| <conference-info version="0" state="full"
| entity="sip:3402934234@chat.example.org">
| <conference-description>
| <subject>Today in Verona</subject>
| <conf-uris>
| <entry>
| <uri>tel:+18882934234</uri>
| </entry>
| </conf-uris>
| </conference-description>
| <users>
| <user entity="sip:montague@chat.example.org;gr=Romeo"
| state="full">
| <display-text>Romeo</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <associated-aors>
| <entry>
| <uri>xmpp:romeo@example.org/dr4hcr0st3lup4c</uri>
| </entry>
| </associated-aors>
| <endpoint entity="sip:montague@chat.example.org;gr=Romeo"
| state="full">
| <status>connected</status>
| <joining-info>
| <when>2013-12-12T10:01:03.691128+01:00</when>
| </joining-info>
| <media id="211835820">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| <user entity="sip:montague@chat.example.org;gr=Ben"
| state="full">
| <display-text>Ben</display-text>
| NOTIFY sip:montague@chat.example.org SIP/2.0
| To: "Juliet" <sip:juliet@example.com>;tag=786
| From: <sip:montague@chat.example.org>;tag=087js
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 4 NOTIFY
| Event: conference
| Subscription-State: active;expires=3600
| Content-Type: application/conference-info+xml
| Content-Length: ...
|
| <conference-info version="0" state="full"
| entity="sip:3402934234@chat.example.org">
| <conference-description>
| <subject>Today in Verona</subject>
| <conf-uris>
| <entry>
| <uri>tel:+18882934234</uri>
| </entry>
| </conf-uris>
| </conference-description>
| <users>
| <user entity="sip:montague@chat.example.org;gr=Romeo"
| state="full">
| <display-text>Romeo</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <associated-aors>
| <entry>
| <uri>xmpp:romeo@example.org/dr4hcr0st3lup4c</uri>
| </entry>
| </associated-aors>
| <endpoint entity="sip:montague@chat.example.org;gr=Romeo"
| state="full">
| <status>connected</status>
| <joining-info>
| <when>2013-12-12T10:01:03.691128+01:00</when>
| </joining-info>
| <media id="211835820">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| <user entity="sip:montague@chat.example.org;gr=Ben"
| state="full">
| <display-text>Ben</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:montague@chat.example.org;gr=Ben"
| state="full">
| <status>connected</status>
| <media id="211835821">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| <user entity="sip:montague@chat.example.org;gr=JuliC"
| state="full">
| <display-text>JuliC</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:montague@chat.example.org;gr=JuliC"
| state="full">
| <status>connected</status>
| <media id="211835822">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| </users>
| </conference-info>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:montague@chat.example.org;gr=Ben"
| state="full">
| <status>connected</status>
| <media id="211835821">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| <user entity="sip:montague@chat.example.org;gr=JuliC"
| state="full">
| <display-text>JuliC</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:montague@chat.example.org;gr=JuliC"
| state="full">
| <status>connected</status>
| <media id="211835822">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| </users>
| </conference-info>
The syntax mapping from the RFC 4575 payload to the XMPP participant list MUST be as shown in the following table. (Mappings for elements not mentioned are undefined.)
从RFC4575有效负载到XMPP参与者列表的语法映射必须如下表所示。（未提及的元素映射未定义。）
Table 2: Participant list mapping
表2：参与者列表映射
+--------------------------------+-----------------------------+
| RFC 4575 Element or Attribute | XMPP Element or Attribute |
+--------------------------------+-----------------------------+
| <conference-info/> 'entity' | room JID |
| <subject/> | room subject |
| <user/> 'entity' | occupant JID |
| <display-text/> | participant nickname |
| <endpoint/> 'entity' | occupant JID |
| <user/> 'associated-aors' | user full JID (if avail.) |
+--------------------------------+-----------------------------+
+--------------------------------+-----------------------------+
| RFC 4575 Element or Attribute | XMPP Element or Attribute |
+--------------------------------+-----------------------------+
| <conference-info/> 'entity' | room JID |
| <subject/> | room subject |
| <user/> 'entity' | occupant JID |
| <display-text/> | participant nickname |
| <endpoint/> 'entity' | occupant JID |
| <user/> 'associated-aors' | user full JID (if avail.) |
+--------------------------------+-----------------------------+
Upon receiving such a response, the XMPP-to-SIP gateway sends a SIP 200 OK response to the conference focus (example not shown) and translates the participant list into a series of XMPP presence stanzas.
在接收到这样的响应时，XMPP-to-SIP网关向会议焦点（示例未示出）发送SIP 200 OK响应，并将参与者列表转换为一系列XMPP存在节。
Example 10: XMPP Mapping of Chat Room Presence (F14)
示例10：聊天室状态的XMPP映射（F14）
| <presence from='montague@chat.example.org/Romeo'
| to='juliet@example.com/yn0cl4bnw0yr3vym'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
| <presence from='montague@chat.example.org/Romeo'
| to='juliet@example.com/yn0cl4bnw0yr3vym'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
| <presence from='montague@chat.example.org/Ben'
| to='juliet@example.com/yn0cl4bnw0yr3vym'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
| <presence from='montague@chat.example.org/Ben'
| to='juliet@example.com/yn0cl4bnw0yr3vym'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
| <presence from='montague@chat.example.org/JuliC'
| to='juliet@example.com/yn0cl4bnw0yr3vym'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| <status code='110'/>
| </x>
| </presence>
| <presence from='montague@chat.example.org/JuliC'
| to='juliet@example.com/yn0cl4bnw0yr3vym'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| <status code='110'/>
| </x>
| </presence>
If the NOTIFY request included a subject, the gateway converts that into a separate XMPP message.
如果NOTIFY请求包含主题，网关会将其转换为单独的XMPP消息。
Example 11: XMPP Mapping of Chat Room Subject (F15)
示例11：聊天室主题的XMPP映射（F15）
| <message from='montague@chat.example.org/mayor'
| to='juliet@example.com/yn0cl4bnw0yr3vym'
| id='mbh2vd68'>
| <subject>Today in Verona</subject>
| </message>
| <message from='montague@chat.example.org/mayor'
| to='juliet@example.com/yn0cl4bnw0yr3vym'
| id='mbh2vd68'>
| <subject>Today in Verona</subject>
| </message>
The mapping of SIP and [RFC4575] payload syntax elements to XMPP syntax elements MUST be as shown in the following table. (Mappings for elements not mentioned are undefined.)
SIP和[RFC4575]有效负载语法元素到XMPP语法元素的映射必须如下表所示。（未提及的元素映射未定义。）
Table 3: Message Syntax Mapping from SIP to XMPP
表3：从SIP到XMPP的消息语法映射
+---------------------------------+-----------------------------+
| SIP Header or RFC 4575 Contents | XMPP Element or Attribute |
+---------------------------------+-----------------------------+
| <user/> 'entity' | from |
| To with <display-text> | occupant JID |
| <role>participant</role> | role='participant' |
| [N/A] | affiliation='none' |
+---------------------------------+-----------------------------+
+---------------------------------+-----------------------------+
| SIP Header or RFC 4575 Contents | XMPP Element or Attribute |
+---------------------------------+-----------------------------+
| <user/> 'entity' | from |
| To with <display-text> | occupant JID |
| <role>participant</role> | role='participant' |
| [N/A] | affiliation='none' |
+---------------------------------+-----------------------------+
Once the user has joined the chat room, the user can exchange an unbounded number of messages, both public and private.
一旦用户加入聊天室，用户可以交换无限数量的消息，包括公共消息和私人消息。
The mapping of XMPP syntax elements to MSRP syntax elements MUST be as shown in the following table. (Mappings for elements not mentioned are undefined.)
XMPP语法元素到MSRP语法元素的映射必须如下表所示。（未提及的元素映射未定义。）
Table 4: Message Syntax Mapping from XMPP Message to MSRP
表4：从XMPP消息到MSRP的消息语法映射
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | CPIM Header |
+-----------------------------+-----------------------------+
| to | To |
| from | From |
| <body/> | body of the SEND request |
+-----------------------------+-----------------------------+
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | CPIM Header |
+-----------------------------+-----------------------------+
| to | To |
| from | From |
| <body/> | body of the SEND request |
+-----------------------------+-----------------------------+
When Juliet wants to sends a message to all other occupants in the room, she sends a message of type "groupchat" to the <room@service> itself (in our example, <montague@chat.example.org>).
当朱丽叶想要向房间里的所有其他住户发送消息时，她会向<room@service>本身（在我们的例子中<montague@chat.example.org>).
The following examples show an exchange of a public message.
以下示例显示了公共消息的交换。
Example 12: Juliet Sends Message to All Occupants (F16)
示例12：朱丽叶向所有居住者发送消息（F16）
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org'
| type='groupchat'
| id='lzfed24s'>
| <body>Who knows where Romeo is?</body>
| </message>
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org'
| type='groupchat'
| id='lzfed24s'>
| <body>Who knows where Romeo is?</body>
| </message>
Upon receiving such a message, the XMPP-to-MSRP gateway translates it into an MSRP SEND message.
接收到这样的消息后，XMPP到MSRP网关将其转换为MSRP发送消息。
Example 13: Gateway Maps XMPP Message to MSRP (F17)
示例13：网关将XMPP消息映射到MSRP（F17）
| MSRP a786hjs2 SEND
| To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Message-ID: 87652491
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:montague@chat.example.org>
| From: "Juliet" <sip:juliet@example.com>
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| Who knows where Romeo is?
| -------a786hjs2$
| MSRP a786hjs2 SEND
| To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Message-ID: 87652491
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:montague@chat.example.org>
| From: "Juliet" <sip:juliet@example.com>
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| Who knows where Romeo is?
| -------a786hjs2$
Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header at all, the MSRP switch immediately generates and sends a response.
收到发送请求后，如果请求包含故障报告标题字段值“是”或根本不包含故障报告标题，则MSRP开关立即生成并发送响应。
Example 14: MSRP Switch Returns 200 OK (F18)
示例14:MSRP开关返回200 OK（F18）
| MSRP d93kswow 200 OK
| To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| -------d93kswow$
| MSRP d93kswow 200 OK
| To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| -------d93kswow$
Since an XMPP MUC room could be moderated and an XMPP user cannot be sure whether her message has been accepted without receiving it back from the server, [XEP-0045] states that the sender needs to receive a reflected copy of the message it sent. So, in this scenario, the XMPP-to-MSRP gateway has to reflect the message back to the sender. This procedure only applies to XMPP endpoints.
由于XMPP MUC会议室可以被主持，并且XMPP用户在没有从服务器接收回消息的情况下无法确定其消息是否已被接受，[XEP-0045]表示发送方需要接收其发送的消息的反射副本。因此，在这种情况下，XMPP到MSRP网关必须将消息反射回发送方。此过程仅适用于XMPP端点。
Example 15: Gateway Reflects Message to XMPP User (F19)
示例15：网关将消息反映给XMPP用户（F19）
| <message from='montague@chat.example.org/JuliC'
| to='juliet@example.com/yn0cl4bnw0yr3vym'
| type='groupchat'
| id='ix51z73m'>
| <body>Who knows where Romeo is?</body>
| </message>
| <message from='montague@chat.example.org/JuliC'
| to='juliet@example.com/yn0cl4bnw0yr3vym'
| type='groupchat'
| id='ix51z73m'>
| <body>Who knows where Romeo is?</body>
| </message>
Since each occupant has a unique JID, Juliet can send a "private message" to a selected occupant through the service by sending a message to the user's occupant JID. The XMPP message type ought to be "chat" (and is not allowed to be "groupchat").
由于每个居住者都有一个唯一的JID，Juliet可以通过服务向用户的居住者JID发送消息，从而向选定的居住者发送“私人消息”。XMPP消息类型应该是“chat”（并且不允许是“groupchat”）。
The following examples show an exchange of a private message.
下面的示例显示了私有消息的交换。
Example 16: Juliet Sends Private Message (F20)
示例16：朱丽叶发送私人消息（F20）
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/Romeo'
| type='chat'
| id='6sfln45q'>
| <body>O Romeo, Romeo! wherefore art thou Romeo?</body>
| </message>
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/Romeo'
| type='chat'
| id='6sfln45q'>
| <body>O Romeo, Romeo! wherefore art thou Romeo?</body>
| </message>
Upon receiving such a message, the XMPP-to-MSRP gateway translates it into an MSRP SEND message.
接收到这样的消息后，XMPP到MSRP网关将其转换为MSRP发送消息。
Example 17: Gateway Maps Private Message from XMPP to MSRP (F21)
示例17：网关将私有消息从XMPP映射到MSRP（F21）
| MSRP a786hjs2 SEND
| To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Message-ID: 87652491
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:montague@chat.example.org>;gr=Romeo
| From: <sip:juliet@example.org>;gr=yn0cl4bnw0yr3vym
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| O Romeo, Romeo! wherefore art thou Romeo?
| -------a786hjs2$
| MSRP a786hjs2 SEND
| To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Message-ID: 87652491
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:montague@chat.example.org>;gr=Romeo
| From: <sip:juliet@example.org>;gr=yn0cl4bnw0yr3vym
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| O Romeo, Romeo! wherefore art thou Romeo?
| -------a786hjs2$
After acknowledging the message by sending an MSRP 200 OK message (step F22, not shown), the MSRP switch is responsible for sending the message to the intended recipient. When doing so, it modifies the From header to the sender's address within the chat room.
在通过发送MSRP 200 OK消息（步骤F22，未示出）确认该消息之后，MSRP交换机负责将该消息发送到预期接收者。这样做时，它会将From标头修改为聊天室中发件人的地址。
Example 18: Switch Sends Private Message to SIP User
示例18：交换机向SIP用户发送私有消息
| MSRP a786hjs2 SEND
| To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Message-ID: 87652491
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:romeo@example.org>
| From: <sip:montague@chat.example.org>;gr=JuliC
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| O Romeo, Romeo! wherefore art thou Romeo?
| -------a786hjs2$
| MSRP a786hjs2 SEND
| To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| Message-ID: 87652491
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:romeo@example.org>
| From: <sip:montague@chat.example.org>;gr=JuliC
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| O Romeo, Romeo! wherefore art thou Romeo?
| -------a786hjs2$
Note: If an XMPP-to-MSRP gateway has support for private messaging, it MUST advertise that fact by adding a "private-messages" value to the a=chatroom SDP attribute it sends to the conference focus, as specified in [RFC7701].
注意：如果XMPP-to-MSRP网关支持私有消息传递，则必须按照[RFC7701]中的规定，通过将“私有消息”值添加到发送到会议焦点的a=chatroom SDP属性来公布该事实。
| a=chatroom:nickname private-messages
|a=聊天室：昵称私人消息
The XMPP user might want to change her nickname. She can do so by sending an updated presence stanza to the room, containing a new nickname.
XMPP用户可能想要更改她的昵称。她可以通过向房间发送一个更新的状态节来做到这一点，其中包含一个新的昵称。
Example 19: Juliet Changes Her Nickname (F23)
例19：朱丽叶改名（F23）
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/CapuletGirl'/>
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/CapuletGirl'/>
So far we have assumed that the requested nickname did not conflict with any existing nicknames. The following text describes the handling of a nickname conflict.
到目前为止，我们假设请求的昵称与任何现有昵称都没有冲突。以下文字描述了昵称冲突的处理。
The MSRP switch analyzes the existing allocation of nicknames, and detects that the nickname proposal is already provided to another participant. In this case, the MSRP switch answers with a 425 response.
MSRP交换机分析昵称的现有分配，并检测到昵称建议已提供给另一参与者。在这种情况下，MSRP开关的响应为425。
Example 20: MSRP Switch Does Not Accept Nickname Proposal (F25)
示例20:MSRP交换机不接受昵称建议（F25）
| MSRP a786hjs2 425 Nickname usage failed
| To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| -------a786hjs2
| MSRP a786hjs2 425 Nickname usage failed
| To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp
| From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp
| -------a786hjs2
Upon receiving such a response, the XMPP-to-MSRP gateway translates it into an XMPP presence stanza of type "error", specifying a <conflict/> error condition (which implies that the XMPP client will then need to choose another nickname and repeat the process of joining).
收到这样的响应后，XMPP-to-MSRP网关将其转换为“error”类型的XMPP存在节，指定<conflict/>错误条件（这意味着XMPP客户端需要选择另一个昵称并重复加入过程）。
Example 21: Conflict Error for Nickname (F26)
示例21：昵称冲突错误（F26）
| <presence from='montague@chat.example.org/JuliC'
| to='juliet@example.com/yn0cl4bnw0yr3vym'
| type='error'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| <error type='cancel' by='montague@chat.example.org'>
| <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
| </error>
| </presence>
| <presence from='montague@chat.example.org/JuliC'
| to='juliet@example.com/yn0cl4bnw0yr3vym'
| type='error'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| <error type='cancel' by='montague@chat.example.org'>
| <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
| </error>
| </presence>
Alternatively, the gateway might generate a new nickname request on behalf of the XMPP user, thus shielding the XMPP client from handling the conflict error.
或者，网关可以代表XMPP用户生成一个新的昵称请求，从而屏蔽XMPP客户端处理冲突错误。
In XMPP, there are two methods for inviting another user to a room: direct invitations [XEP-0249] (sent directly from the user's real JID outside the room to the invitee's real JID) and mediated invitations (sent through the room from the user's occupant JID to the invitee's JID). In this document, we cover mediated invitations only.
在XMPP中，有两种方法可以邀请另一个用户到房间：直接邀请[XEP-0249]（从房间外用户的真实JID直接发送到被邀请者的真实JID）和中介邀请（通过房间从用户的住户JID发送到被邀请者的JID）。在本文档中，我们仅介绍中介邀请。
For example, if Juliet decides to invite Benvolio to the room, she sends a message stanza with an invite and Benvolio's JID (which could be his real JID or an occupant JID in another room).
例如，如果朱丽叶决定邀请本沃里奥来房间，她会发送一个带有邀请和本沃里奥的JID（可能是他真正的JID，也可能是另一个房间的住户JID）的信息节。
Example 22: Juliet Invites Benvolio to the Room (F27)
例22：朱丽叶邀请本沃里奥到房间（F27）
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| id='nzd143v8'
| to='montague@chat.example.org'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <invite to='benvolio@example.com'/>
| </x>
| </message>
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| id='nzd143v8'
| to='montague@chat.example.org'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <invite to='benvolio@example.com'/>
| </x>
| </message>
The XMPP-to-SIP gateway then sends a SIP REFER request to the conference focus indicating who needs to be invited in the Refer-To header, as per Section 5.5 of [RFC4579].
然后，根据[RFC4579]第5.5节，XMPP到SIP网关向会议焦点发送SIP REFER请求，指示需要在REFER REFER报头中邀请谁。
Example 23: SIP Mapping of Invite (F28)
示例23:Invite的SIP映射（F28）
| REFER sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 5 REFER
| Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
| Accept: message/sipfrag
| Refer-To: <sip:benvolio@example.com>
| Supported: replaces
| Content-Length: 0
| REFER sip:montague@chat.example.org SIP/2.0
| To: <sip:montague@chat.example.org>
| From: "Juliet" <sip:juliet@example.com>;tag=786
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 5 REFER
| Contact: <sip:juliet@example.com>;gr=yn0cl4bnw0yr3vym
| Accept: message/sipfrag
| Refer-To: <sip:benvolio@example.com>
| Supported: replaces
| Content-Length: 0
The conference focus then acknowledges the SIP REFER request with a 200 OK response (step F29, not shown).
然后，会议焦点以200 OK响应确认SIP REFER请求（步骤F29，未示出）。
The progress of the invitation will be tracked by the received NOTIFY requests as per [RFC3515].
根据[RFC3515]，将通过收到的通知请求跟踪邀请的进度。
Example 24: Progress Notification for Invitation (F30)
示例24：邀请的进度通知（F30）
| NOTIFY sip:juliet@example.com SIP/2.0
| To: <sip:juliet@example.com>;tag=786
| From: <sip:montague@chat.example.org>;tag=087js
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 6 NOTIFY
| Max-Forwards: 70
| Event: refer
| Subscription-State: active;expires=60
| Contact: <sip:montague@chat.example.org;transport=tcp>;isfocus
| Content-Type: message/sipfrag;version=2.0
| Content-Length: ...
| NOTIFY sip:juliet@example.com SIP/2.0
| To: <sip:juliet@example.com>;tag=786
| From: <sip:montague@chat.example.org>;tag=087js
| Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7
| CSeq: 6 NOTIFY
| Max-Forwards: 70
| Event: refer
| Subscription-State: active;expires=60
| Contact: <sip:montague@chat.example.org;transport=tcp>;isfocus
| Content-Type: message/sipfrag;version=2.0
| Content-Length: ...
Note: Implementers might want to be aware that several recently published specifications modify the way in which REFER requests handle SIP notifications (see [RFC7647] and [RFC7614]).
注意：实现者可能希望知道，最近发布的几个规范修改了REFER请求处理SIP通知的方式（请参见[RFC7647]和[RFC7614]）。
If Juliet decides to exit the chat room, her client sends a directed presence stanza of type "unavailable" to the occupant JID she is currently using in the room (here <montague@chat.example.org/JuliC>).
如果Juliet决定退出聊天室，她的客户会向她当前在聊天室中使用的JID使用者发送一个类型为“不可用”的指示状态节（此处<montague@chat.example.org/朱利克>）。
Example 25: Juliet Exits Room (F31)
例25：朱丽叶离开房间（F31）
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/JuliC'
| type='unavailable'/>
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/JuliC'
| type='unavailable'/>
Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE to the conference focus and the conference focus responds with a SIP 200 OK (steps F32 and F33, not shown).
在接收到这样的节时，XMPP-to-SIP网关通过向会议焦点发送SIP BYE来终止SIP会话，并且会议焦点以SIP 200 OK响应（步骤F32和F33，未示出）。
Juliet can include a custom exit message in the presence stanza of type "unavailable", in which case it is broadcast to other participants using the methods described above.
Juliet可以在类型为“不可用”的状态节中包含自定义退出消息，在这种情况下，使用上述方法将其广播给其他参与者。
Example 26: Juliet Exits the Chat Room (F31)
例26：朱丽叶退出聊天室（F31）
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/JuliC'
| type='unavailable'>
| <status>O, look! methinks I see my cousin's ghost</status>
| </presence>
| <presence from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='montague@chat.example.org/JuliC'
| type='unavailable'>
| <status>O, look! methinks I see my cousin's ghost</status>
| </presence>
This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP MUC session. As before, the following diagram outlines the overall protocol flow of a sample session, which includes some optional exchanges (such as sending messages, changing nickname, and inviting another user).
本节介绍如何将多方即时消息（IM）MSRP会话映射到XMPP MUC会话。与前面一样，下图概述了示例会话的总体协议流，其中包括一些可选的交换（例如发送消息、更改昵称和邀请其他用户）。
SIP SIP MSRP XMPP
User Proxy Switch Server
| + S2X GW + M2X GW +X2S GW
| | | +X2M GW
| | | |
| (F35) SIP | | |
| INVITE | | |
|****************>| | |
| (F36) SIP | | |
| 200 OK | | |
|<****************| | |
| (F37) SIP ACK | | |
|****************>| | |
| (F38) SIP | | |
| SUBSCRIBE | | |
| Event: | | |
| conference | | |
|****************>| | |
| (F39) SIP | | |
| 200 OK | | |
|<****************| | |
| | (F40) XMPP presence: enter room |
| |..................................>|
| | (F41) XMPP presence |
| |<..................................|
| (F42) SIP | | |
| NOTIFY | | |
|<****************| | |
| (F43) SIP | | |
| 200 OK | | |
|****************>| | |
. . . .
. . . .
| (F44) MSRP SEND | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| | | (F45) XMPP |
| | | groupchat |
| | | message |
| | |................>|
| | | (F46) XMPP |
| | | groupchat |
| | | message |
| | |<................|
| (F47) MSRP 200 OK | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
SIP SIP MSRP XMPP
User Proxy Switch Server
| + S2X GW + M2X GW +X2S GW
| | | +X2M GW
| | | |
| (F35) SIP | | |
| INVITE | | |
|****************>| | |
| (F36) SIP | | |
| 200 OK | | |
|<****************| | |
| (F37) SIP ACK | | |
|****************>| | |
| (F38) SIP | | |
| SUBSCRIBE | | |
| Event: | | |
| conference | | |
|****************>| | |
| (F39) SIP | | |
| 200 OK | | |
|<****************| | |
| | (F40) XMPP presence: enter room |
| |..................................>|
| | (F41) XMPP presence |
| |<..................................|
| (F42) SIP | | |
| NOTIFY | | |
|<****************| | |
| (F43) SIP | | |
| 200 OK | | |
|****************>| | |
. . . .
. . . .
| (F44) MSRP SEND | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| | | (F45) XMPP |
| | | groupchat |
| | | message |
| | |................>|
| | | (F46) XMPP |
| | | groupchat |
| | | message |
| | |<................|
| (F47) MSRP 200 OK | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
. . . .
| (F48) MSRP SEND | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| (F49) MSRP 200 OK | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
| | | (F50) XMPP |
| | | message |
| | |................>|
. . . .
. . . .
| (F51) MSRP NICKNAME | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| | | (F52) XMPP |
| | | presence |
| | |................>|
| | | (F53) XMPP |
| | | presence |
| | | error |
| | |<................|
| (F54) MSRP 425 Error | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
. . . .
| (F55) SIP REFER | | |
|****************>| | |
| (F56) SIP | | |
| 200 OK | | |
|<****************| | |
| (F57) SIP | | |
| NOTIFY | | |
|<****************| | |
| | (F58) XMPP message invite |
| |..................................>|
. . . .
. . . .
| (F59) SIP BYE | | |
|****************>| | |
| | (F60) XMPP presence unavailable |
| |..................................>|
| | (F61) XMPP presence unavailable |
| |<..................................|
| (F62) SIP | | |
| 200 OK | | |
|<****************| | |
| | | |
. . . .
| (F48) MSRP SEND | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| (F49) MSRP 200 OK | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
| | | (F50) XMPP |
| | | message |
| | |................>|
. . . .
. . . .
| (F51) MSRP NICKNAME | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| | | (F52) XMPP |
| | | presence |
| | |................>|
| | | (F53) XMPP |
| | | presence |
| | | error |
| | |<................|
| (F54) MSRP 425 Error | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
. . . .
| (F55) SIP REFER | | |
|****************>| | |
| (F56) SIP | | |
| 200 OK | | |
|<****************| | |
| (F57) SIP | | |
| NOTIFY | | |
|<****************| | |
| | (F58) XMPP message invite |
| |..................................>|
. . . .
. . . .
| (F59) SIP BYE | | |
|****************>| | |
| | (F60) XMPP presence unavailable |
| |..................................>|
| | (F61) XMPP presence unavailable |
| |<..................................|
| (F62) SIP | | |
| 200 OK | | |
|<****************| | |
| | | |
If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the conference event, then the server SHOULD cache the participant list until the subscription is established and delivered in a SIP NOTIFY request.
如果在为会议事件建立SIP SUBSCRIBE对话框之前收到XMPP状态节，则服务器应缓存参与者列表，直到在SIP NOTIFY请求中建立并交付订阅。
When the SIP user ("Romeo") wants to join a groupchat room ("capulet"), he first has to start the SIP session by sending out a SIP INVITE request containing an offered session description that includes an MSRP media line accompanied by mandatory 'path' and 'chatroom' attributes. Here we assume that Romeo's user agent has been configured to be aware of an MSRP switch (chat.example.org) it can use. The MSRP media line is also accompanied by an 'accept-types' attribute specifying support for a Message/CPIM [RFC3862] top-level wrapper for the MSRP message.
当SIP用户（“Romeo”）想要加入群组聊天室（“capulet”）时，他首先必须通过发送SIP INVITE请求来启动SIP会话，该请求包含提供的会话描述，该会话描述包括MSRP媒体线路以及强制的“路径”和“聊天室”属性。在这里，我们假设罗密欧的用户代理已经被配置为知道它可以使用的MSRP交换机（chat.example.org）。MSRP媒体行还附带一个“accept types”属性，指定对MSRP消息的消息/CPIM[RFC3862]顶级包装的支持。
Example 27: SIP User Starts Session (F35)
示例27:SIP用户启动会话（F35）
| INVITE sip:capulet@rooms.example.com SIP/2.0
| From: "Romeo" <sip:romeo@example.org>;tag=43524545
| To: <sip:capulet@rooms.example.com>
| Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 1 INVITE
| Content-Type: application/sdp
| Content-Length: ...
|
| c=IN IP4 s2x.example.org
| m=message 7313 TCP/MSRP *
| a=accept-types:message/cpim text/plain text/html
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://chat.example.org:7313/ansp71weztas;tcp
| a=chatroom:nickname private-messages
| INVITE sip:capulet@rooms.example.com SIP/2.0
| From: "Romeo" <sip:romeo@example.org>;tag=43524545
| To: <sip:capulet@rooms.example.com>
| Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 1 INVITE
| Content-Type: application/sdp
| Content-Length: ...
|
| c=IN IP4 s2x.example.org
| m=message 7313 TCP/MSRP *
| a=accept-types:message/cpim text/plain text/html
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://chat.example.org:7313/ansp71weztas;tcp
| a=chatroom:nickname private-messages
Upon receiving the INVITE, the SIP proxy needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures discussed in [RFC7247]. Here we assume that the SIP proxy has determined that the domain is serviced by an XMPP server, that it contains or has available to it a SIP-to-XMPP gateway or connection manager (which enables it to speak natively to XMPP servers), and that it hands off the message to the gateway.
收到INVITE后，SIP代理需要确定请求URI或to头的域部分的标识，这是通过遵循[RFC7247]中讨论的过程来完成的。这里，我们假设SIP代理已确定域由XMPP服务器提供服务，它包含或具有SIP-to-XMPP网关或连接管理器（使其能够以本机方式与XMPP服务器通话），并且它将消息传递给网关。
Implementations MAY wait until the nickname is set with an MSRP NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary nickname (such as the SIP From header display name) and use it to join the room. Here we assume the latter.
在加入XMPP MUC之前，实现可以等到昵称被设置为MSRP昵称块，或者可以选择一个临时昵称（例如SIP From头显示名称）并使用它加入房间。这里我们假设后者。
Example 28: SIP-to-XMPP Gateway ACKs Session (F36)
示例28:SIP到XMPP网关ACKs会话（F36）
| SIP/2.0 200 OK
| From: "Romeo" <sip:romeo@example.org>;tag=43524545
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| Contact: <sip:rooms.example.com;transport=tcp>;isfocus
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 1 INVITE
| Content-Type: application/sdp
|
| m=message 8763 TCP/MSRP *
| a=accept-types:message/cpim text/plain text/html
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
| a=chatroom:nickname private-messages
| SIP/2.0 200 OK
| From: "Romeo" <sip:romeo@example.org>;tag=43524545
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| Contact: <sip:rooms.example.com;transport=tcp>;isfocus
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 1 INVITE
| Content-Type: application/sdp
|
| m=message 8763 TCP/MSRP *
| a=accept-types:message/cpim text/plain text/html
| a=accept-wrapped-types:text/plain text/html
| a=path:msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
| a=chatroom:nickname private-messages
The SIP/MSRP user agent subscribes to a conference event package at the destination groupchat service.
SIP/MSRP用户代理在目标groupchat服务订阅会议事件包。
Example 29: Gateway Subscribes to the Conference (F38)
示例29：网关订阅会议（F38）
| SUBSCRIBE sip:capulet@rooms.example.com SIP/2.0
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| From: "Romeo" <sip:romeo@example.org>;tag=43524545
| Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 2 SUBSCRIBE
| Event: conference
| Expires: 600
| Accept: application/conference-info+xml
| Allow-Events: conference
| Content-Length: 0
| SUBSCRIBE sip:capulet@rooms.example.com SIP/2.0
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| From: "Romeo" <sip:romeo@example.org>;tag=43524545
| Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 2 SUBSCRIBE
| Event: conference
| Expires: 600
| Accept: application/conference-info+xml
| Allow-Events: conference
| Content-Length: 0
After the conference subscription request is acknowledged, the SIP-to-XMPP gateway sends presence from Romeo to the MUC chat room.
确认会议订阅请求后，SIP到XMPP网关将状态从Romeo发送到MUC聊天室。
Example 30: Romeo Enters XMPP Chat Room (F40)
示例30：罗密欧进入XMPP聊天室（F40）
| <presence from='romeo@example.org/dr4hcr0st3lup4c'
| to='montague@chat.example.org/Romeo'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| </presence>
| <presence from='romeo@example.org/dr4hcr0st3lup4c'
| to='montague@chat.example.org/Romeo'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| </presence>
If the MUC service is able to add the SIP/MSRP user to the room, it sends presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an <x/> element.
如果MUC服务能够将SIP/MSRP用户添加到房间中，它会将所有现有居住者房间JID的状态发送到新居住者的完整JID，包括有关<x/>元素中角色的扩展状态信息。
Example 31: XMPP Service Sends Presence from Existing Occupants to New Occupant (F41)
示例31:XMPP服务将现有乘员的存在发送给新乘员（F41）
| <presence from='capulet@rooms.example.com/Romeo'
| to='romeo@example.org/dr4hcr0st3lup4c'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| <status code='110'/>
| </x>
| </presence>
|
| <presence from='capulet@rooms.example.com/Ben'
| to='romeo@example.org/dr4hcr0st3lup4c'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
|
| <presence from='capulet@rooms.example.com/JuliC'
| to='romeo@example.org/dr4hcr0st3lup4c'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
| <presence from='capulet@rooms.example.com/Romeo'
| to='romeo@example.org/dr4hcr0st3lup4c'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| <status code='110'/>
| </x>
| </presence>
|
| <presence from='capulet@rooms.example.com/Ben'
| to='romeo@example.org/dr4hcr0st3lup4c'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
|
| <presence from='capulet@rooms.example.com/JuliC'
| to='romeo@example.org/dr4hcr0st3lup4c'>
| <x xmlns='http://jabber.org/protocol/muc#user'>
| <item affiliation='none' role='participant'/>
| </x>
| </presence>
Upon receiving these presence stanzas, if the conference focus has already completed the subscription to the conference event package [RFC4575], the XMPP-to-SIP gateway translates them into a SIP NOTIFY request containing the participant list (represented in the conference-info format specified in [RFC4575]).
收到这些出席节后，如果会议焦点已经完成对会议事件包[RFC4575]的订阅，XMPP到SIP网关将其转换为包含参与者列表（以[RFC4575]中指定的会议信息格式表示）的SIP通知请求。
Example 32: SIP Mapping of XMPP Participant Presence Stanzas (F42)
示例32:XMPP参与者状态节的SIP映射（F42）
| NOTIFY sip:romeo@example.org SIP/2.0
| To: <sip:romeo@example.org>;tag=43524545
| From: <sip:capulet@rooms.example.com>;tag=a3343df32
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 3 NOTIFY
| Event: conference
| Subscription-State: active;expires=3600
| Content-Type: application/conference-info+xml
| Content-Length: ...
|
| <conference-info version="0" state="full"
| entity="sip:capulet@rooms.example.com">
| <conference-description>
| <subject>Today in Verona</subject>
| <conf-uris>
| <entry>
| <uri>tel:+18882934234</uri>
| <uri>sip:capulet@rooms.example.com</uri>
| </entry>
| </conf-uris>
| </conference-description>
| <users>
| <user entity="sip:capulet@rooms.example.com;gr=JuliC"
| state="full">
| <display-text>JuliC</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:capulet@rooms.example.com;gr=JuliC"
| state="full">
| <status>connected</status>
| <media id="211835821">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| <user entity="sip:capulet@rooms.example.com;gr=Ben"
| state="full">
| <display-text>Ben</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:capulet@rooms.example.com;gr=Ben"
| state="full">
| <status>connected</status>
| <media id="211835822">
| NOTIFY sip:romeo@example.org SIP/2.0
| To: <sip:romeo@example.org>;tag=43524545
| From: <sip:capulet@rooms.example.com>;tag=a3343df32
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 3 NOTIFY
| Event: conference
| Subscription-State: active;expires=3600
| Content-Type: application/conference-info+xml
| Content-Length: ...
|
| <conference-info version="0" state="full"
| entity="sip:capulet@rooms.example.com">
| <conference-description>
| <subject>Today in Verona</subject>
| <conf-uris>
| <entry>
| <uri>tel:+18882934234</uri>
| <uri>sip:capulet@rooms.example.com</uri>
| </entry>
| </conf-uris>
| </conference-description>
| <users>
| <user entity="sip:capulet@rooms.example.com;gr=JuliC"
| state="full">
| <display-text>JuliC</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:capulet@rooms.example.com;gr=JuliC"
| state="full">
| <status>connected</status>
| <media id="211835821">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| <user entity="sip:capulet@rooms.example.com;gr=Ben"
| state="full">
| <display-text>Ben</display-text>
| <roles>
| <entry>participant</entry>
| </roles>
| <endpoint entity="sip:capulet@rooms.example.com;gr=Ben"
| state="full">
| <status>connected</status>
| <media id="211835822">
| <type>message</type>
| </media>
| </endpoint>
| </user>
| </users>
| </conference-info>
| <type>message</type>
| </media>
| </endpoint>
| </user>
| </users>
| </conference-info>
Because the "room roster" is communicated in XMPP by means of multiple presence stanzas (one for each participant) whereas the participant list is communicated in SIP by means of a single conference information document, the SIP-to-XMPP gateway will need to keep track of the user's SIP URI and the mapping of that URI into an XMPP address; then, based on that mapping, it will need to determine when it has received a complete room roster from the MUC room, i.e., when it has received the in-room presence of the SIP user (which according to [XEP-0045] is the last presence stanza received in the initial batch sent after joining). Once that happens, the SIP-to-XMPP gateway can construct the conference information document containing the complete participant list and send that to the SIP user.
由于“房间名册”在XMPP中通过多个在场节（每个参与者一个）进行通信，而参与者列表在SIP中通过单个会议信息文档进行通信，因此SIP到XMPP网关将需要跟踪用户的SIP URI以及该URI到XMPP地址的映射；然后，根据该映射，它将需要确定何时从MUC房间收到完整的房间名册，即何时收到SIP用户的室内状态（根据[XEP-0045]，这是加入后发送的初始批中收到的最后一个状态节）。一旦发生这种情况，SIP-to-XMPP网关就可以构建包含完整参与者列表的会议信息文档，并将其发送给SIP用户。
Once the user has joined the chat room, the user can exchange an unbounded number of messages, both public and private.
一旦用户加入聊天室，用户可以交换无限数量的消息，包括公共消息和私人消息。
The mapping of MSRP syntax elements to XMPP syntax elements MUST be as shown in the following table. (Mappings for elements not mentioned are undefined.)
MSRP语法元素到XMPP语法元素的映射必须如下表所示。（未提及的元素映射未定义。）
Table 5: Message Syntax Mapping from MSRP Message to XMPP
表5：从MSRP消息到XMPP的消息语法映射
+-----------------------------+-----------------------------+
| CPIM Header |XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| To | to |
| From | from |
| body of the SEND request | <body/> |
+-----------------------------+-----------------------------+
+-----------------------------+-----------------------------+
| CPIM Header |XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| To | to |
| From | from |
| body of the SEND request | <body/> |
+-----------------------------+-----------------------------+
When Romeo wants to send a message to all other occupants in the room, he sends an MSRP SEND request to <room@service> (<capulet@rooms.example.com> in our example).
当罗密欧想要向房间里的其他所有人发送信息时，他会向<room@service> (<capulet@rooms.example.com>在我们的示例中）。
The following examples show an exchange of a public message.
以下示例显示了公共消息的交换。
Example 33: Romeo Sends a Message to the Chat Room (F44)
示例33：罗密欧向聊天室发送消息（F44）
| MSRP a786hjs2 SEND
| To-Path: msrp://room.example.com:7313/ansp71weztas;tcp
| From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
| Message-ID: 87652492
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:capulet@rooms.example.com>
| From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| Romeo is here!
| -------a786hjs2$
| MSRP a786hjs2 SEND
| To-Path: msrp://room.example.com:7313/ansp71weztas;tcp
| From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
| Message-ID: 87652492
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:capulet@rooms.example.com>
| From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| Romeo is here!
| -------a786hjs2$
Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header at all, the SIP-to-XMPP gateway immediately translates it into an XMPP message stanza and then generates and sends an MSRP response.
收到发送请求后，如果请求包含故障报告头字段值“是”或根本不包含故障报告头，SIP到XMPP网关会立即将其转换为XMPP消息节，然后生成并发送MSRP响应。
Example 34: XMPP Mapping of Message (F45)
示例34：消息的XMPP映射（F45）
| <message from='romeo@example.org/dr4hcr0st3lup4c'
| to='capulet@rooms.example.com'
| type='groupchat'
| id='8gbx1g4p'>
| <body>Romeo is here!</body>
| </message>
| <message from='romeo@example.org/dr4hcr0st3lup4c'
| to='capulet@rooms.example.com'
| type='groupchat'
| id='8gbx1g4p'>
| <body>Romeo is here!</body>
| </message>
Example 35: MSRP Response to Public Message (F47)
示例35：MSRP对公共消息的响应（F47）
| MSRP d93kswow 200 OK
| To-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
| From-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
| -------d93kswow$
| MSRP d93kswow 200 OK
| To-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
| From-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
| -------d93kswow$
Note well that the XMPP MUC room will reflect the sender's message back to all users, including the sender. The MSRP-to-XMPP gateway SHOULD wait until receiving this reflected message before sending an MSRP 200 OK reply to the original sender.
请注意，XMPP MUC房间将把发送者的消息反射回所有用户，包括发送者。MSRP-to-XMPP网关在向原始发送方发送MSRP 200 OK应答之前，应等待收到此反射消息。
Romeo can send a "private message" to a selected occupant via the chat room service by sending a message to the occupant's room nickname.
罗密欧可以通过聊天室服务向选定的住户发送“私人信息”，方法是向住户的房间昵称发送信息。
The following examples show an exchange of a private message.
下面的示例显示了私有消息的交换。
Example 36: Romeo Sends a Private Message (F48)
例36：罗密欧发送私人信息（F48）
| MSRP a786hjs2 SEND
| To-Path: msrp://rooms.example.com:7313/ansp71weztas;tcp
| From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
| Message-ID: 87652492
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:capulet@rooms.example.com>;gr=JuliC
| From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| I am here!!!
| -------a786hjs2$
| MSRP a786hjs2 SEND
| To-Path: msrp://rooms.example.com:7313/ansp71weztas;tcp
| From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp
| Message-ID: 87652492
| Byte-Range: 1-*/*
| Content-Type: message/cpim
|
| To: <sip:capulet@rooms.example.com>;gr=JuliC
| From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| DateTime: 2008-10-15T15:02:31-03:00
| Content-Type: text/plain
|
| I am here!!!
| -------a786hjs2$
The MSRP switch is responsible for transforming the 'From' address into an in-room address (not shown).
MSRP交换机负责将“发件人”地址转换为室内地址（未显示）。
Once the MSRP switch sends that message to the gateway, the gateway is responsible for translating it into XMPP syntax.
一旦MSRP交换机将该消息发送到网关，网关负责将其转换为XMPP语法。
Example 37: XMPP Mapping of Private Message (F50)
示例37：私有消息的XMPP映射（F50）
| <message from='capulet@rooms.example.com/Romeo'
| to='capulet@rooms.example.com/JuliC'
| type='chat'
| id='rg2ca9k7'>
| <body>I am here!!!</body>
| </message>
| <message from='capulet@rooms.example.com/Romeo'
| to='capulet@rooms.example.com/JuliC'
| type='chat'
| id='rg2ca9k7'>
| <body>I am here!!!</body>
| </message>
If Romeo decides to change his nickname within the room, he sends a new MSRP NICKNAME request. In fact, modification of the nickname in MSRP is not different from the initial reservation and usage of a nickname.
如果罗密欧决定在房间内更改他的昵称，他会发送一个新的MSRP昵称请求。事实上，管理系统更新项目中昵称的修改与昵称的初始保留和使用并无不同。
Example 38: MSRP User Changes Nickname (F51)
示例38:MSRP用户更改昵称（F51）
| MSRP a786hjs2 NICKNAME
| To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
| From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
| Use-Nickname: "montecchi"
| -------a786hjs2
| MSRP a786hjs2 NICKNAME
| To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
| From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
| Use-Nickname: "montecchi"
| -------a786hjs2
Upon receiving such a message, the MSRP-to-XMPP gateway translates it into an XMPP presence stanza.
在接收到这样的消息后，MSRP到XMPP网关将其转换为XMPP状态节。
Example 39: XMPP Mapping of Nickname Change (F52)
示例39：昵称更改的XMPP映射（F52）
| <presence from='romeo@example.org/dr4hcr0st3lup4c'
| to='capulet@rooms.example.com/montecchi'/>
| <presence from='romeo@example.org/dr4hcr0st3lup4c'
| to='capulet@rooms.example.com/montecchi'/>
The XMPP server will analyze the nickname allocation and determine if the requested nickname is available. In case the nickname is not available or not usable, the server will generate a presence stanza of type "error" specifying a <conflict/> error condition.
XMPP服务器将分析昵称分配，并确定请求的昵称是否可用。如果昵称不可用或不可用，服务器将生成类型为“error”的presence节，指定<conflict/>错误条件。
Example 40: XMPP Conflict Error for Nickname (F53)
示例40：昵称的XMPP冲突错误（F53）
| <presence from='capulet@rooms.example.com/Romeo'
| to='romeo@example.org/dr4hcr0st3lup4c'
| type='error'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| <error type='cancel' by='capulet@rooms.example.com'>
| <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
| </error>
| </presence>
| <presence from='capulet@rooms.example.com/Romeo'
| to='romeo@example.org/dr4hcr0st3lup4c'
| type='error'>
| <x xmlns='http://jabber.org/protocol/muc'/>
| <error type='cancel' by='capulet@rooms.example.com'>
| <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
| </error>
| </presence>
Upon receiving this stanza, the XMPP-to-MSRP gateway will reply to the NICKNAME request with code 425.
在收到该节后，XMPP到MSRP网关将以代码425回复昵称请求。
Example 41: Gateway Translates XMPP Nickname Conflict to MSRP Error Code (F54)
示例41：网关将XMPP昵称冲突转换为MSRP错误代码（F54）
| MSRP a786hjs2 425 Nickname usage failed
| To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
| From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
| -------a786hjs2
| MSRP a786hjs2 425 Nickname usage failed
| To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp
| From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp
| -------a786hjs2
If a SIP user wants to invite another user to join the conference he will send a REFER request indicating who needs to be invited in the Refer-To header, as per Section 5.5 of [RFC4579].
根据[RFC4579]第5.5节，如果SIP用户希望邀请另一用户加入会议，他将发送一个REFER请求，指示需要在REFER REFER标头中邀请谁。
Example 42: SIP User Invites Another User (F55)
示例42:SIP用户邀请其他用户（F55）
| REFER sip:capulet@rooms.example.com SIP/2.0
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| From: "Romeo" <sip:romeo@example.org>;tag=5534562
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 4 REFER
| Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| Accept: message/sipfrag
| Refer-To: <sip:benvolio@example.com>
| Supported: replaces
| Content-Length: 0
| REFER sip:capulet@rooms.example.com SIP/2.0
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| From: "Romeo" <sip:romeo@example.org>;tag=5534562
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 4 REFER
| Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c
| Accept: message/sipfrag
| Refer-To: <sip:benvolio@example.com>
| Supported: replaces
| Content-Length: 0
The SIP-to-XMPP gateway then acknowledges the SIP REFER request with a 200 OK response (step F56).
然后，SIP到XMPP网关用200 OK响应确认SIP REFER请求（步骤F56）。
The gateway will then send a NOTIFY request as per [RFC3515] indicating that the invitation is in progress. Since there is no way to know the progress of the invitation until the user has joined, implementations are advised to terminate the REFER dialog subscription upon receiving the first NOTIFY request, with a status code of 100 Trying.
然后，网关将根据[RFC3515]发送通知请求，指示邀请正在进行中。由于在用户加入之前无法知道邀请的进度，因此建议实现在收到第一个NOTIFY请求时终止REFER对话框订阅，状态代码为100。
Example 43: Progress Notification for Invitation (F56)
示例43：邀请的进度通知（F56）
| NOTIFY sip:romeo@example.org SIP/2.0
| To: <sip:romeo@example.org>;tag=5534562
| From: <sip:capulet@rooms.example.com>;tag=a3343df32
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 5 NOTIFY
| Event: refer
| Subscription-State: terminated;reason=noresource
| Contact: <sip:capulet@rooms.example.com;transport=tcp>;isfocus
| Content-Type: message/sipfrag;version=2.0
| Content-Length: ...
|
| SIP/2.0 100 Trying
| NOTIFY sip:romeo@example.org SIP/2.0
| To: <sip:romeo@example.org>;tag=5534562
| From: <sip:capulet@rooms.example.com>;tag=a3343df32
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 5 NOTIFY
| Event: refer
| Subscription-State: terminated;reason=noresource
| Contact: <sip:capulet@rooms.example.com;transport=tcp>;isfocus
| Content-Type: message/sipfrag;version=2.0
| Content-Length: ...
|
| SIP/2.0 100 Trying
If Romeo decides to exit the chat room, his client sends a SIP BYE to the <montague@chat.example.org> chat room.
如果罗密欧决定退出聊天室，他的客户会向聊天室发出一声再见<montague@chat.example.org>聊天室。
Example 44: Romeo Terminates Session (F59)
示例44:Romeo终止会话（F59）
| BYE sip:capulet@rooms.example.com SIP/2.0
| Max-Forwards: 70
| From: "Romeo" <sip:romeo@example.org>;tag=5534562
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 6 BYE
| Content-Length: 0
| BYE sip:capulet@rooms.example.com SIP/2.0
| Max-Forwards: 70
| From: "Romeo" <sip:romeo@example.org>;tag=5534562
| To: <sip:capulet@rooms.example.com>;tag=a3343df32
| Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2
| CSeq: 6 BYE
| Content-Length: 0
Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it into a presence stanza of type "unavailable" (F60) and sends it to the XMPP MUC room service. Then, the SIP-to-XMPP gateway responds with a 200 OK to the MSRP user (F62).
收到SIP BYE后，SIP到XMPP网关将其转换为类型为“不可用”（F60）的状态节，并将其发送到XMPP MUC房间服务。然后，SIP到XMPP网关向MSRP用户发出200 OK的响应（F62）。
Example 45: Romeo Exits Chat Room (F60)
示例45：罗密欧退出聊天室（F60）
| <presence from='romeo@example.org/dr4hcr0st3lup4c'
| to='capulet@rooms.example.com/Romeo'
| type='unavailable'/>
| <presence from='romeo@example.org/dr4hcr0st3lup4c'
| to='capulet@rooms.example.com/Romeo'
| type='unavailable'/>
Fundamental rules for mapping addresses between XMPP and SIP are provided in [RFC7247]. However, chat rooms include a more specialized, unique identifier for each participant in a room, called a "nickname". Implementations SHOULD apply the rules for preparation and comparison of nicknames specified in [RFC7700].
[RFC7247]中提供了XMPP和SIP之间映射地址的基本规则。然而，聊天室中的每个参与者都有一个更专业、唯一的标识符，称为“昵称”。实现应应用[RFC7700]中指定的昵称准备和比较规则。
In addition to nicknames, some groupchat implementations also include display names (which might or might not be different from users' nicknames). A display name need not be unique within the context of a room but instead simply provides a user-friendly name for a participant.
除了昵称，一些groupchat实现还包括显示名称（可能与用户的昵称不同，也可能不不同）。显示名称在房间的上下文中不一定是唯一的，而只是为参与者提供一个用户友好的名称。
In the SIP conference event package, the nickname is the value of the Centralized Conferencing (XCON) 'nickname' attribute of the <user/> element [RFC6501] and the display name is the XML character data of the conference-info <display-text/> element [RFC4575]. In XMPP, the nickname is the value of the resourcepart of the occupant JID [XEP-0045] and the display name is the XML character data of the <nick/> element [XEP-0172].
在SIP会议事件包中，昵称是<user/>元素[RFC6501]的集中式会议（XCON）“昵称”属性的值，显示名称是会议信息<display text/>元素[RFC4575]的XML字符数据。在XMPP中，昵称是占用者JID[XEP-0045]的resourcepart的值，显示名称是<nick/>元素[XEP-0172]的XML字符数据。
In practice, the <display-text/> element is treated as canonical in
SIP implementations, and the <nick/> element is rarely used in XMPP
implementations. Therefore, for display purposes, SIP
implementations ought to use the <display-text/> element if the XCON
In practice, the <display-text/> element is treated as canonical in
SIP implementations, and the <nick/> element is rarely used in XMPP
implementations. Therefore, for display purposes, SIP
implementations ought to use the <display-text/> element if the XCON
'nickname' attribute is not present, and XMPP implementations ought to use the resourcepart of the occupant JID if the <nick/> element is not present.
“昵称”属性不存在，如果<nick/>元素不存在，XMPP实现应该使用占用者JID的resourcepart。
If there is a conflict between the SIP nickname and the XMPP nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for adjusting the nickname to avoid the conflict and for informing the SIP or XMPP client of the unique nickname used to join the chat room.
如果SIP昵称和XMPP昵称之间存在冲突，SIP-to-XMPP或XMPP-to-SIP网关负责调整昵称以避免冲突，并将用于加入聊天室的唯一昵称通知SIP或XMPP客户端。
It is possible for MSRP messages to exceed the size allowed by an XMPP service on the far end of an MSRP-to-XMPP gateway; see [RFC7573] for a discussion of this issue.
MSRP消息可能超过MSRP-to-XMPP网关远端XMPP服务允许的大小；有关此问题的讨论，请参见[RFC7573]。
The security considerations of [RFC3261], [RFC4975], [RFC6120], [RFC7247], [RFC7701], and [XEP-0045] apply.
[RFC3261]、[RFC4975]、[RFC6120]、[RFC7247]、[RFC7701]和[XEP-0045]的安全注意事项适用。
This document specifies methods for exchanging groupchat messages through a gateway that translates between SIP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the protocols for which it translates (i.e., MSRP/SIP and XMPP). The addition of gateways to the security models of MSRP, SIP, and XMPP introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between user agents that interface through an MSRP-to-XMPP gateway can be provided only if common formats are supported; unfortunately, although [RFC3862] specifies such a format for one-to-one instant messages, the problem of end-to-end security for multi-party messaging has not been solved in a standardized way.
本文档指定了通过在SIP和XMPP之间转换的网关交换groupchat消息的方法。此类网关必须符合其所翻译协议（即MSRP/SIP和XMPP）的最低安全要求。在MSRP、SIP和XMPP的安全模型中添加网关会带来一些新的风险。特别是，只有在支持通用格式的情况下，才能提供通过MSRP到XMPP网关接口的用户代理之间的端到端安全属性（特别是机密性和完整性）；不幸的是，尽管[RFC3862]为一对一即时消息指定了这种格式，但多方消息的端到端安全性问题尚未以标准化的方式得到解决。
Some of the features that are not addressed by the minimal interoperability baseline defined in this document are relevant to security, such as the ability to administer rooms, kick out and ban users, and enable room moderation. Users needing to take advantage of such features cannot do so through a gateway in a standardized manner and therefore will need to use native clients for the relevant protocol (MSRP or XMPP).
本文档中定义的最低互操作性基线未涉及的一些功能与安全相关，例如管理房间、驱逐和禁止用户以及启用房间调节的功能。需要利用这些功能的用户不能以标准化的方式通过网关这样做，因此需要为相关协议（MSRP或XMPP）使用本机客户端。
As mentioned in [RFC7572], there are several possible methods for end-to-end encryption of one-to-one instant messages. Unfortunately, because there is no widely deployed method for end-to-end encryption of multi-party instant messages, this document cannot provide a recommendation in this regard.
如[RFC7572]所述，一对一即时消息的端到端加密有几种可能的方法。不幸的是，由于没有广泛部署的多方即时消息端到端加密方法，本文档无法提供这方面的建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，DOI 10.17487/RFC4579，2006年8月<http://www.rfc-editor.org/info/rfc4579>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 4975，DOI 10.17487/RFC4975，2007年9月<http://www.rfc-editor.org/info/rfc4975>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<http://www.rfc-editor.org/info/rfc5627>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <http://www.rfc-editor.org/info/rfc6121>.
[RFC6121]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 6121DOI 10.17487/RFC6121，2011年3月<http://www.rfc-editor.org/info/rfc6121>.
[RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling", RFC 7247, DOI 10.17487/RFC7247, May 2014, <http://www.rfc-editor.org/info/rfc7247>.
[RFC7247]Saint Andre，P.，Houri，A.，和J.Hildebrand，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：体系结构、地址和错误处理”，RFC 7247，DOI 10.17487/RFC7247，2014年5月<http://www.rfc-editor.org/info/rfc7247>.
[RFC7573] Saint-Andre, P. and S. Loreto, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions", RFC 7573, DOI 10.17487/RFC7573, June 2015, <http://www.rfc-editor.org/info/rfc7573>.
[RFC7573]Saint Andre，P.和S.Loreto，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：一对一文本聊天会话”，RFC 7573，DOI 10.17487/RFC7573，2015年6月<http://www.rfc-editor.org/info/rfc7573>.
[RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 7700, DOI 10.17487/RFC7700, December 2015, <http://www.rfc-editor.org/info/rfc7700>.
[RFC7700]Saint Andre，P.，“代表昵称的国际化字符串的准备、实施和比较”，RFC 7700，DOI 10.17487/RFC7700，2015年12月<http://www.rfc-editor.org/info/rfc7700>.
[RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, <http://www.rfc-editor.org/info/rfc7701>.
[RFC7701]Niemi，A.，Garcia Martin，M.，和G.Sandbakken，“使用消息会话中继协议（MSRP）的多方聊天”，RFC 7701，DOI 10.17487/RFC7701，2015年12月<http://www.rfc-editor.org/info/rfc7701>.
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012, <http://www.xmpp.org/extensions/xep-0045.html>.
[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452012年2月<http://www.xmpp.org/extensions/xep-0045.html>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，DOI 10.17487/RFC3515，2003年4月<http://www.rfc-editor.org/info/rfc3515>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <http://www.rfc-editor.org/info/rfc3862>.
[RFC3862]Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，DOI 10.17487/RFC3862，2004年8月<http://www.rfc-editor.org/info/rfc3862>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，DOI 10.17487/RFC4353，2006年2月<http://www.rfc-editor.org/info/rfc4353>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，Ed.，“会议状态的会话启动协议（SIP）事件包”，RFC 4575，DOI 10.17487/RFC4575，2006年8月<http://www.rfc-editor.org/info/rfc4575>.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <http://www.rfc-editor.org/info/rfc6501>.
[RFC6501]Novo，O.，Camarillo，G.，Morgan，D.，和J.Urpalainen，“集中会议的会议信息数据模型（XCON）”，RFC 6501，DOI 10.17487/RFC6501，2012年3月<http://www.rfc-editor.org/info/rfc6501>.
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, DOI 10.17487/RFC6502, March 2012, <http://www.rfc-editor.org/info/rfc6502>.
[RFC6502]Camarillo，G.，Srinivasan，S.，Even，R.，和J.Urpalainen，“集中会议的会议事件包数据格式扩展（XCON）”，RFC 6502，DOI 10.17487/RFC6502，2012年3月<http://www.rfc-editor.org/info/rfc6502>.
[RFC7572] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", RFC 7572, DOI 10.17487/RFC7572, June 2015, <http://www.rfc-editor.org/info/rfc7572>.
[RFC7572]Saint Andre，P.，Houri，A.，和J.Hildebrand，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：即时消息传递”，RFC 7572，DOI 10.17487/RFC7572，2015年6月<http://www.rfc-editor.org/info/rfc7572>.
[RFC7614] Sparks, R., "Explicit Subscriptions for the REFER Method", RFC 7614, DOI 10.17487/RFC7614, August 2015, <http://www.rfc-editor.org/info/rfc7614>.
[RFC7614]Sparks，R.“引用方法的显式订阅”，RFC 7614，DOI 10.17487/RFC7614，2015年8月<http://www.rfc-editor.org/info/rfc7614>.
[RFC7647] Sparks, R. and A. Roach, "Clarifications for the Use of REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, September 2015, <http://www.rfc-editor.org/info/rfc7647>.
[RFC7647]Sparks，R.和A.Roach，“与RFC 6665一起使用REFER的澄清”，RFC 7647，DOI 10.17487/RFC7647，2015年9月<http://www.rfc-editor.org/info/rfc7647>.
[XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 0172, March 2012, <http://xmpp.org/extensions/xep-0172.html>.
[XEP-0172]Saint Andre，P.和V.Mercier，“用户昵称”，XSF XEP 0172，2012年3月<http://xmpp.org/extensions/xep-0172.html>.
[XEP-0249] Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249, September 2011, <http://xmpp.org/extensions/xep-0249.html>.
[XEP-0249]圣安德烈，P.，“直接MUC邀请”，XSF XEP 0249，2011年9月<http://xmpp.org/extensions/xep-0249.html>.
Acknowledgements
致谢
Special thanks to Fabio Forno for coauthoring an early draft version of this document and to Ben Campbell for his detailed and insightful reviews.
特别感谢法比奥·福诺（Fabio Forno）和本·坎贝尔（Ben Campbell）共同撰写了本文件的早期草稿，并对其进行了详细而深刻的评论。
Thanks also to Dave Crocker, Philipp Hancke, Olle Johansson, Paul Kyzivat, and Matt Ryan for their feedback.
还要感谢戴夫·克罗克、菲利普·汉克、奥利·约翰逊、保罗·基齐瓦特和马特·瑞安的反馈。
Leif Johansson reviewed the document on behalf of the Security Directorate.
莱夫·约翰逊代表安全局审阅了这份文件。
Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling provided helpful input during IESG review.
Stephen Farrell、Barry Leiba、Pete Resnick和Martin Stiemerling在IESG审查期间提供了有用的意见。
The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group Chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors.
作者衷心感谢工作组主席Markus Isomaki和Yana Stamcheva以及赞助区域主任Gonzalo Camarillo和Alissa Cooper的协助。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint Andre希望感谢Cisco Systems，Inc.在编写本文件早期草稿期间聘用了他。
Authors' Addresses
作者地址
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
Email: peter@andyet.com
URI: https://andyet.com/
Email: peter@andyet.com
URI: https://andyet.com/
Saul Ibarra Corretge AG Projects Dr. Leijdsstraat 92 Haarlem 2021RK The Netherlands
Saul Ibarra Corretge AG项目Leijdstraat博士92 Haarlem 2021RK荷兰
Email: saul@ag-projects.com
Email: saul@ag-projects.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
萨尔瓦托·洛雷托·爱立信·赫萨兰蒂11 Jorvas 02420芬兰
Email: Salvatore.Loreto@ericsson.com
Email: Salvatore.Loreto@ericsson.com