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

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

peter@andyet.com https://andyet.com/

AG Projects

Dr. Leijdsstraat 92 2021RK Haarlem The Netherlands saul@ag-projects.com

Ericsson

Hirsalantie 11 02420 Jorvas Finland Salvatore.Loreto@ericsson.com

RAI Text Chat Groupchat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty 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.

Both the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) can be used for the purpose of multiparty 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 , including mapping of addresses and error conditions. This document specifies mappings for multiparty text chat sessions (often called "groupchat"); specifically, this document defines a mapping between the XMPP Multi-User Chat (MUC) extension and SIP-based multiparty chat using Message Session Relay Protocol as specified in . Both MUC and MSRP contain a large set of features, such as the ability to administer rooms, kick 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.

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 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 and XMPP , with the base document for this series , and with the following groupchat-related specifications: Multi-party Chat Using MSRP Multi-User Chat

A number of technical terms used here are defined in , , , and . The term "JID" is short for "Jabber ID". 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 .

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" (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: romeo@example.org -- a SIP user. romeo@example.org;gr=dr4hcr0st3lup4c -- a particular endpoint associated with the SIP user. example.org -- a SIP proxy with an associated signaling gateway ("S2X GW") to XMPP. chat.example.org -- a SIP-based conference focus and MSRP switch with an associated gateway ("M2X GW") to XMPP. montague@chat.example.org -- a conference at an MSRP switch; not shown in diagram. juliet@example.com -- an XMPP user. juliet@example.com/yn0cl4bnw0yr3vym -- a particular endpoint associated with the XMPP user. example.com -- an XMPP server with an associated gateway ("X2S GW") to SIP and another gateway ("X2M GW") to MSRP. rooms.example.com -- an XMPP MUC service associated with example.com. capulet@rooms.example.com -- a chatroom 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.

| +-----+ | # # & & % / | | # # & +------------------+ % / +-----+ | # # & | 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 ]]> 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 chatroom 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 own inbound gateways).

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 nickname, and inviting another user).

| | | | | (F2) SIP INVITE | | | |****************>| | | | | (F3) | | | | unstandardized | | | | interaction | | | |<&&&&&&&&&&&&&&&>| | | (F4) SIP 200 OK | | | |<****************| | | | (F5) SIP ACK | | | |****************>| | | | (F6) MSRP SEND (bodiless) | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F7) MSRP 200 OK | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | | (F8) MSRP NICKNAME | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F9) MSRP 200 OK | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | | (F10) SIP | | | | SUBSCRIBE | | | | Event: | | | | conference | | | |****************>| | | | (F11) SIP 200 OK| | | |<****************| | | | (F12) SIP NOTIFY| | | |<****************| | | | (F13) SIP 200 OK| | | |****************>| | | (F14) XMPP | | | | presence | | | |<................| | | | (F15) XMPP | | | | MUC subject | | | |<................| | | . . . . . . . . | (F16) XMPP | | | | groupchat | | | | message | | | |................>| | | | | (F17) MSRP SEND | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F18) MSRP 200 OK | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | (F19) XMPP | | | | groupchat | | | | message | | | |<................| | | . . . . . . . . | (F20) XMPP | | | | private | | | | message | | | |................>| | | | | (F21) MSRP SEND | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F22) MSRP 200 OK | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| . . . . . . . . | (F23) XMPP | | | | presence: | | | | change nick | | | |................>| | | | | (F24) MSRP NICKNAME | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F25) MSRP 425 Error | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | (F26) XMPP | | | | presence | | | | error | | | |<................| | | . . . . . . . . | (F27) XMPP | | | | message: | | | | invite | | | |................>| | | | | (F28) SIP | | | | REFER | | | |****************>| | | | (F29) SIP | | | | 200 OK | | | |<****************| | | | (F30) SIP | | | | NOTIFY | | | |<****************| | . . . . . . . . | (F31) XMPP | | | | presence: | | | | exit room | | | |................>| | | | | (F32) SIP BYE | | | |****************>| | | | (F33) SIP | | | | 200 OK | | | |<****************| | | (F34) XMPP | | | | presence | | | | unavailable | | | |<................| | | | | | | ]]> Detailed protocol flows and mappings are provided in the following sections.

As defined in the XMPP Multi-User Chat (MUC) specification , 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 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) | | ]]> 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 . 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.

Example 2: SIP mapping of room join (F2) | From: "Juliet" | Contact: ;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 offer specifies the XMPP-to-MSRP gateway on the XMPP side (in the SDP "path" attribute specified in ) as well as other particulars of the session. There is no direct mapping for the MSRP URIs. In fact MSRP URIs identify a session of instant messages at a particular device; they are ephemeral and have 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 , an explicit port number). The mapping of XMPP syntax elements to SIP and syntax elements MUST be as shown in the following table.

Table 1: Message syntax mapping from XMPP to SIP/SDP As shown in the foregoing example and described in , 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 GRUU portion of the SIP URI. 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 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 ), and contains the extensions specified in .

Example 4: Gateway sends ACK to conference focus (F5) ;tag=087js | From: "Juliet" ;tag=786 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 | CSeq: 2 ACK ]]> In accordance with , the gateway sends a bodiless MSRP message (F6) to the switch immediately upon establising the connection, and the switch acknowledges the that message (F7).

If the chat room server accepted the session, the XMPP-to-MSRP gateway sets up the nickname as received in the presence stanza (i.e., the resourcepart of the 'to' address, such "JuliC" in "montague@chat.example.org/JuliC"). This is done using the extension specified in .

Example 5: Gateway sets up nickname (F8) 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) This section assumes that the nickname request is successful. The error flow resulting from a nickname conflict is described under .

As mentioned in , the joining user will typically also subscribe to a conference event package (see and ) at the focus. Although such a subscription is not required by , 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.

Example 8: Focus accepts subscription request (F11) | To: "Juliet" | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 | CSeq: 3 SUBSCRIBE | Contact: ;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 at the focus.

When the Conference Event package subscription is completed, the focus sends to the XMPP-to-SIP gateway a NOTIFY containing the presence information of all the existing occupants, represented using the format defined in .

Example 10: XMPP mapping of chatroom presence (F14) | | | | | | | | | | | | | | | ]]> If the NOTIFY included a subject, the gateway converts that into a separate XMPP message.

Example 11: XMPP mapping of chatroom subject (F15) | Today in Verona | ]]> The mapping of SIP and payload syntax elements to XMPP syntax elements MUST be as shown in the following table. (Mappings for elements not mentioned are undefined.)

Once the user has joined the chatroom, 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 | body of the SEND request | +-----------------------------+-----------------------------+ ]]>

When Juliet wants to sends a message to all other occupants in the room, she sends a message of type "groupchat" to the <room@service> itself (in our example, <montague@chat.example.org>). The following examples show an exchange of a public message.

Example 12: Juliet sends message to all occupants (F16) | Who knows where Romeo is? | ]]> 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) | From: "Juliet" | 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) 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, 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 prodedure only applies to XMPP endpoints.

Example 15: Gateway reflects message to XMPP user (F19) | Who knows where Romeo is? | ]]>

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) | O Romeo, Romeo! wherefore art thou Romeo? | ]]> 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) ;gr=Romeo | From: ;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 (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 chatroom.

Example 18: Switch sends private message to SIP user | From: ;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 .

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

Example 20: MSRP switch does not accept nickname proposal (F25) 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) | | | | | ]]> 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.

In XMPP there are two methods for inviting another user to a room: direct invitations (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).

Example 22: Juliet invites Benvolio to the room (F27) | | | | ]]> 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 (sec 5.5)

Example 23: SIP mapping of invite (F28) | From: "Juliet" ;tag=5534562 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 | CSeq: 5 REFER | Contact: ;gr=yn0cl4bnw0yr3vym | Accept: message/sipfrag | Refer-To: | 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 .

Example 24: Progress notification for invitation (F30) ;tag=5534562 | From: ;tag=18747389 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 | CSeq: 6 NOTIFY | Max-Forwards: 70 | Event: refer | Subscription-State: active;expires=60 | Contact: ;isfocus | Content-Type: message/sipfrag;version=2.0 | Content-Length: ... ]]> Note: Implementers might want to be aware that work is underway to modify the way in which REFER requests handle SIP notifications ( and ).

If Juliet decides to exit the chatroom, 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) ]]> 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 chatroom (F31) | O, look! methinks I see my cousin's ghost | ]]>

This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP Multi-User Chat (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).

| | | | (F36) SIP | | | | 200 OK | | | |<****************| | | | (F37) SIP ACK | | | |****************>| | | | (F38) SIP | | | | SUBSCRIBE | | | | Event: | | | | conference | | | |****************>| | | | (F39) SIP | | | | 200 OK | | | |<****************| | | | | (F40) XMPP presence: enter room | | |..................................>| | | (F41) XMPP presence | | |<..................................| | (F42) SIP | | | | NOTIFY | | | |<****************| | | | (F43) SIP | | | | 200 OK | | | |****************>| | | . . . . . . . . | (F44) MSRP SEND | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | | | (F45) XMPP | | | | groupchat | | | | message | | | |................>| | | | (F46) XMPP | | | | groupchat | | | | message | | | |<................| | (F47) MSRP 200 OK | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | . . . . . . . . | (F48) MSRP SEND | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F49) MSRP 200 OK | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | | | | (F50) XMPP | | | | message | | | |................>| . . . . . . . . | (F51) MSRP NICKNAME | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | | | (F52) XMPP | | | | presence | | | |................>| | | | (F53) XMPP | | | | presence | | | | error | | | |<................| | (F54) MSRP 425 Error | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | . . . . . . . . | (F55) SIP REFER | | | |****************>| | | | (F56) SIP | | | | 200 OK | | | |<****************| | | | (F57) SIP | | | | NOTIFY | | | |<****************| | | | | (F58) XMPP message invite | | |..................................>| . . . . . . . . | (F59) SIP BYE | | | |****************>| | | | | (F60) XMPP presence unavailable | | |..................................>| | | (F61) XMPP presence unavailable | | |<..................................| | (F62) SIP | | | | 200 OK | | | |<****************| | | | | | | ]]> If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the "conference" event, then the server SHOULD cache the participant list until the subscription is established and delivered in a SIP NOTIFY request.

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 a 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 specifing support for a Message/CPIM top level wrapper for the MSRP message.

Example 27: SIP user starts session (F35) | To: | Contact: ;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 . 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.

Example 28: SIP-to-XMPP gateway acks session (F36) | To: | Contact: ;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 30: Romeo enters XMPP chatroom (F40) | | ]]>

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) | | | | | | | | | | | | | | | | | ]]> Upon receiving these presence stanzas, if the conference focus has already completed the subscription to the Conference Event package , the XMPP-to-SIP gateway translates them into a SIP NOTIFY request containing the participant list (represented in the conference-info format specified in ).

Example 32: SIP mapping of XMPP participant presence stanzas (F42) ;tag=43524545 | From: ;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: ... | | | | Today in Verona | | | tel:+18882934234 | sip:capulet@rooms.example.com | | | | | | JuliC | | participant | | | connected | | message | | | | | Ben | | participant | | | connected | | message | | | | ]]> 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-info 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 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-info document containing the complete participant list and send that to the SIP user.

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

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). The following examples show an exchange of a public message.

Example 33: Romeo sends a message to the chat room (F44) | From: "Romeo" ;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 generate and send an MSRP response.

Example 34: XMPP mapping of message (F45) | Romeo is here! | ]]>

Example 35: MSRP response to public message (F47) 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.

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) ;gr=JuliC | From: "Romeo" ;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) | I am here!!! | ]]>

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.

Example 38: MSRP user changes nickname (F51) 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) ]]> 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) | | | | | ]]> 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)

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 .

Example 42: SIP user invites another user (F55) | From: "Romeo" ;tag=5534562 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 4 NOTIFY | Contact: ;gr=dr4hcr0st3lup4c | Accept: message/sipfrag | Refer-To: | 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 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, with a status code of 100 Trying.

If Romeo decides to exit the chat room, his client sends a SIP BYE to the <montague@chat.example.org> chat room.

Example 44: Romeo terminates session (F59) ;tag=786 | To: ;tag=534 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 5 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 chatroom (F60) ]]>

Fundamental rules for mapping addresses between XMPP and SIP are provided in . However, chatrooms 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 . 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 XCON 'nickname' attribute of the <user/> element and the display name is the XML character data of the conference-info <display-text/> element . In XMPP, the nickname is the value of the resourcepart of the occupant JID and the display name is the XML character data of the <nick/> element . In practice, the <display-text/> element is treated as canonical in SIP implementations, and the <nick/> element is rarely used in XMPP implementations. Therefore, for display purposes SIP implementations ought to use the <display-text/> element if the XCON 'nickname' attribute is not present, and XMPP implementations ought to use the resourcepart of the occupant JID if the <nick/> element is not present. 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 chatroom.

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 for a discussion of this issue.

This document requests no actions of the IANA.

The security considerations of , , , , , and 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 specifies such a format for one-to-one instant messages, the problem of end-to-end security for multiparty 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 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 , 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 multiparty instant messages, this document cannot provide a recommendation in this regard.

Preparation and Comparison of Nicknames This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms. This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON). Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP) The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party instant messaging (IM) sessions, or chat rooms, with MSRP. Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). Key words for use in RFCs to Indicate Requirement Levels Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. SIP: Session Initiation Protocol This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK] Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. [STANDARDS TRACK] The Message Session Relay Protocol (MSRP) This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK] Extensible Messaging and Presence Protocol (XMPP): Core The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK] Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. [STANDARDS-TRACK] Multi-User Chat

stpeter@jabber.org

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Clarifications for the use of REFER with RFC6665 An accepted SIP REFER method creates an implicit subscription using the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. Explicit Subscriptions for the REFER Method The SIP REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible, and complicates avoiding SIP dialog sharing. This document defines an extension to REFER to remove the implicit subscription and replace it with an explicit one. The Session Initiation Protocol (SIP) Refer Method This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK] Common Presence and Instant Messaging (CPIM): Message Format A Framework for Conferencing with the Session Initiation Protocol (SIP) The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community. SDP: Session Description Protocol This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK] A Session Initiation Protocol (SIP) Event Package for Conference State This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS TRACK] Conference Information Data Model for Centralized Conferencing (XCON) RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK] Conference Event Package Data Format Extension for Centralized Conferencing (XCON) This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK] User Nickname

stpeter@jabber.org

valerie.mercier@orange-ftgroup.com

Direct MUC Invitations

stpeter@jabber.org

Special thanks to Fabio Forno for coauthoring an early 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 versions of this document.