RFC 7702: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
- P. Saint-Andre,
- S. Ibarra,
- S. Loreto
Proposed Standard
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
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.
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.
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.
Saint-Andre, et al. Standards Track [Page 1]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Saint-Andre, et al. Standards Track [Page 2]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 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 Saint-Andre, et al. Standards Track [Page 3]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 1. Introduction 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. 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]. 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. 2. Intended Audience 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: o Multi-party Chat Using MSRP [RFC7701] o Multi-User Chat [XEP-0045] Saint-Andre, et al. Standards Track [Page 4]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 3. Terminology A number of technical terms used here are defined in [RFC3261], [RFC4975], [RFC6120], and [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. 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]. 4. Architectural Assumptions 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. 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;gr=dr4hcr0st3lup4c -- a particular endpoint associated with the SIP user. o example.org -- a SIP proxy with an associated SIP-to-XMPP gateway ("S2X GW") to XMPP. o chat.example.org -- a SIP-based conference focus and MSRP switch with an associated MSRP-to-SIP gateway ("M2X GW") to XMPP. o montague@chat.example.org -- a conference at an MSRP switch; not shown in diagram. Saint-Andre, et al. Standards Track [Page 5]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 o juliet@example.com -- an XMPP user. o juliet@example.com/yn0cl4bnw0yr3vym -- a particular endpoint associated with the XMPP user. 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 rooms.example.com -- an XMPP MUC service associated with example.com. o capulet@rooms.example.com -- a chat room at an XMPP MUC service; not shown in diagram. 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. Saint-Andre, et al. Standards Track [Page 6]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 ##################################################################### # # # +------------------+ # # &&&&&&&&&&&&&&&&| 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 Saint-Andre, et al. Standards Track [Page 7]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 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). 5. Multi-party Messaging Session from XMPP MUC to MSRP 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 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 | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| Saint-Andre, et al. Standards Track [Page 8]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 | | (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 | | | |................>| | | Saint-Andre, et al. Standards Track [Page 9]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 | | (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. Saint-Andre, et al. Standards Track [Page 10]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 5.1. Enter Room 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. Example 1: Juliet Enters Room (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. 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. Saint-Andre, et al. Standards Track [Page 11]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 2: SIP Mapping of Room Join (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 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. 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). The mapping of XMPP syntax elements to SIP and [RFC4566] syntax elements MUST be as shown in the following table. Table 1: Message Syntax Mapping from XMPP to 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) Saint-Andre, et al. Standards Track [Page 12]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 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. 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]. Example 3: Chat Room Accepts Session Establishment (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. Example 4: Gateway Sends ACK to Conference Focus (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 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). Saint-Andre, et al. Standards Track [Page 13]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 5.2. Set Nickname 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]. Example 5: Gateway Sets Up Nickname (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. Example 6: MSRP Switch Accepts Nickname Proposal (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.3. Conference Subscription 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. Saint-Andre, et al. Standards Track [Page 14]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 7: Gateway Subscribes to the Conference (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) | 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. 5.4. Presence Broadcast 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]. Saint-Andre, et al. Standards Track [Page 15]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 9: Conference Focus Sends Presence Information (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> Saint-Andre, et al. Standards Track [Page 16]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 | <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.) Table 2: Participant list mapping +--------------------------------+-----------------------------+ | 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.) | +--------------------------------+-----------------------------+ Saint-Andre, et al. Standards Track [Page 17]
RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 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. Example 10: XMPP Mapping of Chat Room Presence (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. Example 11: XMPP Mapping of Chat Room Subject (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.) Saint-Andre, et al. Standards Track [Page 18]