idnits 2.17.1 draft-ivov-xmpp-cusax-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 date (April 04, 2013) is 4030 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-saintandre-impp-call-info-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Informational P. Saint-Andre 5 Expires: October 06, 2013 Cisco Systems, Inc. 6 E. Marocco 7 Telecom Italia 8 April 04, 2013 10 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP) 12 draft-ivov-xmpp-cusax-04 14 Abstract 16 This document describes suggested practices for combined use of the 17 Session Initiation Protocol (SIP) and the Extensible Messaging and 18 Presence Protocol (XMPP). Such practices aim to provide a single 19 fully featured real-time communication service by using complementary 20 subsets of features from each of the protocols. Typically such 21 subsets would include telephony capabilities from SIP and instant 22 messaging and presence capabilities from XMPP. This specification 23 does not define any new protocols or syntax for either SIP or XMPP. 24 However, implementing it may require modifying or at least 25 reconfiguring existing client and server-side software. Also, it is 26 not the purpose of this document to make recommendations as to 27 whether or not such combined use should be preferred to the 28 mechanisms provided natively by each protocol (for example, SIP's 29 SIMPLE or XMPP's Jingle). It merely aims to provide guidance to 30 those who are interested in such a combined use. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 06, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Multi-Party Interactions . . . . . . . . . . . . . . . . . . 8 70 5. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Informative References . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 80 implemented and deployed with different purposes: from its very start 81 SIP's primary goal has been to provide a means of conducting 82 "Internet telephone calls". XMPP on the other hand, has, from its 83 Jabber days, been mostly used for instant messaging and presence 84 [RFC6121], as well as related services such as groupchat rooms 85 [XEP-0045]. 87 For various reasons, these trends have continued through the years 88 even after each of the protocols had been equipped to provide the 89 features it was initially lacking: 91 o Today, in the context of the SIMPLE working group, the IETF has 92 defined a number of protocols and protocol extensions that not 93 only allow for SIP to be used for regular instant messaging and 94 presence but that also provide mechanisms for elaborated features 95 such as multi-user chats, server-stored contact lists, file 96 transfer and others. 98 o Similarly, the XMPP community and the XMPP Standards Foundation 99 have worked on defining a number of XMPP Extension Protocols 100 (XEPs) that provide XMPP implementations with the means of 101 establishing end-to-end sessions. These extensions are often 102 jointly referred to as Jingle and arguably their most popular use 103 case is audio and video calling. 105 Despite these advances, SIP remains the protocol of choice for 106 telephony-like services, especially in enterprises where users are 107 accustomed to features such as voice mail, call park, call queues, 108 conference bridges and many others that are rarely (if at all) 109 available in Jingle-based software. XMPP implementations, on the 110 other hand, greatly outnumber and outperform those available for 111 instant messaging and presence extensions developed in the SIMPLE WG, 112 such as MSRP [RFC4975] and XCAP [RFC4825]. 114 For these reasons, in a number of cases adopters have found 115 themselves needing a set of features that are not offered by any 116 single-protocol solution but that separately exist in SIP and XMPP 117 products. The idea of seamlessly using both protocols together would 118 hence often appeal to service providers. 120 Most often the combined use of SIP and XMPP ("CUSAX") would employ 121 SIP exclusively for audio, video, and telephony services and rely on 122 XMPP for anything else varying from chat, contact list management, 123 and presence to whiteboarding and exchanging files. 125 +------------+ +-------------+ 126 | SIP Server | | XMPP Server | 127 +------------+ +-------------+ 128 \ / 129 media \ / instant messaging, 130 signaling \ / presence, etc. 131 \ / 132 +--------------+ 133 | CUSAX Client | 134 +--------------+ 136 Figure 1: Division of Responsibilities 138 This document explains how such hybrid offerings can be achieved with 139 a minimum of modifications to existing software while providing an 140 optimal user experience. It tries to cover points such as server 141 discovery, determining a SIP AOR while using XMPP and determining an 142 XMPP Jabber Identifier ("JID") from incoming SIP requests. Most of 143 the text here pertains to client behavior but it also recommends 144 certain server-side configurations. 146 Note that this document is focused on coexistence of SIP and XMPP 147 functionality in end-user-oriented clients. By intent it does not 148 define methods for protocol-level mapping between SIP and XMPP, as 149 might be used within a server-side gateway between a SIP network and 150 an XMPP network (a separate series of documents has been produced 151 that defines such mappings). More generally, this document does not 152 describe service policies for inter-domain communication (often 153 called "federation") between service providers (e.g., how a service 154 provider that offers a combined SIP-XMPP service might communicate 155 with a SIP-only or XMPP-only service), nor does it describe the 156 reasons why a service provider might choose SIP or XMPP for various 157 features. 159 Finally, this document concentrates on use cases where the SIP 160 services and XMPP services are controlled by one and the same 161 provider. Since this document is of an informational nature, it is 162 not unreasonable for clients to apply some of the guidelines here 163 even in cases where there is no established relationship between the 164 SIP and the XMPP services (for example, it is reasonable for a client 165 to provide a way for its users to easily start a call to a phone 166 number recorded in a vCard). However, the exact set of rules to 167 follow in such cases is left to application developers. 169 2. Client Bootstrap 171 One of the main problems of using two distinct protocols when 172 providing one service is the impact on usability. Email services, 173 for example, have long been affected by the mixed use of SMTP for 174 outgoing mail and POP3 or IMAP for incoming mail, making it rather 175 complicated for inexperienced users to configure a mail client and 176 start using it with a new service. As a result, Internet service 177 providers often need to provide configuration instructions for 178 various mail clients. Client developers and communication device 179 manufacturers on the other hand often ship with a number of wizards 180 that enable users to easily set up a new account for a number of 181 popular email services. While this may improve the situation to some 182 extent, the user experience is still clearly sub-optimal. 184 While it should be possible for CUSAX users to manually configure 185 their separate SIP and XMPP accounts, dual-stack SIP/XMPP clients 186 ought to provide means of online provisioning. While the specifics 187 of such mechanisms are outside the scope of this specification, they 188 should make it possible for a service provider to remotely configure 189 the clients based on minimal user input (e.g., only a user ID and 190 password). 192 Because many of the features that a CUSAX client would privilege in 193 one protocol would also be available in the other, clients should 194 make it possible for such features to be disabled for a specific 195 account. In particular, it is suggested that clients allow for audio 196 and video calling features to be disabled for XMPP accounts, and that 197 instant messaging and presence features should also be made optional 198 for SIP accounts. 200 The main advantage of this approach is that clients would be able to 201 continue to function properly and use the complete feature set of 202 standalone SIP and XMPP accounts. 204 Once client bootstrap has completed, clients need to log in 205 independently to the SIP and XMPP accounts that make up the CUSAX 206 "service" and then maintain both these connections. In order to 207 improve user experience, when reporting connection status clients may 208 also wish to present the XMPP CUSAX connection as an "instant 209 messaging" or a "chat" account. Similarly they could also depict the 210 SIP CUSAX connection as a "Voice and Video" or a "Telephony" 211 connection. The exact naming is of course entirely up to 212 implementers. The point is that, in cases where SIP and XMPP are 213 components of a service offered by a single provider, such 214 presentation could help users better understand why they are being 215 shown two different connections for what they perceive as a single 216 service. It could alleviate especially situations where one of these 217 connections is disrupted while the other one is still active. 219 3. Operation 221 Once a CUSAX client has been provisioned/configured to connect to the 222 corresponding SIP and XMPP services it would proceed by retrieving 223 its XMPP roster. In order for CUSAX to function properly, XMPP 224 service administrators should make sure that at least one of the 225 vCard [RFC6350] "tel" fields for each contact is properly populated 226 with a SIP URI or a phone number when an XMPP protocol for vCard 227 storage is used (e.g., [XEP-0054] or [XEP-0292]). There are no 228 limitations as to the form of that number. For example while it is 229 desirable to maintain a certain consistency between SIP AORs and XMPP 230 JIDs, that is by no means required. It is quite important however 231 that the phone number or SIP AOR stored in the vCard be reachable 232 through the SIP aspect of this CUSAX service. 234 Additionally, clients that have separete triggers (buttons) for audio 235 and video calls may choose to use the presence or absence of the 236 "video" tel type defined in [RFC6350] and enable or disable the 237 possibility for starting video calls accordingly. 239 To ensure that the foregoing approach is always respected, service 240 providers might consider (1) preventing clients (and hence users) 241 from modifying the vCard "tel" fields or (2) applying some form of 242 validation before storing changes. Of course such validation would 243 be feasible mostly in cases where a single provider controls both the 244 XMPP and the SIP service since such providers would "know" (e.g., 245 based on use of a common user database for both services) what SIP 246 AOR corresponds to a given XMPP user. 248 +--------------+ 249 | Provisioning |-----------+ 250 | Server | | 251 +--------------+ v 252 | +----------------+ 253 | | vCard Storage/ | 254 | | User Directory | 255 | +----------------+ 256 | / \ 257 | +------------+ +-------------+ 258 | | SIP Server | | XMPP Server | 259 | +------------+ +-------------+ 260 | \ / 261 | media \ / instant messaging, 262 | signaling \ / presence, etc. 263 | \ / 264 | +--------------+ 265 +---------------| CUSAX Client | 266 +--------------+ 268 Figure 2: Example Deployment 270 When rendering the roster for a particular XMPP account CUSAX clients 271 should make sure that users are presented with a "Call" option for 272 each roster entry that has a properly set "tel" field even if calling 273 has been disabled for that particular XMPP account. The usefulness 274 of such a feature is not limited to CUSAX. After all, numbers are 275 entered in vCards in order to be dialed and called. Hence, as long 276 as an XMPP client is equipped with accounts that have calling 277 features it may wish to present the user with the option of using 278 these accounts to reach numbers from an XMPP vCard. In order to 279 improve usability, in cases where clients are provisioned with only a 280 single telephony-capable account they ought to initiate calls 281 immediately upon user request without asking users to indicate an 282 account that the call should go through. This way CUSAX users (whose 283 only account with calling capabilities is usually the SIP part of 284 their service) would have a better experience, since from the user's 285 perspective calls "just work at the click of a button". 287 In order to provide a similar experience when the user has multiple 288 telephony-capable accounts, client implementers may choose to 289 indicate the existence of a special relationship between the SIP and 290 XMPP accounts of a CUSAX service. For example, let's say that 291 Alice's service provider has opened both an XMPP account and a SIP 292 account for her. During or after provisioning, her client could 293 indicate that alice@xmpp.example.com has a CUSAX relation to 294 alice@sip.example.com (i.e., that they are two aspects of the same 295 service). This way whenever Alice triggers a call to a contact in 296 her XMPP roster, the client would preferentially initiate this call 297 through her example.com SIP account even if other possibilities exist 298 (such as the XMPP account where the vCard was obtained or a SIP 299 account with another provider). 301 If, on the other hand, no relationship has been configured between 302 the SIP and XMPP accounts of a CUSAX service and the client is aware 303 of multiple telephony-capable accounts, it ought to present the user 304 with the choice of reaching the contact through any of those 305 accounts. This includes the source XMPP account where the vCard was 306 obtained (in case its telephony capabilities are not disabled through 307 configuration or provisioning), in order to guarantee proper 308 operation for XMPP accounts that are not part of a CUSAX deployment. 310 In addition to discovering phone numbers from vCards, clients may 311 also check for alternative communication methods as advertised in 312 XMPP presence broadcasts and Personal Eventing Protocol nodes as 313 described in XEP-0152: Reachability Addresses [XEP-0152]. 315 The client should use XMPP for all other forms of communication with 316 the contacts from its roster, which will occur naturally because they 317 were retrieved through XMPP and only audio/video features were 318 disabled in the XMPP stack. 320 When receiving SIP calls, clients may wish to determine the identity 321 of the caller and a corresponding XMPP roster entry so that users 322 could revert to chatting or other forms of communication that require 323 XMPP. To do so clients could search their roster for an entry whose 324 vCard has a "tel" field matching the originator of the call. 326 In addition, in order to avoid the effort of iterating over an entire 327 roster and retrieving all vCards, CUSAX clients may use a SIP Call- 328 Info header whose 'purpose' token field parameter has a value of 329 "impp" as described in [I-D.saintandre-impp-call-info] such as the 330 following: 332 Call-Info: ;purpose=impp 333 Note that the information from the Call-Info header should only be 334 used as a cue: the actual AOR-to-JID binding would still need to be 335 confirmed by a vCard entry. If this confirmation succeeds the client 336 would not need to search the entire roster and retrieve all vCards. 337 Not performing the check would allow any caller (including malicious 338 ones) to employ someone else's identity and perform various scams or 339 Man-in-the-Middle attacks. 341 4. Multi-Party Interactions 343 This document concentrates on problems related to one-to-one 344 communication. While it is possible for clients and other 345 specifications to build upon this and provide suggestions for 346 improving the Unified Communications user experience in cases of 347 multi-user chats in conference calling (e.g., ways of mapping XMPP 348 Multi-User Chatrooms to conference calls and vice versa), such 349 mechanisms are considered out of scope for this version of CUSAX. 351 5. Federation 353 In theory there are no technical reasons why federation would require 354 special behaviour from CUSAX clients. However, it is worth noting 355 that differences in administration policies may sometimes lead to 356 potentially confusing user experiences. 358 For example, let's say atlanta.example.com observes the CUSAX 359 policies described in this specification. All XMPP users at 360 atlanta.example.com are hence configured to have vCards that match 361 their SIP identities. Alice is therefore used to making free, high- 362 quality SIP calls to all the people in her roster. Alice can also 363 make calls to the PSTN by simply dialing numbers. She may even be 364 used to these calls being billed to her online account so she would 365 careful about how long they last. This is not a problem for her 366 since she can easily distinguish between a free SIP call (one that 367 she made by calling one her roster entries) from a paid PSTN call 368 that she dialed as a number. 370 Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only 371 has an XMPP service. There is no SIP server and Bob uses a regular, 372 XMPP-only client. Bob has however added his mobile number to his 373 vCard in order to make it easily accessible to his contacts. Alice's 374 client would pick up this number and make it possible for Alice to 375 start a call to Bob's mobile phone number. 377 This could be a problem because, other than the fact that Bob's 378 address is from a different domain, Alice would have no obvious and 379 straightforward cues telling her that this is in fact a call to the 380 PSTN. In addition to the potentially lower audio quality, Alice may 381 also end up incurring unexpected charges for such calls. 383 In order to avoid such issues, providers maintaining a CUSAX service 384 for the users in their domain may choose to provide additional cues 385 (e.g., a user interface warning or an an audio tone or message) 386 indicating that a call would incur charges. 388 A slightly less disturbing scenario, where a SIP service might only 389 allow communication with intra-domain numbers, would simply prevent 390 Alice from establishing a call with Bob's mobile. Providers should 391 hence make sure that calls to extra-domain numbers are flagged with 392 an appropriate audio or textual warning. 394 6. Security Considerations 396 Use of the same user agent with two different accounts providing 397 complementary features introduces the possibility of mismatches 398 between the security profiles of those accounts or features. For 399 example, the SIP aspect and XMPP aspect of the CUSAX service might 400 offer different authentication options (e.g., digest authentication 401 for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] 402 for XMPP as specified in [RFC6120]). Similarly, a CUSAX client might 403 successfully negotiate Transport Layer Security (TLS) [RFC5246] when 404 connecting to the XMPP aspect of the service but not when connecting 405 to the SIP aspect. Such mismatches could introduce the possibility 406 of downgrade attacks. User agent developers and service providers 407 ought to ensure that such mismatches are avoided as much as possible. 409 Refer to the specifications for the relevant SIP and XMPP features 410 for detailed security considerations applying to each "stack" in a 411 CUSAX client. 413 7. IANA Considerations 415 This document has no actions for the IANA. 417 8. Informative References 419 [I-D.saintandre-impp-call-info] 420 Saint-Andre, P., "Instant Messaging and Presence Purpose 421 for the Call-Info Header in the Session Initiation 422 Protocol (SIP)", draft-saintandre-impp-call-info-00 (work 423 in progress), March 2013. 425 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 426 A., Peterson, J., Sparks, R., Handley, M., and E. 427 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 428 June 2002. 430 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 431 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 433 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 434 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 436 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 437 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 439 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 440 "Salted Challenge Response Authentication Mechanism 441 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 443 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 444 Protocol (XMPP): Core", RFC 6120, March 2011. 446 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 447 Protocol (XMPP): Instant Messaging and Presence", RFC 448 6121, March 2011. 450 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 451 August 2011. 453 [XEP-0045] 454 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 455 2012. 457 [XEP-0054] 458 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 460 [XEP-0152] 461 Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability 462 Addresses", XEP XEP-0152, February 2013. 464 [XEP-0292] 465 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 466 0292, October 2011. 468 Appendix A. Acknowledgements 470 This draft is inspired by the "SIXPAC" work of Markus Isomaki and 471 Simo Veikkolainen. Markus also provided various suggestions for 472 improving the document. 474 The authors would also like to thank the following persons for their 475 reviews and suggestions: Aaron M. Evans, Sebastien Couture, Olivier 476 Crete, Kevin Gallagher, Adrian Georgescu, Saul Ibarra Corretge, 477 Daniel Pocock, Travis Reitterd, and Gonzalo Salgueiro. 479 Authors' Addresses 481 Emil Ivov 482 Jitsi 483 Strasbourg 67000 484 France 486 Phone: +33-672-811-555 487 Email: emcho@jitsi.org 489 Peter Saint-Andre 490 Cisco Systems, Inc. 491 1899 Wynkoop Street, Suite 600 492 Denver, CO 80202 493 USA 495 Phone: +1-303-308-3282 496 Email: psaintan@cisco.com 498 Enrico Marocco 499 Telecom Italia 500 Via G. Reiss Romoli, 274 501 Turin 10148 502 Italy 504 Email: enrico.marocco@telecomitalia.it