idnits 2.17.1 draft-ietf-stox-groupchat-03.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 16, 2014) is 3688 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-09 -- 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 17, 2014 AG Projects 6 S. Loreto 7 Ericsson 8 March 16, 2014 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Groupchat 12 draft-ietf-stox-groupchat-03 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 17, 2014. 41 Copyright Notice 43 Copyright (c) 2014 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. XMPP MUC to MSRP Multi-party Messaging Session . . . . . . . 4 62 4.1. Enter Room . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Set Nickname . . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. Conference Subscription . . . . . . . . . . . . . . . . . 8 65 4.4. Presence Broadcast . . . . . . . . . . . . . . . . . . . 9 66 4.5. Exchange Messages . . . . . . . . . . . . . . . . . . . . 13 67 4.5.1. Send a Message to All Occupants . . . . . . . . . . . 13 68 4.5.2. Send a Private Message . . . . . . . . . . . . . . . 15 69 4.6. Change Nickname . . . . . . . . . . . . . . . . . . . . . 16 70 4.7. Invite Another User to a Room . . . . . . . . . . . . . . 17 71 4.8. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 18 72 5. MSRP Multi-party Messaging Session to XMPP MUC . . . . . . . 19 73 5.1. Enter Room (Includes Set Nickname) . . . . . . . . . . . 21 74 5.2. Presence Broadcast . . . . . . . . . . . . . . . . . . . 23 75 5.3. Exchange Messages . . . . . . . . . . . . . . . . . . . . 26 76 5.3.1. Send a Message to All Occupants . . . . . . . . . . . 26 77 5.3.2. Send a Private Message . . . . . . . . . . . . . . . 27 78 5.4. Change Nickname . . . . . . . . . . . . . . . . . . . . . 29 79 5.5. Invite Another User to a Room . . . . . . . . . . . . . . 30 80 5.6. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 31 81 6. Handling of Nicknames and Display Names . . . . . . . . . . . 31 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 86 9.2. Informative References . . . . . . . . . . . . . . . . . 33 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 90 1. Introduction 92 Both the Session Initiation Protocol (SIP) [RFC3261] and the 93 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be 94 used for the purpose of multiparty text chat over the Internet. To 95 ensure interworking between these technologies, it is important to 96 define bidirectional protocol mappings. 98 The architectural assumptions underlying such protocol mappings are 99 provided in [I-D.ietf-stox-core], including mapping of addresses and 100 error conditions. This document specifies mappings for multiparty 101 text chat sessions (often called "groupchat"); specifically, this 102 document defines a mapping between the XMPP Multi-User Chat (MUC) 103 extension [XEP-0045] and SIP-based multiparty chat using Message 104 Session Relay Protocol [RFC4975] as specified in 105 [I-D.ietf-simple-chat]. 107 Both MUC and MSRP contain a large set of features, such as the 108 ability to administer rooms, kick and ban users, reserve a nickname 109 within a room, change room subject, enable room moderation, and 110 destroy the room. This document covers only a basic subset of 111 groupchat features: joining a room, establishing or changing (but not 112 permanently registering) a room nickname, modifying presence 113 information within the room, sending a message to all participants, 114 sending a private message to a single participant, inviting another 115 user to the room, and leaving the room. Future documents might 116 define mappings for additional features beyond this set. 118 2. Intended Audience 120 The documents in this series are intended for use by software 121 developers who have an existing system based on one of these 122 technologies (e.g., SIP), and would like to enable communication from 123 that existing system to systems based on the other technology (e.g., 124 XMPP). We assume that readers are familiar with the core 125 specifications for both SIP [RFC3261] and XMPP [RFC6120], with the 126 base document for this series [I-D.ietf-stox-core], and with the 127 following groupchat-related specifications: 129 o The Message Session Relay Protocol (MSRP) [RFC4975] 131 o Multi-User Chat [XEP-0045] 133 3. Terminology 135 A number of technical terms used here are defined in [RFC3261], 136 [RFC4975], [RFC6120], and [XEP-0045]. The term "JID" is short for 137 "Jabber ID". 139 In flow diagrams, SIP/MSRP traffic is shown using arrows such as 140 "***>" whereas XMPP traffic is shown using arrows such as "...>". 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 [RFC2119]. 147 4. XMPP MUC to MSRP Multi-party Messaging Session 149 This section describes how to map an XMPP MUC session to an MSRP 150 Multi-party Messaging session. The following diagram outlines the 151 overall protocol flow of a sample session, which includes some 152 optional exchanges (such as sending messages, changing nickname, and 153 inviting another user). 155 XMPP User Gateway MSRP Conference 156 | | | 157 |(X1) (XMPP) Enter room | | 158 |.........................>| | 159 | |(X2) (SIP) INVITE | 160 | |*************************>| 161 | |(X3) (SIP) 200 OK | 162 | |<*************************| 163 | |(X4) (SIP) ACK | 164 | |*************************>| 165 | |(X5) (MSRP) NICKNAME | 166 | |*************************>| 167 | |(X6) (MSRP) 200 OK | 168 | |<*************************| 169 | |(X7) (SIP) SUBSCRIBE | 170 | | Event:conference | 171 | |*************************>| 172 | |(X8) (SIP) 200 OK | 173 | |<*************************| 174 | |(X9) (SIP) NOTIFY | 175 | |<*************************| 176 | |(X10) (SIP) 200 OK | 177 | |*************************>| 178 |(X11) (XMPP) Presence | | 179 |<.........................| | 180 |(X12) (XMPP) Subject | | 181 |<.........................| | 182 |(X13) (XMPP) Groupchat message | 183 |.........................>| | 184 | |(X14) (MSRP) SEND | 185 | |*************************>| 186 | |(X15) (MSRP) 200 OK | 187 | |<*************************| 188 |(X16) (XMPP) Groupchat message | 189 |<.........................| | 190 |(X17) (XMPP) Private message | 191 |.........................>| | 192 | |(X18) (MSRP) SEND | 193 | |*************************>| 194 | |(X19) (MSRP) 200 OK | 195 | |<*************************| 196 |(X20) (XMPP) Change nick | | 197 |.........................>| | 198 | |(X21) (MSRP) NICKNAME | 199 | |*************************>| 200 | |(X22) (MSRP) 425 Error | 201 | |<*************************| 202 | | | 203 |(X23) (XMPP) Presence Error 204 |<.........................| | 205 |(X24) (XMPP) Message stanza to invite participant | 206 |.........................>| | 207 | |(X25) (SIP) REFER | 208 | |*************************>| 209 | |(X26) (SIP) 200 OK | 210 | |<*************************| 211 | |(X27) (SIP) NOTIFY | 212 | |<*************************| 213 . . . 214 . . . 215 |(X28) (XMPP) Exit room | | 216 |.........................>| | 217 | |(X29) (SIP) BYE | 218 | |*************************>| 219 | |(X30) (SIP) 200 OK | 220 | |<*************************| 221 |(X31) (XMPP) Presence unavailable 222 |<.........................| | 223 | | | 225 Detailed protocol flows and mappings are provided in the following 226 sections. 228 4.1. Enter Room 230 As defined in the XMPP Multi-User Chat (MUC) specification 231 [XEP-0045], when an XMPP user (say, "juliet@example.com") wants to 232 join a groupchat room (say, "verona@chat.example.org"), she sends a 233 directed stanza [RFC6121] to that chat room. In her 234 request she also specifies the nickname she wants to use within the 235 room (say, "JuliC"); in XMPP this room nickname is the resourcepart 236 of an occupant JID (thus "verona@chat.example.org/JuliC"). The 237 joining client signals its ability to speak the multi-user chat 238 protocol by including in the initial presence stanza an empty 239 element qualified by the 'http://jabber.org/protocol/muc' namespace. 241 Example 1: Juliet enters room (X1) 243 | 245 | 246 | 248 Upon receiving such a presence stanza, the XMPP server needs to 249 determine the identity of the domainpart in the 'to' address, which 250 it does by following the procedures discussed in 251 [I-D.ietf-stox-core]. Here we assume that the XMPP server has 252 determined the domain is serviced by a SIP server, that it contains 253 or has available to it an XMPP-to-SIP gateway or connection manager 254 (which enables it to speak natively to SIP servers), and that it 255 hands off the presence stanza to the XMPP-to-SIP gateway. 257 Because a multi-user chat service accepts the presence stanza shown 258 above as a request to enter a room, the XMPP-to-SIP gateway 259 transforms it into a SIP INVITE request. 261 Example 2: SIP mapping of room join (X2) 263 | INVITE sip:verona@chat.example.org SIP/2.0 264 | To: 265 | From: "Juliet" 266 | Contact: ;gr=balcony 267 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 268 | Content-Type: application/sdp 269 | Content-Length: 182 270 | 271 | c=IN IP4 x2s.example.org 272 | m=message 7654 TCP/MSRP * 273 | a=accept-types:text/cpim 274 | a=accept-wrapped-types:text/plain text/html 275 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 276 | a=chatroom 278 Here the Session Description Protocol offer specifies the MSRP-aware 279 XMPP-to-SIP gateway on the XMPP side as well as other particulars of 280 the session. 282 There is no direct mapping for the MSRP URIs. In fact MSRP URIs 283 identify a session of instant messages at a particular device; 284 they are ephemeral and have no meaning outside the scope of that 285 session. The authority component of the MSRP URI MUST contain the 286 XMPP-to-SIP gateway hostname or numeric IP address and an explicit 287 port number. 289 As specified in [I-D.ietf-stox-core], the mapping of XMPP syntax 290 elements to SIP and [RFC4566] syntax elements is as shown in the 291 following table. 293 Table 1: Message syntax mapping from XMPP to SIP/SDP 295 +-----------------------------+-----------------------------+ 296 | XMPP Element or Attribute | SIP Header or SDP Contents | 297 +-----------------------------+-----------------------------+ 298 | from | From | 299 | | Call-ID | 300 | to (without the /nick) | To | 301 +-----------------------------+-----------------------------+ 303 Here we assume that the MSRP conference server accepts the session 304 establishment. It includes the 'isfocus' and other relevant feature 305 tags in the Contact header field of the response. The MSRP 306 conference server also includes an answer session description that 307 acknowledges the choice of media and contains the extensions 308 specified in [I-D.ietf-simple-chat]. 310 Example 3: Chat room accepts session establishment (X3) 312 | SIP/2.0 200 OK 313 | From: 314 | To: "Juliet" ;tag=786 315 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 316 | Contact: ;isfocus 317 | Content-Type: application/sdp 318 | Content-Length: 214 319 | 320 | c=IN IP4 example.org 321 | m=message 12763 TCP/MSRP * 322 | a=chatroom:nickname private-messages 323 | a=accept-types:message/cpim 324 | a=accept-wrapped-types:text/plain text/html 325 | a=path:msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 327 Upon receiving such a response, the SIMPLE server or associated SIP- 328 to-XMPP gateway sends a SIP ACK to the MSRP conference server on 329 behalf of the joining user. 331 Example 4: Gateway sends ACK to MSRP conference server (X4) 333 | ACK sip:verona@chat.example.org SIP/2.0 334 | To: ;tag=087js 335 | From: "Juliet" ;tag=786 336 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 338 4.2. Set Nickname 340 If the chat room server accepted the session, the SIMPLE server or 341 associated SIP-to-XMPP gateway MUST set up the nickname as received 342 in the presence stanza (i.e., the resourcepart of the 'to' address, 343 such "JuliC" in "verona@chat.example.org/JuliC"). The nickname is 344 set up using the extension specified in [I-D.ietf-simple-chat]. 346 Example 5: Gateway sets up nickname (X5) 348 | MSRP a786hjs2 NICKNAME 349 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 350 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 351 | Use-Nickname: "JuliC" 352 | -------a786hjs2 354 The MSRP conference server analyzes the existing allocation of 355 nicknames, accepts the nickname proposal, and answers with a 200 356 response. 358 Example 6: MSRP conference accepts nickname proposal (X6) 360 | MSRP a786hjs2 200 OK 361 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 362 | From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 363 | -------a786hjs2 365 This section assumes that the nickname request is successful. The 366 error flow resulting from a nickname conflict is described under 367 Section 4.6. 369 4.3. Conference Subscription 371 If the nickname request is successful, the XMPP-to-SIP gateway then 372 formally subscribes to the MSRP conference on behalf of the XMPP 373 user. 375 Example 7: Gateway subscribes to the MSRP conference (X7) 377 | SUBSCRIBE sip:verona@chat.example.org SIP/2.0 378 | To: 379 | From: "Juliet" 380 | Contact: ;gr=balcony 381 | Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417 382 | Event: conference 383 | Expires: 600 384 | Accept: application/conference-info+xml 385 | Allow-Events: conference 386 | Content-Length: 0 388 The conference server will accept or reject the request based on 389 local policy. 391 Example 8: MSRP conference server accepts subscription request (X8) 393 | SIP/2.0 200 OK 394 | To: 395 | From: "Juliet" 396 | Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417 397 | Contact: ;isfocus 398 | Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, 399 | CANCEL, UPDATE, MESSAGE, REFER 400 | Expires: 600 401 | Content-Length: 0 403 4.4. Presence Broadcast 405 If the MSRP conference service accepts the request to enter a room, 406 the XMPP user expects to receive back presence information from all 407 the existing occupants of the room. So the XMPP-to-SIP gateway MUST 408 subscribe to the Conference Event package [RFC4575] on the MSRP 409 conference server. When the subscription is completed the MSRP 410 conference server sends to the XMPP-to-SIP gateway a NOTIFY 411 containing the presence information of all the existing occupants, 412 represented using the [RFC4575] format. 414 Example 9: MSRP conference sends presence information (X9) 416 | NOTIFY sip:verona@chat.example.org SIP/2.0 417 | To: "Juliet" ;gr=balcony 418 | From: ;tag=a3343df32 419 | Call-ID: 6F563BA1-8177-4CED-8710-78D4D9593B08 420 | Event: conference 421 | Subscription-State: active;expires=3600 422 | Content-Type: application/conference-info+xml 423 | Content-Length: ... 424 | 425 | 427 | 428 | Today in Verona 429 | 430 | 431 | tel:+18882934234 432 | 433 | 434 | 435 | 436 | 438 | Romeo 439 | 440 | participant 441 | 442 | 443 | 444 | xmpp:romeo@example.com/orchard 445 | 446 | 447 | 449 | connected 450 | 451 | 2013-12-12T10:01:03.691128+01:00 452 | 453 | 454 | message 455 | 456 | 457 | 458 | 460 | Ben 461 | 462 | participant 463 | 464 | 466 | connected 467 | 468 | message 469 | 470 | 471 | 472 | 474 | JuliC 475 | 476 | participant 477 | 478 | 480 | connected 481 | 482 | message 483 | 484 | 485 | 486 | 487 | 489 The following table shows the syntax mapping from the RFC 4575 490 payload to the XMPP participant list. (Mappings for elements not 491 mentioned are undefined.) 493 Table 2: Participant list mapping 495 +--------------------------------+-----------------------------+ 496 | RFC 4575 Element | XMPP Element or Attribute | 497 +--------------------------------+-----------------------------+ 498 | conference-info entity | room JID | 499 | conference subject | room subject | 500 | user entity | occupant JID | 501 | user display-text / nickname | participant nickname | 502 | endpoint entity | occupant JID | 503 | user associated-aors | user full JID (if avail.) | 504 +--------------------------------+-----------------------------+ 506 Upon receiving such a response, the SIP-to-XMPP gateway MUST send a 507 200 OK to the MSRP conference server and translate the participant 508 list into a series of XMPP presence stanzas. 510 Example 10: XMPP mapping of chatroom presence (F11) 512 | 514 | 515 | 516 | 517 | 519 | 521 | 522 | 523 | 524 | 526 | 528 | 529 | 530 | 531 | 532 | 534 If the NOTIFY included a subject, the gateway converts that into a 535 separate XMPP message. 537 Example 11: XMPP mapping of chatroom subject (F12) 539 | 542 | Today in Verona 543 | 545 The mapping of SIP and [RFC4575] payload syntax elements to XMPP 546 syntax elements is as shown in the following table. (Mappings for 547 elements not mentioned are undefined.) 548 Table 3: Message syntax mapping from SIP to XMPP 550 +---------------------------------+-----------------------------+ 551 | SIP Header or RFC4575 Contents | XMPP Element or Attribute | 552 +---------------------------------+-----------------------------+ 553 | | from | 554 | Call-ID | thread | 555 | To + / | to | 556 | roles | role | 557 | 'none' | affiliation | 558 +---------------------------------+-----------------------------+ 560 4.5. Exchange Messages 562 Once the user has joined the chatroom, the user can exchange an 563 unbounded number of messages, both public and private. 565 The mapping of XMPP syntax elements to MSRP syntax elements is as 566 shown in the following table. (Mappings for elements not mentioned 567 are undefined.) 569 Table 4: Message syntax mapping from XMPP Message to MSRP 571 +-----------------------------+-----------------------------+ 572 | XMPP Element or Attribute | CPIM Header | 573 +-----------------------------+-----------------------------+ 574 | to | To | 575 | from | From | 576 | | body of the SEND request | 577 +-----------------------------+-----------------------------+ 579 4.5.1. Send a Message to All Occupants 581 When Juliet wants to sends a message to all other occupants in the 582 room, she sends a message of type "groupchat" to the 583 itself (in our example, ). 585 The following examples show an exchange of a public message. 587 Example 12: Juliet sends message to all occupants (X13) 589 | 593 | Who knows where Romeo is? 594 | 595 Upon receiving such a message, the XMPP-to-SIP gateway MUST translate 596 it into an MSRP SEND message. 598 Example 13: Gateway maps XMPP message to MSRP (X14) 600 | MSRP a786hjs2 SEND 601 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 602 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 603 | Message-ID: 87652491 604 | Byte-Range: 1-*/* 605 | Content-Type: message/cpim 606 | 607 | To: 608 | From: "Juliet" 609 | DateTime: 2008-10-15T15:02:31-03:00 610 | Content-Type: text/plain 611 | 612 | Who knows where Romeo is? 613 | -------a786hjs2$ 615 Upon receiving the SEND request, if the request either contains a 616 Failure-Report header field value of "yes" or does not contain a 617 Failure-Report header at all, the MSRP conference server MUST 618 immediately generate and send a response. 620 Example 14: MSRP conference returns 200 OK (X15) 622 | MSRP d93kswow 200 OK 623 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 624 | From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 625 | -------d93kswow$ 627 Since an XMPP MUC room could be moderated and an XMPP user cannot be 628 sure whether her message has been accepted or not without receiving 629 it back from the server, [XEP-0045] states that the sender needs to 630 receive the same message it has generated. So in this scenario the 631 XMPP-to-SIP gateway has to reflect the message back to the sender. 632 This prodedure only applies to XMPP endpoints. 634 Example 15: Gateway reflects message to XMPP user (X16) 636 | 640 | Who knows where Romeo is? 641 | 643 4.5.2. Send a Private Message 645 Since each occupant has a unique JID, Juliet can send a "private 646 message" to a selected occupant through the service by sending a 647 message to the user's occupant JID. The XMPP message type SHOULD be 648 "chat" and MUST NOT be "groupchat", but MAY be left unspecified. 650 If the XMPP-to-SIP gateway has support for private messaging it MUST 651 advertise that fact by adding a "private-messages" value to the 652 a=chatroom SDP attribute it sends to the MSRP conference server, as 653 specified in [I-D.ietf-simple-chat]. 655 | a=chatroom:nickname private-messages 657 The following examples show an exchange of a private message. 659 Example 16: Juliet sends private message (X17) 661 | 665 | O Romeo, Romeo! wherefore art thou Romeo? 666 | 668 Upon receiving such a message, the XMPP-to-SIP gateway MUST translate 669 it into an MSRP SEND message. 671 Example 17: Gateway maps private message from XMPP to MSRP (X18) 673 | MSRP a786hjs2 SEND 674 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 675 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 676 | Message-ID: 87652491 677 | Byte-Range: 1-*/* 678 | Content-Type: message/cpim 679 | 680 | To: ;gr=Romeo 681 | From: ;gr=balcony 682 | DateTime: 2008-10-15T15:02:31-03:00 683 | Content-Type: text/plain 684 | 685 | O Romeo, Romeo! wherefore art thou Romeo? 686 | -------a786hjs2$ 688 After acknowledging the message by sending a SIP 200 OK (step X19), 689 the MSRP conference server is responsible for sending the message to 690 the intended recipient (not shown in the protocol flow). When doing 691 so, it MUST modify the "From" header to the sender's address within 692 the chatroom. 694 Example 18: MSRP conference sends private message to SIP user 696 | MSRP a786hjs2 SEND 697 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 698 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 699 | Message-ID: 87652491 700 | Byte-Range: 1-*/* 701 | Content-Type: message/cpim 702 | 703 | To: 704 | From: ;gr=JuliC 705 | DateTime: 2008-10-15T15:02:31-03:00 706 | Content-Type: text/plain 707 | 708 | O Romeo, Romeo! wherefore art thou Romeo? 709 | -------a786hjs2$ 711 4.6. Change Nickname 713 The XMPP user might want to change her nickname. She can do so by 714 sending an updated presence stanza to the room, containing a new 715 nickname. 717 Example 19: Juliet changes her nickname (X20) 719 | 722 So far we have assumed that the requested nickname did not conflict 723 with any existing nicknames. The following text describes the 724 handling of a nickname conflict. 726 The MSRP conference server analyzes the existing allocation of 727 nicknames, and detects that the nickname proposal is already provided 728 to another participant. In this case the MSRP conference server 729 answers with a 425 response. 731 Example 20: MSRP conference does not accept nickname proposal (X22) 733 | MSRP a786hjs2 425 Nickname usage failed 734 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 735 | From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 736 | -------a786hjs2 737 Upon receiving such a response, the SIP-to-XMPP gateway SHOULD 738 translate it into an XMPP presence stanza of type "error" specifying 739 a error condition (which implies that the XMPP client 740 will then need to choose another nickname and repeat the process of 741 joining). 743 Example 21: Conflict error for nickname (X23) 745 | 748 | 749 | 750 | 751 | 752 | 754 Alternatively, the gateway might generate a new nickname request on 755 behalf of the XMPP user, thus shielding the XMPP client from handling 756 the conflict error. 758 4.7. Invite Another User to a Room 760 In XMPP there are two methods for inviting another user to a room: 761 direct invitations [XEP-0249] (sent directly from the user's real JID 762 outside the room to the invitee's real JID) and mediated invitations 763 (sent through the room from the user's occupant JID to the invitee's 764 JID). In this document we cover mediated invitations only. 766 For example, if Juliet decides to invite Benvolio to the room, she 767 sends a message stanza with an invite and Benvolio's JID (which could 768 be his real JID or an occupant JID in another room). 770 Example 22: Juliet invites Benvolio to the room (X24) 772 | 775 | 776 | 777 | 778 | 780 The SIP-to-XMPP gateway then sends a SIP REFER request to the MSRP 781 conference server indicating who needs to be invited in the Refer-To 782 header, as per [RFC4579] (sec 5.5) 783 Example 23: SIP mapping of invite (X25) 785 | REFER sip:verona@chat.example.com SIP/2.0 786 | To: 787 | From: "Juliet" ;tag=5534562 788 | Call-ID: 7FFCD8F7-EEB6-4506-A566-80D3CFC4C6E6 789 | Contact: ;gr=balcony 790 | Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 791 | Accept: message/sipfrag 792 | Refer-To: 793 | Supported: replaces 794 | Content-Length: 0 796 The MSRP conference server then acknowledges the SIP REFER request 797 with a 200 OK response (step X25). 799 The progress of the invitation will be tracked by the received NOTIFY 800 requests as per [RFC3515]. 802 Example 24: Progress notification for invitation (X27) 804 | NOTIFY sip:juliet@example.com SIP/2.0 805 | To: ;tag=5534562 806 | From: ;tag=18747389 807 | Call-ID: 7FFCD8F7-EEB6-4506-A566-80D3CFC4C6E6 808 | Max-Forwards: 70 809 | Event: refer 810 | Subscription-State: active;expires=60 811 | Contact: ;isfocus 812 | Content-Type: message/sipfrag;version=2.0 813 | Content-Length: ... 815 4.8. Exit Room 817 If Juliet decides to exit the chatroom, her client sends a directed 818 presence stanza of type "unavailable" to the occupant JID she is 819 currently using in the room (here ). 821 Example 25: Juliet exits room (X28) 823 | 827 Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the 828 SIP session by sending a SIP BYE to the MSRP conference server and 829 the MSRP conference server responds with a 200 OK (steps X29 and 830 X30). 832 Juliet MAY include a custom exit message in the presence stanza of 833 type "unavailable", in which case it SHOULD be broadcasted to other 834 participants using the methods described above. 836 Example 26: Juliet exits the chatroom (F31) 838 | 841 | Time to go! 842 | 844 5. MSRP Multi-party Messaging Session to XMPP MUC 846 This section describes how to map a Multi-party Instant Message (IM) 847 MSRP session to an XMPP Multi-User Chat (MUC) session. As before, 848 the following diagram outlines the overall protocol flow of a sample 849 session, which includes some optional exchanges (such as sending 850 messages, changing nickname, and inviting another user). 852 SIP User Gateway XMPP MUC 853 | | | 854 |(S1)(SIP) INVITE | | 855 |************************>| | 856 |(S2) (SIP) 200 OK | | 857 |<************************| | 858 |(S3) (SIP) ACK | | 859 |************************>| | 860 |(S4) (MSRP) NICKNAME | | 861 |************************>| | 862 | |(S5)(XMPP) Enter room | 863 | |..........................>| 864 |(S6) (MSRP) 200 OK | | 865 |<************************| | 866 | |(S7)(XMPP) (XMPP) Presence | 867 | |<..........................| 868 |(S8)(SIP) SUBSCRIBE | | 869 | Event:conference | | 870 |************************>| | 871 |(S9) (SIP) 200 OK | | 872 |<************************| | 873 |(S10) (SIP) NOTIFY | | 874 |<************************| | 875 |(S11) (SIP) 200 OK | | 876 |************************>| | 877 | |(S12)(XMPP) (XMPP) Subject | 878 | |<..........................| 879 |(S13)(MSRP) SEND | | 880 |************************>| | 881 | |(S14)(XMPP) Chat message | 882 |(S15)(MSRP) 200 OK |..........................>| 883 |<........................|(S16)(XMPP) Chat message | 884 | |<..........................| 885 |(S17)(MSRP) SEND | | 886 |<************************| | 887 |(S18)(MSRP) 200 OK | | 888 |************************>| | 889 |(S19)(MSRP) SEND | | 890 |************************>| | 891 | |(S20)(XMPP) Private message| 892 | |..........................>| 893 |(S21)(MSRP) 200 OK | | 894 |<************************| | 895 |(S22)(MSRP) NICKNAME | | 896 |************************>| | 897 | |(S23)(XMPP) Presence | 898 | |..........................>| 899 | |(S24)(XMPP) Presence Error | 900 | |<..........................| 901 |(S25)(MSRP) 425 Error | | 902 |<************************| | 903 |(S26)(SIP) REFER | | 904 |************************>| | 905 |(S27)(SIP) 200 OK | | 906 |<************************| | 907 |(S28)(SIP) NOTIFY | | 908 |<************************| | 909 | |(S29)(XMPP) Message stanza | 910 | | to invite participant | 911 | |..........................>| 912 . . . 913 . . . 914 |(S30)(SIP) BYE | | 915 |************************>| | 916 | |(S31)(XMPP) Exiting a room | 917 | |..........................>| 918 |(S32)(SIP) 200 OK | | 919 |<************************| | 920 | | | 922 If the XMPP presence stanza is received before the SIP SUBSCRIBE 923 dialog is established for the "conference" event, then the server 924 SHOULD cache the participant list until the subscription is 925 established and delivered in a SIP NOTIFY request. 927 5.1. Enter Room (Includes Set Nickname) 929 When the SIP user ("Romeo") wants to join a groupchat room 930 ("Verona"), he first has to start the SIP session by sending out a 931 SIP INVITE request containing an offered session description that 932 includes an MSRP media line accompanied by a mandatory "path" and 933 "chatroom" attributes. The MSRP media line is also accompanied by an 934 "accept-types" attribute specifing support for a Message/CPIM top 935 level wrapper for the MSRP message. 937 Example 27: SIP user starts session (S1) 939 | INVITE sip:verona@chat.example.org SIP/2.0 940 | To: 941 | From: "Romeo" 942 | Contact: ;gr=orchard 943 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 944 | Content-Type: application/sdp 945 | Content-Length: 163 946 | 947 | c=IN IP4 s2x.example.net 948 | m=message 7313 TCP/MSRP * 949 | a=accept-types:message/cpim text/plain text/html 950 | a=accept-wrapped-types:text/plain text/html 951 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 952 | a=chatroom 954 Upon receiving the INVITE, the SIP server needs to determine the 955 identity of the domain portion of the Request-URI or To header, which 956 it does by following the procedures discussed in 957 [I-D.ietf-stox-core]. Here we assume that the SIP server has 958 determined that the domain is serviced by an XMPP server, that it 959 contains or has available to it a SIP-to-XMPP gateway or connection 960 manager (which enables it to speak natively to XMPP servers), and 961 that it hands off the message to the gateway. 963 Implementations MAY wait until the nickname is set with an MSRP 964 NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary 965 nickname (such as the SIP From header display name) and use it to 966 join the room. 968 Example 28: SIP user acks session (S3) 970 | SIP/2.0 200 OK 971 | To: 972 | From: "Romeo" 973 | Contact: ;isfocus 974 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 975 | Content-Type: application/sdp 976 | 977 | c=IN IP4 x2s.example.com 978 | m=message 8763 TCP/MSRP * 979 | a=accept-types:message/cpim text/plain text/html 980 | a=accept-wrapped-types:text/plain text/html 981 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 982 | a=chatroom:nickname private-messages 984 The SIP user then requests a nickname. 986 Example 29: MSRP user sets up nickname (S4) 988 | MSRP a786hjs2 NICKNAME 989 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 990 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 991 | Use-Nickname: "Romeo" 992 | -------a786hjs2 994 Upon receiving the MSRP NICKNAME request, the SIP-to-XMPP gateway is 995 responsible for generating an XMPP presence stanza and sending it to 996 the chatroom. 998 Example 30: Romeo enters XMPP chatroom (S5) 1000 | 1002 | 1003 | 1005 If the room does not already contain another user with the requested 1006 nickname, the service accepts the access request. Thus if the 1007 gateway does not receive any stanza of type "error" specifying a 1008 error condition within a reasonable amount of time (e.g., 1009 5 seconds), it MUST answer the MSRP nickname proposal with a 200 OK 1010 response (S6). 1012 Example 31: Acknowledgement of join (S6) 1014 | MSRP a786hjs2 200 OK 1015 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1016 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1017 | -------a786hjs2 1019 Once the nickname has been set the user subscribes to the conference 1020 event. 1022 Example 32: User subscribes to the conference event (S8) 1024 | SUBSCRIBE sip:verona@chat.example.org SIP/2.0 1025 | To: 1026 | From: "Romeo" 1027 | Contact: ;gr=orchard 1028 | Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417 1029 | Event: conference 1030 | Expires: 600 1031 | Accept: application/conference-info+xml 1032 | Allow-Events: conference 1033 | Content-Length: 0 1035 The gateway will accept or reject the request based on local policy. 1037 Example 33: Gateway accepts subscription (S9) 1039 | SIP/2.0 200 OK 1040 | To: 1041 | From: "Romeo" 1042 | Call-ID: A260DEBD-4F1F-45D1-A2C0-3696636F6417 1043 | Contact: ;isfocus 1044 | Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, 1045 | CANCEL, UPDATE, MESSAGE, REFER 1046 | Expires: 600 1047 | Content-Length: 0 1049 5.2. Presence Broadcast 1051 If the multi-user chat service is able to add the SIP user to the 1052 room, it sends presence from all the existing occupants' room JIDs to 1053 the new occupant's full JID, including extended presence information 1054 about roles in an element. 1056 Example 34: XMPP service sends presence from existing occupants to 1057 new occupant (S7) 1059 | 1061 | 1062 | 1063 | 1064 | 1065 | 1066 | 1067 | 1069 | 1070 | 1071 | 1072 | 1073 | 1074 | 1076 | 1077 | 1078 | 1079 | 1081 Upon receiving these presence stanzas, if the MSRP conference server 1082 has already completed the subscription to the Conference Event 1083 package [RFC4575], the XMPP-to-SIP gateway MUST translate them into a 1084 SIP NOTIFY request containing the participant list (represented in 1085 the conference-info format specified in [RFC4575]). 1087 Example 35: MSRP mapping of XMPP participant presence (S10) 1089 | NOTIFY sip:romeo@example.com SIP/2.0 1090 | To: ;tag=43524545 1091 | From: ;tag=a3343df32 1092 | Call-ID: 6F563BA1-8177-4CED-8710-78D4D9593B08 1093 | Event: conference 1094 | Subscription-State: active;expires=3600 1095 | Content-Type: application/conference-info+xml 1096 | Content-Length: ... 1097 | 1098 | 1100 | 1101 | Today in Verona 1102 | 1103 | 1104 | tel:+18882934234 1105 | sip:verona@chat.example.org 1106 | 1107 | 1108 | 1109 | 1110 | 1112 | JuliC 1113 | 1114 | participant 1115 | 1116 | 1118 | connected 1119 | 1120 | message 1121 | 1122 | 1123 | 1124 | 1126 | Ben 1127 | 1128 | participant 1129 | 1130 | 1132 | connected 1133 | 1134 | message 1135 | 1136 | 1137 | 1138 | 1140 Because the "room roster" is communicated in XMPP by means of 1141 multiple presence stanzas (one for each participant) whereas the 1142 participant list is communicated in SIP by means of a single 1143 conference-info document, the SIP-to-XMPP gateway will need to keep 1144 track of the user's SIP URI and the mapping of that URI into an XMPP 1145 address; then, based on that mapping, it will need to determine when 1146 it has received a complete room roster from the MUC room, i.e., when 1147 it has received the in-room presence of the SIP user (which according 1148 to [XEP-0045] is the last presence stanza received in the initial 1149 batch sent after joining). Once that happens, the SIP-to-XMPP 1150 gateway can construct the conference-info document containing the 1151 complete participant list and send that to the SIP user. 1153 5.3. Exchange Messages 1155 Once the user has joined the chat room, the user can exchange an 1156 unbounded number of messages, both public and private. 1158 The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be 1159 as shown in the following table. (Mappings for elements not 1160 mentioned are undefined.) 1162 Table 5: Message syntax mapping from MSRP Message to XMPP 1164 +-----------------------------+-----------------------------+ 1165 | CPIM Header |XMPP Element or Attribute | 1166 +-----------------------------+-----------------------------+ 1167 | To | to | 1168 | From | from | 1169 | body of the SEND request | | 1170 +-----------------------------+-----------------------------+ 1172 5.3.1. Send a Message to All Occupants 1174 When Romeo wants to send a message to all other occupants in the 1175 room, he sends an MSRP SEND request to itself (i.e., 1176 in our example). 1178 The following examples show an exchange of a public message. 1180 Example 36: Romeo sends a message to the chat room (S13) 1182 | MSRP a786hjs2 SEND 1183 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1184 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1185 | Message-ID: 87652492 1186 | Byte-Range: 1-*/* 1187 | Content-Type: message/cpim 1188 | 1189 | To: 1190 | From: "Romeo" ;gr=orchard 1191 | DateTime: 2008-10-15T15:02:31-03:00 1192 | Content-Type: text/plain 1193 | 1194 | Romeo is here! 1195 | -------a786hjs2$ 1197 Upon receiving the SEND request, if the request either contains a 1198 Failure-Report header field value of "yes" or does not contain a 1199 Failure-Report header at all, the SIP-to-XMPP gateway MUST 1200 immediately translate it into an XMPP message stanza (S14) and then 1201 generate and send an MSRP response (S15). 1203 Example 37: XMPP mapping of message (S14) 1205 | 1209 | Romeo is here! 1210 | 1212 Example 38: MSRP response to public message (S15) 1214 | MSRP d93kswow 200 OK 1215 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1216 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1217 | -------d93kswow$ 1219 Note well that the XMPP MUC room will reflect the sender's message 1220 back to all users, including the sender. In MSRP this reflected 1221 message is unnecessary. Therefore gateways are advised to maintain a 1222 cache and if the same stanza is received within a reasonable amount 1223 of time, assume is the reflected message and ignore it. 1225 5.3.2. Send a Private Message 1227 Romeo can send a "private message" to a selected occupant via the 1228 chat room service by sending a message to the occupant's room 1229 nickname. 1231 The following examples show an exchange of a private message. 1233 Example 39: Romeo sends a private message (S19) 1235 | MSRP a786hjs2 SEND 1236 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1237 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1238 | Message-ID: 87652492 1239 | Byte-Range: 1-*/* 1240 | Content-Type: message/cpim 1241 | 1242 | To: ;gr=JuliC 1243 | From: "Romeo" ;gr=orchard 1244 | DateTime: 2008-10-15T15:02:31-03:00 1245 | Content-Type: text/plain 1246 | 1247 | I am here!!! 1248 | -------a786hjs2$ 1250 The MSRP conference is responsible for transforming the "From" 1251 address into an in-room address. 1253 Example 40: MSRP handling of private message 1255 | MSRP a786hjs2 SEND 1256 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1257 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1258 | Message-ID: 87652492 1259 | Byte-Range: 1-*/* 1260 | Content-Type: message/cpim 1261 | 1262 | To: ;gr=JuliC 1263 | From: ;gr=Romeo 1264 | DateTime: 2008-10-15T15:02:31-03:00 1265 | Content-Type: text/plain 1266 | 1267 | I am here!!! 1268 | -------a786hjs2$ 1270 Once the MSRP conference sends that message to the gateway, the 1271 gateway is responsible for translating it into XMPP syntax. 1273 Example 41: XMPP mapping of private message (S20) 1275 | 1279 | I am here!!! 1280 | 1282 5.4. Change Nickname 1284 If Romeo decides to change his nickname within the room, he MUST send 1285 a new MSRP NICKNAME request. In fact modification of the nickname in 1286 MSRP is not different from the initial reservation and usage of a 1287 nickname. 1289 Example 42: MSRP user changes nickname (S22) 1291 | MSRP a786hjs2 NICKNAME 1292 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1293 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1294 | Use-Nickname: "montecchi" 1295 | -------a786hjs2 1297 Upon receiving such a message, the SIP-to-XMPP gateway MUST translate 1298 it into an XMPP presence stanza. 1300 Example 43: XMPP mapping of nickname change (S23) 1302 | 1305 The XMPP server will analyze the nickname allocation and determine if 1306 the requested nickname is available. In case the nickname is not 1307 available or not usable, the server will generate a presence stanza 1308 of type "error" specifying a error condition. 1310 Example 44: XMPP conflict error for nickname (S24) 1312 | 1315 | 1316 | 1317 | 1318 | 1319 | 1321 Upon receiving this stanza, the XMPP-SIP gateway will reply to the 1322 NICKNAME request with code 425 1323 Example 45: Gateway translates XMPP nickname conflict to MSRP error 1324 code (S25) 1326 | MSRP a786hjs2 425 Nickname usage failed 1327 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1328 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1329 | -------a786hjs2 1331 5.5. Invite Another User to a Room 1333 If a SIP user wants to invite another user to join the conference he 1334 will send a REFER request indicating who needs to be invited in the 1335 Refer-To header, as per Section 5.5 of [RFC4579]. 1337 Example 46: Inviting an XMPP participant (S26) 1339 | REFER sip:verona@chat.example.org SIP/2.0 1340 | To: 1341 | From: "Romeo" ;tag=5534562 1342 | Call-ID: AA11FE6F-8E13-42F3-BF35-AB509FAADA39 1343 | Contact: ;gr=orchard 1344 | Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 1345 | Accept: message/sipfrag 1346 | Refer-To: 1347 | Supported: replaces 1348 | Content-Length: 0 1350 The XMPP-SIP gateway then acknowledges the SIP REFER request with a 1351 200 OK response (step S27). 1353 The gateway will then send a NOTIFY requests as per [RFC3515] 1354 indicating that the invitation is is progress. Since there is no way 1355 know the progress of the invitation until the user has joined, 1356 implementations are advised to terminate the REFER dialog 1357 subscription with the first NOTIFY, with a status code of 100 Trying. 1359 Example 47: Progress notification for invitation (S28) 1361 | NOTIFY sip:romeo@example.com SIP/2.0 1362 | To: ;tag=5534562 1363 | From: ;tag=18747389 1364 | Call-ID: AA11FE6F-8E13-42F3-BF35-AB509FAADA39 1365 | Event: refer 1366 | Subscription-State: terminated;reason=noresource 1367 | Contact: ;isfocus 1368 | Content-Type: message/sipfrag;version=2.0 1369 | Content-Length: 20 1370 | 1371 | SIP/2.0 100 Trying 1373 5.6. Exit Room 1375 If Romeo decides to exit the chat room, his client sends a SIP BYE to 1376 the chat room. 1378 Example 48: Romeo terminates session (S30) 1380 | BYE sip:verona@chat.example.org SIP/2.0 1381 | Max-Forwards: 70 1382 | From: "Romeo" ;tag=786 1383 | To: ;tag=534 1384 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 1385 | Cseq: 1 BYE 1386 | Content-Length: 0 1388 Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it 1389 into a presence stanza (F19) and sends it to the XMPP MUC room 1390 service. Then the SIP-to-XMPP gateway responds with a 200 OK to the 1391 MSRP user. 1393 Example 49: Romeo exits chatroom (S31) 1395 | 1399 6. Handling of Nicknames and Display Names 1401 Fundamental rules for mapping addresses between XMPP and SIP are 1402 provided in [I-D.ietf-stox-core]. However, chatrooms include a more 1403 specialized, unique identifier for each participant in a room, called 1404 a nickname. Implementations are strongly encouraged to apply the 1405 rules for preparation and comparison of nicknames specified in 1406 [I-D.ietf-precis-nickname]. 1408 In addition to nicknames, some groupchat implementations also include 1409 display names (which might or might not be different from users' 1410 nicknames). A display name need not be unique within the context of 1411 a room but instead simply provides a user-friendly name for a 1412 participant. 1414 In SIP, the nickname is the value of the XCON 'nickname' attribute of 1415 the element [RFC6501] and the display name is the XML 1416 character data of the conference-info element 1417 [RFC4575]. In XMPP, the nickname is the value of the resourcepart of 1418 the occupant JID [XEP-0045] and the display name is the XML character 1419 data of the element [XEP-0172]. 1421 In practice, the element is treated as canonical in 1422 SIP implementations, and the element is rarely used in XMPP 1423 implementations. Therefore, for display purposes SIP implementations 1424 ought to use the element (not the XCON 'nickname' 1425 attribute) and XMPP implementations ought to use the resourcepart of 1426 the occupant JID (not the character data of the element). 1428 If there is a conflict between the SIP nickname and the XMPP 1429 nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for 1430 adjusting the nickname to avoid the conflict and for informing the 1431 SIP or XMPP client of the unique nickname used to join the chatroom. 1433 7. IANA Considerations 1435 This document requests no actions of the IANA. 1437 8. Security Considerations 1439 The security considerations of [RFC3261], [RFC4975], [RFC6120], 1440 [I-D.ietf-stox-core], [I-D.ietf-simple-chat], and [XEP-0045] apply. 1442 9. References 1444 9.1. Normative References 1446 [I-D.ietf-precis-nickname] 1447 Saint-Andre, P., "Preparation and Comparison of 1448 Nicknames", draft-ietf-precis-nickname-09 (work in 1449 progress), January 2014. 1451 [I-D.ietf-simple-chat] 1452 Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1453 party Instant Message (IM) Sessions Using the Message 1454 Session Relay Protocol (MSRP)", draft-ietf-simple-chat-18 1455 (work in progress), January 2013. 1457 [I-D.ietf-stox-core] 1458 Saint-Andre, P., Houri, A., and J. Hildebrand, 1459 "Interworking between the Session Initiation Protocol 1460 (SIP) and the Extensible Messaging and Presence Protocol 1461 (XMPP): Core", draft-ietf-stox-core-11 (work in progress), 1462 February 2014. 1464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1465 Requirement Levels", BCP 14, RFC 2119, March 1997. 1467 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1468 A., Peterson, J., Sparks, R., Handley, M., and E. 1469 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1470 June 2002. 1472 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1473 (SIP) Call Control - Conferencing for User Agents", RFC 1474 4579, August 2006. 1476 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1477 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1479 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1480 Protocol (XMPP): Core", RFC 6120, March 2011. 1482 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1483 Protocol (XMPP): Instant Messaging and Presence", RFC 1484 6121, March 2011. 1486 [XEP-0045] 1487 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, July 1488 2008. 1490 9.2. Informative References 1492 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1493 Method", RFC 3515, April 2003. 1495 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1496 Description Protocol", RFC 4566, July 2006. 1498 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1499 Initiation Protocol (SIP) Event Package for Conference 1500 State", RFC 4575, August 2006. 1502 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1503 "Conference Information Data Model for Centralized 1504 Conferencing (XCON)", RFC 6501, March 2012. 1506 [XEP-0172] 1507 Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 1508 0172, March 2012. 1510 [XEP-0249] 1511 Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249, 1512 September 2011. 1514 Appendix A. Acknowledgements 1516 Special thanks to Fabio Forno for coauthoring an early version of 1517 this document. 1519 Thanks also to Dave Crocker, Philipp Hancke, and Olle Johansson for 1520 their feedback. 1522 The authors gratefully acknowledge the assistance of Markus Isomaki 1523 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 1524 and Alissa Cooper as the sponsoring Area Directors. 1526 Some text in this document was borrowed from [I-D.ietf-stox-core] and 1527 from [XEP-0045]. 1529 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 1530 employing him during his work on earlier versions of this document. 1532 Authors' Addresses 1534 Peter Saint-Andre 1535 &yet 1536 P.O. Box 787 1537 Parker, CO 80134 1538 USA 1540 Email: ietf@stpeter.im 1542 Saul Ibarra Corretge 1543 AG Projects 1544 Dr. Leijdsstraat 92 1545 Haarlem 2021RK 1546 The Netherlands 1548 Email: saul@ag-projects.com 1549 Salvatore Loreto 1550 Ericsson 1551 Hirsalantie 11 1552 Jorvas 02420 1553 Finland 1555 Email: Salvatore.Loreto@ericsson.com