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: |
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: ;tag=087js
480 From: ;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 ).
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
507 711609sa
508
509
510
511 urn:xmpp:ssn
512
513 true
514 it
515
516
517
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: ;tag=087js
525 From: ;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
541 711609sa
542
543
544
545 urn:xmpp:ssn
546
547 true
548
549
550
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 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 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
603 711609sa
604 Art thou not Romeo, and a Montague?
605
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
650 711609sa
651 Neither, fair saint, if either thee dislike.
652
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 stanza to Romeo containing a data form of
664 type "submit". The stanza MUST contain a
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
674 711609sa
675
676
677
678 urn:xmpp:ssn
679
680
681 1
682
683
684
685
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: ;tag=786
697 To: ;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: ;tag=786
705 To: ;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 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 value it received.
716 Example: (F14) Romeo acknowledges termination (XMPP translation)
718
721 711609sa
722
723
724
725 urn:xmpp:ssn
726
727
728 1
729
730
731
732
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
766 711609sa
767
768
769
770 urn:xmpp:ssn
771
772
773 0
774
775
776
777
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: ;tag=786
814 To: ;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 child of the 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
836 711609sa
837
838
839
840 urn:xmpp:ssn
841
842
843 0
844
845
846 I'm busy!
847
848
849
850
852 3. XMPP Informal Session to MSRP
854 In XMPP, the "informal session" approach is to simply send someone a
855 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
898 711609sa
899 Art thou not Romeo, and a Montague?
900
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:
910 From: ;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: ;tag=087js
928 From: ;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: ;tag=087js
945 From: ;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
991 711609sa
992 Neither, fair saint, if either thee dislike.
993
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: ;tag=087js
1003 To: ;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: ;tag=786
1014 To: ;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:
1084 From: ;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
1116 742507no
1117
1118
1119 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
1173 742507no
1174
1175
1176
1177 urn:xmpp:ssn
1178
1179 true
1180 it
1181
1182
1183
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: ;tag=534
1195 From: ;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: ;tag=534
1216 From: ;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
1223 element cannot be inserted).
1225 Example: (F6) Romeo sends ACK (XMPP translation)
1227
1230 742507no
1231
1232
1233
1234 urn:xmpp:ssn
1235
1236
1237 true
1238
1239
1240
1241
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
1271 742507no
1272 I take thee at thy word ...
1273
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 | |
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
1298 711609sa
1299 What man art thou ...?
1300
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: ;tag=576
1325 To: ;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 stanza containing a data form
1332 of type "submit". The element MUST contain a
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
1342 742507no
1343
1344
1345
1346 urn:xmpp:ssn
1347
1348
1349 1
1350
1351
1352
1353
1355 Juliet explicitly acknowledges the termination of the chat session on
1356 the XMPP side by sending a 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 value it received.
1360 Example: (F13) Juliet acknowledges the termination of the session
1362
1365 742507no
1366
1367
1368
1369 urn:xmpp:ssn
1370
1371
1372 1
1373
1374
1375
1376
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: ;tag=576
1386 To: ;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
1447 742507no
1448
1449
1450
1451 urn:xmpp:ssn
1452
1453 0
1454
1455
1456
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 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:
1508 From: ;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: ;tag=534
1524 From: ;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: ;tag=534
1538 From: ;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
1558 742507no
1559 I take thee at thy word ...
1560
1562 Example: (F6) Juliet sends a reply
1564
1567 711609sa
1568 What man art thou ...?
1569
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: ;tag=576
1588 To: ;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: ;tag=576
1598 To: ;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