idnits 2.17.1 draft-saintandre-sip-xmpp-chat-04.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-saintandre-sip-xmpp-core-02 == Outdated reference: A later version (-03) exists of draft-saintandre-sip-xmpp-im-01 == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-16 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Cisco Systems, Inc. 4 Intended status: Informational E. Gavita 5 Expires: April 18, 2013 N. Hossain 6 S. Loreto 7 Ericsson 8 October 15, 2012 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat 12 draft-saintandre-sip-xmpp-chat-04 14 Abstract 16 This document defines a bi-directional protocol mapping for the 17 exchange of instant messages in the context of a one-to-one chat 18 session between a user of the Session Initiation Protocol (SIP) and a 19 user of the Extensible Messaging and Presence Protocol (XMPP). 20 Specifically for SIP text chat, this document specifies a mapping to 21 the Message Session Relay Protocol (MSRP). 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.4. Formal and Informal Sessions . . . . . . . . . . . . . . . 5 74 1.5. Gateway Heuristics . . . . . . . . . . . . . . . . . . . . 6 75 1.6. Connection Maintenance . . . . . . . . . . . . . . . . . . 6 76 1.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 7 77 1.8. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7 78 2. XMPP Formal Chat Session to MSRP . . . . . . . . . . . . . . . 7 79 2.1. Initiating a Formal Session . . . . . . . . . . . . . . . 8 80 2.2. Accepting a Formal Session . . . . . . . . . . . . . . . . 11 81 2.3. Exchanging Messages . . . . . . . . . . . . . . . . . . . 13 82 2.4. Terminating a Formal Session . . . . . . . . . . . . . . . 16 83 2.5. Cancelling the Negotiation . . . . . . . . . . . . . . . . 17 84 2.6. Rejecting a Formal Session . . . . . . . . . . . . . . . . 19 85 3. XMPP Informal Session to MSRP . . . . . . . . . . . . . . . . 20 86 4. MSRP to XMPP Formal Session . . . . . . . . . . . . . . . . . 24 87 4.1. Initiating a Session . . . . . . . . . . . . . . . . . . . 25 88 4.2. Accepting a Session . . . . . . . . . . . . . . . . . . . 28 89 4.3. Completing the Transaction . . . . . . . . . . . . . . . . 29 90 4.4. Exchanging Messages . . . . . . . . . . . . . . . . . . . 29 91 4.5. Terminating a Session . . . . . . . . . . . . . . . . . . 31 92 4.6. Cancelling the Transaction . . . . . . . . . . . . . . . . 33 93 4.7. Rejecting the Transaction . . . . . . . . . . . . . . . . 34 94 4.8. Session Negotiation Fails . . . . . . . . . . . . . . . . 34 95 5. MSRP to XMPP Informal Session . . . . . . . . . . . . . . . . 35 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 39 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 103 1. Introduction 105 1.1. Overview 107 Both the Session Initiation Protocol [RFC3261] and the Extensible 108 Messaging and Presence Protocol [RFC6120] can be used for the purpose 109 of one-to-one text chat over the Internet. To ensure interworking 110 between these technologies, it is important to define bi-directional 111 protocol mappings. 113 The architectural assumptions underlying such protocol mappings are 114 provided in [I-D.saintandre-sip-xmpp-core], including mapping of 115 addresses and error conditions. Mappings for single instant messages 116 (sometimes called "pager-mode" messaging) are provided in 117 [I-D.saintandre-sip-xmpp-im]. This document specifies mappings for 118 one-to-one text chat sessions (sometimes called "session-mode" 119 messaging); in particular, this document specifies mappings between 120 XMPP and the Message Session Relay Protocol [RFC4975]. Mapping of 121 multi-user text chat (sometimes called "groupchat") is out of scope 122 for this document. 124 1.2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 1.3. Scope 133 Both XMPP and SIP/SIMPLE technologies enable end users to send 134 "instant messages" to other end users. The term "instant message" 135 usually refers to messages sent between two end users for delivery in 136 close to real time (rather than messages that are stored and 137 forwarded to the intended recipient upon request). Generally, there 138 are three kinds of instant messages: 140 1. Single messages, which are sent from the sender to the recipient 141 outside the context of any one-to-one chat session or multi-user 142 text conference. The message is immediately delivered and not 143 stored in an inbox. In XMPP a single message is a 144 stanza of type "normal" as specified in [RFC6121]. In SIP/SIMPLE 145 a single message is sent via the MESSAGE method as specified in 146 [RFC3428]. 147 2. One-to-one chat messages, which are sent from the sender to the 148 recipient (i.e., one-to-one) in the context of a "chat session" 149 between the two entities. In XMPP a chat message is a 150 stanza of type "chat". In SIP/SIMPLE a chat message is sent 151 using an MSRP session as specified in [RFC4975]. 152 3. Groupchat messages, which are sent from a sender to multiple 153 recipients (i.e., two or more) in the context of a "multi-user 154 chat session", "text conference", or "chatroom". In XMPP a 155 groupchat message is a stanza of type "groupchat" that 156 is reflected from the sender to multiple recipients by a multi- 157 user chat service, as defined in [XEP-0045]. In SIP/SIMPLE a 158 groupchat message is reflected from the sender to multiple 159 recipients by a conference server that uses MSRP to handle 160 groupchat sessions, as defined in [MSRP-MULTI]. 162 This document covers only scenario #2 for converting XMPP messages of 163 type "chat" to and from their corresponding SIP INVITE and MSRP 164 message types on the SIP/SIMPLE side. 166 As in [I-D.saintandre-sip-xmpp-im] and related documents, the 167 approach taken here is to directly map syntax and semantics from one 168 protocol to another. The mapping described herein depends on the 169 protocols defined in the following specifications: 171 o XMPP chat sessions using message stanzas of type "chat" are 172 specified in [RFC6121]. 173 o A method for formally negotiating an XMPP chat session is 174 specified in the Stanza Session Negotiation extension to XMPP 175 [XEP-0155]. 176 o SIP-based chat sessions using the SIP INVITE and SEND request 177 types are specified in [RFC4975]. 179 1.4. Formal and Informal Sessions 181 The traditional model for a one-to-one chat "session" in XMPP is for 182 a user to simply send a message of type "chat" to a contact, without 183 any formal negotiation of session parameters; the contact would then 184 reply to the message, and the sum total of such messages exchanged 185 during a defined period of time can be considered a chat session. 186 This informal approach to chat sessions in XMPP can be mapped both to 187 SIP pager-mode messaging using the SIP MESSAGE method (as documented 188 in [I-D.saintandre-sip-xmpp-core]) and to an MSRP chat session. How 189 a gateway chooses to map the XMPP chat session to the SIP side is a 190 matter of the implementation, although guidelines are provided under 191 Section 1.5. 193 However, in XMPP it is also possible to formally request a chat 194 session and negotiate its parameters (e.g., security, privacy, 195 message logging) before beginning the session and exchanging 196 messages. The protocol for doing so is defined in [XEP-0155]. In 197 this case, the XMPP chat session SHOULD be translated into an MSRP 198 session. 200 This document covers the mapping of both informal and formally- 201 negotiated XMPP chat sessions into MSRP sessions, and from MSRP 202 sessions into XMPP informal and formal sessions. 204 1.5. Gateway Heuristics 206 When a gateway receives a chat message or chat session request 207 intended for a recipient that is registered with the gateway itself 208 or has an account on a local service, it SHOULD adhere to the 209 following process in determining whether to (1) initiate a formal 210 chat session with the recipient, (2) initiate an informal chat 211 session with the recipient, or (3) return an error to the sender. 213 1. If the gateway has knowledge of the recipient's online endpoints 214 (available resources in XMPP or registered UAs in SIP), then it 215 SHOULD discover the capabilities of those endpoints. 216 2. If the gateway determines that one or more of the endpoints 217 supports formal chat sessions, it SHOULD initiate a formal chat 218 session with one of those endpoints (deciding among the endpoints 219 based on presence information or communications priority). 220 3. If the gateway determines that none of the endpoints supports 221 formal chat sessions, it SHOULD initiate an informal chat session 222 with one of those endpoints (deciding among the endpoints based 223 on presence information or communications priority). 224 4. If the gateway does not know if the recipient has any online 225 endpoints, it SHOULD return an appropriate error to the sender. 227 The methods by which a gateway determines support for various 228 capabilities are protocol-specific. For XMPP a gateway SHOULD use 229 the Service Discovery extension defined in [XEP-0030] or, if it 230 receives presence information from the XMPP endpoint, use the Entity 231 Capabilities extension defined in [XEP-0115]. For MSRP a gateway 232 SHOULD use the Session Description Protocol defined in [RFC4566] in 233 conjunction with a high-level protocol that provides a capability 234 query, such as the SIP OPTIONS request defined in [RFC3261]. 236 1.6. Connection Maintenance 238 XMPP makes use of long-lived TCP connections. If mobility affecting 239 Layer 3 causes a dropped connection, the connection must be re- 240 established. If mobility does not preserve the IP address, the TCP 241 connection will be dropped. Any TLS session and SASL associations 242 must be re-established if the TCP connection is dropped. XMPP binds 243 directly to TCP in the core specification, so the TCP session must 244 remain open for the entire duration of the chat session. The XMPP 245 Standards Foundation does define protocol extensions enabling 246 transport of XMPP traffic over HTTP (refer to [XEP-0124] and 247 [XEP-0206]), so that individual messages are carried using HTTP and 248 are more robust in environments such as mobile networks, allowing for 249 better recovery if a TCP session is broken. 251 SIMPLE is similar when using MSRP. The Message Session Relay 252 Protocol [RFC4975] is a protocol for transmitting instant messages 253 (IM) in the context of a session. The protocol specification 254 describes how the session can be negotiated and established with an 255 offer or answer (see [RFC3264]) using the Session Description 256 Protocol [RFC4566]. In SIMPLE, this exchange is carried using SIP as 257 the signaling protocol. After the TCP connection is established, if 258 it fails for any reason, then an MSRP endpoint MAY choose to re- 259 create such a session using a new SDP exchange in a SIP re-INVITE. 260 SIMPLE also uses the MESSAGE request type for transporting instant 261 messaging outside the context of a session. The MESSAGE request is 262 sent inside the signaling path without establishing any dedicated 263 connection. 265 1.7. Acknowledgements 267 Some text in this document was borrowed from 268 [I-D.saintandre-sip-xmpp-core] and from [XEP-0155]. 270 1.8. Discussion Venue 272 The authors welcome discussion and comments related to the topics 273 presented in this document. The preferred forum is the 274 mailing list, for which archives and subscription 275 information are available at 276 . 278 2. XMPP Formal Chat Session to MSRP 280 This section describes how to map an XMPP "formal session" to an MSRP 281 session. 283 The XMPP formal session is based on the protocol described in 284 [XEP-0155], which enables the initiation, renegotiation, and 285 termination of a formal chat session on the XMPP side. This approach 286 maps to the semantic of the SIP INVITE and BYE methods. 288 XMPP User GW SIP User 289 | | | 290 |(F1) (XMPP) Stanza session request | 291 |------------------------->| | 292 | |(F2) (SIP) INVITE | 293 | |------------------------->| 294 | |(F3) (SIP) 200 OK | 295 | |<-------------------------| 296 |(F4) (XMPP) Stanza session acceptance | 297 |<-------------------------| | 298 | |(F5) (SIP) ACK | 299 | |------------------------->| 300 |(F6) (XMPP) Stanza session completion | 301 |------------------------->| | 302 |(F7) (XMPP) A chat message | 303 |------------------------->| | 304 | |(F8) (MSRP) SEND | 305 | |------------------------->| 306 | |(F9) (MSRP) A reply | 307 |(F10) (XMPP) A reply | | 308 |<-------------------------| | 309 | | | 310 . . . 311 . . . 312 . . . 313 | | | 314 |(F11) (XMPP) Stanza session termination | 315 |------------------------->| | 316 | |(F12) (SIP) BYE | 317 | |------------------------->| 318 | |(F13) (SIP) 200 OK | 319 | |<-------------------------| 320 |(F14) (XMPP) Termination acknowledgment | 321 |<-------------------------| | 323 2.1. Initiating a Formal Session 325 When the XMPP user ("Juliet") wants to initiate a negotiated session 326 with a SIP user ("Romeo"), she sends a stanza to Romeo 327 containing a child qualified by the 328 'http://jabber.org/protocol/feature-neg' namespace. The 329 stanza must not contain a child (as specified in [RFC6121]), 330 since that child element is used for human-readable text. The 331 stanza type should be "normal". The stanza MUST contain a 332 element for tracking purposes (where the newly-generated 333 ThreadID is unique to the proposed session). The encapsulated data 334 form MUST contain a FORM_TYPE field whose type is "hidden" and whose 335 value is "urn:xmpp:ssn"; it must also contain a boolean field named 336 "accept". 338 The XMPP user may request a session with a specific resource of the 339 contact. However in this document the resource identifier will be 340 ignored and discarded for cross-system interworking. 342 Example: (F1) Juliet starts a formal session 344 347 711609sa 348 349 350 Open chat with Juliet? 351 352 urn:xmpp:ssn 353 354 357 true 358 359 360 363 en 364 365 366 367 370 may 371 374 377 378 379 380 382 Upon receiving such a session request, the XMPP server to which 383 Juliet has authenticated attempts to deliver the request to a local 384 user or attempts to route the request to the remote domain that 385 services the hostname in the 'to' attribute. Naturally, in this 386 document we assume that the hostname in the 'to' attribute is an IM- 387 aware SIP service hosted by a separate server. 389 As specified in [RFC6121], the XMPP server needs to determine the 390 identity of the remote domain, which it does by performing one or 391 more [RFC2782] lookups. For message stanzas, the order of lookups 392 recommended by [RFC6121] is to first try the "_xmpp-server" service 393 as specified in [RFC6120] and to then try the "_im" service as 394 specified in [RFC3861]. Here we assume that the first lookup will 395 fail but that the second lookup will succeed and return a resolution 396 "_im._simple.example.net.", since we have already assumed that the 397 example.net hostname is running a SIP instant messaging service. 398 (Note: The XMPP server may have previously determined that the remote 399 domain is a SIMPLE server, in which case it would not need to perform 400 the SRV lookups; the caching of such information is a matter of 401 implementation and local service policy, and is therefore out of 402 scope for this document.) 404 Once the XMPP server (example.com) has determined that the remote 405 domain is serviced by a SIMPLE server, it hands the XMPP message off 406 to its local XMPP-to-SIP gateway (x2s.example.com), which transforms 407 the message into SIP syntax and routes it to the remote SIMPLE server 408 (example.net). 410 Example: (F2) Juliet starts a formal session (SIP transformation) 412 INVITE sip:romeo@example.net SIP/2.0 413 To: 414 From: ;tag=786 415 Subject: Open chat with Juliet? 416 Call-ID: 711609sa 417 Content-Type: application/sdp 419 c=IN IP4 x2s.example.com 420 m=message 7654 TCP/MSRP * 421 a=accept-types:text/plain 422 a=lang:en 423 a=lang:it 424 a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 426 Here the Session Description Protocol offer specifies the MSRP-aware 427 XMPP-to-SIP gateway on the XMPP side as well as other particulars of 428 the session. 430 There is no direct mapping for the MSRP URIs. In fact MSRP URIs 431 identify a session of instant messages at a particular device; 432 they are ephemeral and have no meaning outside the scope of that 433 session. The authority component of the MSRP URI MUST contain the 434 XMPP-to-SIP gateway hostname or numeric IP address and an explicit 435 port number. 437 Native XMPP messages as described in [RFC6121] supports text 438 (i.e., UTF-8) only. However, there exists an XMPP extension for 439 XHTML-formatted messges, as defined by the XHTML-IM integration 440 set specified in [XEP-0071]. Unless the use of XHTML-formatted 441 messages is supported by the endpoints or negotiated during 442 session establishment, the "accept-types" attribute that follows 443 an MSRP media line SHOULD indicate "text/plain" as the only media- 444 type that is acceptable to the endpoint; if XHTML is supported or 445 negotiated, the "accept-types" attribute MAY also indicate a 446 media-type of "text/html". (Note: The XHTML-IM integration set 447 supports only a subset of XHTML formatting; it is the 448 responsibility of a gateway to map between full XHTML and 449 XHTML-IM.) 451 As specified in [I-D.saintandre-sip-xmpp-core], the mapping of XMPP 452 syntax elements to SIP and SDP syntax elements SHOULD be as shown in 453 the following table. (Mappings for elements not mentioned are 454 undefined.) 456 Table 1: Message syntax mapping from XMPP to SIP/SDP 458 +-----------------------------+-----------------------------+ 459 | XMPP Element or Attribute | SIP Header or SDP Contents | 460 +-----------------------------+-----------------------------+ 461 | | Call-ID | 462 | from | From | 463 | to | To | 464 | | Subject | 465 | xml:lang | a=lang:<language tag> | 466 | - | a=accept-types:text/plain | 467 +-----------------------------+-----------------------------+ 469 2.2. Accepting a Formal Session 471 Here we assume that the SIP user agent that receives the SIP 472 invitation (containing an offered session description that includes a 473 session of MSRP) accepts the invitation and includes an answer 474 session description that acknowledges the choice of media. 476 Example: (F3) Romeo accepts the request 478 SIP/2.0 200 OK 479 To: <sip:romeo@example.net>;tag=087js 480 From: <sip:juliet@example.com>;tag=786 481 Call-ID: 711609sa 482 Content-Type: application/sdp 484 c=IN IP4 example.net 485 m=message 12763 TCP/MSRP * 486 a=accept-types:text/plain 487 a=lang:it 488 a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 490 Upon receiving such a response, the SIMPLE server or associated SIP- 491 to-XMPP gateway SHOULD remember that this is a response to a SIP 492 transaction related to an XMPP-SIP translation, based on the SIP 493 Call-ID (which is functionally equivalent to the XMPP <thread/>). 494 The SIP-to-XMPP gateway is responsible for translating the response 495 into an XMPP message stanza and routing it from the SIP user to the 496 XMPP server or associated XMPP-to-SIP gateway. 498 The SIP-to-XMPP gateway MUST include in the response translation 499 values for all the fields that the XMPP request indicated are 500 required. 502 Example: (F4) Romeo accepts the request (XMPP translation) 504 <message from='romeo@example.net' 505 to='juliet@example.com' 506 type='normal'> 507 <thread>711609sa</thread> 508 <feature xmlns='http://jabber.org/protocol/feature-neg'> 509 <x xmlns='jabber:x:data' type='submit'> 510 <field var='FORM_TYPE'> 511 <value>urn:xmpp:ssn</value> 512 </field> 513 <field var='accept'><value>true</value></field> 514 <field var='language'><value>it</value></field> 515 </x> 516 </feature> 517 </message> 519 The SIP-to-XMPP gateway MUST also send a SIP ACK to the SIP user. 521 Example: (F5) Gateway sends ACK to Romeo's UA 523 ACK sip:romeo@example.net SIP/2.0 524 To: <sip:romeo@example.net>;tag=087js 525 From: <sip:juliet@example.com>;tag=786 526 Call-ID: 711609sa 528 If Romeo accepted the session, Juliet MUST either complete or cancel 529 the stanza session negotiation. The user's client SHOULD verify that 530 the selected values of the fields are acceptable before completing 531 the stanza session negotiation -- and confirming that the session is 532 open -- by replying with the form 'type' attribute set to 'result'. 533 The form MUST contain the FORM_TYPE field and the "accept" field set 534 to "1" or "true". 536 Example: (F6) Juliet completes negotiation 538 <message from='juliet@example.com' 539 to='romeo@example.net' 540 type='normal'> 541 <thread>711609sa</thread> 542 <feature xmlns='http://jabber.org/protocol/feature-neg'> 543 <x xmlns='jabber:x:data' type='result'> 544 <field var='FORM_TYPE'> 545 <value>urn:xmpp:ssn</value> 546 </field> 547 <field var='accept'><value>true</value></field> 548 </x> 549 </feature> 550 </message> 552 Upon receiving such a stanza completing the session negotiation, the 553 XMPP server MUST NOT send any confirmation to the SIP side; instead, 554 it MUST route the acceptance to the SIMPLE server or associated SIP- 555 to-XMPP gateway. 557 The session is now open and the parties can proceed to exchanging 558 messages. 560 2.3. Exchanging Messages 562 Once the session is created, the endpoints can exchange an unbounded 563 number of messages. 565 The XMPP 'id' attribute is not required in the protocol and there is 566 no way to enforce its use for messages. It is RECOMMENDED to include 567 it as a negotiable item in the SSN negotiation, via the "message-ids" 568 field. However, it is possible that the 'id' will not be present 569 within the <message/> stanza; in this case the XMPP-to-SIP gateway 570 MUST generate a new unique Message-ID. 572 If the XMPP user has not explicitly requested message receipts during 573 the negotiation, it is RECOMMENDED that the SIP-to-XMPP gateway shall 574 insert a Failure-Report header field value of "no" during the 575 creation of a SEND request. The XMPP user can include a request for 576 message receipts using the Message Receipts XMPP protocol extension 577 [XEP-0184]; use of this extension can be negotiated via the 578 "urn:xmpp:receipts" field during SSN negotiation. 580 The mapping of XMPP syntax elements to MSRP syntax elements SHOULD be 581 as shown in the following table. (Mappings for elements not 582 mentioned are undefined.) 584 Table 2: Message syntax mapping from XMPP Message to MSRP 586 +-----------------------------+-----------------------------+ 587 | XMPP Element or Attribute | MSRP Header | 588 +-----------------------------+-----------------------------+ 589 | to | To-Path | 590 | from | From-Path | 591 | <body/> | body of the SEND request | 592 | - | Content-Type: text/plain | 593 | id | Message-ID | 594 +-----------------------------+-----------------------------+ 596 The following examples show an exchange of messages. 598 Example: (F7) Juliet sends an XMPP message 600 <message from='juliet@example.com' 601 to='romeo@example.net' 602 type='chat'> 603 <thread>711609sa</thread> 604 <body>Art thou not Romeo, and a Montague?</body> 605 </message> 606 Example: (F8) Gateway transforms XMPP message to MSRP 608 MSRP a786hjs2 SEND 609 To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 610 From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 611 Message-ID: 87652491 612 Byte-Range: 1-25/25 613 Content-Type: text/plain 615 Art thou not Romeo, and a Montague? 616 -------a786hjs2$ 618 Upon receiving the SEND request, if the request either contains a 619 Failure-Report header field value of "yes" or does not contain a 620 Failure-Report header at all, Romeo's client MUST immediately 621 generate and send a response. 623 MSRP d93kswow 200 OK 624 To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 625 From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 626 -------d93kswow$ 628 Romeo can then send a reply using his MSRP user agent. 630 Example: (F9) Romeo sends a reply 632 MSRP a786hjs2 SEND 633 To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 634 From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 635 Message-ID: 87652491 636 Byte-Range: 1-25/25 637 Content-Type: text/plain 639 Neither, fair saint, if either thee dislike. 640 -------a786hjs2$ 642 The SIP-to-XMPP gateway would then transform that message into 643 appropriate XMPP syntax for routing to the intended recipient. 645 Example: (F10) Gateway transforms MSRP message to XMPP 647 <message from='romeo@example.net' 648 to='juliet@example.com' 649 type='chat'> 650 <thread>711609sa</thread> 651 <body>Neither, fair saint, if either thee dislike.</body> 652 </message> 653 Note: The size of the XML character data of an XMPP message is not 654 limited by the protocol, but is sometimes limited in deployment. 655 However messages sent using MSRP can be delivered in several SEND 656 requests, so when the XMPP-to-SIP gateway receives a message longer 657 then 2048, it is STRONGLY RECOMMENDED it delivers this message using 658 as few chunks (at least 2048 octets long) as possible. 660 2.4. Terminating a Formal Session 662 If Juliet decides to terminate the negotiated chat session, her 663 client sends a <message/> stanza to Romeo containing a data form of 664 type "submit". The <message/> stanza MUST contain a <thread/> 665 element with the same XML character data as the original initiation 666 request. The data form containing a boolean field named "terminate" 667 set to a value of "1" or "true". 669 Example: (F11) Juliet terminates the chat session 671 <message from='juliet@example.com' 672 to='romeo@example.net' 673 type='normal'> 674 <thread>711609sa</thread> 675 <feature xmlns='http://jabber.org/protocol/feature-neg'> 676 <x xmlns='jabber:x:data' type='submit'> 677 <field var='FORM_TYPE'> 678 <value>urn:xmpp:ssn</value> 679 </field> 680 <field var='terminate'> 681 <value>1</value> 682 </field> 683 </x> 684 </feature> 685 </message> 687 Upon receiving such stanza terminating the chat session, the XMPP-to- 688 SIP gateway terminates the SIP session by sending a SIP BYE to tear 689 down the MSRP session with Romeo's client. Romeo's SIP client then 690 responds with a 200 OK. 692 Example: (F12) Juliet terminates the chat session (SIP translation) 694 BYE romeo@example.net sip: SIP/2.0 695 Max-Forwards: 70 696 From: <sip:juliet@example.com>;tag=786 697 To: <sip:romeo@example.net>;tag=087js 698 Call-ID: 711609sa 699 Cseq: 1 BYE 700 Content-Length: 0 701 Example: (F13) Romeo acknowledges termination 703 SIP/2.0 200 OK 704 From: <sip:juliet@example.com>;tag=786 705 To: <sip:romeo@example.net>;tag=087js 706 Call-ID: 711609sa 707 CSeq: 1 BYE 708 Content-Length: 0 710 Upon receiving the 200 OK, the SIP-to-XMPP gateway acknowledges the 711 termination of the chat session on the XMPP side by sending a 712 <message/> containing a data form of type "result", and the value of 713 the "terminate" field set to "1" or "true". The client must mirror 714 the <thread/> value it received. 716 Example: (F14) Romeo acknowledges termination (XMPP translation) 718 <message from='romeo@example.net' 719 to='juliet@example.com' 720 type='normal'> 721 <thread>711609sa</thread> 722 <feature xmlns='http://jabber.org/protocol/feature-neg'> 723 <x xmlns='jabber:x:data' type='result'> 724 <field var='FORM_TYPE'> 725 <value>urn:xmpp:ssn</value> 726 </field> 727 <field var='terminate'> 728 <value>1</value> 729 </field> 730 </x> 731 </feature> 732 </message> 734 2.5. Cancelling the Negotiation 736 If Romeo accepted the session but Juliet decides to cancel the stanza 737 session negotiation, the flow is as follows. 739 XMPP User GW SIP User 740 | | | 741 |(F1) (XMPP) Stanza session request | 742 |------------------------->| | 743 | |(F2) (SIP) INVITE | 744 | |------------------------->| 745 | |(F3) (SIP) 200 OK | 746 | |<-------------------------| 747 |(F4) (XMPP) Stanza session acceptance | 748 |<-------------------------| | 749 | |(F5) (SIP) ACK | 750 | |------------------------->| 751 |(F6) (XMPP) Stanza session cancelling | 752 |------------------------->| | 753 | |(F7) (SIP) BYE | 754 | |------------------------->| 755 | |(F8) (SIP) 200 OK | 756 | |<-------------------------| 758 That is, Juliet's client shall reply with a data form containing the 759 FORM_TYPE field and the "accept" field set to "0" or "false": 761 Example: (F6) User cancels stanza session negotiation 763 <message from='juliet@example.com' 764 to='romeo@example.net' 765 type='normal'> 766 <thread>711609sa</thread> 767 <feature xmlns='http://jabber.org/protocol/feature-neg'> 768 <x xmlns='jabber:x:data' type='result'> 769 <field var='FORM_TYPE'> 770 <value>urn:xmpp:ssn</value> 771 </field> 772 <field var='accept'> 773 <value>0</value> 774 </field> 775 </x> 776 </feature> 777 </message> 779 Upon receiving such stanza cancelling the session negotiation, the 780 XMPP-to-SIP gateway MUST send a SIP BYE. Once the XMPP-to-SIP 781 gateway receives the 200 OK, the internal session data is removed and 782 the session is officially cancelled also in the SIP-to-XMPP gateway. 784 If the SIP user had sent any messages to XMPP while awaiting 785 confirmation of the session, the SIP-to-XMPP gateway MUST return them 786 to the SIP user with an appropriate error. 788 2.6. Rejecting a Formal Session 790 A common scenario occurs when the SIP UA is currently unwilling or 791 unable to accept a formal session, in which case the flow is as 792 follows. 794 XMPP User GW SIP User 795 | | | 796 |(F1) (XMPP) Stanza session request | 797 |------------------------->| | 798 | |(F2) (SIP) INVITE | 799 | |------------------------->| 800 | |(F3) (SIP) 4xx/6xx | 801 | |<-------------------------| 802 |(F4) (XMPP) Stanza session decline | 803 |<-------------------------| | 805 Here the SIP UA declining an offer contained in an INVITE SHOULD 806 return a 4xx or a 6xx response, such as 406 Not Acceptable or 603 807 Decline. Such a response SHOULD include a Warning header field value 808 explaining why the offer was rejected. 810 Example: (F3) SIP user declines offer and specifies reason (SIP) 812 SIP/2.0 603 Decline 813 From: <sip:juliet@example.com>;tag=786 814 To: <sip:romeo@example.net>;tag=087js 815 Call-ID: 711609sa 816 Warning: I'm busy! 817 Content-Length: 0 819 Upon receiving the error response for the SIP INVITE, the XMPP-to-SIP 820 gateway shall send a "Session Reject" message back to the XMPP 821 Client. This message contains a data form that MUST contain the 822 FORM_TYPE field and the "accept" field set to "0" or "false". It is 823 RECOMENDED that the form does not contain any other field even if the 824 request indicated they are required. The client MAY include a reason 825 in the <body/> child of the <message/> stanza. The content of the 826 Warning header field present in the SIP response SHOULD be mapped to 827 a "reason" field in the data form. If the Warning header is not 828 present then the descriptive phrase of the SIP response can be used. 830 Example: (F4) SIP user declines offer and specifies reason (XMPP 831 translation) 833 <message from='romeo@example.net' 834 to='juliet@example.com' 835 type='normal'> 836 <thread>711609sa</thread> 837 <feature xmlns='http://jabber.org/protocol/feature-neg'> 838 <x xmlns='jabber:x:data' type='submit'> 839 <field var='FORM_TYPE'> 840 <value>urn:xmpp:ssn</value> 841 </field> 842 <field var='accept'> 843 <value>0</value> 844 </field> 845 <field var='reason'> 846 <value>I'm busy!</value> 847 </field> 848 </x> 849 </feature> 850 </message> 852 3. XMPP Informal Session to MSRP 854 In XMPP, the "informal session" approach is to simply send someone a 855 <message/> of type "chat" without starting any session negotiation 856 ahead of time (as described in [RFC6121]). The XMPP "informal 857 session" approach maps very well into a SIP MESSAGE request, as 858 described in [I-D.saintandre-sip-xmpp-core]. However, the XMPP 859 informal session approach can also be mapped to MSRP if the XMPP-to- 860 SIP gateway maintains additional state. 862 The order of events is as follows. 864 XMPP User GW SIP User 865 | | | 866 |(F1) (XMPP) Chat message | | 867 |------------------------->| | 868 | |(F2) (SIP) INVITE | 869 | |------------------------->| 870 | |(F3) (SIP) 200 OK | 871 | |<-------------------------| 872 | |(F4) (SIP) ACK | 873 | |------------------------->| 874 | |(F5) (MSRP) SEND | 875 | |------------------------->| 876 | |(F6) (MSRP) A reply | 877 | |<-------------------------| 878 |(F7) (XMPP) A reply | | 879 |<-------------------------| | 880 | | | 881 . . . 882 . . . 883 . . . 884 | | | 885 | |(F8) (SIP) BYE | 886 | |<-------------------------| 887 | |(F9) (SIP) 200 OK | 888 | |------------------------->| 889 | | | 891 First the XMPP user would generate an XMPP chat message. 893 Example: (F1) Juliet sends an XMPP message 895 <message from='juliet@example.com' 896 to='romeo@example.net' 897 type='chat'> 898 <thread>711609sa</thread> 899 <body>Art thou not Romeo, and a Montague?</body> 900 </message> 902 The local SIP-to-XMPP gateway at the SIMPLE server would then 903 determine if Romeo supports MSRP. If so, the SIP-to-XMPP gateway 904 would initiate an MSRP session with Romeo on Juliet's behalf. 906 Example: (F2) Gateway starts a formal session on behalf of Juliet 908 INVITE sip:romeo@example.net SIP/2.0 909 To: <sip:romeo@example.net> 910 From: <sip:juliet@example.com>;tag=786 911 Subject: Open chat with Juliet? 912 Call-ID: 711609sa 913 Content-Type: application/sdp 915 c=IN IP4 x2s.example.com 916 m=message 7654 TCP/MSRP * 917 a=accept-types:text/plain 918 a=lang:en 919 a=lang:it 920 a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 922 Here we assume that Romeo accepts the MSRP session request. 924 Example: (F3) Romeo accepts the request 926 SIP/2.0 200 OK 927 To: <sip:romeo@example.net>;tag=087js 928 From: <sip:juliet@example.com>;tag=786 929 Call-ID: 711609sa 930 Content-Type: application/sdp 932 c=IN IP4 s2x.example.net 933 m=message 12763 TCP/MSRP * 934 a=accept-types:text/plain 935 a=lang:it 936 a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 938 The XMPP-to-SIP gateway then acks the session acceptance on behalf of 939 Juliet. 941 Example: (F4) Gateway sends ACK to Romeo's UA 943 ACK sip:romeo@example.net SIP/2.0 944 To: <sip:romeo@example.net>;tag=087js 945 From: <sip:juliet@example.com>;tag=786 946 Call-ID: 711609sa 948 The XMPP-to-SIP gateway then transforms the original XMPP chat 949 message into MSRP. 951 Example: (F5) Gateway transforms XMPP message to MSRP 953 MSRP a786hjs2 SEND 954 From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 955 To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 956 Message-ID: 87652491 957 Byte-Range: 1-25/25 958 Content-Type: text/plain 960 Art thou not Romeo, and a Montague? 961 -------a786hjs2$ 963 Romeo can then send a reply using his MSRP user agent. 965 Example: (F6) Romeo sends a reply 967 MSRP a786hjs2 SEND 968 To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 969 From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp 970 Message-ID: 87652491 971 Byte-Range: 1-25/25 972 Failure-Report: no 973 Content-Type: text/plain 975 Neither, fair saint, if either thee dislike. 976 -------a786hjs2$ 978 Note: As previously described, if the users have not negotiated the 979 use message receipts, it is RECOMMENDED that the SIP-to-XMPP gateway 980 shall insert a Failure-Report header field value of "no" during the 981 creation of a SEND request. 983 The SIP-to-XMPP gateway would then transform that message into 984 appropriate XMPP syntax for routing to the intended recipient. 986 Example: (F7) Gateway transforms MSRP message to XMPP 988 <message from='romeo@example.net' 989 to='juliet@example.com' 990 type='chat'> 991 <thread>711609sa</thread> 992 <body>Neither, fair saint, if either thee dislike.</body> 993 </message> 995 When the MSRP user wishes to end the chat session, the user's MSRP 996 client sends a SIP BYE. 998 Example: (F8) Romeo terminates the chat session 1000 BYE juliet@example.com sip: SIP/2.0 1001 Max-Forwards: 70 1002 From: <sip:romeo@example.net>;tag=087js 1003 To: <sip:juliet@example.com>;tag=786 1004 Call-ID: 711609sa 1005 Cseq: 1 BYE 1006 Content-Length: 0 1008 The BYE is then acknowledged by the XMPP-to-SIP gateway. 1010 Example: (F9) Gateway acknowledges termination 1012 SIP/2.0 200 OK 1013 From: <sip:juliet@example.com>;tag=786 1014 To: <sip:romeo@example.net>;tag=087js 1015 Call-ID: 711609sa 1016 CSeq: 1 BYE 1017 Content-Length: 0 1019 4. MSRP to XMPP Formal Session 1021 Unlike the XMPP protocol, the MSRP protocol offers only one way to 1022 initiate a chat session, typically using the Session Description 1023 Protocol [RFC4566] via the SIP offer/answer mechanism (see 1024 [RFC3264]). 1026 The order of events is as follows. 1028 SIP User GW XMPP User 1029 | | | 1030 |(F1)(SIP) INVITE | | 1031 |------------------------>| | 1032 | |(F2)(XMPP) Stanza session request 1033 | |------------------------->| 1034 | |(F3)(XMPP) Stanza session acceptance 1035 | |<-------------------------| 1036 |(F4)(SIP) 200 OK | | 1037 |<------------------------| | 1038 |(F5)(SIP) ACK | | 1039 |------------------------>| | 1040 | |(F6)(XMPP) Stanza session completion 1041 | |------------------------->| 1042 |(F7)(MSRP) SEND | | 1043 |------------------------>| | 1044 | |(F8)(XMPP) A chat message | 1045 | |------------------------->| 1046 | |(F9)(XMPP) A reply | 1047 | |<-------------------------| 1048 |(F10)(MSRP) SEND | | 1049 |<------------------------| | 1050 | | | 1051 . . . 1052 . . . 1053 . . . 1054 | | | 1055 |(F11)(SIP) BYE | | 1056 |------------------------>| | 1057 | |(F12)(XMPP) Stanza session termination 1058 | |------------------------->| 1059 | |(F13)(XMPP) Termination acknowledgment 1060 | |<-------------------------| 1061 |(F14)(SIP) 200 OK | | 1062 |<------------------------| | 1064 4.1. Initiating a Session 1066 When Romeo wants to start an MSRP message session with Juliet, he 1067 first has to start the SIP session by sending out a SIP INVITE 1068 request containing an offered session description that includes an 1069 MSRP media line accompanied by a mandatory "path" attribute and 1070 corresponding URIs. The MSRP media line is also accompanied by an 1071 "accept-types" attribute used to specify the only media-types 1072 acceptable for Romeo (i.e., text/plain and/or text/html). 1074 Note: In addition to plain text messages, MSRP is able to carry 1075 arbitrary (binary) Multipurpose Internet Mail Extensions [RFC2045] 1076 compliant content, such as images or video clips. Disposition of 1077 media types other than text/plain and text/html is out of scope for 1078 this specification and is a matter of implementation. 1080 Example: (F1) SIP user starts the session 1082 INVITE sip:juliet@example.com SIP/2.0 1083 To: <sip:juliet@example.com> 1084 From: <sip:romeo@example.net>;tag=576 1085 Subject: Open chat with Romeo? 1086 Call-ID: 742507no 1087 Content-Type: application/sdp 1089 c=IN IP4 s2x.example.net 1090 m=message 7313 TCP/MSRP * 1091 a=accept-types:text/plain 1092 a=lang:en 1093 a=lang:it 1094 a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 1096 Upon receiving the INVITE, the SIP-to-XMPP gateway needs to determine 1097 the identity of the remote domain, which it does by performing one or 1098 more DNS SRV lookups [RFC2782]. The SIP-to-XMPP gateway SHOULD 1099 resolve the address present in the To header of the INVITE to an im 1100 URI, then follow the rules in [RFC3861] regarding the "_im" SRV 1101 service for the target domain contained in the To header. If SRV 1102 address resolution fails for the "_im" service, the SIP-to-XMPP 1103 gateway MAY attempt a lookup for the "_xmpp-server" service as 1104 specified in [RFC6120] or MAY return an error to the sender (i.e. 502 1105 Bad Gateway). 1107 If SRV address resolution succeeds, the SIP-to-XMPP gateway is 1108 responsible for translating the request into an XMPP message stanza 1109 to initiate a negotiated session from the SIP user to the XMPP user. 1111 Example: (F2) SIP user starts the session (XMPP transformation) 1113 <message from='romeo@example.net' 1114 to='juliet@example.com' 1115 type='normal'> 1116 <thread>742507no</thread> 1117 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1118 <x xmlns='jabber:x:data' type='form'> 1119 <title>Open chat with Romeo? 1120 1121 urn:xmpp:ssn 1122 1123 1124 true 1125 1126 1127 1130 en 1131 1132 1133 1134 1135 1136 1138 The mapping of SIP and SDP syntax elements to XMPP syntax elements 1139 SHOULD be as shown in the following table. (Mappings for elements 1140 not mentioned in the foregoing table are undefined.) 1142 Table 3: Message syntax mapping from SIP to XMPP 1144 +-----------------------------+-----------------------------+ 1145 | SIP Header or SDP Contents | XMPP Element or Attribute | 1146 +-----------------------------+-----------------------------+ 1147 | Call-ID | | 1148 | From | from | 1149 | To | to | 1150 | Subject | | 1151 | accept-types | - | 1152 | a=lang | xml:lang | 1153 | To | to | 1154 +-----------------------------+-----------------------------+ 1156 See previous note regarding negotiation and use of the XHTML-IM 1157 integration set for XHTML-formatted messages (i.e., the "text/html" 1158 accept-type). 1160 4.2. Accepting a Session 1162 If the request is accepted then Juliet's client MUST include all the 1163 fields that were marked as required in the request message. 1165 In the example below, we assume that Juliet accepts the session and 1166 specifies that she prefers to speak Italian with Romeo. 1168 Example: (F3) Juliet accepts session and specifies parameters 1170 <message from='juliet@example.com' 1171 to='romeo@example.net' 1172 type='normal'> 1173 <thread>742507no</thread> 1174 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1175 <x xmlns='jabber:x:data' type='submit'> 1176 <field var='FORM_TYPE'> 1177 <value>urn:xmpp:ssn</value> 1178 </field> 1179 <field var='accept'><value>true</value></field> 1180 <field var='language'><value>it</value></field> 1181 </x> 1182 </feature> 1183 </message> 1185 Upon receiving such a response, the SIP-to-XMPP gateway SHOULD 1186 remember that this is a response to a stanza related to an SIP-XMPP 1187 translation, based on the SIP Call-ID. The SIP-to-XMPP gateway is 1188 responsible for translating the response into a SIP response and 1189 delivering it from the XMPP user back to the SIP user. 1191 Example: (F4) Juliet accepts session (SIP translation) 1193 SIP/2.0 200 OK 1194 To: <sip:juliet@example.com>;tag=534 1195 From: <sip:romeo@example.net>;tag=576 1196 Call-ID: 742507no 1197 Content-Type: application/sdp 1199 c=IN IP4 x2s.example.com 1200 m=message 8763 TCP/MSRP * 1201 a=accept-types:text/plain 1202 a=lang:it 1203 a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1205 4.3. Completing the Transaction 1207 In this case, the 200 OK is routed back and is received by Romeo's 1208 UA. Finally, Romeo's client sends an acknowledgment message, ACK, to 1209 Juliet's client to confirm the reception of the final response (200 1210 OK). 1212 Example: (F5) Romeo sends ACK 1214 ACK sip:juliet@example.com SIP/2.0 1215 To: <sip:juliet@example.com>;tag=534 1216 From: <sip:romeo@example.net>;tag=576 1217 Call-ID: 742507no 1219 Upon receiving the ACK, the SIP-to-XMPP gateway SHOULD remember this 1220 is an acknowledgment to an XMPP formal session. The SIP-to-XMPP 1221 gateway is responsible for translating the acknowledgment into a 1222 confirmation stanza, without inserting other content (e.g. a <body/> 1223 element cannot be inserted). 1225 Example: (F6) Romeo sends ACK (XMPP translation) 1227 <message from='romeo@example.net' 1228 to='juliet@example.com' 1229 type='normal'> 1230 <thread>742507no</thread> 1231 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1232 <x xmlns='jabber:x:data' type='result'> 1233 <field var='FORM_TYPE'> 1234 <value>urn:xmpp:ssn</value> 1235 </field> 1236 <field var='accept'> 1237 <value>true</value> 1238 </field> 1239 </x> 1240 </feature> 1241 </message> 1243 4.4. Exchanging Messages 1245 When Romeo wants to send a message, he creates an MSRP SEND request 1246 that contains the message. 1248 Example: (F7) Romeo sends a message 1250 MSRP ad49kswow SEND 1251 To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1252 From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1253 Message-ID: 44921zaqwsx 1254 Byte-Range: 1-32/32 1255 Failure-Report: no 1256 Content-Type: text/plain 1258 I take thee at thy word ... 1259 -------ad49kswow$ 1261 Upon receiving the MSRP SEND request, the SIP-to-XMPP gateway SHOULD 1262 remember that the message is for an XMPP user. The SIP-to-XMPP 1263 gateway is responsible for translating the MSRP SEND request into an 1264 XMPP message stanza. 1266 Example: (F8) Romeo sends a message (XMPP translation) 1268 <message from='romeo@example.net' 1269 to='juliet@example.com' 1270 type='chat'> 1271 <thread>742507no</thread> 1272 <body>I take thee at thy word ...</body> 1273 </message> 1275 The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be 1276 as shown in the following table. (Mappings for elements not 1277 mentioned are undefined.) 1279 Table 4: Message syntax mapping from MSRP Message to XMPP 1281 +-----------------------------+-----------------------------+ 1282 | MSRP Header | XMPP Element or Attribute | 1283 +-----------------------------+-----------------------------+ 1284 | To-Path | to | 1285 | From-Path | from | 1286 | body of the SEND request | <body/> | 1287 | Content-Type: text/plain | - | 1288 | Message-ID | id | 1289 +-----------------------------+-----------------------------+ 1291 Upon receiving the chat message, Juliet can send a reply. 1293 Example: (F9) Juliet sends a reply 1295 <message from='juliet@example.com' 1296 to='romeo@example.net' 1297 type='chat'> 1298 <thread>711609sa</thread> 1299 <body>What man art thou ...?</body> 1300 </message> 1302 Example: (F10) Gateway transforms XMPP message to MSRP 1304 MSRP a786hjs2 SEND 1305 From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1306 To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 1307 Message-ID: 87652491 1308 Byte-Range: 1-25/25 1309 Failure-Report: no 1310 Content-Type: text/plain 1312 What man art thou ...? 1313 -------a786hjs2$ 1315 4.5. Terminating a Session 1317 When Romeo wants to terminate the session, he is required to send a 1318 SIP BYE request. 1320 Example: (F11) Romeo terminates the session 1322 BYE juliet@example.com sip: SIP/2.0 1323 Max-Forwards: 70 1324 From: <sip:romeo@example.net>;tag=576 1325 To: <sip:juliet@example.com>;tag=534 1326 Call-ID: 742507no 1327 Cseq: 1 BYE 1328 Content-Length: 0 1330 Upon receiving the SIP BYE request, the XMPP-to-SIP gateway SHOULD 1331 translate the request to a <message/> stanza containing a data form 1332 of type "submit". The <message/> element MUST contain a <thread/> 1333 element with the same XML character data as the original initiation 1334 request. The data form containing a boolean field named "terminate" 1335 should be set to a value of "1" or "true". 1337 Example: (F12) Romeo terminates the session (XMPP translation) 1339 <message from='romeo@example.net' 1340 to='juliet@example.com' 1341 type='normal'> 1342 <thread>742507no</thread> 1343 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1344 <x xmlns='jabber:x:data' type='submit'> 1345 <field var='FORM_TYPE'> 1346 <value>urn:xmpp:ssn</value> 1347 </field> 1348 <field var='terminate'> 1349 <value>1</value> 1350 </field> 1351 </x> 1352 </feature> 1353 </message> 1355 Juliet explicitly acknowledges the termination of the chat session on 1356 the XMPP side by sending a <message/> containing a data form of type 1357 "result", and the value of the "terminate" field set to "1" or 1358 "true". The client MUST mirror the <thread/> value it received. 1360 Example: (F13) Juliet acknowledges the termination of the session 1362 <message from='juliet@example.com' 1363 to='romeo@example.net' 1364 type='normal'> 1365 <thread>742507no</thread> 1366 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1367 <x xmlns='jabber:x:data' type='result'> 1368 <field var='FORM_TYPE'> 1369 <value>urn:xmpp:ssn</value> 1370 </field> 1371 <field var='terminate'> 1372 <value>1</value> 1373 </field> 1374 </x> 1375 </feature> 1376 </message> 1378 Upon receiving the acknowledgment message, the XMPP-to-SIP gateway 1379 SHOULD translate it to a SIP answer 200 OK. 1381 Example: (F14) Juliet acknowledges the termination of the session 1382 (SIP translation) 1384 SIP/2.0 200 OK 1385 From: <sip:romeo@example.net>;tag=576 1386 To: <sip:juliet@example.com>;tag=534 1387 Call-ID: 742507no 1388 CSeq: 1 BYE 1390 4.6. Cancelling the Transaction 1392 SIP User GW XMPP User 1393 | | | 1394 |(F1)(SIP) INVITE | | 1395 |----------------------->| | 1396 | |(F2)(XMPP) Stanza session request 1397 | |------------------------->| 1398 |(F3)(SIP) CANCEL | | 1399 |----------------------->| | 1400 | |(F4)(XMPP) Stanza session termination 1401 | |------------------------->| 1402 | |(F5)(XMPP) Stanza acknowledgment 1403 | | session termination 1404 | |<-------------------------| 1405 |(F6)(SIP) 200 OK | | 1406 |<-----------------------| | 1408 A common scenario occurs when the SIP user issues an invitation to 1409 set up a chat session with an XMPP user and immediately after the SIP 1410 invitation is sent, the SIP user decides to cancel it. The SIP-to- 1411 XMPP gateway will receive the CANCEL request and using the Call-ID, 1412 To, From and CSeq (sequence number only) header field values as a 1413 guide, will issue an XMPP stanza session termination request to the 1414 XMPP user to cancel the XMPP formal session (assuming that it was 1415 already set up). Once the XMPP-to-SIP gateway receives an ACK stanza 1416 message for the session termination, the XMPP-to-SIP gateway will 1417 respond with a status of 200 (OK) back to the SIP user. It is 1418 important to note that if the SIP session transaction does not exist, 1419 the XMPP-to-SIP gateway will return a status of 481 (Transaction Does 1420 Not Exist) back to the SIP User. 1422 4.7. Rejecting the Transaction 1424 SIP User GW XMPP User 1425 | | | 1426 |(F1)(SIP) INVITE | | 1427 |-------------------------->| | 1428 | |(F2)(XMPP) Stanza session request 1429 | |------------------------->| 1430 | |(F3)(XMPP) Stanza session decline 1431 | |<-------------------------| 1432 |(F4)(SIP) 4xx/6xx | | 1433 |<--------------------------| | 1435 Another common scenario occurs when the XMPP UA is currently not 1436 willing or able to accept a formal session request. The XMPP UA 1437 SHOULD decline the invitation. The data form MUST contain the 1438 FORM_TYPE field and the "accept" field set to "0" or "false". It is 1439 RECOMMENDED that the form does not contain any other fields even if 1440 the request indicated they are required. 1442 Example: (F3) User declines offer 1444 <message from='juliet@example.com' 1445 to='romeo@example.net' 1446 type='normal'> 1447 <thread>742507no</thread> 1448 <feature xmlns='http://jabber.org/protocol/feature-neg'> 1449 <x xmlns='jabber:x:data' type='submit'> 1450 <field var='FORM_TYPE'> 1451 <value>urn:xmpp:ssn</value> 1452 </field> 1453 <field var='accept'><value>0</value></field> 1454 </x> 1455 </feature> 1456 </message> 1458 Upon receiving the declined response for the XMPP formal session 1459 request, the XMPP-to-SIP gateway SHOULD return a 4xx or a 6xx SIP 1460 response back to the SIP client. 1462 4.8. Session Negotiation Fails 1464 If the XMPP recipient of a formal session request does not support 1465 stanza session negotiation as specified in [XEP-0155], it will return 1466 an XMPP <service-unavailable/> stanza error. Upon receiving this 1467 error from the XMPP recipient, the XMPP-to-SIP gateway SHOULD return 1468 a 501 SIP response back to the SIP sender. 1470 5. MSRP to XMPP Informal Session 1472 When an MSRP client sends messages through a gateway to an XMPP 1473 client that does not support formal sessinos, the order of events is 1474 as follows. 1476 SIP User GW XMPP User 1477 | | | 1478 |(F1)(SIP) INVITE | | 1479 |------------------------>| | 1480 |(F2)(SIP) 200 OK | | 1481 |<------------------------| | 1482 |(F3)(SIP) ACK | | 1483 |------------------------>| | 1484 |(F4)(MSRP) SEND | | 1485 |------------------------>| | 1486 | |(F5)(XMPP) A chat message | 1487 | |------------------------->| 1488 | |(F6)(XMPP) A reply | 1489 | |<-------------------------| 1490 | | | 1491 |(F7)(MSRP) SEND | | 1492 |<------------------------| | 1493 | | | 1494 . . . 1495 . . . 1496 . . . 1497 | | | 1498 |(F8)(SIP) BYE | | 1499 |------------------------>| | 1500 |(F9)(SIP) 200 OK | | 1501 |<------------------------| | 1502 | | | 1504 Example: (F1) SIP user starts the session 1506 INVITE sip:juliet@example.com SIP/2.0 1507 To: <sip:juliet@example.com> 1508 From: <sip:romeo@example.net>;tag=576 1509 Subject: Open chat with Romeo? 1510 Call-ID: 742507no 1511 Content-Type: application/sdp 1513 c=IN IP4 s2x.example.net 1514 m=message 7313 TCP/MSRP * 1515 a=accept-types:text/plain 1516 a=lang:en 1517 a=lang:it 1518 a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 1520 Example: (F2) Gateway accepts session on Juliet's behalf 1522 SIP/2.0 200 OK 1523 To: <sip:juliet@example.com>;tag=534 1524 From: <sip:romeo@example.net>;tag=576 1525 Call-ID: 742507no 1526 Content-Type: application/sdp 1528 c=IN IP4 x2s.example.com 1529 m=message 8763 TCP/MSRP * 1530 a=accept-types:text/plain 1531 a=lang:it 1532 a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1534 Example: (F3) Romeo sends ACK 1536 ACK sip:juliet@example.com SIP/2.0 1537 To: <sip:juliet@example.com>;tag=534 1538 From: <sip:romeo@example.net>;tag=576 1539 Call-ID: 742507no 1540 Example: (F4) Romeo sends a message 1542 MSRP ad49kswow SEND 1543 To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1544 From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1545 Message-ID: 44921zaqwsx 1546 Byte-Range: 1-32/32 1547 Failure-Report: no 1548 Content-Type: text/plain 1550 I take thee at thy word ... 1551 -------ad49kswow$ 1553 Example: (F5) Romeo sends a message (XMPP translation) 1555 <message from='romeo@example.net' 1556 to='juliet@example.com' 1557 type='chat'> 1558 <thread>742507no</thread> 1559 <body>I take thee at thy word ...</body> 1560 </message> 1562 Example: (F6) Juliet sends a reply 1564 <message from='juliet@example.com' 1565 to='romeo@example.net' 1566 type='chat'> 1567 <thread>711609sa</thread> 1568 <body>What man art thou ...?</body> 1569 </message> 1571 Example: (F8) Gateway transforms XMPP message to MSRP 1573 MSRP a786hjs2 SEND 1574 To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp 1575 From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1576 Message-ID: 87652491 1577 Byte-Range: 1-25/25 1578 Failure-Report: no 1579 Content-Type: text/plain 1581 What man art thou ...? 1582 -------a786hjs2$ 1583 Example: (F9) Romeo terminates the session 1585 BYE juliet@example.com sip: SIP/2.0 1586 Max-Forwards: 70 1587 From: <sip:romeo@example.net>;tag=576 1588 To: <sip:juliet@example.com>;tag=534 1589 Call-ID: 742507no 1590 Cseq: 1 BYE 1591 Content-Length: 0 1593 Example: (F10) Gateway acknowledges the termination of the session on 1594 behalf of XMPP user 1596 SIP/2.0 200 OK 1597 From: <sip:romeo@example.net>;tag=576 1598 To: <sip:juliet@example.com>;tag=534 1599 Call-ID: 742507no 1600 CSeq: 1 BYE 1602 6. Security Considerations 1604 To follow. 1606 7. IANA Considerations 1608 This document requests no actions of IANA. 1610 8. References 1612 8.1. Normative References 1614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1615 Requirement Levels", BCP 14, RFC 2119, March 1997. 1617 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1618 A., Peterson, J., Sparks, R., Handley, M., and E. 1619 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1620 June 2002. 1622 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1623 with Session Description Protocol (SDP)", RFC 3264, 1624 June 2002. 1626 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 1627 and Presence", RFC 3861, August 2004. 1629 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1630 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1632 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1633 Protocol (XMPP): Core", RFC 6120, March 2011. 1635 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1636 Protocol (XMPP): Instant Messaging and Presence", 1637 RFC 6121, March 2011. 1639 [XEP-0155] 1640 Paterson, I. and P. Saint-Andre, "Stanza Session 1641 Negotiation", XSF XEP 0155, January 2008. 1643 8.2. Informative References 1645 [I-D.saintandre-sip-xmpp-core] 1646 Saint-Andre, P., Houri, A., and J. Hildebrand, 1647 "Interworking between the Session Initiation Protocol 1648 (SIP) and the Extensible Messaging and Presence Protocol 1649 (XMPP): Core", draft-saintandre-sip-xmpp-core-02 (work in 1650 progress), October 2012. 1652 [I-D.saintandre-sip-xmpp-im] 1653 Saint-Andre, P., Houri, A., and J. Hildebrand, 1654 "Interworking between the Session Initiation Protocol 1655 (SIP) and the Extensible Messaging and Presence Protocol 1656 (XMPP): Instant Messaging", 1657 draft-saintandre-sip-xmpp-im-01 (work in progress), 1658 March 2009. 1660 [MSRP-MULTI] 1661 Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1662 party Instant Message (IM) Sessions Using the Message 1663 Session Relay Protocol (MSRP)", draft-ietf-simple-chat-16 1664 (work in progress), August 2012. 1666 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1667 Extensions (MIME) Part One: Format of Internet Message 1668 Bodies", RFC 2045, November 1996. 1670 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1671 specifying the location of services (DNS SRV)", RFC 2782, 1672 February 2000. 1674 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1675 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1676 for Instant Messaging", RFC 3428, December 2002. 1678 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1679 Description Protocol", RFC 4566, July 2006. 1681 [XEP-0030] 1682 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1683 Andre, "Service Discovery", XSF XEP 0030, June 2008. 1685 [XEP-0045] 1686 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 1687 April 2007. 1689 [XEP-0071] 1690 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, August 2007. 1692 [XEP-0115] 1693 Hildebrand, J., Saint-Andre, P., Troncon, R., and J. 1694 Konieczny, "Entity Capabilities", XSF XEP 0115, 1695 February 2008. 1697 [XEP-0124] 1698 Paterson, I., Smith, D., and P. Saint-Andre, 1699 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 1700 XEP 0124, October 2008. 1702 [XEP-0184] 1703 Saint-Andre, P. and J. Hildebrand, "Message Receipts", XSF 1704 XEP 0184, September 2007. 1706 [XEP-0206] 1707 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, 1708 October 2008. 1710 Authors' Addresses 1712 Peter Saint-Andre 1713 Cisco Systems, Inc. 1714 1899 Wynkoop Street, Suite 600 1715 Denver, CO 80202 1716 USA 1718 Phone: +1-303-308-3282 1719 Email: psaintan@cisco.com 1720 Eddy Gavita 1721 Ericsson 1722 Decarie Boulevard 1723 Town of Mount Royal, Quebec 1724 Canada 1726 Email: eddy.gavita@ericsson.com 1728 Nazin Hossain 1729 Ericsson 1730 Decarie Boulevard 1731 Town of Mount Royal, Quebec 1732 Canada 1734 Email: Nazin.Hossain@ericsson.com 1736 Salvatore Loreto 1737 Ericsson 1738 Hirsalantie 11 1739 Jorvas 02420 1740 Finland 1742 Email: Salvatore.Loreto@ericsson.com