idnits 2.17.1 draft-ietf-stox-groupchat-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3312 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-16 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0045' -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft &yet 4 Intended status: Standards Track S. Ibarra 5 Expires: September 6, 2015 AG Projects 6 S. Loreto 7 Ericsson 8 March 5, 2015 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Groupchat 12 draft-ietf-stox-groupchat-11 14 Abstract 16 This document defines a bidirectional protocol mapping for the 17 exchange of instant messages in the context of a multiparty chat 18 session among users of the Session Initiation Protocol (SIP) and 19 users of the Extensible Messaging and Presence Protocol (XMPP). 20 Specifically, this document defines a mapping between the SIP-based 21 Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat 22 (MUC) extension. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 4 62 5. XMPP MUC to MSRP Multi-party Messaging Session . . . . . . . 7 63 5.1. Enter Room . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2. Set Nickname . . . . . . . . . . . . . . . . . . . . . . 12 65 5.3. Conference Subscription . . . . . . . . . . . . . . . . . 13 66 5.4. Presence Broadcast . . . . . . . . . . . . . . . . . . . 14 67 5.5. Exchange Messages . . . . . . . . . . . . . . . . . . . . 18 68 5.5.1. Send a Message to All Occupants . . . . . . . . . . . 18 69 5.5.2. Send a Private Message . . . . . . . . . . . . . . . 20 70 5.6. Change Nickname . . . . . . . . . . . . . . . . . . . . . 21 71 5.7. Invite Another User to a Room . . . . . . . . . . . . . . 22 72 5.8. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 24 73 6. MSRP Multi-party Messaging Session to XMPP MUC . . . . . . . 24 74 6.1. Enter Room . . . . . . . . . . . . . . . . . . . . . . . 26 75 6.2. Presence Broadcast . . . . . . . . . . . . . . . . . . . 28 76 6.3. Exchange Messages . . . . . . . . . . . . . . . . . . . . 31 77 6.3.1. Send a Message to All Occupants . . . . . . . . . . . 31 78 6.3.2. Send a Private Message . . . . . . . . . . . . . . . 32 79 6.4. Change Nickname . . . . . . . . . . . . . . . . . . . . . 33 80 6.5. Invite Another User to a Room . . . . . . . . . . . . . . 34 81 6.6. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 35 82 7. Handling of Nicknames and Display Names . . . . . . . . . . . 36 83 8. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 37 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 38 88 11.2. Informative References . . . . . . . . . . . . . . . . . 39 89 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 92 1. Introduction 94 Both the Session Initiation Protocol (SIP) [RFC3261] and the 95 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be 96 used for the purpose of multiparty text chat over the Internet. To 97 ensure interworking between these technologies, it is important to 98 define bidirectional protocol mappings. 100 The architectural assumptions underlying such protocol mappings are 101 provided in [RFC7247], including mapping of addresses and error 102 conditions. This document specifies mappings for multiparty text 103 chat sessions (often called "groupchat"); specifically, this document 104 defines a mapping between the XMPP Multi-User Chat (MUC) extension 105 [XEP-0045] and SIP-based multiparty chat using Message Session Relay 106 Protocol [RFC4975] as specified in [I-D.ietf-simple-chat]. 108 Both MUC and MSRP contain a large set of features, such as the 109 ability to administer rooms, kick and ban users, reserve a nickname 110 within a room, change room subject, enable room moderation, and 111 destroy the room. This document covers only a basic subset of 112 groupchat features: joining a room, establishing or changing (but not 113 permanently registering) a room nickname, modifying presence 114 information within the room, sending a message to all participants, 115 sending a private message to a single participant, inviting another 116 user to the room, and leaving the room. Future documents might 117 define mappings for additional features beyond this set. 119 2. Intended Audience 121 The documents in this series are intended for use by software 122 developers who have an existing system based on one of these 123 technologies (e.g., SIP), and would like to enable communication from 124 that existing system to systems based on the other technology (e.g., 125 XMPP). We assume that readers are familiar with the core 126 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the 127 base document for this series [RFC7247], and with the following 128 groupchat-related specifications: 130 o Multi-party Chat Using MSRP [I-D.ietf-simple-chat] 132 o Multi-User Chat [XEP-0045] 134 3. Terminology 136 A number of technical terms used here are defined in [RFC3261], 137 [RFC4975], [RFC6120], and [XEP-0045]. The term "JID" is short for 138 "Jabber ID". 140 In flow diagrams, MSRP traffic is shown using arrows such as "&&&>", 141 SIP traffic is shown using arrows such as "***>", XMPP traffic is 142 shown using arrows such as "...>". 144 In protocol flows and examples, provisional SIP responses have been 145 elided for the sake of brevity. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 [RFC2119]. 152 4. Architectural Assumptions 154 XMPP and MSRP differ in their assumptions regarding groupchat 155 traffic. In XMPP, a message of type 'groupchat' is just another 156 stanza, and is handled directly by an XMPP server or routed to an 157 associated server component for multi-user chat. By contrast, 158 sessions (including groupchat sessions) in MSRP are considered to be 159 a type of media (similar to audio/video sessions): signaling to set 160 up, manage, and tear down the session is handled by a "conference 161 focus" (here we assume via SIP) but the session data itself is 162 handled by a separate entity called an MSRP switch. How the 163 conference focus and MSRP switch communicate is a matter of 164 implementation and deployment. 166 An architectural diagram for a possible gateway deployment is shown 167 below, where the entities have the following significance: 169 o romeo@example.org -- a SIP user. 171 o romeo@example.org;gr=dr4hcr0st3lup4c -- a particular endpoint 172 associated with the SIP user. 174 o example.org -- a SIP proxy with an associated signaling gateway 175 ("S2X GW") to XMPP. 177 o chat.example.org -- a SIP-based conference focus and MSRP switch 178 with an associated gateway ("M2X GW") to XMPP. 180 o montague@chat.example.org -- a conference at an MSRP switch; not 181 shown in diagram. 183 o juliet@example.com -- an XMPP user. 185 o juliet@example.com/yn0cl4bnw0yr3vym -- a particular endpoint 186 associated with the XMPP user. 188 o example.com -- an XMPP server with an associated gateway ("X2S 189 GW") to SIP and another gateway ("X2M GW") to MSRP. 191 o rooms.example.com -- an XMPP MUC service associated with 192 example.com. 194 o capulet@rooms.example.com -- a chatroom at an XMPP MUC service; 195 not shown in diagram. 197 These are logical entities, and several of them might be co-located 198 in the same physical entity. For example, the SIP conference focus 199 and MSRP switch and associated gateways, or the XMPP server and MUC 200 service and associated gateways, might be part of the same deployed 201 code. In addition, it is likely that an XMPP service would not have 202 separate gateways for XMPP-to-SIP translation and XMPP-to-MSRP 203 translation, but would instead have a single gateway. 205 ##################################################################### 206 # # 207 # +------------------+ # 208 # &&&&&&&&&&&&&&&&| chat.example.org |<%%%%%%%%%%% # 209 # & &&&&| (MSRP switch) +-----+ % # 210 # & & +---------------| M2X | % # 211 # & & % | GW | % # 212 # & & % +-----+ % # 213 # & & % : % # 214 # & & % ///////////////////////////////////# 215 # & & % / : % # 216 # & & % / : +-----+ # 217 # & & % / : | X2M | # 218 # & & % / : +-------| GW |---+ # 219 # & & % / :.>| +-----+ | # 220 # & & % / | | # 221 # & +------------------+ % / +-----+ | # 222 # & | chat.example.org |<*******/*| X2S | example.com | # 223 # & | (conference | % **/*| GW | (XMPP server) | # 224 # & | focus) +-----+ % * / +-----+ | # 225 # & +------------| S2X | % * / | +-------------------+ # 226 # & * | GW |......*./....>| | rooms.example.com | # 227 # & * +-----+ % * / +-----| (MUC service) | # 228 # & * % * / ^ : +-------------------+ # 229 # & +---------------+ % * / : : # 230 # &&| example.org |<********* / : : # 231 # | (SIP proxy) +-----+ % / : : # 232 # +-------------| S2X | % / : : # 233 # * | GW |......./........ : # 234 # * +-----+ % / : # 235 # * % / : # 236 # romeo@example.org / juliet@example.com # 237 # ;gr=dr4hcr0st3lup4c / /yn0cl4bnw0yr3vym # 238 # / # 239 # --SIP/MSRP DOMAIN-- / --XMPP DOMAIN-- # 240 # / # 241 ##################################################################### 243 Legend: 244 . = XMPP 245 % = MSRP 246 * = SIP 247 & = unstandardized communication paths 248 / = separation of administrative domains 250 Figure 1: Logical Deployment Architecture 252 In SIP, there is no necessity for a SIP user such as 253 romeo@example.org to make use of his SIP proxy in order to join a 254 chatroom on the XMPP network; for example, he could try to directly 255 find a SIP service at example.com or independently locate a SIP-to- 256 XMPP gateway. Although as a simplifying assumption this document 257 shows the more expected path of using one's "home" SIP proxy and 258 shows gateways as associated with the sending domain, nothing in this 259 document ought to be construed as discouraging other deployment 260 architectures or communication paths (e.g., services hosting own 261 inbound gateways). 263 5. XMPP MUC to MSRP Multi-party Messaging Session 265 This section describes how to map an XMPP MUC session to an MSRP 266 Multi-party Messaging session. The following diagram outlines the 267 overall protocol flow of a sample session, which includes some 268 optional exchanges (such as sending messages, changing nickname, and 269 inviting another user). 271 XMPP XMPP SIP MSRP 272 User Server Conference Switch 273 | + X2S GW Focus + M2X GW 274 | & X2M GW + S2X GW | 275 | | | | 276 | (F1) XMPP | | | 277 | enter room | | | 278 |................>| | | 279 | | (F2) SIP INVITE | | 280 | |****************>| | 281 | | | (F3) | 282 | | | unstandardized | 283 | | | interaction | 284 | | |<&&&&&&&&&&&&&&&>| 285 | | (F4) SIP 200 OK | | 286 | |<****************| | 287 | | (F5) SIP ACK | | 288 | |****************>| | 289 | | (F6) MSRP SEND (bodiless) | 290 | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| 291 | | (F7) MSRP 200 OK | 292 | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| 293 | | (F8) MSRP NICKNAME | 294 | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| 295 | | (F9) MSRP 200 OK | 296 | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| 297 | | (F10) SIP | | 298 | | SUBSCRIBE | | 299 | | Event: | | 300 | | conference | | 301 | |****************>| | 302 | | (F11) SIP 200 OK| | 303 | |<****************| | 304 | | (F12) SIP NOTIFY| | 305 | |<****************| | 306 | | (F13) SIP 200 OK| | 307 | |****************>| | 308 | (F14) XMPP | | | 309 | presence | | | 310 |<................| | | 311 | (F15) XMPP | | | 312 | MUC subject | | | 313 |<................| | | 314 . . . . 315 . . . . 316 | (F16) XMPP | | | 317 | groupchat | | | 318 | message | | | 319 |................>| | | 320 | | (F17) MSRP SEND | 321 | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| 322 | | (F18) MSRP 200 OK 323 | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| 324 | (F19) XMPP | | | 325 | groupchat | | | 326 | message | | | 327 |<................| | | 328 . . . . 329 . . . . 330 | (F20) XMPP | | | 331 | private | | | 332 | message | | | 333 |................>| | | 334 | | (F21) MSRP SEND | 335 | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| 336 | | (F22) MSRP 200 OK 337 | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| 338 . . . . 339 . . . . 340 | (F23) XMPP | | | 341 | presence: | | | 342 | change nick | | | 343 |................>| | | 344 | | (F24) MSRP NICKNAME | 345 | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| 346 | | (F25) MSRP 425 Error | 347 | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| 348 | (F26) XMPP | | | 349 | presence | | | 350 | error | | | 351 |<................| | | 352 . . . . 353 . . . . 354 | (F27) XMPP | | | 355 | message: | | | 356 | invite | | | 357 |................>| | | 358 | | (F28) SIP | | 359 | | REFER | | 360 | |****************>| | 361 | | (F29) SIP | | 362 | | 200 OK | | 363 | |<****************| | 364 | | (F30) SIP | | 365 | | NOTIFY | | 366 | |<****************| | 367 . . . . 368 . . . . 369 | (F31) XMPP | | | 370 | presence: | | | 371 | exit room | | | 372 |................>| | | 373 | | (F32) SIP BYE | | 374 | |****************>| | 375 | | (F33) SIP | | 376 | | 200 OK | | 377 | |<****************| | 378 | (F34) XMPP | | | 379 | presence | | | 380 | unavailable | | | 381 |<................| | | 382 | | | | 384 Detailed protocol flows and mappings are provided in the following 385 sections. 387 5.1. Enter Room 389 As defined in the XMPP Multi-User Chat (MUC) specification 390 [XEP-0045], when an XMPP user (say, "juliet@example.com") wants to 391 join a groupchat room (say, "montague@chat.example.org"), she sends a 392 directed stanza [RFC6121] to that chat room. In her 393 request she also specifies the nickname she wants to use within the 394 room (say, "JuliC"); in XMPP this room nickname is the resourcepart 395 of an occupant JID (thus "montague@chat.example.org/JuliC"). The 396 joining client signals its ability to speak the multi-user chat 397 protocol by including in the initial presence stanza an empty 398 element qualified by the 'http://jabber.org/protocol/muc' namespace. 400 Example 1: Juliet enters room (F1) 402 | 404 | 405 | 407 Upon receiving such a presence stanza, the XMPP server needs to 408 determine the identity of the domainpart in the 'to' address, which 409 it does by following the procedures discussed in [RFC7247]. Here we 410 assume that the XMPP server has determined the domain is serviced by 411 a SIP server, that it contains or has available to it an XMPP-to-SIP 412 gateway or connection manager (which enables it to speak natively to 413 SIP servers), and that it hands off the presence stanza to the XMPP- 414 to-SIP gateway. 416 Because a multi-user chat service accepts the presence stanza shown 417 above as a request to enter a room, the XMPP-to-SIP gateway 418 transforms it into a SIP INVITE request. 420 Example 2: SIP mapping of room join (F2) 422 | INVITE sip:montague@chat.example.org SIP/2.0 423 | To: 424 | From: "Juliet" 425 | Contact: ;gr=yn0cl4bnw0yr3vym 426 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 427 | CSeq: 1 INVITE 428 | Content-Type: application/sdp 429 | Content-Length: ... 430 | 431 | c=IN IP4 x2s.example.org 432 | m=message 7654 TCP/MSRP * 433 | a=accept-types:text/cpim 434 | a=accept-wrapped-types:text/plain text/html 435 | a=path:msrp://x2m.example.com:7654/jshA7weztas;tcp 436 | a=chatroom:nickname private-messages 438 Here the Session Description Protocol offer specifies the XMPP-to- 439 MSRP gateway on the XMPP side (in the SDP "path" attribute specified 440 in [RFC4975]) as well as other particulars of the session. 442 There is no direct mapping for the MSRP URIs. In fact MSRP URIs 443 identify a session of instant messages at a particular device; 444 they are ephemeral and have no meaning outside the scope of that 445 session. The authority component of the MSRP URI here MUST 446 contain the XMPP-to-MSRP gateway hostname or numeric IP address 447 (as well as, in accordance with [RFC4975], an explicit port 448 number). 450 The mapping of XMPP syntax elements to SIP and [RFC4566] syntax 451 elements MUST be as shown in the following table. 453 Table 1: Message syntax mapping from XMPP to SIP/SDP 455 +-----------------------------+-----------------------------+ 456 | XMPP Element or Attribute | SIP Header or SDP Contents | 457 +-----------------------------+-----------------------------+ 458 | from | From | 459 | to (without the /nick) | To | 460 +-----------------------------+-----------------------------+ 462 As shown in the foregoing example and described in [RFC7247], the 463 XMPP-to-SIP gateway MUST map the bare JID ("localpart@domainpart") of 464 the XMPP sender to the SIP From header and include the resourcepart 465 of the full JID as the GRUU portion [RFC5627] of the SIP URI. 467 Here we assume that the SIP conference focus accepts the session 468 establishment. The Contact header field of the SIP 200 OK response 469 includes the 'isfocus' feature tag specified in [RFC4353] along with 470 other relevant feature tags. The conference focus also includes an 471 answer session description that acknowledges the choice of media, 472 specifies the MSRP URI of the switch (in the "path" attribute 473 specified in [RFC4975]), and contains the extensions specified in 474 [I-D.ietf-simple-chat]. 476 Example 3: Chat room accepts session establishment (F4) 478 | SIP/2.0 200 OK 479 | From: "Juliet" ;tag=786 480 | To: 481 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 482 | CSeq: 1 INVITE 483 | Contact: ;isfocus 484 | Content-Type: application/sdp 485 | Content-Length: ... 486 | 487 | v=0 488 | c=IN IP4 example.org 489 | s=- 490 | m=message 12763 TCP/MSRP * 491 | a=accept-types:message/cpim 492 | a=accept-wrapped-types:text/plain text/html 493 | a=path:msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp 494 | a=chatroom:nickname private-messages 496 Upon receiving such a response, the XMPP-to-SIP gateway sends a SIP 497 ACK to the conference focus on behalf of the joining user. 499 Example 4: Gateway sends ACK to conference focus (F5) 501 | ACK sip:montague@chat.example.org SIP/2.0 502 | To: ;tag=087js 503 | From: "Juliet" ;tag=786 504 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 505 | CSeq: 2 ACK 507 In accordance with [RFC4975], the gateway sends a bodiless MSRP 508 message (F6) to the switch immediately upon establising the 509 connection, and the switch acknowledges the that message (F7). 511 5.2. Set Nickname 513 If the chat room server accepted the session, the XMPP-to-MSRP 514 gateway sets up the nickname as received in the presence stanza 515 (i.e., the resourcepart of the 'to' address, such "JuliC" in 516 "montague@chat.example.org/JuliC"). This is done using the extension 517 specified in [I-D.ietf-simple-chat]. 519 Example 5: Gateway sets up nickname (F8) 521 | MSRP a786hjs2 NICKNAME 522 | To-Path: msrp://montague@chat.example.org:12763/kjhd37s2s20w2a;tcp 523 | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 524 | Use-Nickname: "JuliC" 525 | -------a786hjs2 527 The MSRP switch analyzes the existing allocation of nicknames, 528 accepts the nickname proposal, and answers with a 200 response. 530 Example 6: MSRP switch accepts nickname proposal (F9) 532 | MSRP a786hjs2 200 OK 533 | To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 534 | From-Path: msrp://montague@chat.example.org:12763/kjhd37s2s20w2a 535 | ;tcp 536 | -------a786hjs2 538 This section assumes that the nickname request is successful. The 539 error flow resulting from a nickname conflict is described under 540 Section 5.6. 542 5.3. Conference Subscription 544 As mentioned in [I-D.ietf-simple-chat], the joining user will 545 typically also subscribe to a conference event package (see [RFC4575] 546 and [RFC6502]) at the focus. Although such a subscription is not 547 required by [I-D.ietf-simple-chat], in practice the temporary and 548 context-dependent presence subscriptions and room rosters involved in 549 joining an XMPP MUC room are best mapped to the conference event 550 package. 552 Example 7: Gateway subscribes to the conference (F10) 554 | SUBSCRIBE sip:montague@chat.example.org SIP/2.0 555 | To: 556 | From: "Juliet" 557 | Contact: ;gr=yn0cl4bnw0yr3vym 558 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 559 | CSeq: 3 SUBSCRIBE 560 | Event: conference 561 | Expires: 600 562 | Accept: application/conference-info+xml 563 | Allow-Events: conference 564 | Content-Length: 0 566 The focus will accept or reject the request based on local policy. 568 Example 8: Focus accepts subscription request (F11) 570 | SIP/2.0 200 OK 571 | From: 572 | To: "Juliet" 573 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 574 | CSeq: 3 SUBSCRIBE 575 | Contact: ;isfocus 576 | Expires: 600 577 | Content-Length: 0 579 If the conference focus accepts the request to enter a room, the XMPP 580 user expects to receive back presence information from all the 581 existing occupants of the room. To make this happen, the XMPP-to-SIP 582 gateway subscribes to the Conference Event package [RFC4575] at the 583 focus. 585 5.4. Presence Broadcast 587 When the Conference Event package subscription is completed, the 588 focus sends to the XMPP-to-SIP gateway a NOTIFY containing the 589 presence information of all the existing occupants, represented using 590 the format defined in [RFC4575]. 592 Example 9: Conference focus sends presence information (F12) 594 | NOTIFY sip:montague@chat.example.org SIP/2.0 595 | To: "Juliet" ;gr=yn0cl4bnw0yr3vym 596 | From: ;tag=a3343df32 597 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 598 | CSeq: 4 NOTIFY 599 | Event: conference 600 | Subscription-State: active;expires=3600 601 | Content-Type: application/conference-info+xml 602 | Content-Length: ... 603 | 604 | 606 | 607 | Today in Verona 608 | 609 | 610 | tel:+18882934234 611 | 612 | 613 | 614 | 615 | 617 | Romeo 618 | 619 | participant 620 | 621 | 622 | 623 | xmpp:romeo@example.org/dr4hcr0st3lup4c 624 | 625 | 626 | 628 | connected 629 | 630 | 2013-12-12T10:01:03.691128+01:00 631 | 632 | 633 | message 634 | 635 | 636 | 637 | 639 | Ben 640 | 641 | participant 642 | 643 | 645 | connected 646 | 647 | message 648 | 649 | 650 | 651 | 653 | JuliC 654 | 655 | participant 656 | 657 | 659 | connected 660 | 661 | message 662 | 663 | 664 | 665 | 666 | 668 The syntax mapping from the RFC 4575 payload to the XMPP participant 669 list MUST be as shown in the following table. (Mappings for elements 670 not mentioned are undefined.) 672 Table 2: Participant list mapping 674 +--------------------------------+-----------------------------+ 675 | RFC 4575 Element or Attribute | XMPP Element or Attribute | 676 +--------------------------------+-----------------------------+ 677 | 'entity' | room JID | 678 | | room subject | 679 | 'entity' | occupant JID | 680 | | participant nickname | 681 | 'entity' | occupant JID | 682 | 'associated-aors' | user full JID (if avail.) | 683 +--------------------------------+-----------------------------+ 685 Upon receiving such a response, the XMPP-to-SIP gateway sends a SIP 686 200 OK response to the conference focus (example not shown) and 687 translate the participant list into a series of XMPP presence 688 stanzas. 690 Example 10: XMPP mapping of chatroom presence (F14) 692 | 694 | 695 | 696 | 697 | 699 | 701 | 702 | 703 | 704 | 706 | 708 | 709 | 710 | 711 | 712 | 714 If the NOTIFY included a subject, the gateway converts that into a 715 separate XMPP message. 717 Example 11: XMPP mapping of chatroom subject (F15) 719 | 722 | Today in Verona 723 | 725 The mapping of SIP and [RFC4575] payload syntax elements to XMPP 726 syntax elements MUST be as shown in the following table. (Mappings 727 for elements not mentioned are undefined.) 728 Table 3: Message syntax mapping from SIP to XMPP 730 +---------------------------------+-----------------------------+ 731 | SIP Header or RFC4575 Contents | XMPP Element or Attribute | 732 +---------------------------------+-----------------------------+ 733 | 'entity' | from | 734 | To with | occupant JID | 735 | participant | role='participant' | 736 | [N/A] | affiliation='none' | 737 +---------------------------------+-----------------------------+ 739 5.5. Exchange Messages 741 Once the user has joined the chatroom, the user can exchange an 742 unbounded number of messages, both public and private. 744 The mapping of XMPP syntax elements to MSRP syntax elements MUST be 745 as shown in the following table. (Mappings for elements not 746 mentioned are undefined.) 748 Table 4: Message syntax mapping from XMPP Message to MSRP 750 +-----------------------------+-----------------------------+ 751 | XMPP Element or Attribute | CPIM Header | 752 +-----------------------------+-----------------------------+ 753 | to | To | 754 | from | From | 755 | | body of the SEND request | 756 +-----------------------------+-----------------------------+ 758 5.5.1. Send a Message to All Occupants 760 When Juliet wants to sends a message to all other occupants in the 761 room, she sends a message of type "groupchat" to the 762 itself (in our example, ). 764 The following examples show an exchange of a public message. 766 Example 12: Juliet sends message to all occupants (F16) 768 | 772 | Who knows where Romeo is? 773 | 774 Upon receiving such a message, the XMPP-to-MSRP gateway translates it 775 into an MSRP SEND message. 777 Example 13: Gateway maps XMPP message to MSRP (F17) 779 | MSRP a786hjs2 SEND 780 | To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp 781 | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 782 | Message-ID: 87652491 783 | Byte-Range: 1-*/* 784 | Content-Type: message/cpim 785 | 786 | To: 787 | From: "Juliet" 788 | DateTime: 2008-10-15T15:02:31-03:00 789 | Content-Type: text/plain 790 | 791 | Who knows where Romeo is? 792 | -------a786hjs2$ 794 Upon receiving the SEND request, if the request either contains a 795 Failure-Report header field value of "yes" or does not contain a 796 Failure-Report header at all, the MSRP switch immediately generates 797 and sends a response. 799 Example 14: MSRP switch returns 200 OK (F18) 801 | MSRP d93kswow 200 OK 802 | To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 803 | From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp 804 | -------d93kswow$ 806 Since an XMPP MUC room could be moderated and an XMPP user cannot be 807 sure whether her message has been accepted without receiving it back 808 from the server, [XEP-0045] states that the sender needs to receive a 809 reflected copy of the message it sent. So in this scenario the XMPP- 810 to-MSRP gateway has to reflect the message back to the sender. This 811 prodedure only applies to XMPP endpoints. 813 Example 15: Gateway reflects message to XMPP user (F19) 815 | 819 | Who knows where Romeo is? 820 | 822 5.5.2. Send a Private Message 824 Since each occupant has a unique JID, Juliet can send a "private 825 message" to a selected occupant through the service by sending a 826 message to the user's occupant JID. The XMPP message type ought to 827 be "chat" (and is not allowed to be "groupchat"). 829 The following examples show an exchange of a private message. 831 Example 16: Juliet sends private message (F20) 833 | 837 | O Romeo, Romeo! wherefore art thou Romeo? 838 | 840 Upon receiving such a message, the XMPP-to-MSRP gateway translates it 841 into an MSRP SEND message. 843 Example 17: Gateway maps private message from XMPP to MSRP (F21) 845 | MSRP a786hjs2 SEND 846 | To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp 847 | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 848 | Message-ID: 87652491 849 | Byte-Range: 1-*/* 850 | Content-Type: message/cpim 851 | 852 | To: ;gr=Romeo 853 | From: ;gr=yn0cl4bnw0yr3vym 854 | DateTime: 2008-10-15T15:02:31-03:00 855 | Content-Type: text/plain 856 | 857 | O Romeo, Romeo! wherefore art thou Romeo? 858 | -------a786hjs2$ 860 After acknowledging the message by sending an MSRP 200 OK (step F22, 861 not shown), the MSRP switch is responsible for sending the message to 862 the intended recipient. When doing so, it modifies the "From" header 863 to the sender's address within the chatroom. 865 Example 18: Switch sends private message to SIP user 867 | MSRP a786hjs2 SEND 868 | To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp 869 | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 870 | Message-ID: 87652491 871 | Byte-Range: 1-*/* 872 | Content-Type: message/cpim 873 | 874 | To: 875 | From: ;gr=JuliC 876 | DateTime: 2008-10-15T15:02:31-03:00 877 | Content-Type: text/plain 878 | 879 | O Romeo, Romeo! wherefore art thou Romeo? 880 | -------a786hjs2$ 882 Note: If an XMPP-to-MSRP gateway has support for private messaging, 883 it MUST advertise that fact by adding a "private-messages" value to 884 the a=chatroom SDP attribute it sends to the conference focus, as 885 specified in [I-D.ietf-simple-chat]. 887 | a=chatroom:nickname private-messages 889 5.6. Change Nickname 891 The XMPP user might want to change her nickname. She can do so by 892 sending an updated presence stanza to the room, containing a new 893 nickname. 895 Example 19: Juliet changes her nickname (F23) 897 | 900 So far we have assumed that the requested nickname did not conflict 901 with any existing nicknames. The following text describes the 902 handling of a nickname conflict. 904 The MSRP switch analyzes the existing allocation of nicknames, and 905 detects that the nickname proposal is already provided to another 906 participant. In this case the MSRP switch answers with a 425 907 response. 909 Example 20: MSRP switch does not accept nickname proposal (F25) 911 | MSRP a786hjs2 425 Nickname usage failed 912 | To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp 913 | From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp 914 | -------a786hjs2 916 Upon receiving such a response, the XMPP-to-MSRP gateway translates 917 it into an XMPP presence stanza of type "error" specifying a 918 error condition (which implies that the XMPP client will 919 then need to choose another nickname and repeat the process of 920 joining). 922 Example 21: Conflict error for nickname (F26) 924 | 927 | 928 | 929 | 930 | 931 | 933 Alternatively, the gateway might generate a new nickname request on 934 behalf of the XMPP user, thus shielding the XMPP client from handling 935 the conflict error. 937 5.7. Invite Another User to a Room 939 In XMPP there are two methods for inviting another user to a room: 940 direct invitations [XEP-0249] (sent directly from the user's real JID 941 outside the room to the invitee's real JID) and mediated invitations 942 (sent through the room from the user's occupant JID to the invitee's 943 JID). In this document we cover mediated invitations only. 945 For example, if Juliet decides to invite Benvolio to the room, she 946 sends a message stanza with an invite and Benvolio's JID (which could 947 be his real JID or an occupant JID in another room). 949 Example 22: Juliet invites Benvolio to the room (F27) 951 | 954 | 955 | 956 | 957 | 959 The XMPP-to-SIP gateway then sends a SIP REFER request to the 960 conference focus indicating who needs to be invited in the Refer-To 961 header, as per [RFC4579] (sec 5.5) 963 Example 23: SIP mapping of invite (F28) 965 | REFER sip:montague@chat.example.org SIP/2.0 966 | To: 967 | From: "Juliet" ;tag=5534562 968 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 969 | CSeq: 5 REFER 970 | Contact: ;gr=yn0cl4bnw0yr3vym 971 | Accept: message/sipfrag 972 | Refer-To: 973 | Supported: replaces 974 | Content-Length: 0 976 The conference focus then acknowledges the SIP REFER request with a 977 200 OK response (step F29, not shown). 979 The progress of the invitation will be tracked by the received NOTIFY 980 requests as per [RFC3515]. 982 Example 24: Progress notification for invitation (F30) 984 | NOTIFY sip:juliet@example.com SIP/2.0 985 | To: ;tag=5534562 986 | From: ;tag=18747389 987 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 988 | CSeq: 6 NOTIFY 989 | Max-Forwards: 70 990 | Event: refer 991 | Subscription-State: active;expires=60 992 | Contact: ;isfocus 993 | Content-Type: message/sipfrag;version=2.0 994 | Content-Length: ... 996 Note: Implementers might want to be aware that work is underway to 997 modify the way in which REFER requests handle SIP notifications 998 ([I-D.sparks-sipcore-refer-clarifications] and 999 [I-D.sparks-sipcore-refer-explicit-subscription]). 1001 5.8. Exit Room 1003 If Juliet decides to exit the chatroom, her client sends a directed 1004 presence stanza of type "unavailable" to the occupant JID she is 1005 currently using in the room (here ). 1007 Example 25: Juliet exits room (F31) 1009 | 1013 Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the 1014 SIP session by sending a SIP BYE to the conference focus and the 1015 conference focus responds with a SIP 200 OK (steps F32 and F33, not 1016 shown). 1018 Juliet can include a custom exit message in the presence stanza of 1019 type "unavailable", in which case it is broadcast to other 1020 participants using the methods described above. 1022 Example 26: Juliet exits the chatroom (F31) 1024 | 1027 | O, look! methinks I see my cousin's ghost 1028 | 1030 6. MSRP Multi-party Messaging Session to XMPP MUC 1032 This section describes how to map a Multi-party Instant Message (IM) 1033 MSRP session to an XMPP Multi-User Chat (MUC) session. As before, 1034 the following diagram outlines the overall protocol flow of a sample 1035 session, which includes some optional exchanges (such as sending 1036 messages, changing nickname, and inviting another user). 1038 SIP SIP MSRP XMPP 1039 User Proxy Switch Server 1040 | + S2X GW + M2X GW + MUC & GWs 1041 | | | | 1042 | (F35) SIP | | | 1043 | INVITE | | | 1044 |****************>| | | 1045 | (F36) SIP | | | 1046 | 200 OK | | | 1047 |<****************| | | 1048 | (F37) SIP ACK | | | 1049 |****************>| | | 1050 | (F38) SIP | | | 1051 | SUBSCRIBE | | | 1052 | Event: | | | 1053 | conference | | | 1054 |****************>| | | 1055 | (F39) SIP | | | 1056 | 200 OK | | | 1057 |<****************| | | 1058 | | (F40) XMPP presence: enter room | 1059 | |..................................>| 1060 | | (F41) XMPP presence | 1061 | |<..................................| 1062 | (F42) SIP | | | 1063 | NOTIFY | | | 1064 |<****************| | | 1065 | (F43) SIP | | | 1066 | 200 OK | | | 1067 |****************>| | | 1068 . . . . 1069 . . . . 1070 | (F44) MSRP SEND | | 1071 |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | 1072 | | | (F45) XMPP | 1073 | | | groupchat | 1074 | | | message | 1075 | | |................>| 1076 | | | (F46) XMPP | 1077 | | | groupchat | 1078 | | | message | 1079 | | |<................| 1080 | (F47) MSRP 200 OK | | 1081 |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | 1082 . . . . 1083 . . . . 1084 | (F48) MSRP SEND | | 1085 |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | 1086 | (F49) MSRP 200 OK | | 1087 |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | 1088 | | | (F50) XMPP | 1089 | | | message | 1090 | | |................>| 1091 . . . . 1093 . . . . 1094 | (F51) MSRP NICKNAME | | 1095 |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | 1096 | | | (F52) XMPP | 1097 | | | presence | 1098 | | |................>| 1099 | | | (F53) XMPP | 1100 | | | presence | 1101 | | | error | 1102 | | |<................| 1103 | (F54) MSRP 425 Error | | 1104 |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | 1105 . . . . 1106 . . . . 1107 | (F55) SIP REFER | | | 1108 |****************>| | | 1109 | (F56) SIP | | | 1110 | 200 OK | | | 1111 |<****************| | | 1112 | (F57) SIP | | | 1113 | NOTIFY | | | 1114 |<****************| | | 1115 | | (F58) XMPP message invite | 1116 | |..................................>| 1117 . . . . 1118 . . . . 1119 | (F59) SIP BYE | | | 1120 |****************>| | | 1121 | | (F60) XMPP presence unavailable | 1122 | |..................................>| 1123 | | (F61) XMPP presence unavailable | 1124 | |<..................................| 1125 | (F62) SIP | | | 1126 | 200 OK | | | 1127 |<****************| | | 1128 | | | | 1130 If the XMPP presence stanza is received before the SIP SUBSCRIBE 1131 dialog is established for the "conference" event, then the server 1132 SHOULD cache the participant list until the subscription is 1133 established and delivered in a SIP NOTIFY request. 1135 6.1. Enter Room 1137 When the SIP user ("Romeo") wants to join a groupchat room 1138 ("capulet"), he first has to start the SIP session by sending out a 1139 SIP INVITE request containing an offered session description that 1140 includes an MSRP media line accompanied by a mandatory "path" and 1141 "chatroom" attributes. Here we assume that Romeo's user agent has 1142 been configured to be aware of an MSRP switch (chat.example.org) it 1143 can use. The MSRP media line is also accompanied by an "accept- 1144 types" attribute specifing support for a Message/CPIM top level 1145 wrapper for the MSRP message. 1147 Example 27: SIP user starts session (F35) 1149 | INVITE sip:capulet@rooms.example.com SIP/2.0 1150 | From: "Romeo" 1151 | To: 1152 | Contact: ;gr=dr4hcr0st3lup4c 1153 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1154 | CSeq: 1 INVITE 1155 | Content-Type: application/sdp 1156 | Content-Length: ... 1157 | 1158 | c=IN IP4 s2x.example.org 1159 | m=message 7313 TCP/MSRP * 1160 | a=accept-types:message/cpim text/plain text/html 1161 | a=accept-wrapped-types:text/plain text/html 1162 | a=path:msrp://chat.example.org:7313/ansp71weztas;tcp 1163 | a=chatroom:nickname private-messages 1165 Upon receiving the INVITE, the SIP proxy needs to determine the 1166 identity of the domain portion of the Request-URI or To header, which 1167 it does by following the procedures discussed in [RFC7247]. Here we 1168 assume that the SIP proxy has determined that the domain is serviced 1169 by an XMPP server, that it contains or has available to it a SIP-to- 1170 XMPP gateway or connection manager (which enables it to speak 1171 natively to XMPP servers), and that it hands off the message to the 1172 gateway. 1174 Implementations MAY wait until the nickname is set with an MSRP 1175 NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary 1176 nickname (such as the SIP From header display name) and use it to 1177 join the room. Here we assume the latter. 1179 Example 28: SIP-to-XMPP gateway acks session (F36) 1181 | SIP/2.0 200 OK 1182 | From: "Romeo" 1183 | To: 1184 | Contact: ;isfocus 1185 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1186 | CSeq: 1 INVITE 1187 | Content-Type: application/sdp 1188 | 1189 | m=message 8763 TCP/MSRP * 1190 | a=accept-types:message/cpim text/plain text/html 1191 | a=accept-wrapped-types:text/plain text/html 1192 | a=path:msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp 1193 | a=chatroom:nickname private-messages 1195 The SIP/MSRP user agent subscribes to a conference event package at 1196 the destination groupchat service. 1198 Example 29: Gateway subscribes to the conference (F38) 1200 | SUBSCRIBE sip:capulet@rooms.example.com SIP/2.0 1201 | To: 1202 | From: "Romeo" 1203 | Contact: ;gr=dr4hcr0st3lup4c 1204 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1205 | CSeq: 2 SUBSCRIBE 1206 | Event: conference 1207 | Expires: 600 1208 | Accept: application/conference-info+xml 1209 | Allow-Events: conference 1210 | Content-Length: 0 1212 After the conference subscription request is acknowledged, the SIP- 1213 to-XMPP gateway sends presence from Romeo to the MUC chatroom. 1215 Example 30: Romeo enters XMPP chatroom (F40) 1217 | 1219 | 1220 | 1222 6.2. Presence Broadcast 1224 If the MUC service is able to add the SIP/MSRP user to the room, it 1225 sends presence from all the existing occupants' room JIDs to the new 1226 occupant's full JID, including extended presence information about 1227 roles in an element. 1229 Example 31: XMPP service sends presence from existing occupants to 1230 new occupant (F41) 1232 | 1234 | 1235 | 1236 | 1237 | 1238 | 1239 | 1240 | 1242 | 1243 | 1244 | 1245 | 1246 | 1247 | 1249 | 1250 | 1251 | 1252 | 1254 Upon receiving these presence stanzas, if the conference focus has 1255 already completed the subscription to the Conference Event package 1256 [RFC4575], the XMPP-to-SIP gateway translates them into a SIP NOTIFY 1257 request containing the participant list (represented in the 1258 conference-info format specified in [RFC4575]). 1260 Example 32: SIP mapping of XMPP participant presence stanzas (F42) 1262 | NOTIFY sip:romeo@example.org SIP/2.0 1263 | To: ;tag=43524545 1264 | From: ;tag=a3343df32 1265 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1266 | CSeq: 3 NOTIFY 1267 | Event: conference 1268 | Subscription-State: active;expires=3600 1269 | Content-Type: application/conference-info+xml 1270 | Content-Length: ... 1271 | 1272 | 1274 | 1275 | Today in Verona 1276 | 1277 | 1278 | tel:+18882934234 1279 | sip:capulet@rooms.example.com 1280 | 1281 | 1282 | 1283 | 1284 | 1286 | JuliC 1287 | 1288 | participant 1289 | 1290 | 1292 | connected 1293 | 1294 | message 1295 | 1296 | 1297 | 1298 | 1300 | Ben 1301 | 1302 | participant 1303 | 1304 | 1306 | connected 1307 | 1308 | message 1309 | 1310 | 1311 | 1312 | 1314 Because the "room roster" is communicated in XMPP by means of 1315 multiple presence stanzas (one for each participant) whereas the 1316 participant list is communicated in SIP by means of a single 1317 conference-info document, the SIP-to-XMPP gateway will need to keep 1318 track of the user's SIP URI and the mapping of that URI into an XMPP 1319 address; then, based on that mapping, it will need to determine when 1320 it has received a complete room roster from the MUC room, i.e., when 1321 it has received the in-room presence of the SIP user (which according 1322 to [XEP-0045] is the last presence stanza received in the initial 1323 batch sent after joining). Once that happens, the SIP-to-XMPP 1324 gateway can construct the conference-info document containing the 1325 complete participant list and send that to the SIP user. 1327 6.3. Exchange Messages 1329 Once the user has joined the chat room, the user can exchange an 1330 unbounded number of messages, both public and private. 1332 The mapping of MSRP syntax elements to XMPP syntax elements MUST be 1333 as shown in the following table. (Mappings for elements not 1334 mentioned are undefined.) 1336 Table 5: Message syntax mapping from MSRP Message to XMPP 1338 +-----------------------------+-----------------------------+ 1339 | CPIM Header |XMPP Element or Attribute | 1340 +-----------------------------+-----------------------------+ 1341 | To | to | 1342 | From | from | 1343 | body of the SEND request | | 1344 +-----------------------------+-----------------------------+ 1346 6.3.1. Send a Message to All Occupants 1348 When Romeo wants to send a message to all other occupants in the 1349 room, he sends an MSRP SEND request to 1350 ( in our example). 1352 The following examples show an exchange of a public message. 1354 Example 33: Romeo sends a message to the chat room (F44) 1356 | MSRP a786hjs2 SEND 1357 | To-Path: msrp://room.example.com:7313/ansp71weztas;tcp 1358 | From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp 1359 | Message-ID: 87652492 1360 | Byte-Range: 1-*/* 1361 | Content-Type: message/cpim 1362 | 1363 | To: 1364 | From: "Romeo" ;gr=dr4hcr0st3lup4c 1365 | DateTime: 2008-10-15T15:02:31-03:00 1366 | Content-Type: text/plain 1367 | 1368 | Romeo is here! 1369 | -------a786hjs2$ 1370 Upon receiving the SEND request, if the request either contains a 1371 Failure-Report header field value of "yes" or does not contain a 1372 Failure-Report header at all, the SIP-to-XMPP gateway immediately 1373 translates it into an XMPP message stanza and then generate and send 1374 an MSRP response. 1376 Example 34: XMPP mapping of message (F45) 1378 | 1382 | Romeo is here! 1383 | 1385 Example 35: MSRP response to public message (F47) 1387 | MSRP d93kswow 200 OK 1388 | To-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp 1389 | From-Path: msrp://chat.example.org:7313/ansp71weztas;tcp 1390 | -------d93kswow$ 1392 Note well that the XMPP MUC room will reflect the sender's message 1393 back to all users, including the sender. The MSRP-to-XMPP gateway 1394 SHOULD wait until receiving this reflected message before sending an 1395 MSRP 200 OK reply to the original sender. 1397 6.3.2. Send a Private Message 1399 Romeo can send a "private message" to a selected occupant via the 1400 chat room service by sending a message to the occupant's room 1401 nickname. 1403 The following examples show an exchange of a private message. 1405 Example 36: Romeo sends a private message (F48) 1407 | MSRP a786hjs2 SEND 1408 | To-Path: msrp://rooms.example.com:7313/ansp71weztas;tcp 1409 | From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp 1410 | Message-ID: 87652492 1411 | Byte-Range: 1-*/* 1412 | Content-Type: message/cpim 1413 | 1414 | To: ;gr=JuliC 1415 | From: "Romeo" ;gr=dr4hcr0st3lup4c 1416 | DateTime: 2008-10-15T15:02:31-03:00 1417 | Content-Type: text/plain 1418 | 1419 | I am here!!! 1420 | -------a786hjs2$ 1422 The MSRP switch is responsible for transforming the "From" address 1423 into an in-room address (not shown). 1425 Once the MSRP switch sends that message to the gateway, the gateway 1426 is responsible for translating it into XMPP syntax. 1428 Example 37: XMPP mapping of private message (F50) 1430 | 1434 | I am here!!! 1435 | 1437 6.4. Change Nickname 1439 If Romeo decides to change his nickname within the room, he sends a 1440 new MSRP NICKNAME request. In fact modification of the nickname in 1441 MSRP is not different from the initial reservation and usage of a 1442 nickname. 1444 Example 38: MSRP user changes nickname (F51) 1446 | MSRP a786hjs2 NICKNAME 1447 | To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp 1448 | From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp 1449 | Use-Nickname: "montecchi" 1450 | -------a786hjs2 1451 Upon receiving such a message, the MSRP-to-XMPP gateway translates it 1452 into an XMPP presence stanza. 1454 Example 39: XMPP mapping of nickname change (F52) 1456 | 1459 The XMPP server will analyze the nickname allocation and determine if 1460 the requested nickname is available. In case the nickname is not 1461 available or not usable, the server will generate a presence stanza 1462 of type "error" specifying a error condition. 1464 Example 40: XMPP conflict error for nickname (F53) 1466 | 1469 | 1470 | 1471 | 1472 | 1473 | 1475 Upon receiving this stanza, the XMPP-to-MSRP gateway will reply to 1476 the NICKNAME request with code 425 1478 Example 41: Gateway translates XMPP nickname conflict to MSRP error 1479 code (F54) 1481 | MSRP a786hjs2 425 Nickname usage failed 1482 | To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp 1483 | From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp 1484 | -------a786hjs2 1486 6.5. Invite Another User to a Room 1488 If a SIP user wants to invite another user to join the conference he 1489 will send a REFER request indicating who needs to be invited in the 1490 Refer-To header, as per Section 5.5 of [RFC4579]. 1492 Example 42: SIP user invites another user (F55) 1494 | REFER sip:capulet@rooms.example.com SIP/2.0 1495 | To: 1496 | From: "Romeo" ;tag=5534562 1497 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1498 | CSeq: 4 NOTIFY 1499 | Contact: ;gr=dr4hcr0st3lup4c 1500 | Accept: message/sipfrag 1501 | Refer-To: 1502 | Supported: replaces 1503 | Content-Length: 0 1505 The SIP-to-XMPP gateway then acknowledges the SIP REFER request with 1506 a 200 OK response (step F56). 1508 The gateway will then send a NOTIFY request as per [RFC3515] 1509 indicating that the invitation is in progress. Since there is no way 1510 to know the progress of the invitation until the user has joined, 1511 implementations are advised to terminate the REFER dialog 1512 subscription upon receiving the first NOTIFY, with a status code of 1513 100 Trying. 1515 Example 43: Progress notification for invitation (F56) 1517 | NOTIFY sip:romeo@example.org SIP/2.0 1518 | To: ;tag=5534562 1519 | From: ;tag=18747389 1520 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1521 | CSeq: 4 NOTIFY 1522 | Event: refer 1523 | Subscription-State: terminated;reason=noresource 1524 | Contact: ;isfocus 1525 | Content-Type: message/sipfrag;version=2.0 1526 | Content-Length: ... 1527 | 1528 | SIP/2.0 100 Trying 1530 6.6. Exit Room 1532 If Romeo decides to exit the chat room, his client sends a SIP BYE to 1533 the chat room. 1535 Example 44: Romeo terminates session (F59) 1537 | BYE sip:capulet@rooms.example.com SIP/2.0 1538 | Max-Forwards: 70 1539 | From: "Romeo" ;tag=786 1540 | To: ;tag=534 1541 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1542 | CSeq: 5 BYE 1543 | Content-Length: 0 1545 Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it 1546 into a presence stanza of type "unavailable" (F60) and sends it to 1547 the XMPP MUC room service. Then the SIP-to-XMPP gateway responds 1548 with a 200 OK to the MSRP user (F62). 1550 Example 45: Romeo exits chatroom (F60) 1552 | 1556 7. Handling of Nicknames and Display Names 1558 Fundamental rules for mapping addresses between XMPP and SIP are 1559 provided in [RFC7247]. However, chatrooms include a more 1560 specialized, unique identifier for each participant in a room, called 1561 a nickname. Implementations SHOULD apply the rules for preparation 1562 and comparison of nicknames specified in [I-D.ietf-precis-nickname]. 1564 In addition to nicknames, some groupchat implementations also include 1565 display names (which might or might not be different from users' 1566 nicknames). A display name need not be unique within the context of 1567 a room but instead simply provides a user-friendly name for a 1568 participant. 1570 In the SIP conference event package, the nickname is the value of the 1571 XCON 'nickname' attribute of the element [RFC6501] and the 1572 display name is the XML character data of the conference-info 1573 element [RFC4575]. In XMPP, the nickname is the 1574 value of the resourcepart of the occupant JID [XEP-0045] and the 1575 display name is the XML character data of the element 1576 [XEP-0172]. 1578 In practice, the element is treated as canonical in 1579 SIP implementations, and the element is rarely used in XMPP 1580 implementations. Therefore, for display purposes SIP implementations 1581 ought to use the element if the XCON 'nickname' 1582 attribute is not present, and XMPP implementations ought to use the 1583 resourcepart of the occupant JID if the element is not 1584 present. 1586 If there is a conflict between the SIP nickname and the XMPP 1587 nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for 1588 adjusting the nickname to avoid the conflict and for informing the 1589 SIP or XMPP client of the unique nickname used to join the chatroom. 1591 8. Message Size 1593 It is possible for MSRP messages to exceed the size allowed by an 1594 XMPP service on the far end of an MSRP-to-XMPP gateway; see 1595 [I-D.ietf-stox-chat] for a discussion of this issue. 1597 9. IANA Considerations 1599 This document requests no actions of the IANA. 1601 10. Security Considerations 1603 The security considerations of [RFC3261], [RFC4975], [RFC6120], 1604 [RFC7247], [I-D.ietf-simple-chat], and [XEP-0045] apply. 1606 This document specifies methods for exchanging groupchat messages 1607 through a gateway that translates between SIP and XMPP. Such a 1608 gateway MUST be compliant with the minimum security requirements of 1609 the protocols for which it translates (i.e., MSRP/SIP and XMPP). The 1610 addition of gateways to the security models of MSRP, SIP, and XMPP 1611 introduces some new risks. In particular, end-to-end security 1612 properties (especially confidentiality and integrity) between user 1613 agents that interface through an MSRP-to-XMPP gateway can be provided 1614 only if common formats are supported; unfortunately, although 1615 [RFC3862] specifies such a format for one-to-one instant messages, 1616 the problem of end-to-end security for multiparty messaging has not 1617 been solved in a standardized way. 1619 Some of the features that are not addressed by the minimal 1620 interoperability baseline defined in this document are relevant to 1621 security, such as the ability to administer rooms, kick and ban 1622 users, and enable room moderation. Users needing to take advantage 1623 of such features cannot do so through a gateway in a standardized 1624 manner and therefore will need to use native clients for the relevant 1625 protocol (MSRP or XMPP). 1627 As mentioned in [I-D.ietf-stox-im], there are several possible 1628 methods for end-to-end encryption of one-to-one instant messages. 1629 Unfortunately, because there is no widely deployed method for end-to- 1630 end encryption of multiparty instant messages, this document cannot 1631 provide a recommendation in this regard. 1633 11. References 1635 11.1. Normative References 1637 [I-D.ietf-precis-nickname] 1638 Saint-Andre, P., "Preparation and Comparison of 1639 Nicknames", draft-ietf-precis-nickname-16 (work in 1640 progress), March 2015. 1642 [I-D.ietf-simple-chat] 1643 Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1644 party Instant Message (IM) Sessions Using the Message 1645 Session Relay Protocol (MSRP)", draft-ietf-simple-chat-18 1646 (work in progress), January 2013. 1648 [I-D.ietf-stox-chat] 1649 Saint-Andre, P. and S. Loreto, "Interworking between the 1650 Session Initiation Protocol (SIP) and the Extensible 1651 Messaging and Presence Protocol (XMPP): One-to-One Text 1652 Chat Sessions", draft-ietf-stox-chat-11 (work in 1653 progress), March 2015. 1655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1656 Requirement Levels", BCP 14, RFC 2119, March 1997. 1658 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1659 A., Peterson, J., Sparks, R., Handley, M., and E. 1660 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1661 June 2002. 1663 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1664 (SIP) Call Control - Conferencing for User Agents", RFC 1665 4579, August 2006. 1667 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1668 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1670 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1671 Agent URIs (GRUUs) in the Session Initiation Protocol 1672 (SIP)", RFC 5627, October 2009. 1674 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1675 Protocol (XMPP): Core", RFC 6120, March 2011. 1677 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1678 Protocol (XMPP): Instant Messaging and Presence", RFC 1679 6121, March 2011. 1681 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, 1682 "Interworking between the Session Initiation Protocol 1683 (SIP) and the Extensible Messaging and Presence Protocol 1684 (XMPP): Architecture, Addresses, and Error Handling", RFC 1685 7247, May 2014. 1687 [XEP-0045] 1688 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, July 1689 2008. 1691 11.2. Informative References 1693 [I-D.ietf-stox-im] 1694 Saint-Andre, P., Houri, A., and J. Hildebrand, 1695 "Interworking between the Session Initiation Protocol 1696 (SIP) and the Extensible Messaging and Presence Protocol 1697 (XMPP): Instant Messaging", draft-ietf-stox-im-13 (work in 1698 progress), March 2015. 1700 [I-D.sparks-sipcore-refer-clarifications] 1701 Sparks, R. and A. Roach, "Clarifications for the use of 1702 REFER with RFC6665", draft-sparks-sipcore-refer- 1703 clarifications-05 (work in progress), October 2014. 1705 [I-D.sparks-sipcore-refer-explicit-subscription] 1706 Sparks, R., "Explicit Subscriptions for the REFER Method", 1707 draft-sparks-sipcore-refer-explicit-subscription-02 (work 1708 in progress), October 2014. 1710 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1711 Method", RFC 3515, April 2003. 1713 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1714 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1716 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1717 Session Initiation Protocol (SIP)", RFC 4353, February 1718 2006. 1720 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1721 Description Protocol", RFC 4566, July 2006. 1723 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1724 Initiation Protocol (SIP) Event Package for Conference 1725 State", RFC 4575, August 2006. 1727 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1728 "Conference Information Data Model for Centralized 1729 Conferencing (XCON)", RFC 6501, March 2012. 1731 [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. 1732 Urpalainen, "Conference Event Package Data Format 1733 Extension for Centralized Conferencing (XCON)", RFC 6502, 1734 March 2012. 1736 [XEP-0172] 1737 Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 1738 0172, March 2012. 1740 [XEP-0249] 1741 Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249, 1742 September 2011. 1744 Appendix A. Acknowledgements 1746 Special thanks to Fabio Forno for coauthoring an early version of 1747 this document, and to Ben Campbell for his detailed and insightful 1748 reviews. 1750 Thanks also to Dave Crocker, Philipp Hancke, Olle Johansson, Paul 1751 Kyzivat, and Matt Ryan for their feedback. 1753 Leif Johansson reviewed the document on behalf of the Security 1754 Directorate. 1756 Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling 1757 provided helpful input during IESG review. 1759 The authors gratefully acknowledge the assistance of Markus Isomaki 1760 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 1761 and Alissa Cooper as the sponsoring Area Directors. 1763 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 1764 employing him during his work on earlier versions of this document. 1766 Authors' Addresses 1767 Peter Saint-Andre 1768 &yet 1770 Email: peter@andyet.com 1771 URI: https://andyet.com/ 1773 Saul Ibarra Corretge 1774 AG Projects 1775 Dr. Leijdsstraat 92 1776 Haarlem 2021RK 1777 The Netherlands 1779 Email: saul@ag-projects.com 1781 Salvatore Loreto 1782 Ericsson 1783 Hirsalantie 11 1784 Jorvas 02420 1785 Finland 1787 Email: Salvatore.Loreto@ericsson.com