[要約] RFC 7702は、SIPとXMPPの間でのグループチャットの相互運用性に関するガイドラインです。このRFCの目的は、SIPとXMPPの間でグループチャットを実現するためのプロトコル仕様を提供することです。
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）間のインターワーキング：グループチャット
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.
このドキュメントでは、Session Initiation Protocol（SIP）のユーザーとExtensible Messaging and Presence Protocol（XMPP）のユーザー間のマルチパーティチャットセッションのコンテキストでインスタントメッセージを交換するための双方向プロトコルマッピングを定義します。具体的には、このドキュメントでは、SIPベースのメッセージセッションリレープロトコル（MSRP）とXMPPマルチユーザーチャット（MUC）拡張の間のマッピングを定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
Session Initiation Protocol（SIP）[RFC3261]とExtensible Messaging and Presence Protocol（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]で提供されています。このドキュメントでは、マルチパーティのテキストチャットセッション（「グループチャット」と呼ばれることが多い）のマッピングを指定します。具体的には、このドキュメントでは、XMPPマルチユーザーチャット（MUC）拡張[XEP-0045]と、[RFC7701]で指定されているメッセージセッションリレープロトコル（MSRP）[RFC4975]を使用したSIPベースのマルチパーティチャット間のマッピングを定義します。
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の両方には、部屋の管理、ユーザーの解任と禁止、部屋内のニックネームの予約、部屋の件名の変更、部屋のモデレートの有効化、部屋の破棄など、さまざまな機能が含まれています。このドキュメントでは、グループチャット機能の基本的なサブセットのみについて説明します。部屋への参加、部屋のニックネームの確立または変更（ただし恒久的な登録ではない）、部屋内のプレゼンス情報の変更、すべての参加者へのメッセージの送信、1人の参加者へのプライベートメッセージの送信、別のユーザーを部屋に招待し、部屋を離れます。今後のドキュメントでは、このセット以外の追加機能のマッピングを定義する可能性があります。
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:
このシリーズのドキュメントは、これらのテクノロジーの1つに基づく既存のシステム（SIPなど）を持ち、その既存のシステムから他のテクノロジーに基づくシステム（例： XMPP）。読者は、SIP [RFC3261]とXMPP [RFC6120]の両方のコア仕様、このシリーズのベースドキュメント[RFC7247]、および次のグループチャット関連の仕様に精通していることを前提としています。
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].
ここで使用されるいくつかの技術用語は、[RFC 3261]、[RFC 4975]、[RFC 6120]、および[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 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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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のセッション（グループチャットセッションを含む）は、一種のメディア（オーディオ/ビデオセッションと同様）と見なされます。セッションをセットアップ、管理、および終了するためのシグナリングは、「会議フォーカス」によって処理されます[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 example.org-SIPからXMPPへのゲートウェイ（ "S2X GW"）からXMPPへのSIPプロキシ。
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-関連するMSRP-to-SIPゲートウェイ（ "M2X GW"）からXMPPへのSIPベースの会議フォーカスとMSRPスイッチ。
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-SIPへのXMPP-to-SIPゲートウェイ（「X2S GW」）およびMSRPへのXMPP-to-MSRPゲートウェイ（「X2M GW」）が関連付けられたXMPPサーバー。
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-- #
# / #
#####################################################################
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では、romeo @ example.orgなどのSIPユーザーがXMPPネットワーク上のチャットルームに参加するためにSIPプロキシを使用する必要はありません。たとえば、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 |
| |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|
| | (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 | | |
|<................| | |
| | | |
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]をそのチャットルームに送信します。彼女のリクエストでは、部屋で使用するニックネームも指定しています（たとえば、「JuliC」）。 XMPPでは、この部屋のニックネームは、居住者のJIDのリソース部分です（したがって、「montague@chat.example.org/JuliC」）。参加するクライアントは、「http://jabber.org/protocol/muc」名前空間で修飾された空の<x />要素を最初のプレゼンススタンザに含めることにより、マルチユーザーチャットプロトコルを話す能力を知らせます。
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>
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サーバーは[RFC7247]で説明されている手順に従って、「宛先」アドレスのドメインパーツのIDを特定する必要があります。ここでは、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：ルーム参加（F2）のSIPマッピング
| 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.
ここで、Session Description Protocol（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 |
+-----------------------------+-----------------------------+
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) 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.
前述の例に示され、[RFC7247]で説明されているように、XMPP-to-SIPゲートウェイは、XMPP送信者のベアJID（ "localpart @ domainpart"）をSIP Fromヘッダーにマップし、完全なJIDのリソースパートを含める必要があります。 SIP URIのグローバルにルーティング可能なユーザーエージェントURI（GRUU）部分[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ヘッダーフィールドには、[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
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：ゲートウェイが会議フォーカス（F5）に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ゲートウェイは、プレゼンススタンザで受信したニックネーム（つまり、「mont」@ chat.exampleの「JuliC」などの「to」アドレスのリソース部分）を設定します.org / JuliC」）。これは、[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
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
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
The focus will accept or reject the request based on local policy.
フォーカスは、ローカルポリシーに基づいて要求を受け入れるか拒否します。
Example 8: Focus Accepts Subscription Request (F11)
例8：フォーカスがサブスクリプション要求を受け入れる（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
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.
会議のフォーカスが部屋に入室する要求を受け入れる場合、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].
会議イベントパッケージのサブスクリプションが完了すると、フォーカスはXMPP-to-SIPゲートウェイに、[RFC4575]で定義されている形式を使用して表されているすべての既存の居住者のプレゼンス情報を含むNOTIFY要求を送信します。
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>
| <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.)
RFC 4575ペイロードから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.) |
+--------------------------------+-----------------------------+
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/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>
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>
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.) Table 3: Message Syntax Mapping from SIP to XMPP
SIPおよび[RFC4575]ペイロード構文要素の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' |
+---------------------------------+-----------------------------+
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 |
+-----------------------------+-----------------------------+
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>).
ジュリエットがルーム内の他のすべての居住者にメッセージを送信する場合、彼女は「groupchat」タイプのメッセージを<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>
Upon receiving such a message, the XMPP-to-MSRP gateway translates it
into an MSRP SEND message.
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$
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.
SEND要求を受信したときに、要求に "yes"のFailure-Reportヘッダーフィールド値が含まれているか、まったく含まれていない場合、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$
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>
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を持っているので、ジュリエットはユーザーの居住者JIDにメッセージを送信することにより、サービスを通じて選択された居住者に「プライベートメッセージ」を送信できます。 XMPPメッセージタイプは「チャット」である必要があります（「グループチャット」にすることはできません）。
The following examples show an exchange of a private message.
次の例は、プライベートメッセージの交換を示しています。
Example 16: Juliet Sends Private Message (F20)
例16：Julietがプライベートメッセージを送信する（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>
Upon receiving such a message, the XMPP-to-MSRP gateway translates it into an MSRP SEND message.
このようなメッセージを受信すると、XMPP-to-MSRPゲートウェイはそれをMSRP SENDメッセージに変換します。
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$
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$
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属性に「private-messages」値を追加することにより、その事実を通知する必要があります。
| a=chatroom:nickname private-messages
| a = chatroom：nickname private-messages
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'/>
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
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ゲートウェイはそれをタイプ「エラー」の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>
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では、別のユーザーを部屋に招待する方法が2つあります。直接招待[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).
たとえば、ジュリエットがBenvolioを部屋に招待することを決定した場合、彼女はメッセージスタンザに招待とBenvolioのJID（実際のJIDまたは別の部屋の占有者のJIDである可能性があります）を送信します。
Example 22: Juliet Invites Benvolio to the Room (F27)
例22：JulietがBenvolioを部屋に招待する（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>
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].
次に、XMPP-to-SIPゲートウェイは、[RFC4579]のセクション5.5に従って、Refer-Toヘッダーで誰を招待する必要があるかを示すSIP REFERリクエストを会議のフォーカスに送信します。
Example 23: SIP Mapping of Invite (F28)
例23：招待の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
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]のように、受信したNOTIFYリクエストによって追跡されます。
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: ...
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>).
ジュリエットがチャットルームを終了することを決定した場合、彼女のクライアントは、タイプ "利用不可"の指定プレゼンススタンザを、現在ルームで使用している居住者JID（ここでは<montague@chat.example.org/JuliC>）に送信します。
Example 25: Juliet Exits Room (F31)
例25：ジュリエットが部屋を出る（F31）
| <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は、タイプ「unavailable」のプレゼンススタンザにカスタム終了メッセージを含めることができます。その場合、上記の方法を使用して他の参加者にブロードキャストされます。
Example 26: Juliet Exits the Chat Room (F31)
例26：Julietがチャットルームを終了する（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>
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 | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
. . . .
| (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要求で配信されるまで参加者リストをキャッシュする必要があります（SHOULD）。
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"）に参加したい場合、最初に、必須を伴うMSRPメディアラインを含む提供されたセッションの説明を含むSIP INVITE要求を送信して、SIPセッションを開始する必要があります。 「パス」および「チャットルーム」属性。ここでは、Romeoのユーザーエージェントが、使用できるMSRPスイッチ（chat.example.org）を認識するように構成されていると想定しています。 MSRPメディアラインには、MSRPメッセージのMessage / CPIM [RFC3862]トップレベルラッパーのサポートを指定する 'accept-types'属性も付属しています。
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
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プロキシは、Request-URIまたはToヘッダーのドメイン部分のIDを特定する必要があります。これは、[RFC7247]で説明されている手順に従って行われます。ここでは、SIPプロキシが、ドメインがXMPPサーバーによってサービスされていること、SIPから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.
実装は、ニックネームがMSRP NICKNAMEチャンクで設定されるまで待機してから、XMPP MUCに参加するか、一時的なニックネーム（SIP Fromヘッダーの表示名など）を選択して、部屋に参加するために使用できます。ここでは後者を想定しています。
Example 28: SIP-to-XMPP Gateway ACKs Session (F36)
例28：SIP-to-XMPPゲートウェイACKセッション（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
The SIP/MSRP user agent subscribes to a conference event package at the destination groupchat service.
SIP / MSRPユーザーエージェントは、宛先グループチャットサービスで会議イベントパッケージにサブスクライブします。
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
After the conference subscription request is acknowledged, the SIP-to-XMPP gateway sends presence from Romeo to the MUC chat room.
会議サブスクリプション要求が確認されると、SIP-to-XMPPゲートウェイがRomeoからMUCチャットルームにプレゼンスを送信します。
Example 30: Romeo Enters XMPP Chat Room (F40)
例30：RomeoがXMPPチャットルーム（F40）に入る
| <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>
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-to-SIPゲートウェイは、それらを参加者リスト（conference-info形式で表される）を含むSIP NOTIFYリクエストに変換します。 [RFC4575]で指定されています）。
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">
| <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.
「部屋名簿」は複数のプレゼンススタンザ（参加者ごとに1つ）を介してXMPPで通信されますが、参加者リストは単一の会議情報ドキュメントを使用してSIPで通信されるため、SIP-to-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/> |
+-----------------------------+-----------------------------+
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).
Romeoがルーム内の他のすべての居住者にメッセージを送信する場合、MSRP SEND要求を<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：Romeoがチャットルームにメッセージを送信する（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$
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.
SEND要求を受信すると、要求に "yes"のFailure-Reportヘッダーフィールド値が含まれているか、まったく含まれていない場合、SIP-to-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>
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$
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から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.
Romeoは、チャットルームサービスを介して、選択した居住者に部屋のニックネームにメッセージを送信することにより、「プライベートメッセージ」を送信できます。
The following examples show an exchange of a private message.
次の例は、プライベートメッセージの交換を示しています。
Example 36: Romeo Sends a Private Message (F48)
例36：Romeoがプライベートメッセージを送信する（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$
The MSRP switch is responsible for transforming the 'From' address into an in-room address (not shown).
MSRPスイッチは、「From」アドレスを室内アドレス（図示せず）に変換します。
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>
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 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
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'/>
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サーバーはニックネームの割り当てを分析し、リクエストされたニックネームが利用可能かどうかを判断します。ニックネームが使用できないか使用できない場合、サーバーは<conflict />エラー条件を指定するタイプ「error」のプレゼンススタンザを生成します。
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>
Upon receiving this stanza, the XMPP-to-MSRP gateway will reply to the NICKNAME request with code 425.
このスタンザを受信すると、XMPP-to-MSRPゲートウェイはNICKNAMEリクエストにコード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
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].
SIPユーザーが別のユーザーを会議に招待する場合は、[RFC4579]のセクション5.5に従って、Refer-Toヘッダーで誰を招待する必要があるかを示す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
The SIP-to-XMPP gateway then acknowledges the SIP REFER request with a 200 OK response (step F56).
次に、SIP-to-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要求を送信します。ユーザーが参加するまで招待の進行状況を知る方法がないため、実装では、最初のNOTIFYリクエストを受信したときにREFERダイアログサブスクリプションを終了し、ステータスコードを100 Tryingにすることをお勧めします。
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
If Romeo decides to exit the chat room, his client sends a SIP BYE to the <montague@chat.example.org> chat room.
Romeoがチャットルームを終了することを決定した場合、彼のクライアントはSIP BYEを<montague@chat.example.org>チャットルームに送信します。
Example 44: Romeo Terminates Session (F59)
例44：ロミオがセッションを終了する（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
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-to-XMPPゲートウェイはそれをタイプ「利用不可」（F60）のプレゼンススタンザに変換し、XMPP MUCルームサービスに送信します。次に、SIP-to-XMPPゲートウェイは、200 OKでMSRPユーザーに応答します（F62）。
Example 45: Romeo Exits Chat Room (F60)
例45：Romeoがチャットルームを終了する（F60）
| <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].
XMPPとSIPの間でアドレスをマッピングするための基本的なルールは、[RFC7247]で提供されています。ただし、チャットルームには、「ニックネーム」と呼ばれる、部屋の各参加者用のより専門的な一意の識別子が含まれています。実装は、[RFC7700]で指定されたニックネームの準備と比較のルールを適用する必要があります（SHOULD）。
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.
ニックネームに加えて、一部のグループチャット実装には表示名も含まれます（表示名はユーザーのニックネームと異なる場合と異なる場合があります）。表示名は部屋のコンテキスト内で一意である必要はありませんが、代わりに参加者にわかりやすい名前を提供するだけです。
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]のCentralized Conferencing（XCON） 'nickname'属性の値であり、表示名はConference-info <display- text />要素[RFC4575]。 XMPPでは、ニックネームは居住者JID [XEP-0045]のresourcepartの値であり、表示名は<nick />要素のXML文字データ[XEP-0172]です。
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.
'nickname'属性は存在せず、XMPP実装は、<nick />要素が存在しない場合、居住者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から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の間で変換するゲートウェイを介してグループチャットメッセージを交換する方法を指定します。そのようなゲートウェイは、それが変換するプロトコル（つまり、MSRP / SIPおよびXMPP）の最小セキュリティ要件に準拠している必要があります。 MSRP、SIP、XMPPのセキュリティモデルにゲートウェイを追加すると、いくつかの新しいリスクが生じます。特に、MSRPからXMPPへのゲートウェイを介してインターフェイスするユーザーエージェント間のエンドツーエンドのセキュリティプロパティ（特に機密性と整合性）は、一般的な形式がサポートされている場合にのみ提供できます。残念ながら、[RFC3862]は1対1のインスタントメッセージにこのような形式を指定していますが、マルチパーティメッセージングのエンドツーエンドのセキュリティの問題は、標準化された方法では解決されていません。
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]で述べられているように、1対1のインスタントメッセージのエンドツーエンドの暗号化にはいくつかの可能な方法があります。残念ながら、マルチパーティのインスタントメッセージをエンドツーエンドで暗号化する方法は広く普及していないため、このドキュメントではこの点について推奨することはできません。
[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：Session Initiation Protocol」 、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、「Session Initiation Protocol（SIP）Call Control-Conferencing for User Agents」、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。、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>。
[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。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、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。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、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。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、DOI 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、「Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（XMPP）：Architecture、Addresses、and Error Handlingの間のインターワーキング」、 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、「Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（XMPP）：One-to-One Text Chat Sessions」、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] Saint-Andre、P。、「マルチユーザーチャット」、XSF XEP 0045、2012年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。、「Session Initiation Protocol（SIP）Refer Method」、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、「Common Presence and Instant Messaging（CPIM）：Message Format」、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。、「Session Initiation Protocol（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：Session Description Protocol」、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、編、「会議状態用のSession Initiation Protocol（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、「Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（XMPP）：Instant Messaging」の間のインターワーキング：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。、「REFERメソッドの明示的なサブスクリプション」、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、「Clarifications for the Use of REFER with RFC 6665」、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、「User Nickname」、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] Saint-Andre、P。、「Direct MUC Invitations」、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.
フィードバックを提供してくれたDave Crocker、Philipp Hancke、Olle Johansson、Paul Kyzivat、Matt Ryanにも感謝します。
Leif Johansson reviewed the document on behalf of the Security Directorate.
Leif Johanssonがセキュリティ総局に代わって文書をレビューしました。
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、スポンサーとしてのArea Directorとしての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/
Saul Ibarra Corretge AG Projects Dr. Leijdsstraat 92 Haarlem 2021RK The Netherlands
Saul Ibarra Corretge AG Projects Dr. Leijdsstraat 92 Haarlem 2021RKオランダ
Email: saul@ag-projects.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: Salvatore.Loreto@ericsson.com