idnits 2.17.1 draft-ivov-xmpp-cusax-09.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 (October 02, 2013) is 3858 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ivov-grouptextchat-purpose-03 -- 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: April 05, 2014 Cisco Systems, Inc. 6 E. Marocco 7 Telecom Italia 8 October 02, 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-09 14 Abstract 16 This document suggests some strategies for the combined use of the 17 Session Initiation Protocol (SIP) and the Extensible Messaging and 18 Presence Protocol (XMPP) both in user-oriented clients and in 19 deployed servers. Such strategies, which mainly consist of 20 configuration changes and minimal software modifications to existing 21 clients and servers, aim to provide a single, full-featured, real- 22 time communication service by using complementary subsets of features 23 from SIP and from XMPP. Typically such subsets consist of telephony 24 capabilities from SIP and instant messaging and presence capabilities 25 from XMPP. This document does not define any new protocols or syntax 26 for either SIP or XMPP, and by intent does not attempt to standardize 27 "best current practices". Instead, it merely aims to provide 28 practical guidance to those who are interested in the combined use of 29 SIP and XMPP for real-time communication. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 05, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Server-Side Setup . . . . . . . . . . . . . . . . . . . . 7 69 3.2. Service Management . . . . . . . . . . . . . . . . . . . 7 70 3.3. Client-Side Discovery and Usability . . . . . . . . . . . 8 71 3.4. Indicating a Relationship Between SIP and XMPP Accounts . 9 72 3.5. Matching Incoming SIP Calls to XMPP JIDs . . . . . . . . 10 73 4. Multi-Party Interactions . . . . . . . . . . . . . . . . . . 11 74 5. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. Summary of Suggested Strategies . . . . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 87 implemented and deployed with different purposes: from its very start 88 SIP's primary goal has been to provide a means of conducting 89 "Internet telephone calls". XMPP on the other hand, has, from its 90 Jabber days, been mostly used for instant messaging and presence 91 [RFC6121], as well as related services such as groupchat rooms 92 [XEP-0045]. 94 For various reasons, these trends have continued through the years 95 even after each of the protocols had been equipped to provide the 96 features it was initially lacking: 98 o In the context of the SIMPLE working group, the IETF has defined a 99 number of protocols and protocol extensions that not only allow 100 for SIP to be used for regular instant messaging and presence but 101 that also provide mechanisms for related features such as multi- 102 party chat, server-stored contact lists, and file transfer 103 [RFC6914]. 105 o Similarly, the XMPP community and the XMPP Standards Foundation 106 have worked on defining a number of XMPP Extension Protocols 107 (XEPs) that provide XMPP implementations with the means of 108 establishing end-to-end sessions. These extensions are often 109 jointly referred to as Jingle [XEP-0166] and arguably their most 110 popular use case is audio and video calling [XEP-0167]. 112 However, although SIP has been extended for messaging and presence 113 and XMPP has been extended for voice and video, the reality is that 114 SIP remains the protocol of choice for telephony-like services and 115 XMPP remains the protocol of choice for IM and presence services. As 116 a result, a number of adopters have found themselves needing features 117 that are not offered by any single-protocol solution, but that 118 separately exist in SIP and XMPP implementations. The idea of 119 seamlessly using both protocols together would hence often appeal to 120 service providers and users. Most often, such a service 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. Because these 124 services and clients involve the combined use of SIP and XMPP, we 125 label them "CUSAX" for short. 127 +------------+ +-------------+ 128 | SIP Server | | XMPP Server | 129 +------------+ +-------------+ 130 \ / 131 media \ / instant messaging, 132 signaling \ / presence, etc. 133 \ / 134 +--------------+ 135 | CUSAX Client | 136 +--------------+ 138 Figure 1: Division of Responsibilities 140 This document suggests different configuration options and minimal 141 modifications to existing software so that clients and servers can 142 offer these hybrid services while providing an optimal user 143 experience. It covers server discovery, determining a SIP Address of 144 Record (AOR) while using XMPP, and determining an XMPP Jabber 145 Identifier ("JID") from incoming SIP requests. Most of the text here 146 pertains to client behavior but we also suggest certain server-side 147 configurations and operational strategies. The document also 148 discusses significant security considerations that can arise when 149 offering a dual-protocol solution, and provides advice for avoiding 150 security mismatches that would result in degraded communications 151 security for end users. 153 Note that this document is focused on coexistence of SIP and XMPP 154 functionality in end-user-oriented clients. By intent it does not 155 define methods for protocol-level mapping between SIP and XMPP, as 156 might be used within a server-side gateway between a SIP network and 157 an XMPP network (a separate series of documents has been produced 158 that defines such mappings). More generally, this document does not 159 describe service policies for inter-domain communication (often 160 called "federation") between service providers (e.g., how a service 161 provider that offers a CUSAX service might communicate with a SIP- 162 only or XMPP-only service), nor does it describe the reasons why a 163 service provider might choose SIP or XMPP for various features. 165 This document concentrates on use cases where the SIP services and 166 XMPP services are controlled by one and the same provider, since that 167 assumption greatly simplifies both client implementation and server- 168 side deployment (e.g., a single service provider can enforce common 169 or coordinated policies across both the SIP and XMPP aspects of a 170 CUSAX service, which is not possible if a SIP service is offered by 171 one provider and an XMPP service is offered by another provider). 172 Since this document is of an informational nature, it is not 173 unreasonable for clients to apply some of the guidelines here even in 174 cases where there is no established relationship between the SIP and 175 the XMPP services (for example, it is reasonable for a client to 176 provide a way for its users to easily start a call to a phone number 177 or SIP URI found in a vCard or obtained from a user directory). 178 However, the strategies to pursue in such cases are left to 179 application developers. 181 This document makes a further simplifying assumption by discussing 182 only the use of a single client, not use of and coordination among 183 multiple endpoints controlled by the same user (e.g., user agents 184 running simultaneously on a laptop computer, tablet, and mobile 185 phone). Although user agents running on separate endpoints might 186 themselves be CUSAX clients or might engage in different aspects of 187 an interaction (e.g., a user might employ her mobile phone for audio 188 and her tablet for video and text chat), such usage complicates the 189 guidelines for developers of user agents and therefore is left as a 190 matter of implementation for now. 192 It is important to note that this document does not attempt to 193 standardize "best current practices" in the sense defined in the 194 Internet Standards Process [RFC2026]. Instead, it collects together 195 informational documentation about some strategies that might prove 196 helpful to those who implement and deploy combined SIP-XMPP software 197 and services. With sufficient use and appropriate modification to 198 incorporate the lessons of experience, these strategies might someday 199 form the basis for standardization of best current practices. 201 2. Client Bootstrap 203 One of the main problems of using two distinct protocols when 204 providing one service is the impact on usability. Email services, 205 for example, have long been affected by the mixed use of SMTP for 206 outgoing mail and POP3 or IMAP for incoming mail. Although standard 207 service discovery methods (such as the proper DNS records) make it 208 possible for a user agent to locate the right host(s) for connect 209 purposes, they do not provide the kind of detailed information that 210 is needed to actually configure the user agent for use with the 211 service. As a result, it is rather complicated for inexperienced 212 users to configure a mail client and start using it with a new 213 service, and as a result Internet service providers often need to 214 provide configuration instructions for various mail clients. Client 215 developers and communication device manufacturers on the other hand 216 often ship with a number of so-called "wizard" interfaces that enable 217 users to easily configure accounts with a number of popular email 218 services. Although this may improve the situation to some extent, 219 the user experience is still clearly sub-optimal. 221 While it should be possible for CUSAX users to manually configure 222 their separate SIP and XMPP accounts (often using "wizards"), service 223 providers offering CUSAX services to users of dual-stack SIP/XMPP 224 clients ought to provide methods for online provisioning, typically 225 by means of a web-based service at an HTTPS URL (naturally, single- 226 purpose SIP services or XMPP services could offer such methods as 227 well, but they can be especially helpful where the two aspects of the 228 CUSAX service need to have several configuration options in common). 230 Although the specifics of such mechanisms are outside the scope of 231 this document, they should make it possible for a service provider to 232 remotely configure the clients based on minimal user input (e.g., 233 only a user ID and password). As far as the authors are aware, no 234 open protocol for endpoint configuration is yet available and 235 adopted; however, application developers are encouraged to explore 236 the potential for future progress in this space (e.g., perhaps based 237 on technologies such as WebFinger [RFC7033]). 239 By default, when a CUSAX client is used in concert with SIP and XMPP 240 accounts that have a CUSAX relationship (see Section 3.4), the client 241 should disable audio and video calling over XMPP and disable instant 242 messaging and presence over SIP. (It is a matter of implementation 243 whether a CUSAX client allows a user to override these defaults in 244 various ways, e.g., by domain, by individual contact, or by device.) 245 The main advantage of this approach is that a client would employ the 246 most relevant features from both SIP and XMPP when used in the 247 context of a CUSAX service. Note that this default configuration 248 does not apply to standalone SIP accounts or XMPP accounts, for which 249 other settings are likely to be more appropriate (see Section 3.4 for 250 details). 252 Once a client has been provisioned, it needs to independently log 253 into the SIP account and XMPP account that make up the CUSAX 254 "service" and then maintain both connections. 256 In order to improve the user experience, when reporting connection 257 status a CUSAX client may wish to present the XMPP connection as an 258 "instant messaging" or a "chat" account and the SIP connection as a 259 "Voice and Video" or a "Telephony" connection. The exact naming is 260 of course entirely up to implementers. The point is that, in cases 261 where SIP and XMPP are components of a service offered by a single 262 provider, such presentation could help users better understand why 263 they are being shown two different connections for what they perceive 264 as a single service. It could alleviate especially situations where 265 one of these connections is disrupted while the other one is still 266 active. Alternatively, the developers of a CUSAX client or the 267 providers of a CUSAX service might decide to force a client to 268 completely disconnect unless both aspects are successfully connected. 270 Clients may also choose to delay their XMPP connection until they 271 have been successfully registered on SIP. This would help avoid the 272 situation where a user appears online to her contacts but calling the 273 user's client would fail because the user's client is still 274 connecting to the SIP aspect of the CUSAX service. 276 3. Operation 277 Once a CUSAX client has been provisioned and authorized to connect to 278 the corresponding SIP and XMPP services it would proceed by 279 retrieving its XMPP roster. 281 The client should use XMPP for most forms of communication with the 282 contacts from this roster, which will occur naturally because they 283 were retrieved through XMPP. Audio/video features however, would 284 typically be disabled in the XMPP stack, so media-related 285 communication based on these features (e.g., direct calls, 286 conferences, desktop streaming, etc.) would happen over SIP. The 287 rest of this section describes deployment, discovery, usability and 288 linking semantics that enable CUSAX clients to seamlessly use SIP for 289 these features. 291 3.1. Server-Side Setup 293 In order for CUSAX to function properly, XMPP service administrators 294 should make sure that at least one of the vCard [RFC6350] "tel" 295 fields for each contact is properly populated with a SIP URI for the 296 user's address at the SIP audio/video service provided by the CUSAX 297 server. There are no limitations as to the form of that number. For 298 example while it is desirable to maintain a certain consistency 299 between SIP AORs and XMPP JIDs, that is by no means required. It is 300 quite important however that the phone number or SIP AOR stored in 301 the vCard be reachable through the SIP aspect of this CUSAX service. 302 (The same considerations apply even if the directory storage format 303 is not vCard storage over XMPP as described by [XEP-0054] or 304 [XEP-0292].) 306 Administrators may also choose to include the "video" tel type 307 defined in [RFC6350] for accounts that would be capable of handling 308 video communication. 310 To ensure that the foregoing approach is always respected, service 311 providers might consider validating the values of vCard "tel" fields 312 before storing changes. Of course such validation would be feasible 313 only in cases where a single provider controls both the XMPP and the 314 SIP service since such providers would "know" (e.g., based on use of 315 a common user database for both services) what SIP AOR corresponds to 316 a given XMPP user. 318 3.2. Service Management 320 The task of operating and managing a standalone SIP service or XMPP 321 service is not always easy. Combining the two into a unified service 322 introduces additional challenges, including: 324 o The necessity of opening additional ports on the client side if 325 SIP functionality is added to an existing XMPP deployment or vice- 326 versa. 328 o The potential for important differences in security posture across 329 SIP and XMPP (e.g., SIP servers and XMPP servers might support 330 different TLS ciphersuites). 332 o The need for, ideally, a common authentication backend and other 333 infrastructure that is shared across the SIP and XMPP aspects of 334 the combined service. 336 o Coordinated monitoring and logging of the SIP and XMPP servers to 337 enable the correlation of incidents and the pinpointing of 338 problems. 340 o The difficulty of troubleshooting client-side issues, e.g. if the 341 client loses connectivity for XMPP but maintains its SIP 342 connection. 344 Although separation of functionality (SIP for media, XMPP for IM and 345 presence) can help to ease the operational burden to some extent, 346 service providers are urged to address the foregoing challenges and 347 similar issues when preparing to launch a CUSAX service. 349 Beyond the issues listed above, service providers might want to be 350 aware of more subtle operational issues that can arise. For example, 351 if a service provider uses different network operators for the SIP 352 service and the XMPP service, end-to-end connectivity might be more 353 reliable or consistent in one service than in the other service. 354 Similar issues can arise when the media path and the signaling path 355 go over different networks, even in standalone SIP or XMPP services. 356 Providers of CUSAX services are advised to consider the potential for 357 such topologies to cause operational challenges. 359 3.3. Client-Side Discovery and Usability 361 When rendering the roster for a particular XMPP account CUSAX clients 362 should make sure that users are presented with a "Call" option for 363 each roster entry that has a properly set "tel" field. This is the 364 case even if calling features have been disabled for that particular 365 XMPP account, as advised by this document. The usefulness of such a 366 feature is not limited to CUSAX. After all, numbers are entered in 367 vCards or stored in directories in order to be dialed and called. 368 Hence, as long as an XMPP client has any means of conducting a call 369 it may wish to make it possible for the user to easily dial any 370 numbers that it learned through whatever means. 372 Clients that have separate triggers (e.g., buttons) for audio calls 373 and video calls may choose to use the presence or absence of the 374 "video" tel type defined in [RFC6350] as the basis for choosing 375 whether to enable or disable the possibility for starting video calls 376 (i.e., if there is no "video" tel type for a particular contact, the 377 client could disable the "video call" button for that contact). 379 In addition to discovering phone numbers from vCards or user 380 directories, clients may also check for alternative communication 381 methods as advertised in XMPP presence broadcasts and Personal 382 Eventing Protocol nodes as described in XEP-0152: Reachability 383 Addresses [XEP-0152]. However, these indications are merely hints, 384 and a receiving client ought not associate a SIP address and an XMPP 385 address unless it has some way to verify the relationship (e.g., the 386 vCard of the XMPP account lists the SIP address and the vCard of the 387 SIP account lists the XMPP address, or the relationship is made 388 explicit in a record provided by a trusted directory). Alternatively 389 or in cases where vCard or directory data is not available, a CUSAX 390 client could take the user's own address book as the canonical source 391 for contact addresses. 393 3.4. Indicating a Relationship Between SIP and XMPP Accounts 395 In order to improve usability, in cases where clients are provisioned 396 with only a single telephony-capable account they ought to initiate 397 calls immediately upon user request without asking users to indicate 398 an account that the call should go through. This way CUSAX users 399 (whose only account with calling capabilities is usually the SIP part 400 of their service) would have a better experience, since from the 401 user's perspective calls "just work at the click of a button". 403 In some cases however, clients will be configured with more than the 404 two XMPP and SIP accounts provisioned by the CUSAX provider. Users 405 are likely to add additional stand-alone XMPP or SIP accounts (or 406 accounts for other communications protocols), any of which might have 407 both telephony and instant messaging capabilities. Such situations 408 can introduce additional ambiguity since all of the telephony-capable 409 accounts could be used for calling the numbers the client has learned 410 from vCards or directories. 412 To avoid such confusion, client implementers and CUSAX service 413 providers may choose to indicate the existence of a special 414 relationship between the SIP and XMPP accounts of a CUSAX service. 415 For example, let's say that Alice's service provider has opened both 416 an XMPP account and a SIP account for her. During or after 417 provisioning, her client could indicate that alice@xmpp.example.com 418 has a CUSAX relationship to alice@sip.example.com (i.e., that they 419 are two aspects of the same service). This way whenever Alice 420 triggers a call to a contact in her XMPP roster, the client would 421 preferentially initiate this call through her example.com SIP account 422 even if other possibilities exist (such as the XMPP account where the 423 vCard was obtained or a SIP account with another provider). 424 Similarly, the client would preferentially initiate textual chat 425 sessions using her XMPP account. 427 If, on the other hand, no relationship has been configured or 428 discovered between a SIP account and an XMPP account, and the client 429 is aware of multiple telephony-capable accounts, it ought to present 430 the user with the option of using XMPP Jingle as one method for 431 engaging in audio and video interactions with a contact who has an 432 XMPP address. This can help to ensure that a CUSAX user can complete 433 audio and video calls with XMPP users who are not part of a CUSAX 434 deployment. 436 3.5. Matching Incoming SIP Calls to XMPP JIDs 438 When receiving a SIP call, a CUSAX client may wish to determine the 439 identity of the caller and a corresponding XMPP roster entry so that 440 the receiving user could revert to chatting or other forms of 441 communication that require XMPP. To do so, a CUSAX client could 442 search the user's roster for an entry whose vCard has a "tel" field 443 matching the originator of the call. In addition, in order to avoid 444 the effort of iterating over the entire roster of the user and 445 retrieving vCards for all of the user's contacts, the receiving 446 client may guess at the identity of the caller based a SIP Call-Info 447 header whose 'purpose' header field parameter has a value of "impp" 448 as described in [RFC6993]. To enable this usage, a sending client 449 would need to include such a Call-Info header in the SIP messages 450 that it sends when initiating a call. An example follows. 452 Call-Info: ;purpose=impp 454 Note that the information from the Call-Info header should only be 455 used as a cue: the actual AOR-to-JID binding would still need to be 456 confirmed by the vCard of a contact in the receiving user's roster or 457 through some other trusted means (such as an enterprise directory). 458 If this confirmation succeeds the client would not need to search the 459 entire roster and retrieve all vCards. Not performing the check 460 might enable any caller (including malicious ones) to employ someone 461 else's identity and perform various scams or Man-in-the-Middle 462 attacks. 464 However, although an AOR-to-JID binding can be a helpful hint to the 465 user, nothing in the foregoing paragraph ought to be construed as 466 necessarily discouraging users, clients, or service providers from 467 accepting calls originated by entities that are not established 468 contacts of the user (e.g., as reflected in the user's roster); that 469 is a policy matter for the user, client, or service provider. 471 4. Multi-Party Interactions 473 CUSAX clients that support the SIP conferencing framework [RFC4353] 474 can detect when a call they are participating in is actually a 475 conference and can then subscribe to conference state updates as per 476 [RFC4575]. A regular SIP user agent might also use the same 477 conference URI for text communication with the Message Session Relay 478 Protocol (MSRP). However, given that SIP's instant messaging 479 capabilities would normally be disabled (or simply not supported) in 480 CUSAX deployments, an XMPP Multi-User Chat (MUC) room [XEP-0045] 481 associated with the conference can be announced/discovered through 482 bearing the "grouptextchat" purpose 483 [I-D.ivov-grouptextchat-purpose]. Similarly, an XMPP MUC room can 484 advertise the SIP URI of an associated service for audio/video 485 interactions using the 'audio-video-uri' field of the "muc#roominfo" 486 data form [XEP-0004] to include extended information [XEP-0128] about 487 the MUC room within XMPP service discovery [XEP-0030]; see [XEP-0045] 488 for an example. These methods would enable a CUSAX-aware SIP 489 conference server to advertise the existence of an associated XMPP 490 chatroom, and for a CUSAX-aware XMPP chatroom to advertise the 491 existence of an associated SIP conference server. 493 If a CUSAX client joins the MUC room associated with a particular 494 call, it should not rely on any synchronization between the two. 495 Both the SIP conference and the XMPP MUC room would function 496 independently, each issuing and delivering its own state updates. 497 Hence it is possible that that certain peers would temporarily or 498 permanently be reachable in only one of the two conferences. This 499 would typically be the case with single-stack clients that have only 500 joined the SIP call or the XMPP MUC room. It is therefore important 501 for CUSAX clients to provide a clear indication to users as to the 502 level of involvement of the various participants: i.e., a user needs 503 to be able to easily understand whether a certain participant can 504 receive text messages, audio/video, or both. 506 At the level of the CUSAX service, it is also possible to enforce 507 tighter integration between the XMPP MUC room and the SIP conference. 508 Permissions, roles, kicks and bans that are granted and performed in 509 the MUC room can easily be imitated by the conference focus/mixer 510 into the SIP call. If, for example, a certain MUC member is muted, 511 the conference mixer can choose to also apply the mute on the media 512 stream corresponding to that participant. However, the details and 513 exact level of such integration are entirely up to implementers and 514 service providers. 516 The approach above describes one relatively lightweight possibility 517 of combining SIP and XMPP multi-party interaction semantics without 518 requiring tight integration between the two. As with the rest of 519 this document, this approach is by no means normative. 520 Implementations and future documents may define other methods or 521 provide other suggestions for improving the unified communications 522 user experience in cases of multi-user chats and conference calling. 524 5. Federation 526 In theory there are no technical reasons why federation (i.e., inter- 527 domain communication) would require special behavior from CUSAX 528 clients. However, it is worth noting that differences in 529 administration policies may sometimes lead to potentially confusing 530 user experiences. 532 For example, let's say atlanta.example.com observes the CUSAX 533 policies described in this document. All XMPP users at 534 atlanta.example.com are hence configured to have vCards that match 535 their SIP identities. Alice is therefore used to making free, high- 536 quality SIP calls to all the people in her roster. Alice can also 537 make calls to the PSTN by simply dialing numbers. She may even be 538 used to these calls being billed to her online account so she would 539 be careful about how long they last. This is not a problem for her 540 since she can easily distinguish between a free SIP call (one that 541 she made by calling one her roster entries) from a paid PSTN call 542 that she dialed as a number. 544 Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only 545 has an XMPP service. There is no SIP server and Bob uses an XMPP- 546 only client. However, Bob has added his mobile number to his vCard 547 in order to make it easily accessible to his contacts. Alice's 548 client would pick up this number and make it possible for Alice to 549 start a call to Bob's mobile phone number. 551 This could be a problem because, other than the fact that Bob's 552 address is from a different domain, Alice would have no obvious and 553 straightforward cues telling her that this is in fact a call to the 554 PSTN. In addition to the potentially lower audio quality, Alice may 555 also end up incurring unexpected charges for such calls. 557 In order to avoid such issues, providers maintaining a CUSAX service 558 for the users in their domain may choose to provide additional cues 559 (e.g., a service-generated signal that triggers a user interface 560 warning in a CUSAX client, an auditory tone, or a spoken message) 561 indicating that a call would incur unexpected charges. 563 Another scenario arises when a SIP service allow communication only 564 with intra-domain numbers; here Alice might be prevented from 565 establishing a call with Bob's mobile phone. Providers should 566 therefore make sure that calls to inter-domain numbers are flagged 567 with an appropriate audio or textual warning. 569 6. Summary of Suggested Strategies 571 The following strategies are suggested for CUSAX user agents: 573 1. By default, prefer SIP for audio and video, and XMPP for 574 messaging and presence. 576 2. Use XMPP for all forms of communication with the contacts from 577 the XMPP roster, with the exception of features that are based 578 on establishing real-time sessions (e.g. audio/video calls), 579 for which SIP should be used. 581 3. Provide online provisioning options for providers to remotely 582 setup SIP and XMPP accounts so that users wouldn't need to go 583 through a multi-step configuration process. 585 4. Provide online provisioning options for providers to completely 586 disable features for an account associated with a given protocol 587 (SIP or XMPP) if the features are preferred in another protocol 588 (XMPP or SIP). 590 5. Present a "Call" option for each roster entry that has a 591 properly set "tel" field in the vCard or equivalent. 593 6. If the client is provisioned with only a single telephony- 594 capable account, initiate calls immediately upon user request 595 without asking users to indicate an account that the call should 596 go through. 598 7. If no relationship has been configured or discovered between a 599 SIP account and an XMPP account, and the client is aware of 600 multiple telephony-capable accounts, present the user with the 601 choice of reaching the contact through any of those accounts. 603 8. If known, indicate the existence of a special relationship 604 between the SIP and XMPP accounts of a CUSAX service. 606 9. Optionally, present the XMPP connection as an "instant 607 messaging" or a "chat" account and the SIP connection as a 608 "Voice and Video" or a "Telephony" acccount. 610 10. Optionally, determine the identity of the audio/video caller and 611 a corresponding XMPP roster entry so that the user could use 612 textual chatting or other forms of communication that require 613 XMPP. 615 11. Optionally, delay the XMPP connection until after a SIP 616 connection has been successfully registered. 618 12. Optionally, check for alternative communication methods (SIP 619 addresses advertised over XMPP, and XMPP addresses advertised 620 over SIP). 622 The following strategies are suggested for CUSAX services: 624 1. Use online provisioning and configuration of accounts so that 625 users won't need to setup two separate accounts for the CUSAX 626 service. 628 2. Use online provisioning so that calling features are disabled for 629 all XMPP accounts. 631 3. Ensure that at least one of the vCard "tel" fields for each XMPP 632 user is properly populated with a SIP URI that is reachable 633 through the SIP service. 635 4. Optionally, include the "video" tel type for accounts that are 636 capable of handling video communication. 638 5. Optionally, provision clients with information indicating that 639 specific SIP and XMPP accounts are related in a CUSAX service. 641 6. Optionally, attach a "Call-Info" header with an "impp" purpose to 642 all SIP INVITE messages, so that clients can more rapidly 643 associate a caller with a roster entry and display a "Caller ID". 645 7. IANA Considerations 647 This document has no actions for the IANA. 649 8. Security Considerations 651 Use of the same user agent with two different accounts providing 652 complementary features introduces the possibility of mismatches 653 between the security profiles of those accounts or features. Two 654 security mismatches of particular concern are: 656 o The SIP aspect and XMPP aspect of a CUSAX service might offer 657 different authentication options (e.g., digest authentication for 658 SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] 659 for XMPP as specified in [RFC6120]). Because SIP uses a password- 660 based method (digest) and XMPP uses a pluggable framework for 661 authentication via the Simple Authentication and Security Layer 662 (SASL) technology [RFC4422], it is also possible that the XMPP 663 connection could be authenticated using a password-free method 664 such as client certificates with SASL EXTERNAL even though a 665 username and password is used for the SIP connection. 667 o The Transport Layer Security (TLS) [RFC5246] ciphersuites offered 668 or negotiated on the XMPP side might be different from those on 669 the SIP side because of implementation or configuration 670 differences between the SIP server and the XMPP server. Even more 671 seriously, a CUSAX client might successfully negotiate TLS when 672 connecting to the XMPP aspect of the service but not when 673 connecting to the SIP aspect, or vice-versa. In this situation an 674 end user might think that the combined CUSAX session with the 675 service is protected by TLS, even though only one aspect is 676 protected. 678 Security mismatches such as these (as well as others related to end- 679 to-end encryption of messages or media) introduce the possibility of 680 downgrade attacks, eavesdropping, information leakage, and other 681 security vulnerabilities. User agent developers and service 682 providers must ensure that such mismatches are avoided as much as 683 possible (e.g., by enforcing common and strong security 684 configurations and policies across protocols). Specifically, if both 685 protocols are not safeguarded by similar levels of cryptographic 686 protection, the user must be informed of that fact and given the 687 opportunity to bring both up to the same level. 689 Section 5 discusses potential issues that may arise due to a mismatch 690 between client capabilities, such as calls being initiated with costs 691 that are not expected by the end user. Such issues could be 692 triggered maliciously, as well as by accident. Implementers 693 therefore need to provide necessary cues to raise user awareness as 694 suggested in Section 5. 696 Refer to the specifications for the relevant SIP and XMPP features 697 for detailed security considerations applying to each "stack" in a 698 CUSAX client. 700 9. References 702 9.1. Normative References 704 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 705 A., Peterson, J., Sparks, R., Handley, M., and E. 707 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 708 June 2002. 710 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 711 Protocol (XMPP): Core", RFC 6120, March 2011. 713 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 714 Protocol (XMPP): Instant Messaging and Presence", RFC 715 6121, March 2011. 717 9.2. Informative References 719 [I-D.ivov-grouptextchat-purpose] 720 Ivov, E., "A Group Text Chat Purpose for Conference and 721 Service URIs in the Session Initiation Protocol (SIP) 722 Event Package for Conference State ", draft-ivov- 723 grouptextchat-purpose-03 (work in progress), June 2013. 725 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 726 3", BCP 9, RFC 2026, October 1996. 728 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 729 Session Initiation Protocol (SIP)", RFC 4353, February 730 2006. 732 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 733 Security Layer (SASL)", RFC 4422, June 2006. 735 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 736 Initiation Protocol (SIP) Event Package for Conference 737 State", RFC 4575, August 2006. 739 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 740 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 742 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 743 "Salted Challenge Response Authentication Mechanism 744 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 746 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 747 August 2011. 749 [RFC6914] Rosenberg, J., "SIMPLE Made Simple: An Overview of the 750 IETF Specifications for Instant Messaging and Presence 751 Using the Session Initiation Protocol (SIP)", RFC 6914, 752 April 2013. 754 [RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose 755 for the Call-Info Header Field in the Session Initiation 756 Protocol (SIP)", RFC 6993, July 2013. 758 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 759 "WebFinger", RFC 7033, September 2013. 761 [XEP-0004] 762 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 763 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 765 [XEP-0030] 766 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 767 Andre, "Service Discovery", XSF XEP 0030, June 2008. 769 [XEP-0045] 770 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 771 2012. 773 [XEP-0054] 774 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 776 [XEP-0128] 777 Saint-Andre, P., "Service Discovery Extensions", XSF XEP 778 0128, October 2004. 780 [XEP-0152] 781 Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability 782 Addresses", XEP XEP-0152, September 2013. 784 [XEP-0166] 785 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 786 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 787 2009. 789 [XEP-0167] 790 Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. 791 Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, December 792 2009. 794 [XEP-0292] 795 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 796 0292, September 2013. 798 Appendix A. Acknowledgements 799 This draft is inspired by the "SIXPAC" work of Markus Isomaki and 800 Simo Veikkolainen. Markus also provided various suggestions for 801 improving the document. 803 The authors would also like to thank the following people for their 804 reviews and suggestions: Sebastien Couture, Dan-Christian Bogos, 805 Richard Brady, Olivier Crete, Aaron Evans, Kevin Gallagher, Adrian 806 Georgescu, Saul Ibarra Corretge, David Laban, Gergely Lukacsy, Murray 807 Mar, Daniel Pocock, Travis Reitter, and Gonzalo Salgueiro. 809 Brian Carpenter, Ted Hardie, Paul Hoffman, and Benson Schliesser 810 reviewed the document on behalf of the General Area Review Team, the 811 Applications Area Directorate, the Security Directorate, and the 812 Operations and Management Directorate, respectively. 814 Benoit Claise, Barry Leiba, and Pete Resnick provided helpful and 815 substantive feedback during IESG review. 817 The document shepherd was Mary Barnes. The sponsoring Area Director 818 was Gonzalo Camarillo. 820 Authors' Addresses 822 Emil Ivov 823 Jitsi 824 Strasbourg 67000 825 France 827 Phone: +33-177-624-330 828 Email: emcho@jitsi.org 830 Peter Saint-Andre 831 Cisco Systems, Inc. 832 1899 Wynkoop Street, Suite 600 833 Denver, CO 80202 834 USA 836 Phone: +1-303-308-3282 837 Email: psaintan@cisco.com 838 Enrico Marocco 839 Telecom Italia 840 Via G. Reiss Romoli, 274 841 Turin 10148 842 Italy 844 Email: enrico.marocco@telecomitalia.it