diff options
Diffstat (limited to 'doc/rfc/rfc7702.txt')
| -rw-r--r-- | doc/rfc/rfc7702.txt | 2411 |
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc7702.txt b/doc/rfc/rfc7702.txt new file mode 100644 index 0000000..ea3cbf3 --- /dev/null +++ b/doc/rfc/rfc7702.txt @@ -0,0 +1,2411 @@ + + + + + + +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] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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> + + + + + +Saint-Andre, et al. Standards Track [Page 19] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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> + + + + +Saint-Andre, et al. Standards Track [Page 20] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + +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. + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 21] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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. + + + + + + + + +Saint-Andre, et al. Standards Track [Page 22] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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). + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 23] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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: ... + + + + + +Saint-Andre, et al. Standards Track [Page 24] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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> + +6. MSRP Multi-party Messaging Session to XMPP MUC + + 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). + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 25] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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 | | + |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | + . . . . + + + + + +Saint-Andre, et al. Standards Track [Page 26] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + . . . . + | (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 | | | + |<****************| | | + | | | | + + + + + + +Saint-Andre, et al. Standards Track [Page 27] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 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. + +6.1. Enter Room + + 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. + + Example 27: SIP User Starts Session (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. + + 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. + + + +Saint-Andre, et al. Standards Track [Page 28] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + Example 28: SIP-to-XMPP Gateway ACKs Session (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. + + Example 29: Gateway Subscribes to the Conference (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. + + Example 30: Romeo Enters XMPP Chat Room (F40) + + | <presence from='romeo@example.org/dr4hcr0st3lup4c' + | to='montague@chat.example.org/Romeo'> + | <x xmlns='http://jabber.org/protocol/muc'/> + | </presence> + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 29] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + +6.2. Presence Broadcast + + 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. + + Example 31: XMPP Service Sends Presence from Existing Occupants to + New Occupant (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]). + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 30] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + Example 32: SIP Mapping of XMPP Participant Presence Stanzas (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"> + + + +Saint-Andre, et al. Standards Track [Page 31] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + | <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. + +6.3. 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 MSRP syntax elements to XMPP syntax elements MUST be + as shown in the following table. (Mappings for elements not + mentioned are undefined.) + + Table 5: Message Syntax Mapping from MSRP Message to XMPP + + +-----------------------------+-----------------------------+ + | CPIM Header |XMPP Element or Attribute | + +-----------------------------+-----------------------------+ + | To | to | + | From | from | + | body of the SEND request | <body/> | + +-----------------------------+-----------------------------+ + +6.3.1. Send a Message to All Occupants + + 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). + + + + + + +Saint-Andre, et al. Standards Track [Page 32] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + The following examples show an exchange of a public message. + + Example 33: Romeo Sends a Message to the Chat Room (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. + + Example 34: XMPP Mapping of Message (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) + + | 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. + + + + + + +Saint-Andre, et al. Standards Track [Page 33] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + +6.3.2. Send a Private Message + + Romeo can send a "private message" to a selected occupant via the + chat room service by sending a message to the occupant's room + nickname. + + The following examples show an exchange of a private message. + + Example 36: Romeo Sends a Private Message (F48) + + | 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). + + Once the MSRP switch sends that message to the gateway, the gateway + is responsible for translating it into XMPP syntax. + + Example 37: XMPP Mapping of Private Message (F50) + + | <message from='capulet@rooms.example.com/Romeo' + | to='capulet@rooms.example.com/JuliC' + | type='chat' + | id='rg2ca9k7'> + | <body>I am here!!!</body> + | </message> + +6.4. Change Nickname + + 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. + + + + + +Saint-Andre, et al. Standards Track [Page 34] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + Example 38: MSRP User Changes Nickname (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. + + Example 39: XMPP Mapping of Nickname Change (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. + + Example 40: XMPP Conflict Error for Nickname (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. + + Example 41: Gateway Translates XMPP Nickname Conflict to MSRP Error + Code (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 + +6.5. Invite Another User to a Room + + 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]. + + + +Saint-Andre, et al. Standards Track [Page 35] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + Example 42: SIP User Invites Another User (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). + + 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. + + Example 43: Progress Notification for Invitation (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 + +6.6. Exit Room + + If Romeo decides to exit the chat room, his client sends a SIP BYE to + the <montague@chat.example.org> chat room. + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 36] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + Example 44: Romeo Terminates Session (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). + + Example 45: Romeo Exits Chat Room (F60) + + | <presence from='romeo@example.org/dr4hcr0st3lup4c' + | to='capulet@rooms.example.com/Romeo' + | type='unavailable'/> + +7. Handling of Nicknames and Display Names + + 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]. + + 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]. + + 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 + + + + +Saint-Andre, et al. Standards Track [Page 37] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + 'nickname' attribute is not present, and XMPP implementations ought + to use the resourcepart of the occupant JID if the <nick/> element is + not present. + + 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. + +8. Message Size + + 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. + +9. Security Considerations + + The security considerations of [RFC3261], [RFC4975], [RFC6120], + [RFC7247], [RFC7701], and [XEP-0045] apply. + + 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. + + 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). + + 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. + + + + + +Saint-Andre, et al. Standards Track [Page 38] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + +10. References + +10.1. Normative References + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + + + + + +Saint-Andre, et al. Standards Track [Page 39] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + [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>. + + [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>. + + [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>. + + [XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February + 2012, <http://www.xmpp.org/extensions/xep-0045.html>. + +10.2. Informative References + + [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>. + + [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>. + + [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>. + + [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>. + + [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>. + + + + + + + + +Saint-Andre, et al. Standards Track [Page 40] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + + [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>. + + [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>. + + [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>. + + [RFC7614] Sparks, R., "Explicit Subscriptions for the REFER Method", + RFC 7614, DOI 10.17487/RFC7614, August 2015, + <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>. + + [XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF + XEP 0172, March 2012, + <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>. + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 41] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + +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. + + Thanks also to Dave Crocker, Philipp Hancke, Olle Johansson, Paul + Kyzivat, and Matt Ryan for their feedback. + + Leif Johansson reviewed the document on behalf of the Security + Directorate. + + Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling + provided helpful input during IESG review. + + 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. + + Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for + employing him during his work on earlier draft versions of this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 42] + +RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 + + +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 + + Email: saul@ag-projects.com + + + Salvatore Loreto + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + Email: Salvatore.Loreto@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 43] + |