tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7702

Proposed STD
Pages: 43
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: STOX

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat

Part 1 of 2, p. 1 to 25
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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]

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   #####################################################################
   #                                                                   #
   #                  +------------------+                             #
   #  &&&&&&&&&&&&&&&&| 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

Top      ToC       Page 8 
   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                  |
    |                 |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%|

Top      ToC       Page 9 
    |                 | (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     |                 |                 |
    |................>|                 |                 |

Top      ToC       Page 10 
    |                 | (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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
   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)

Top      ToC       Page 13 
   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).

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
   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].

Top      ToC       Page 16 
   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>

Top      ToC       Page 17 
   |        <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.)  |
       +--------------------------------+-----------------------------+

Top      ToC       Page 18 
   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.)

Top      ToC       Page 19 
   Table 3: Message Syntax Mapping from SIP to 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'         |
       +---------------------------------+-----------------------------+

5.5.  Exchange Messages

   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.)

   Table 4: Message Syntax Mapping from XMPP Message to MSRP

       +-----------------------------+-----------------------------+
       |  XMPP Element or Attribute  |  CPIM Header                |
       +-----------------------------+-----------------------------+
       |  to                         |  To                         |
       |  from                       |  From                       |
       |  <body/>                    |  body of the SEND request   |
       +-----------------------------+-----------------------------+

5.5.1.  Send a Message to All Occupants

   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>).

   The following examples show an exchange of a public message.

   Example 12: Juliet Sends Message to All Occupants (F16)

   |  <message from='juliet@example.com/yn0cl4bnw0yr3vym'
   |           to='montague@chat.example.org'
   |           type='groupchat'
   |           id='lzfed24s'>
   |        <body>Who knows where Romeo is?</body>
   |  </message>

Top      ToC       Page 20 
   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)

   |  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.

   Example 14: MSRP Switch Returns 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.

   Example 15: Gateway Reflects Message to XMPP User (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>

Top      ToC       Page 21 
5.5.2.  Send a Private 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").

   The following examples show an exchange of a private message.

   Example 16: Juliet Sends Private Message (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.

   Example 17: Gateway Maps Private Message from XMPP to 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.

Top      ToC       Page 22 
   Example 18: Switch Sends Private Message to SIP User

   |  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].

   |  a=chatroom:nickname private-messages

5.6.  Change Nickname

   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.

   Example 19: Juliet Changes Her Nickname (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.

Top      ToC       Page 23 
   Example 20: MSRP Switch Does Not Accept Nickname Proposal (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).

   Example 21: Conflict Error for Nickname (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.

5.7.  Invite Another User to a Room

   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.

   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).

Top      ToC       Page 24 
   Example 22: Juliet Invites Benvolio to the Room (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].

   Example 23: SIP Mapping of Invite (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).

   The progress of the invitation will be tracked by the received NOTIFY
   requests as per [RFC3515].

   Example 24: Progress Notification for Invitation (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: ...

Top      ToC       Page 25 
   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]).

5.8.  Exit Room

   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>).

   Example 25: Juliet Exits Room (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).

   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.

   Example 26: Juliet Exits the Chat Room (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>



(page 25 continued on part 2)

Next RFC Part