idnits 2.17.1 draft-veikkolainen-sip-voip-xmpp-im-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 537 has weird spacing: '...r field whe...' == Line 588 has weird spacing: '...r field whe...' -- The document date (July 10, 2009) is 5403 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3920' is defined on line 890, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2976 (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: A later version (-05) exists of draft-saintandre-sip-xmpp-core-01 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Veikkolainen 3 Internet-Draft M. Isomaki 4 Intended status: Standards Track Nokia 5 Expires: January 11, 2010 July 10, 2009 7 Guidelines and Protocol Extensions for Combining SIP Based Real-time 8 Media Sessions With XMPP Based Instant Messaging and Presence Service. 9 draft-veikkolainen-sip-voip-xmpp-im-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 11, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This memo defines guidelines and protocol extensions for combining 48 Session Initiation Protocol (SIP) based real-time media sessions with 49 Extensible Messaging and Presence Protocol (XMPP) based instant 50 messaging and presence services in a seamless manner. This is 51 accomplished by integration and protocol extension support in the 52 endpoints, without requiring any changes in the SIP or XMPP server 53 infrastructure. It is even possible that SIP and XMPP services are 54 offered by different service providers. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 60 3. Deployment scenarios and use cases . . . . . . . . . . . . . . 4 61 3.1. Deployment scenarios . . . . . . . . . . . . . . . . . . . 4 62 3.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Overview of operation . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Endpoints engaged in XMPP conversation adding a SIP 66 session . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Endpoints engaged in a SIP session adding an XMPP IM 68 conversation . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.3. Using XMPP presence for publishing and obtaining SIP 70 contact address, media capabilities and availability . . . 9 71 6. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Extensions to XMPP message stanza . . . . . . . . . . . . 9 73 6.1.1. The element . . . . . . . . . . . . . . 9 74 6.1.2. The element . . . . . . . . . . . . 10 75 6.2. Extensions to XMPP presence stanza . . . . . . . . . . . . 11 76 6.3. Extensions to SIP headers . . . . . . . . . . . . . . . . 11 77 6.3.1. SIP XMPP-Thread header . . . . . . . . . . . . . . . . 11 78 6.3.2. SIP XMPP-Contact header . . . . . . . . . . . . . . . 12 79 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Endpoint engaged in an IM session adds a voice/video 81 component to the conversation . . . . . . . . . . . . . . 14 82 7.2. Endpoint engaged in a SIP session adds an XMPP IM 83 conversation . . . . . . . . . . . . . . . . . . . . . . . 17 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 Currently most standards-based Voice over IP (VoIP) deployments use 95 Session Initiation Protocol (SIP). In addition to providing basic 96 voice service SIP has an extensive support for more advanced 97 telephony features including interworking with the traditional Public 98 Switched Telephone Network (PSTN). SIP is also gaining popularity in 99 the field of video communication. 101 At the same time, the Extensible Messaging and Presence Protocol 102 (XMPP) is enjoying widespread usage in instant messaging and presence 103 services. An interesting scenario arises when a SIP based voice and 104 video service is combined together with an XMPP based instant 105 messaging and presence service. 107 This memo describes how SIP based real-time sessions and XMPP based 108 IM and presence can be offered using existing server implementations. 109 This memo also presents a set of requirements and protocol extensions 110 for SIP User Agent and XMPP client implementations in order to offer 111 a seamless usage experience when using SIP based VoIP with XMPP based 112 instant messaging and presence. 114 Combining SIP based real-time services with XMPP based presence and 115 IM service can be accomplished in the endpoints; no support is needed 116 in the service infrastructure. It is even possible to achieve 117 seamless integration when SIP and XMPP services are offered by 118 different service providers. 120 The main issues that need to be addressed when offering such combined 121 services are identities and addressing. SIP and XMPP both use a 122 similar addressing scheme (based on "user@domain" structure) to 123 identify users and endpoints but there are some subtle differences as 124 well. We do not assume any algorithmic correlation or translation 125 between SIP and XMPP Universal Resource Identifiers (URI), even when 126 they identify the same user or endpoint. New protocol mechanisms are 127 needed to tie together communication contexts that are based on the 128 two protocols. 130 We do not discuss how protocol translation through a gateway could be 131 performed between the protocols; this is the subject of other work, 132 see for example [I-D.saintandre-sip-xmpp-core]. 134 We focus on one-to-one communication only. Multiparty use cases such 135 as combining SIP voice conference with XMPP IM group chat are beyond 136 the scope. 138 The document structure is as follows: Section 2 presents the document 139 conventions and definitions, Section 3 presents deployment scenarios 140 and use cases, Section 4 lists the requirements, Section 5 provides 141 an overview of the protocol operation, Section 6 provides the 142 definitions, and examples are presented in Section 7. 144 2. Conventions Used in This Document 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in BCP 14, RFC 2119 149 [RFC2119] and indicate requirement levels for compliant 150 implementations. 152 The following definitions are used in this memo: 154 Integrated endpoint is an implementation that combines the 155 functionality of SIP User Agent and XMPP client and can offer its 156 user a seamless user experience in the sense that a single UI and 157 contact information can be user for voice and video communication 158 using the SIP protocol as well as instant messaging and presence 159 sharing using XMPP. We assume an integrated endpoint is able to 160 support SIP and XMPP protocol extensions defined in this memo. 162 Separated endpoint refers to independent SIP User Agent and XMPP 163 client implementations that are not aware of each other if they 164 are used by the same user. The users use SIP UA for voice and 165 video, while using XMPP client for IM and presence. It is assumed 166 that a separated endpoint does not support any SIP or XMPP 167 protocol extensions defined in this memo. 169 3. Deployment scenarios and use cases 171 This section presents the assumptions we make about SIP and XMPP 172 deployments with respect to endpoints and server infrastructure. We 173 also enumerate the actual use cases that the combined service must 174 accommodate for. 176 3.1. Deployment scenarios 178 We assume that the server infrastructures for SIP and XMPP are 179 totally separated, thus no exchange of information is expected 180 between these. We do not even assume that SIP and XMPP services are 181 offered by the same service provider. This means that the user 182 identities can belong to two different domains. However, if the same 183 service provider offers both SIP and XMPP service, it is recommended 184 that the URIs sip:user@domain and xmpp:user@domain correspond to the 185 same user. 187 We assume that the user initially only knows the contact address of 188 the other user in one protocol space. The contact address for the 189 other protocol must be learned through this. 191 We consider only cases where two integrated endpoints interact. When 192 an integrated endpoint communicates with a separated endpoint, normal 193 SIP and XMPP procedures apply and no extensions defined in this memo 194 are used. 196 3.2. Use cases 198 o Two users who both use an integrated endpoint start an (XMPP) IM 199 conversation. After the exchange of initial messages, their UIs 200 show that the other party is capable of (SIP) voice and/or video 201 in addition to IM. Either user can at any point add voice and/or 202 video component to the conversation in such a way that it ends up 203 in the same endpoint and conversation context where the IM 204 exchange is already taking place. (Note that for this use case 205 the conversation initiator initially only needs to know the other 206 user's XMPP user id.) 208 o Two users who both use an integrated endpoint start a (SIP) voice 209 and/or video call. As the call is established, their UIs show 210 that the other party is capable for (XMPP) IM. Either user can at 211 any point add an IM component to the conversation in such a way 212 that it ends up in the same endpoint and conversation context 213 where the voice and/or video call is already taking place. (Note 214 that for this use case the caller initially only needs to know the 215 other user's SIP user id.) 217 It is possible to vary the two cases above so that one of the 218 users initiates a "multimedia call" to the other one, i.e. SIP 219 voice and/or video and XMPP IM are all active from the start. 220 Technically this happens according to the two-phased approach 221 above, and it invisible from the end-user. 223 o A user of an integrated endpoint is able to publish her SIP voice 224 and video related presence status as part of her XMPP presence. 225 The status includes information such as user's SIP contact address 226 (for the integrated endpoint), media capability and availability 227 and whether the user is currently on the phone. Another user of 228 an integrated endpoint can see the presence status (assuming she 229 is authorized for that) and based on that initiate calls. For 230 instance watcher's UI can now for certain show that the user on 231 her roster is capable of receiving multimedia calls. (Note that 232 the watcher initially only needs to know the other user's XMPP 233 user id.) 234 OPEN ISSUE: Is there a use case for discovering other user's XMPP 235 identity based on her SIP identity without needing to establish a 236 media session. SIP OPTIONS would be one possibility for that (as 237 we do not assume SIP presence support). 239 4. Requirements 241 This section presents the protocol requirements. 243 REQ-1: It must be possible for the sender of an XMPP message to 244 include its SIP contact information within the message. The 245 contact information must allow the recipient to establish the 246 SIP session such that the session is routed to the same 247 endpoint which is hosting the XMPP conversation. As 248 including the same information in every message would create 249 some overhead, it is desirable to be able to convey the 250 contact only once per IM conversation/thread. 252 REQ-2: It must be possible for the caller to convey in the SIP 253 session initiation information which allows the callee to 254 correlate the session with an ongoing XMPP conversation. 256 REQ-3: It must be possible for the SIP User Agent Client and User 257 Agent Server that establish a real-time media session to 258 exchange their XMPP contact information so that either 259 endpoint can at any time send XMPP messages to the other 260 endpoint. 262 REQ-4: It must be possible for the sender to convey in the XMPP 263 message information which allows the recipient to correlate 264 the message with an ongoing SIP session. 266 REQ-5: It must be possible to include SIP real-time media related 267 contact and status in XMPP presence information. The 268 information must contain at least SIP contact address to 269 identify a user or a user agent instance, media capabilities 270 and general availability status 272 OPEN ISSUE: Should we define requirements related to error or 273 corner cases here. For instance what happens to communication 274 attempts after the other party has closed the conversation 275 context, e.g. a correlated XMPP message that is sent after the 276 related SIP session is terminated. Or a SIP INVITE that appears 277 two days after the XMPP IM conversation was ended. 279 NOTE: There is also an implicit requirement that we must take 280 Session Border Controllers into account when defining how SIP User 281 Agents are able to identify an existing session between them in a 282 common manner. 284 5. Overview of operation 286 Both SIP and XMPP allow registration of multiple endpoints using the 287 same identifier, either a SIP AOR or XMPP Jabber ID (JID). When two 288 endpoints are engaged in an IM conversation, for example, and wish to 289 add a voice component to the communication, it has to be ensured that 290 the resulting SIP dialog is targeted to the same endpoint that is 291 running the IM conversation. Fortunately, both XMPP and SIP provide 292 a mechanism for this. 294 [I-D.ietf-sip-gruu] defines mechanisms for a SIP UA to obtain and use 295 a Globally Routable User Agent (UA) URI, or GRUU. A GRUU will route 296 a call to a specific UA instance. Unfortunately, not all SIP 297 registrars support the optional GRUU mechanism. In that case the SIP 298 UA has not other option but to use its AOR in place of GRUU. 300 In XMPP, a "full JID" consists of a name, domain and a resource 301 identifier in the form of . The resource 302 identifier can be used to identify a specific endpoint. 304 5.1. Endpoints engaged in XMPP conversation adding a SIP session 306 Bob Alice 307 | | 308 | IM session | 309 |<=====================>| 310 | | 311 | (F1) INVITE | 312 |---------------------->| 313 | | 314 | (F2) 200OK | 315 |<----------------------| 316 | | 317 | (F3) ACK | 318 |---------------------->| 319 | | 320 | RTP media | 321 |<=====================>| 322 | | 324 This case starts by one endpoint (Bob) sending a message stanza to 325 another (Alice). Bob includes a element in the message and 326 chooses a unique value for it. In his first message Bob also 327 includes his SIP URI in element, defined in 328 Section 6.1. If Bob has been able to obtain a GRUU from his 329 registrar, he populates the with that. Otherwise a 330 mere AOR is used. When Alice receives Bob's SIP URI Alice stores it 331 associated with the current . When responding to Bob's 332 messages Alice also includes a element and her SIP URI (GRUU 333 or AOR) in . Upon receiving Alice's first message Bob 334 stores Alice's SIP URI associated with the current . In 335 addition to containing a SIP URI, also conveys the 336 information whether an endpoint supports audio or video or both 337 medias. So, based on exchanged elements, both 338 endpoints now know each others SIP URIs and media capabilities. 340 The same value is used in all further messages by both 341 endpoints to keep track of the conversation. As long as the 342 value is unchanged, the element need not be repeated, 343 unless either endpoint's SIP GRUU changes for some reason. 345 When either party wants to extend the IM conversation by adding SIP 346 voice or video session, they address a SIP INVITE to the SIP URI 347 learned in . If the element contained a 348 GRUU, it ensures that the INVITE will be routed to the correct 349 endpoint. The caller populates an XMPP-Thread header, defined in 350 Section 6.3.1, in the INVITE with the value of . The callee 351 is thus able to correlate the SIP session to the IM conversation. 352 The callee replays XMPP-Thread in responses to INVITE to indicate 353 that the correlation was successful. 355 5.2. Endpoints engaged in a SIP session adding an XMPP IM conversation 357 In this case two endpoints first have a SIP voice or video session. 358 They exchange their full JIDs within the session establishment: the 359 caller (Bob) adds XMPP-Contact header, defined in Section 6.3.2, in 360 INVITE populating it with his full JID. XMPP-Contact also includes 361 an opaque end-to-end identifier for the session common to both 362 endpoints. The callee (Alice) stores this information as part of the 363 session state. In 200 OK response to INVITE Alice includes similar 364 XMPP-Contact header with her full JID, and replays the end-to-end 365 session identifier. Bob stores this information as part of his 366 session state. Both endpoints now know each others full JIDs and 367 have a common reference to the session. 369 OPEN ISSUE: Instead of defining XMPP-specific session identifier 370 we could use SIP call-id as is. However, there is a concern that 371 call-id may be changed by SBCs en route is thus might not be a 372 useful as a common reference for both User Agents. 374 [I-D.kaplan-sip-session-id] defines a Session-ID header that 375 potentially could also be used. 377 When either endpoint wants to send XMPP messages to each other, they 378 address them to the full JID learned from XMPP-Contact header. This 379 ensures that the messages reach the correct endpoint. In the very 380 first message the sender also includes element, 381 defined in Section 6.1, with the session identifier value learned 382 from XMPP-Contact. The recipient uses the value to correlate the 383 message with the SIP session and echoes it back the first message it 384 sends to indicate that the correlation was successful. 386 5.3. Using XMPP presence for publishing and obtaining SIP contact 387 address, media capabilities and availability 389 SIP related presence information is encoded in XMPP presence schema 390 as an extension. It includes endpoints SIP URI (preferably GRUU but 391 can be also AOR), media capabilities (audio, video), and availability 392 (open, closed, busy). Based on this information XMPP Presence 393 watcher is able to initiate SIP voice and video sessions. 395 6. Protocol extensions 397 In this section we define protocol extensions to meet the 398 requirements stated in the previous section. 400 6.1. Extensions to XMPP message stanza 402 The child elements of the message stanza can be extended with 403 elements from other namespaces. For the purposes of carrying a SIP 404 identifier in the message stanza, we define two new elements, the 405 element and element. 407 6.1.1. The element 409 The element, qualified by urn:xmpp:sip-contact 410 namespace, has one mandatory attribute, "target", which defines the 411 target's SIP URI. The format of the "target" attribute is an 412 absoluteURI defined in [RFC3261]. 414 When an endpoint initiates an XMPP IM conversation, and wants to 415 offer a possibility to later add a SIP real-time media session, it 416 MUST include a element as a child element in the first 417 the stanza it sends, and MUST add a element and 418 populate its value according to [RFC3921]. The endpoint MUST include 419 in the "target" attribute of the element the SIP URI it 420 wishes to be contacted at. If the endpoint is aware of its GRUU, it 421 SHOULD use that as the value in the target attribute; otherwise it 422 MAY use its AOR. 424 The endpoint receiving an XMPP stanza that includes 425 and elements MUST copy the element 426 value to the first stanza it sends back, as defined in 427 [RFC3921], and MUST include a element and set the 428 "target" attribute value to the SIP URI it wishes to be contacted at. 430 An endpoint MUST add its audio and video capabilities defined in 431 [RFC3840] to the contact address in the "target" attribute, and MUST 432 understand those capabilities if received from the other endpoint. 433 An endpoint MAY add other media capabilities. 435 When an endpoint receives a element in a 436 stanza, it MUST store the value of the target attribute, and use it 437 as the SIP URI in an INVITE request if the user of the endpoint would 438 like to add a SIP session to the IM conversation context 440 For example, a element carrying a SIP Globally Routable 441 Unique URI (GRUU) would be 443 447 6.1.2. The element 449 In order to indicate that an XMPP IM conversation is related to an 450 existing SIP session, we define a new element in the message stanza 451 called . The , qualified by the 452 urn:xmpp:sip-correlation namespace, has one mandatory attribute, 453 "value". 455 The endpoint sending the stanza MUST set the "value" 456 attribute to the value of the correlation-value parameter of the SIP 457 XMPP-Contact header, defined in Section 6.3.2. The XMPP-Contact 458 header is exchanged during the setup of the SIP session. 460 An endpoint receiving a stanza which includes a element MUST first compare the "from" attribute value of 462 the stanza to the XMPP JID in the contact-value of the 463 XMPP-Contact header of its active SIP sessions. If a matching SIP 464 session is found, the endpoint then MUST compare the "value" 465 attribute of the element to the correlation-value 466 of the XMPP-Contact header of that SIP session. If the "value" 467 attribute matches to correlation-value of an XMPP-Contact header, the 468 stanza is correlated to that SIP session. If the user 469 replies to the message, the values of the element and the 470 "value" attribute of the element in the first reply 471 MUST be the same as in the original message. This indicates that the 472 correlation was successful. The correlation is valid as long as the 473 messages are exchanged with the same value. 475 As an example, consider a case where a SIP session was set up, and 476 during that time one of the endpoints included a XMPP-Contact header 477 with the correlation-value parameter set to the value 'xyz123'. Now, 478 when the same endpoint wishes to add an XMPP IM session, it would add 479 a element in the message stanza carrying the same 480 value in the "value" attribute: 482 484 OPEN ISSUE: XML Schemas to be provided 486 6.2. Extensions to XMPP presence stanza 488 The XMPP presence stanza defined in [RFC3921] can be extended with 489 any properly-namespaced child element. We define a new optional 490 element called which, qualified by the urn:xmpp:contact 491 namespace, MAY appear as a child element in the presence stanza. 493 The contact element SHOULD be set to the SIP address (GRUU or AOR) 494 the endpoint wishes to be contacted at for further communication. 496 Exact syntax and XML Schema of the correlation element is TBD. 498 6.3. Extensions to SIP headers 500 6.3.1. SIP XMPP-Thread header 502 In order to indicate that the SIP dialog is related to an existing 503 XMPP messaging session, we define a new SIP header, called XMPP- 504 Thread. The XMPP-Thread contains information that can be used by the 505 terminating endpoint to correlate the SIP session establishment to an 506 existing XMPP conversation. 508 The endpoint sending a SIP INVITE request MUST include an XMPP-Thread 509 header, and set its value to the value of the element used 510 in the XMPP IM conversation. 512 The endpoint receiving a SIP INVITE which includes an XMPP-Thread 513 header acts as follows: 515 o it first compares the Contact header value with all SIP GRUUs from 516 elements in active XMPP IM conversations, and unless 517 a match is found, 519 o compares P-Asserted-Identity header value with all other SIP URIs 520 from elements in active XMPP IM conversations 522 o if a single match is found, the receiving endpoint MUST compare 523 the value of the XMPP-Thread element to the element 524 values of existing XMPP IM conversations the endpoint has active, 525 and 527 o if the value matches, the SIP INVITE is correlated to the IM 528 conversation. The endpoint MUST copy the XMPP-Thread header to 529 any of the 2xx series responses. 531 Figure 1 defines support of XMPP-Contact header in SIP requests and 532 responses, and extends Table 2 of [RFC3261]. MESSAGE, SUBCRIBE and 533 NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in 534 [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and 535 [RFC3903], respectively. 537 Header field where proxy ACK BYE CAN INV OPT REG MSG 538 ------------ ----- ----- --- --- --- --- --- --- --- 539 XMPP-Thread R - - - o - - - 540 XMPP-Thread 2xx - - - o - - - 542 SUB NOT REF INF UPD PRA PUB 543 --- --- --- --- --- --- --- 544 XMPP-Thread R - - - - - - - 545 XMPP-Thread 2xx - - - - - - - 547 Figure 1: XMPP-Thread header support 549 The syntax of the XMPP-Thread using augmented Backur-Naur Form (ABNF) 550 [RFC5234] is defined as follows: 552 XMPP-Thread = "XMPP-Thread" HCOLON thread-value 553 thread-value = token 554 ;defined in RFC3261 556 6.3.2. SIP XMPP-Contact header 558 The XMPP-Contact header is used to carry the XMPP JID and an opaque 559 token that can be used for correlation purposes. 561 When an endpoint initiates a SIP session, and wants to offer the 562 possibility to later add an XMPP IM conversation, it MUST include an 563 XMPP-Contact header in the initial SIP request. The contact-value of 564 the XMPP-Contact header MUST be set to the full XMPP JID the endpoint 565 wishes to be contacted at, and the correlation-value SHOULD be set to 566 the value of the Call-ID of the SIP session. If the Call-ID cannot 567 be used, the endpoint MUST select the correlation-value such that it 568 fulfills the same uniqueness requirements defined for Call-ID in 569 Section 8.1.1.4 of [RFC3261]. 571 An endpoint sending a 2xx series response to an INVITE that contains 572 XMPP-Contact header MUST include a XMPP-Contact header in the 573 response, MUST set the contact-value of the header to the full XMPP 574 JID the endpoint wishes to be contacted at, and MUST copy the 575 correlation-value from the INVITE to the 2xx response. 577 The endpoint receiving a SIP request or response with an XMPP-Contact 578 header, MUST store the value of the correlation-value as part of the 579 session state in order to be able to later correlate an XMPP IM 580 conversation with the SIP session. 582 Figure 2 defines support of XMPP-Contact header in SIP requests and 583 responses, and extends Table 2 of [RFC3261]. MESSAGE, SUBCRIBE and 584 NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in 585 [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and 586 [RFC3903], respectively. 588 Header field where proxy ACK BYE CAN INV OPT REG MSG 589 ------------ ----- ----- --- --- --- --- --- --- --- 590 XMPP-Contact R - - - o - - - 591 XMPP-Contact 2xx - - - o - - - 593 SUB NOT REF INF UPD PRA PUB 594 --- --- --- --- --- --- --- 595 XMPP-Contact R - - - - - - - 596 XMPP-Contact 2xx - - - o - - - 598 Figure 2: XMPP-Contact header field support 600 The syntax of the XMPP-Contact using augmented Backur-Naur Form 601 (ABNF) [RFC5234] is defined as follows: 603 XMPP-Contact = "XMPP-Contact" HCOLON contact-value SEMI correlation-value 604 contact-value = token 605 ;defined in RFC3261 606 correlation-value =token 607 7. Examples 609 7.1. Endpoint engaged in an IM session adds a voice/video component to 610 the conversation 612 Bob Alice 613 | | 614 | (F1) | 615 |---------------------->| 616 | | 617 | (F2) | 618 |<----------------------| 619 | | 620 | (F3) INVITE | 621 |---------------------->| 622 | | 623 | (F4) 200OK | 624 |<----------------------| 625 | | 626 | (F5) ACK | 627 |---------------------->| 628 | | 629 | RTP media | 630 |<=====================>| 631 | | 633 SIP voice session added to XMPP IM conversation 635 Bob and Alice are engaged in an XMPP IM session, when Bob would like 636 to add voice/video component to the discussion. 638 When Bob and Alice exchange message stanzas, they also include the 639 SIP address they would like to be contacted at. In this example, Bob 640 is aware of its GRUU, while Alice is merely aware of her SIP AOR. 641 Both include the SIP identifier in a contact element in the message 642 stanza. 644 649 Hi! 650 e0ffe42b28561960c6b12b944a092794b9683a38 652 656 658 (F1) Bob sends a message stanza to 659 Alice 661 In the above message, Bob includes his GRUU, and also the media 662 capabilities Bob is capable of handling (audio and video). 664 Alice sends back a message stanza containing her SIP contact 665 information. 667 672 Hello there! 673 e0ffe42b28561960c6b12b944a092794b9683a38 675 677 679 (F2) Alice sends a message stanza to 680 Bob 682 Bob then decides to add SIP voice call to the existing XMPP 683 conversation. He picks up Alice's contact information that Alice 684 sent to him in a message stanza, and issues a SIP INVITE request to 685 that URI. The XMPP-Thread carries the value of the element. 687 INVITE sip:alice@example.net SIP/2.0 688 Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100 689 Max-Forwards: 70 690 To: Alice 691 From: Bob ;tag=18593756298 692 Call-ID: a84b4c76e66710@ua-991.domain.com 693 CSeq: 314159 INVITE 694 XMPP-Thread:e0ffe42b28561960c6b12b944a092794b9683a38 695 Contact: 698 Content-Type: application/sdp 699 Content-Length: 142 701 (SDP not shown) 703 (F3) Bob sends a SIP INVITE to 704 Alice 706 Alice responds with 200 OK accepting the session invitation request. 707 Alice also includes the XMPP-Thread element to indicate that she has 708 received the thread and successfully correlated the session 709 invitation to the XMPP conversation. 711 SIP/2.0 200 OK 712 Via: SIP/2.0/UDP p1.example.com 713 ;branch=z9hG4bKnashds8;received=192.0.2.3 714 Via: SIP/2.0/UDP p1.domain.com 715 ;branch=z9hG4bKnashds8;received=192.0.2.2 716 Via: SIP/2.0/UDP ua-991.domain.com 717 ;branch=apo92hgb2k100;received=192.0.2.1 718 Max-Forwards: 70 719 To: Alice ;tag=c09hh1lsn 720 From: Bob ;tag=18593756298 721 Call-ID: a84b4c76e66710@ua-991.domain.com 722 CSeq: 314159 INVITE 723 XMPP-Thread:e0ffe42b28561960c6b12b944a092794b9683a38 724 Contact: 725 Content-Type: application/sdp 726 Content-Length: 131 728 (SDP not shown) 730 (F4) Alice accepts the session and sends a 200OK 731 to Bob 733 Bob then sends a ACK as per normal SIP procedures. 735 7.2. Endpoint engaged in a SIP session adds an XMPP IM conversation 737 Bob Alice 738 | | 739 | | 740 | (F1) INVITE | 741 |---------------------->| 742 | | 743 | (F2) 200OK | 744 |<----------------------| 745 | | 746 | (F3) ACK | 747 |---------------------->| 748 | | 749 | RTP media | 750 |<=====================>| 751 | | 752 | (F4) | 753 |---------------------->| 754 | | 755 | (F5) | 756 |<----------------------| 758 XMPP IM conversation added to SIP voice 759 session 761 Bob invites Alice to a SIP session. In the INVITE request, Bob 762 includes the XMPP-Contact header including his XMPP JID. 764 INVITE sip:alice@example.net SIP/2.0 765 Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100 766 Max-Forwards: 70 767 To: Alice 768 From: Bob ;tag=18593756298 769 Call-ID: a84b4c76e66710@ua-991.domain.com 770 CSeq: 314159 INVITE 771 XMPP-contact: 772 ;a84b4c76e66710@ua-991.domain.com 773 Contact: 776 Content-Type: application/sdp 777 Content-Length: 142 779 (SDP not shown) 780 (F1) Bob sends a SIP INVITE to 781 Alice 783 SIP/2.0 200 OK 784 Via: SIP/2.0/UDP p1.example.com 785 ;branch=z9hG4bKnashds8;received=192.0.2.3 786 Via: SIP/2.0/UDP p1.domain.com 787 ;branch=z9hG4bKnashds8;received=192.0.2.2 788 Via: SIP/2.0/UDP ua-991.domain.com 789 ;branch=apo92hgb2k100;received=192.0.2.1 790 Max-Forwards: 70 791 To: Alice ;tag=c09hh1lsn 792 From: Bob ;tag=18593756298 793 Call-ID: a84b4c76e66710@ua-991.domain.com 794 CSeq: 314159 INVITE 795 XMPP-Contact: 796 ;a84b4c76e66710@ua-991.domain.com 797 Contact: 798 Content-Type: application/sdp 799 Content-Length: 131 801 (SDP not shown) 803 (F2) Alice accepts the session and sends a 200OK 804 to Bob 806 811 Hi! 812 e0ffe42b28561960c6b12b944a092794b9683a38 813 814 816 (F4) Bob sends a message to 817 Alice 819 Alice sends back a message stanza copying the sip-correlation value 820 indicating the the correlation was successful. 822 827 Hello there! 828 e0ffe42b28561960c6b12b944a092794b9683a38 829 830 832 (F5) Alice sends a message stanza to 833 Bob 835 8. IANA Considerations 837 TBD 839 9. Security Considerations 841 The contact and correlation information is sensitive and we need to 842 prevent connection hijacking and impersonation. If the contact 843 information that is sent over one protocol is forged, the identity 844 verification mechanism in the other no longer help as an attacker is 845 able to assert the false identity. 847 10. Acknowledgments 849 TBD 851 11. References 853 11.1. Normative References 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 859 October 2000. 861 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 862 A., Peterson, J., Sparks, R., Handley, M., and E. 863 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 864 June 2002. 866 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 867 Provisional Responses in Session Initiation Protocol 868 (SIP)", RFC 3262, June 2002. 870 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 871 Event Notification", RFC 3265, June 2002. 873 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 874 UPDATE Method", RFC 3311, October 2002. 876 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 877 and D. Gurle, "Session Initiation Protocol (SIP) Extension 878 for Instant Messaging", RFC 3428, December 2002. 880 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 881 Method", RFC 3515, April 2003. 883 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 884 "Indicating User Agent Capabilities in the Session 885 Initiation Protocol (SIP)", RFC 3840, August 2004. 887 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 888 for Event State Publication", RFC 3903, October 2004. 890 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 891 Protocol (XMPP): Core", RFC 3920, October 2004. 893 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 894 Protocol (XMPP): Instant Messaging and Presence", 895 RFC 3921, October 2004. 897 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 898 Specifications: ABNF", STD 68, RFC 5234, January 2008. 900 11.2. Informative References 902 [I-D.ietf-sip-gruu] 903 Rosenberg, J., "Obtaining and Using Globally Routable User 904 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 905 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 906 October 2007. 908 [I-D.kaplan-sip-session-id] 909 Kaplan, H., "A Session Identifier for the Session 910 Initiation Protocol (SIP)", draft-kaplan-sip-session-id-02 911 (work in progress), March 2009. 913 [I-D.saintandre-sip-xmpp-core] 914 Saint-Andre, P., Houri, A., and J. Hildebrand, 915 "Interworking between the Session Initiation Protocol 916 (SIP) and the Extensible Messaging and Presence Protocol 917 (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in 918 progress), March 2009. 920 Authors' Addresses 922 Simo Veikkolainen 923 Nokia 924 P.O. Box 407 925 NOKIA GROUP, FI 00045 926 Finland 928 Phone: +358 50 486 4463 929 Email: simo.veikkolainen@nokia.com 931 Markus Isomaki 932 Nokia 933 P.O. Box 100 934 NOKIA GROUP, FI 00045 935 Finland 937 Phone: +358 50 522 5984 938 Email: markus.isomaki@nokia.com