idnits 2.17.1 draft-ivov-xmpp-cusax-06.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 (June 06, 2013) is 3948 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-01 -- 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: December 08, 2013 Cisco Systems, Inc. 6 E. Marocco 7 Telecom Italia 8 June 06, 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-06 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 the practices outlined in this document may 25 require modifying or at least reconfiguring existing client and 26 server-side software. Also, it is not the purpose of this document 27 to make recommendations as to whether or not such combined use should 28 be preferred to the mechanisms provided natively by each protocol 29 (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to 30 provide guidance to 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 December 08, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Server-Side Setup . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Client-Side Discovery and Usability . . . . . . . . . . . 7 71 3.3. Indicating a Relation Between SIP and XMPP Accounts . . . 8 72 3.4. Matching Incoming SIP Calls to XMPP JIDs . . . . . . . . 9 73 4. Multi-Party Interactions . . . . . . . . . . . . . . . . . . 9 74 5. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Summary of Suggested Practices . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 9. Informative References . . . . . . . . . . . . . . . . . . . 14 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 85 implemented and deployed with different purposes: from its very start 86 SIP's primary goal has been to provide a means of conducting 87 "Internet telephone calls". XMPP on the other hand, has, from its 88 Jabber days, been mostly used for instant messaging and presence 89 [RFC6121], as well as related services such as groupchat rooms 90 [XEP-0045]. 92 For various reasons, these trends have continued through the years 93 even after each of the protocols had been equipped to provide the 94 features it was initially lacking: 96 o Today, in the context of the SIMPLE working group, the IETF has 97 defined a number of protocols and protocol extensions that not 98 only allow for SIP to be used for regular instant messaging and 99 presence but that also provide mechanisms for elaborated features 100 such as multi-user chats, server-stored contact lists, file 101 transfer and others. 103 o Similarly, the XMPP community and the XMPP Standards Foundation 104 have worked on defining a number of XMPP Extension Protocols 105 (XEPs) that provide XMPP implementations with the means of 106 establishing end-to-end sessions. These extensions are often 107 jointly referred to as Jingle and arguably their most popular use 108 case is audio and video calling. 110 Despite these advances, SIP remains the protocol of choice for 111 telephony-like services, especially in enterprises where users are 112 accustomed to features such as voice mail, call park, call queues, 113 conference bridges and many others that are rarely (if at all) 114 available in Jingle-based software. XMPP implementations, on the 115 other hand, greatly outnumber and outperform those available for 116 instant messaging and presence extensions developed in the SIMPLE WG, 117 such as MSRP [RFC4975] and XCAP [RFC4825]. 119 As a result, a number of adopters have found themselves needing 120 features that are not offered by any single-protocol solution, but 121 that separately exist in SIP and XMPP implementations. The idea of 122 seamlessly using both protocols together would hence often appeal to 123 service providers. Most often, such a service would employ SIP 124 exclusively for audio, video, and telephony services and rely on XMPP 125 for anything else varying from chat, contact list management, and 126 presence to whiteboarding and exchanging files. Because these 127 services and clients involve the combined use of SIP and XMPP, we 128 label them "CUSAX" for short. 130 +------------+ +-------------+ 131 | SIP Server | | XMPP Server | 132 +------------+ +-------------+ 133 \ / 134 media \ / instant messaging, 135 signaling \ / presence, etc. 136 \ / 137 +--------------+ 138 | CUSAX Client | 139 +--------------+ 141 Figure 1: Division of Responsibilities 143 This document explains how such hybrid offerings can be achieved with 144 a minimum of modifications to existing software while providing an 145 optimal user experience. It covers server discovery, determining a 146 SIP Address of Record (AOR) while using XMPP, and determining an XMPP 147 Jabber Identifier ("JID") from incoming SIP requests. Most of the 148 text here pertains to client behavior but it also recommends certain 149 server-side configurations. 151 Note that this document is focused on coexistence of SIP and XMPP 152 functionality in end-user-oriented clients. By intent it does not 153 define methods for protocol-level mapping between SIP and XMPP, as 154 might be used within a server-side gateway between a SIP network and 155 an XMPP network (a separate series of documents has been produced 156 that defines such mappings). More generally, this document does not 157 describe service policies for inter-domain communication (often 158 called "federation") between service providers (e.g., how a service 159 provider that offers a combined SIP-XMPP service might communicate 160 with a SIP-only or XMPP-only service), nor does it describe the 161 reasons why a service provider might choose SIP or XMPP for various 162 features. 164 This document concentrates on use cases where the SIP services and 165 XMPP services are controlled by one and the same provider, since that 166 assumption greatly simplifies both client implementation and server- 167 side deployment (e.g., a single service provider can enforce common 168 or coordinated policies across both the SIP and XMPP aspects of a 169 CUSAX service, which is not possible if a SIP service is offered by 170 one provider and an XMPP service is offered by another). Since this 171 document is of an informational nature, it is not unreasonable for 172 clients to apply some of the guidelines here even in cases where 173 there is no established relationship between the SIP and the XMPP 174 services (for example, it is reasonable for a client to provide a way 175 for its users to easily start a call to a phone number recorded in a 176 vCard or obtained from a user directory). However, the exact set of 177 rules to follow in such cases is left to application developers. 179 Finally, this document makes a further simplifying assumption by 180 discussing only the use of a single client, not use of and 181 coordination among multiple endpoints controlled by the same user 182 (e.g., user agents running simultaneously on a laptop computer, 183 tablet, and mobile phone). 185 2. Client Bootstrap 187 One of the main problems of using two distinct protocols when 188 providing one service is the impact on usability. Email services, 189 for example, have long been affected by the mixed use of SMTP for 190 outgoing mail and POP3 or IMAP for incoming mail. Although standard 191 service discovery methods (such as the proper DNS records) make it 192 possible for a user agent to locate the right host(s) at which to 193 connect, they do not provide the kind of detailed information that is 194 needed to actually configure the user agent for use with the service. 195 As a result, it is rather complicated for inexperienced users to 196 configure a mail client and start using it with a new service, and 197 Internet service providers often need to provide configuration 198 instructions for various mail clients. Client developers and 199 communication device manufacturers on the other hand often ship with 200 a number of wizards that enable users to easily set up a new account 201 for a number of popular email services. While this may improve the 202 situation to some extent, the user experience is still clearly sub- 203 optimal. 205 While it should be possible for CUSAX users to manually configure 206 their separate SIP and XMPP accounts, service providers offering 207 CUSAX services to users of dual-stack SIP/XMPP clients ought to 208 provide means of online provisioning, typically by means of a web- 209 based service at an HTTP URI (naturally single-purpose SIP services 210 or XMPP services could offer online provisioning as well, but they 211 can be especially helpful where the two aspects of the CUSAX service 212 need to have several configuration options in common). While the 213 specifics of such mechanisms are outside the scope of this 214 specification, they should make it possible for a service provider to 215 remotely configure the clients based on minimal user input (e.g., 216 only a user ID and password). 218 Because many of the features that a CUSAX client would prefer in one 219 protocol would also be available in the other, clients should make it 220 possible for such features to be disabled for a specific account. In 221 particular, it is suggested that clients allow for audio and video 222 calling features to be disabled for XMPP accounts, and that instant 223 messaging and presence features should also be made optional for SIP 224 accounts. 226 The main advantage of this approach is that clients would be able to 227 continue to function properly and use the complete feature set of 228 standalone SIP and XMPP accounts. 230 Once clients have been provisioned, they need to independently log 231 into the SIP and XMPP accounts that make up the CUSAX "service" and 232 then maintain both these connections as displayed in Figure 2. 234 +--------------+ 235 | Provisioning |-----------+ 236 | Server | | 237 +--------------+ v 238 | +----------------+ 239 | | User Directory | 240 | +----------------+ 241 | / \ 242 | +------------+ +-------------+ 243 | | SIP Server | | XMPP Server | 244 | +------------+ +-------------+ 245 | \ / 246 | media \ / instant messaging, 247 | signaling \ / presence, etc. 248 | \ / 249 | +--------------+ 250 +---------------| CUSAX Client | 251 +--------------+ 253 Figure 2: Example Deployment 255 In order to improve the user experience, when reporting connection 256 status clients may also wish to present the XMPP connection as an 257 "instant messaging" or a "chat" account. Similarly they could also 258 depict the SIP connection as a "Voice and Video" or a "Telephony" 259 connection. The exact naming is of course entirely up to 260 implementers. The point is that, in cases where SIP and XMPP are 261 components of a service offered by a single provider, such 262 presentation could help users better understand why they are being 263 shown two different connections for what they perceive as a single 264 service. It could alleviate especially situations where one of these 265 connections is disrupted while the other one is still active. 266 Naturally, the developers of a CUSAX client or the providers of a 267 CUSAX service might decide not to accept such situations and force a 268 client to completely disconnect unless both aspects are successfully 269 connected. 271 Clients may also choose to delay their XMPP connection until they 272 have been successfully registered on SIP. This would help avoid the 273 situation where a user appears online to its contacts but calling it 274 would fail because their clients is still connecting to the SIP 275 aspect of their CUSAX service. 277 3. Operation 279 Once a CUSAX client has been provisioned and authorized to connect to 280 the corresponding SIP and XMPP services it would proceed by 281 retrieving its XMPP roster. 283 The client should use XMPP for all forms of communication with the 284 contacts from this roster, which will occur naturally because they 285 were retrieved through XMPP. Audio/video features however, are 286 disabled in the XMPP stack, so any form of communication based on 287 these features (e.g. direct calls, conferences, desktop streaming, 288 etc.) will happen over SIP. The rest of this section describes 289 deployment, discovery, usability and linking semantics that allow 290 CUSAX clients to fall back and seamlessly use SIP for these features. 292 3.1. Server-Side Setup 294 In order for CUSAX to function properly, XMPP service administrators 295 should make sure that at least one of the vCard [RFC6350] "tel" 296 fields for each contact is properly populated with a SIP URI or a 297 phone number when an XMPP protocol for vCard storage is used (e.g., 298 [XEP-0054] or [XEP-0292]). There are no limitations as to the form 299 of that number. For example while it is desirable to maintain a 300 certain consistency between SIP AORs and XMPP JIDs, that is by no 301 means required. It is quite important however that the phone number 302 or SIP AOR stored in the vCard be reachable through the SIP aspect of 303 this CUSAX service. (The same considerations apply even if the 304 directory storage format is not vCard.) 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 (1) preventing clients (and hence users) 312 from modifying the vCard "tel" fields or (2) applying some form of 313 validation before storing changes. Of course such validation would 314 be feasible mostly in cases where a single provider controls both the 315 XMPP and the SIP service since such providers would "know" (e.g., 316 based on use of a common user database for both services) what SIP 317 AOR corresponds to a given XMPP user (as indicated in Figure 2). 319 3.2. Client-Side Discovery and Usability 321 When rendering the roster for a particular XMPP account CUSAX clients 322 should make sure that users are presented with a "Call" option for 323 each roster entry that has a properly set "tel" field. This is the 324 case even if calling features have been disabled for that particular 325 XMPP account, as advised by this document. The usefulness of such a 326 feature is not limited to CUSAX. After all, numbers are entered in 327 vCards or stored in directories in order to be dialed and called. 328 Hence, as long as an XMPP client has any means of conducting a call 329 it may wish to make it possible for the user to easily dial any 330 numbers that it learned through whatever means. 332 Clients that have separate triggers (e.g., buttons) for audio calls 333 and video calls may choose to use the presence or absence of the 334 "video" tel type defined in [RFC6350] as the basis for choosing 335 whether to enable or disable the possibility for starting video calls 336 (i.e., if there is no "video" tel type for a particular contact, do 337 not provide a way for the user to start a video call with that 338 contact). 340 In addition to discovering phone numbers from vCards or user 341 directories, clients may also check for alternative communication 342 methods as advertised in XMPP presence broadcasts and Personal 343 Eventing Protocol nodes as described in XEP-0152: Reachability 344 Addresses [XEP-0152]. However, these indications are merely hints, 345 and a receiving client ought not associate a SIP address and an XMPP 346 address unless it has some way to verify the association (e.g., the 347 vCard of the XMPP account lists the SIP address and the vCard of the 348 SIP account lists the XMPP address, or the association is made 349 explicit in a record provided by a trusted directory). Alternatively 350 or in cases where vCard or directory data is not available, a CUSAX 351 client could take the user's own address book as the canonical source 352 for contact addresses. 354 3.3. Indicating a Relation Between SIP and XMPP Accounts 356 In order to improve usability, in cases where clients are provisioned 357 with only a single telephony-capable account they ought to initiate 358 calls immediately upon user request without asking users to indicate 359 an account that the call should go through. This way CUSAX users 360 (whose only account with calling capabilities is usually the SIP part 361 of their service) would have a better experience, since from the 362 user's perspective calls "just work at the click of a button". 364 In some cases however, clients will be configured with more than the 365 two XMPP and SIP accounts provisioned by the CUSAX provider. Users 366 are likely to add additional stand-alone XMPP or SIP accounts (or 367 accounts for other communications protocols), any of which might have 368 both telephony and instant messaging capabilities. Such situations 369 can introduce additional ambiguity since all of the telephony-capable 370 accounts could be used for calling the numbers the client has learned 371 from vCards or directories. 373 To avoid such confusion, client implementers and CUSAX service 374 providers may choose to indicate the existence of a special 375 relationship between the SIP and XMPP accounts of a CUSAX service. 376 For example, let's say that Alice's service provider has opened both 377 an XMPP account and a SIP account for her. During or after 378 provisioning, her client could indicate that alice@xmpp.example.com 379 has a CUSAX relation to alice@sip.example.com (i.e., that they are 380 two aspects of the same service). This way whenever Alice triggers a 381 call to a contact in her XMPP roster, the client would preferentially 382 initiate this call through her example.com SIP account even if other 383 possibilities exist (such as the XMPP account where the vCard was 384 obtained or a SIP account with another provider). 386 If, on the other hand, no relationship has been configured or 387 discovered between a SIP account and an XMPP account, and the client 388 is aware of multiple telephony-capable accounts, it ought to present 389 the user with the choice of reaching the contact through any of those 390 accounts. This includes the source XMPP account where the vCard was 391 obtained (in case its telephony capabilities are not disabled through 392 configuration or provisioning), in order to guarantee proper 393 operation for XMPP accounts that are not part of a CUSAX deployment. 395 3.4. Matching Incoming SIP Calls to XMPP JIDs 397 When receiving SIP calls, clients may wish to determine the identity 398 of the caller and a corresponding XMPP roster entry so that users 399 could revert to chatting or other forms of communication that require 400 XMPP. To do so clients could search their roster for an entry whose 401 vCard has a "tel" field matching the originator of the call. In 402 addition, in order to avoid the effort of iterating over an entire 403 roster and retrieving all vCards, CUSAX clients may use a SIP Call- 404 Info header whose 'purpose' header field parameter has a value of 405 "impp" as described in [I-D.saintandre-impp-call-info]. An example 406 follows. 408 Call-Info: ;purpose=impp 410 Note that the information from the Call-Info header should only be 411 used as a cue: the actual AOR-to-JID binding would still need to be 412 confirmed by a vCard entry or through some other trusted means (such 413 as an enterprise directory). If this confirmation succeeds the 414 client would not need to search the entire roster and retrieve all 415 vCards. Not performing the check might enable any caller (including 416 malicious ones) to employ someone else's identity and perform various 417 scams or Man-in-the-Middle attacks. 419 However, although an AOR-to-JID binding can be a helpful hint to the 420 user, nothing in the foregoing paragraph ought to be construed as 421 necessarily discouraging users, clients, or service providers from 422 accepting calls originated by entities that are not established 423 contacts of the user (e.g., as reflected in the user's roster); that 424 is a policy matter for the user, client, or service provider. 426 4. Multi-Party Interactions 428 CUSAX clients that support the SIP conferencing framework [RFC4353] 429 can detect when a call they are participating in is actually a 430 conference and can then subscribe for conference state updates as per 431 [RFC4575]. A regular SIP user agent would also use the same 432 conference URI for text communication with the Message Session Relay 433 Protocol (MSRP). However, given that SIP's instant messaging 434 capabilities would normally be disabled (or simply not supported) in 435 CUSAX deployments, an XMPP Multi-User Chat (MUC) [XEP-0045] 436 associated with the conference can be announced/discovered through 437 bearing the "grouptextchat" purpose 438 [I-D.ivov-grouptextchat-purpose]. Similarly, an XMPP MUC can 439 advertise the SIP URI of an associated service for audio/video 440 interactions using the 'audio-video-uri' field of the "muc#roominfo" 441 data form [XEP-0004] to include extended information [XEP-0128] about 442 the MUC room within XMPP service discovery [XEP-0030]; see [XEP-0045] 443 for an example. 445 Once a CUSAX client joins the MUC associated with a particular call 446 it should not rely on any synchronization between the two. Both the 447 SIP conference and the XMPP MUC would function independently, each 448 issuing and delivering its own state updates. It is hence possible 449 that that certain peers would temporarily or permanently be reachable 450 in only one of the two conferences. This would typically be the case 451 with single-stack clients that have only joined the SIP call or the 452 XMPP MUC. It is therefore important for CUSAX clients to provide a 453 clear indication to users as to the level of participation of the 454 various participants. In other words, a user needs to be able to 455 easily understand whether a certain participant can receive text 456 messages, audio/video, or both. 458 Of course, tighter integration between the XMPP MUC and the SIP 459 conference is also possible. Permissions, roles, kicks and bans that 460 are granted and performed in the MUC can easily be imitated by the 461 conference focus/mixer into the SIP call. If for example, a certain 462 MUC member is muted, the conference mixer can choose to also apply 463 the mute on the media stream corresponding to that participant. The 464 details and exact level of such integration is of course entirely up 465 to implementers and service providers. 467 The approach above describes one relatively lightweight possibility 468 of combining SIP and XMPP multi-party interaction semantics without 469 requiring tight integration between the two. As with the rest of 470 this specification, this approach is by no means normative. 471 Implementation and future specifications may define other methods or 472 provide other suggestions for improving the Unified Communications 473 user experience in cases of multi-user chats in conference calling. 475 5. Federation 476 In theory there are no technical reasons why federation would require 477 special behavior from CUSAX clients. However, it is worth noting 478 that differences in administration policies may sometimes lead to 479 potentially confusing user experiences. 481 For example, let's say atlanta.example.com observes the CUSAX 482 policies described in this specification. All XMPP users at 483 atlanta.example.com are hence configured to have vCards that match 484 their SIP identities. Alice is therefore used to making free, high- 485 quality SIP calls to all the people in her roster. Alice can also 486 make calls to the PSTN by simply dialing numbers. She may even be 487 used to these calls being billed to her online account so she would 488 be careful about how long they last. This is not a problem for her 489 since she can easily distinguish between a free SIP call (one that 490 she made by calling one her roster entries) from a paid PSTN call 491 that she dialed as a number. 493 Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only 494 has an XMPP service. There is no SIP server and Bob uses a regular, 495 XMPP-only client. Bob has however added his mobile number to his 496 vCard in order to make it easily accessible to his contacts. Alice's 497 client would pick up this number and make it possible for Alice to 498 start a call to Bob's mobile phone number. 500 This could be a problem because, other than the fact that Bob's 501 address is from a different domain, Alice would have no obvious and 502 straightforward cues telling her that this is in fact a call to the 503 PSTN. In addition to the potentially lower audio quality, Alice may 504 also end up incurring unexpected charges for such calls. 506 In order to avoid such issues, providers maintaining a CUSAX service 507 for the users in their domain may choose to provide additional cues 508 (e.g., a user interface warning or an an audio tone or message) 509 indicating that a call would incur charges. 511 A slightly less disturbing scenario, where a SIP service might only 512 allow communication with intra-domain numbers, would simply prevent 513 Alice from establishing a call with Bob's mobile. Providers should 514 hence make sure that calls to inter-domain numbers are flagged with 515 an appropriate audio or textual warning. 517 6. Summary of Suggested Practices 519 The following practices are suggested for CUSAX user agents: 521 1. By default, prefer SIP for audio and video, and XMPP for 522 messaging and presence. 524 2. Use XMPP for all forms of communication with the contacts from 525 the XMPP roster, with the exception of features that are based 526 on establishing real-time sessions (e.g. audio/video calls) in 527 which case use SIP. 529 3. Provide on-line provisioning options for providers to remotely 530 setup SIP and XMPP accounts so that users wouldn't need to go 531 through a multi-step configuration process. 533 4. Provide on-line provisioning options for providers to completely 534 disable features for an account associated with a given protocol 535 (SIP or XMPP) if the features are preferred in another protocol 536 (XMPP or SIP). 538 5. Present a "Call" option for each roster entry that has a 539 properly set "tel" field. 541 6. If the client is provisioned with only a single telephony- 542 capable account, initiate calls immediately upon user request 543 without asking users to indicate an account that the call should 544 go through. 546 7. If no relationship has been configured or discovered between a 547 SIP account and an XMPP account, and the client is aware of 548 multiple telephony-capable accounts, present the user with the 549 choice of reaching the contact through any of those accounts. 551 8. Optionally, indicate the existence of a special relationship 552 between the SIP and XMPP accounts of a CUSAX service. 554 9. Optionally, present the XMPP connection as an "instant 555 messaging" or a "chat" account and the SIP connection as a 556 "Voice and Video" or a "Telephony" acccount. 558 10. Optionally, determine the identity of the audio/video caller and 559 a corresponding XMPP roster entry so that the user could revert 560 to textual chatting or other forms of communication that require 561 XMPP. 563 11. Optionally, delay the XMPP connection until after a SIP 564 connection has been successfully registered. 566 12. Optionally, check for alternative communication methods (SIP 567 addresses advertised over XMPP, and XMPP addresses advertised 568 over SIP). 570 The following practices are suggested for CUSAX services: 572 1. Use online provisioning and configuration of accounts so that 573 users won't need to setup two separate accounts for your service. 575 2. Use online provisioning so that calling features are disabled for 576 all XMPP accounts. 578 3. Ensure that at least one of the vCard "tel" fields for each XMPP 579 user is properly populated with a SIP URI or a phone number that 580 are reachable through your SIP service. 582 4. Optionally, include the "video" tel type for accounts that are 583 capable of handling video communication. 585 5. Optionally, provision clients with information indicating that 586 specific SIP and XMPP accounts are related in a CUSAX service. 588 6. Optionally, attach a "Call-Info" header with an "impp" purpose to 589 all your SIP INVITE messages, so that clients can more rapidly 590 associate a caller with a roster entry and display a "Caller ID". 592 7. Security Considerations 594 Use of the same user agent with two different accounts providing 595 complementary features introduces the possibility of mismatches 596 between the security profiles of those accounts or features. For 597 example, the SIP aspect and XMPP aspect of the CUSAX service might 598 offer different authentication options (e.g., digest authentication 599 for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] 600 for XMPP as specified in [RFC6120]). Similarly, a CUSAX client might 601 successfully negotiate Transport Layer Security (TLS) [RFC5246] when 602 connecting to the XMPP aspect of the service but not when connecting 603 to the SIP aspect. Such mismatches could introduce the possibility 604 of downgrade attacks. User agent developers and service providers 605 ought to ensure that such mismatches are avoided as much as possible. 607 Refer to the specifications for the relevant SIP and XMPP features 608 for detailed security considerations applying to each "stack" in a 609 CUSAX client. 611 8. IANA Considerations 613 This document has no actions for the IANA. 615 9. Informative References 617 [I-D.ivov-grouptextchat-purpose] 618 Ivov, E., "A Group Text Chat Purpose for Conference and 619 Service URIs in the Session Initiation Protocol (SIP) 620 Event Package for Conference State ", draft-ivov- 621 grouptextchat-purpose-01 (work in progress), May 2013. 623 [I-D.saintandre-impp-call-info] 624 Saint-Andre, P., "Instant Messaging and Presence Purpose 625 for the Call-Info Header in the Session Initiation 626 Protocol (SIP) ", draft-saintandre-impp-call-info-04 (work 627 in progress), May 2013. 629 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 630 A., Peterson, J., Sparks, R., Handley, M., and E. 631 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 632 June 2002. 634 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 635 Session Initiation Protocol (SIP)", RFC 4353, February 636 2006. 638 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 639 Initiation Protocol (SIP) Event Package for Conference 640 State", RFC 4575, August 2006. 642 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 643 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 645 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 646 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 648 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 649 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 651 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 652 "Salted Challenge Response Authentication Mechanism 653 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 655 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 656 Protocol (XMPP): Core", RFC 6120, March 2011. 658 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 659 Protocol (XMPP): Instant Messaging and Presence", RFC 660 6121, March 2011. 662 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 663 August 2011. 665 [XEP-0004] 666 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 667 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 669 [XEP-0030] 670 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 671 Andre, "Service Discovery", XSF XEP 0030, June 2008. 673 [XEP-0045] 674 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 675 2012. 677 [XEP-0054] 678 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 680 [XEP-0128] 681 Saint-Andre, P., "Service Discovery Extensions", XSF XEP 682 0128, October 2004. 684 [XEP-0152] 685 Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability 686 Addresses", XEP XEP-0152, February 2013. 688 [XEP-0292] 689 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 690 0292, October 2011. 692 Appendix A. Acknowledgements 694 This draft is inspired by the "SIXPAC" work of Markus Isomaki and 695 Simo Veikkolainen. Markus also provided various suggestions for 696 improving the document. 698 The authors would also like to thank the following people for their 699 reviews and suggestions: Sebastien Couture, Dan-Christian Bogos, 700 Richard Brady, Olivier Crete, Aaron Evans, Kevin Gallagher, Adrian 701 Georgescu, Saul Ibarra Corretge, David Laban, Gergely Lukacsy, Murray 702 Mar, Daniel Pocock, Travis Reitter, and Gonzalo Salgueiro. 704 Authors' Addresses 705 Emil Ivov 706 Jitsi 707 Strasbourg 67000 708 France 710 Phone: +33-177-624-330 711 Email: emcho@jitsi.org 713 Peter Saint-Andre 714 Cisco Systems, Inc. 715 1899 Wynkoop Street, Suite 600 716 Denver, CO 80202 717 USA 719 Phone: +1-303-308-3282 720 Email: psaintan@cisco.com 722 Enrico Marocco 723 Telecom Italia 724 Via G. Reiss Romoli, 274 725 Turin 10148 726 Italy 728 Email: enrico.marocco@telecomitalia.it