| Network Working Group | E. Ivov |
| Internet-Draft | Jitsi |
| Intended status: Informational | P. Saint-Andre |
| Expires: October 13, 2013 | Cisco Systems, Inc. |
| E. Marocco | |
| Telecom Italia | |
| April 11, 2013 |
CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)
draft-ivov-xmpp-cusax-04
This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing it may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Historically SIP [RFC3261] and XMPP [RFC6120] have often been implemented and deployed with different purposes: from its very start SIP's primary goal has been to provide a means of conducting "Internet telephone calls". XMPP on the other hand, has, from its Jabber days, been mostly used for instant messaging and presence [RFC6121], as well as related services such as groupchat rooms [XEP-0045].
For various reasons, these trends have continued through the years even after each of the protocols had been equipped to provide the features it was initially lacking:
Despite these advances, SIP remains the protocol of choice for telephony-like services, especially in enterprises where users are accustomed to features such as voice mail, call park, call queues, conference bridges and many others that are rarely (if at all) available in Jingle-based software. XMPP implementations, on the other hand, greatly outnumber and outperform those available for instant messaging and presence extensions developed in the SIMPLE WG, such as MSRP [RFC4975] and XCAP [RFC4825].
For these reasons, in a number of cases adopters have found themselves needing a set of features that are not offered by any single-protocol solution but that separately exist in SIP and XMPP products. The idea of seamlessly using both protocols together would hence often appeal to service providers.
Most often the combined use of SIP and XMPP ("CUSAX") would employ SIP exclusively for audio, video, and telephony services and rely on XMPP for anything else varying from chat, contact list management, and presence to whiteboarding and exchanging files.
+------------+ +-------------+
| SIP Server | | XMPP Server |
+------------+ +-------------+
\ /
media \ / instant messaging,
signaling \ / presence, etc.
\ /
+--------------+
| CUSAX Client |
+--------------+
Figure 1: Division of Responsibilities
This document explains how such hybrid offerings can be achieved with a minimum of modifications to existing software while providing an optimal user experience. It tries to cover points such as server discovery, determining a SIP AOR while using XMPP and determining an XMPP Jabber Identifier ("JID") from incoming SIP requests. Most of the text here pertains to client behavior but it also recommends certain server-side configurations.
Note that this document is focused on coexistence of SIP and XMPP functionality in end-user-oriented clients. By intent it does not define methods for protocol-level mapping between SIP and XMPP, as might be used within a server-side gateway between a SIP network and an XMPP network (a separate series of documents has been produced that defines such mappings). More generally, this document does not describe service policies for inter-domain communication (often called "federation") between service providers (e.g., how a service provider that offers a combined SIP-XMPP service might communicate with a SIP-only or XMPP-only service), nor does it describe the reasons why a service provider might choose SIP or XMPP for various features.
Finally, this document concentrates on use cases where the SIP services and XMPP services are controlled by one and the same provider. Since this document is of an informational nature, it is not unreasonable for clients to apply some of the guidelines here even in cases where there is no established relationship between the SIP and the XMPP services (for example, it is reasonable for a client to provide a way for its users to easily start a call to a phone number recorded in a vCard). However, the exact set of rules to follow in such cases is left to application developers.
One of the main problems of using two distinct protocols when providing one service is the impact on usability. Email services, for example, have long been affected by the mixed use of SMTP for outgoing mail and POP3 or IMAP for incoming mail, making it rather complicated for inexperienced users to configure a mail client and start using it with a new service. As a result, Internet service providers often need to provide configuration instructions for various mail clients. Client developers and communication device manufacturers on the other hand often ship with a number of wizards that enable users to easily set up a new account for a number of popular email services. While this may improve the situation to some extent, the user experience is still clearly sub-optimal.
While it should be possible for CUSAX users to manually configure their separate SIP and XMPP accounts, dual-stack SIP/XMPP clients ought to provide means of online provisioning. While the specifics of such mechanisms are outside the scope of this specification, they should make it possible for a service provider to remotely configure the clients based on minimal user input (e.g., only a user ID and password).
Because many of the features that a CUSAX client would privilege in one protocol would also be available in the other, clients should make it possible for such features to be disabled for a specific account. In particular, it is suggested that clients allow for audio and video calling features to be disabled for XMPP accounts, and that instant messaging and presence features should also be made optional for SIP accounts.
The main advantage of this approach is that clients would be able to continue to function properly and use the complete feature set of standalone SIP and XMPP accounts.
Once client bootstrap has completed, clients need to log in independently to the SIP and XMPP accounts that make up the CUSAX "service" and then maintain both these connections. In order to improve user experience, when reporting connection status clients may also wish to present the XMPP CUSAX connection as an "instant messaging" or a "chat" account. Similarly they could also depict the SIP CUSAX connection as a "Voice and Video" or a "Telephony" connection. The exact naming is of course entirely up to implementers. The point is that, in cases where SIP and XMPP are components of a service offered by a single provider, such presentation could help users better understand why they are being shown two different connections for what they perceive as a single service. It could alleviate especially situations where one of these connections is disrupted while the other one is still active.
Once a CUSAX client has been provisioned/configured to connect to the corresponding SIP and XMPP services it would proceed by retrieving its XMPP roster. In order for CUSAX to function properly, XMPP service administrators should make sure that at least one of the vCard [RFC6350] "tel" fields for each contact is properly populated with a SIP URI or a phone number when an XMPP protocol for vCard storage is used (e.g., [XEP-0054] or [XEP-0292]). There are no limitations as to the form of that number. For example while it is desirable to maintain a certain consistency between SIP AORs and XMPP JIDs, that is by no means required. It is quite important however that the phone number or SIP AOR stored in the vCard be reachable through the SIP aspect of this CUSAX service.
Additionally, clients that have separete triggers (buttons) for audio and video calls may choose to use the presence or absence of the "video" tel type defined in [RFC6350] and enable or disable the possibility for starting video calls accordingly.
To ensure that the foregoing approach is always respected, service providers might consider (1) preventing clients (and hence users) from modifying the vCard "tel" fields or (2) applying some form of validation before storing changes. Of course such validation would be feasible mostly in cases where a single provider controls both the XMPP and the SIP service since such providers would "know" (e.g., based on use of a common user database for both services) what SIP AOR corresponds to a given XMPP user.
+--------------+
| Provisioning |-----------+
| Server | |
+--------------+ v
| +----------------+
| | vCard Storage/ |
| | User Directory |
| +----------------+
| / \
| +------------+ +-------------+
| | SIP Server | | XMPP Server |
| +------------+ +-------------+
| \ /
| media \ / instant messaging,
| signaling \ / presence, etc.
| \ /
| +--------------+
+---------------| CUSAX Client |
+--------------+
Figure 2: Example Deployment
When rendering the roster for a particular XMPP account CUSAX clients should make sure that users are presented with a "Call" option for each roster entry that has a properly set "tel" field even if calling has been disabled for that particular XMPP account. The usefulness of such a feature is not limited to CUSAX. After all, numbers are entered in vCards in order to be dialed and called. Hence, as long as an XMPP client is equipped with accounts that have calling features it may wish to present the user with the option of using these accounts to reach numbers from an XMPP vCard. In order to improve usability, in cases where clients are provisioned with only a single telephony-capable account they ought to initiate calls immediately upon user request without asking users to indicate an account that the call should go through. This way CUSAX users (whose only account with calling capabilities is usually the SIP part of their service) would have a better experience, since from the user's perspective calls "just work at the click of a button".
In order to provide a similar experience when the user has multiple telephony-capable accounts, client implementers may choose to indicate the existence of a special relationship between the SIP and XMPP accounts of a CUSAX service. For example, let's say that Alice's service provider has opened both an XMPP account and a SIP account for her. During or after provisioning, her client could indicate that alice@xmpp.example.com has a CUSAX relation to alice@sip.example.com (i.e., that they are two aspects of the same service). This way whenever Alice triggers a call to a contact in her XMPP roster, the client would preferentially initiate this call through her example.com SIP account even if other possibilities exist (such as the XMPP account where the vCard was obtained or a SIP account with another provider).
If, on the other hand, no relationship has been configured between the SIP and XMPP accounts of a CUSAX service and the client is aware of multiple telephony-capable accounts, it ought to present the user with the choice of reaching the contact through any of those accounts. This includes the source XMPP account where the vCard was obtained (in case its telephony capabilities are not disabled through configuration or provisioning), in order to guarantee proper operation for XMPP accounts that are not part of a CUSAX deployment.
In addition to discovering phone numbers from vCards, clients may also check for alternative communication methods as advertised in XMPP presence broadcasts and Personal Eventing Protocol nodes as described in XEP-0152: Reachability Addresses [XEP-0152].
The client should use XMPP for all other forms of communication with the contacts from its roster, which will occur naturally because they were retrieved through XMPP and only audio/video features were disabled in the XMPP stack.
When receiving SIP calls, clients may wish to determine the identity of the caller and a corresponding XMPP roster entry so that users could revert to chatting or other forms of communication that require XMPP. To do so clients could search their roster for an entry whose vCard has a "tel" field matching the originator of the call.
Call-Info: <xmpp:alice@example.com> ;purpose=impp
In addition, in order to avoid the effort of iterating over an entire roster and retrieving all vCards, CUSAX clients may use a SIP Call-Info header whose 'purpose' token field parameter has a value of "impp" as described in [I-D.saintandre-impp-call-info] such as the following:
This document concentrates on problems related to one-to-one communication. While it is possible for clients and other specifications to build upon this and provide suggestions for improving the Unified Communications user experience in cases of multi-user chats in conference calling (e.g., ways of mapping XMPP Multi-User Chatrooms to conference calls and vice versa), such mechanisms are considered out of scope for this version of CUSAX.
In theory there are no technical reasons why federation would require special behaviour from CUSAX clients. However, it is worth noting that differences in administration policies may sometimes lead to potentially confusing user experiences.
For example, let's say atlanta.example.com observes the CUSAX policies described in this specification. All XMPP users at atlanta.example.com are hence configured to have vCards that match their SIP identities. Alice is therefore used to making free, high-quality SIP calls to all the people in her roster. Alice can also make calls to the PSTN by simply dialing numbers. She may even be used to these calls being billed to her online account so she would careful about how long they last. This is not a problem for her since she can easily distinguish between a free SIP call (one that she made by calling one her roster entries) from a paid PSTN call that she dialed as a number.
Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only has an XMPP service. There is no SIP server and Bob uses a regular, XMPP-only client. Bob has however added his mobile number to his vCard in order to make it easily accessible to his contacts. Alice's client would pick up this number and make it possible for Alice to start a call to Bob's mobile phone number.
This could be a problem because, other than the fact that Bob's address is from a different domain, Alice would have no obvious and straightforward cues telling her that this is in fact a call to the PSTN. In addition to the potentially lower audio quality, Alice may also end up incurring unexpected charges for such calls.
In order to avoid such issues, providers maintaining a CUSAX service for the users in their domain may choose to provide additional cues (e.g., a user interface warning or an an audio tone or message) indicating that a call would incur charges.
A slightly less disturbing scenario, where a SIP service might only allow communication with intra-domain numbers, would simply prevent Alice from establishing a call with Bob's mobile. Providers should hence make sure that calls to extra-domain numbers are flagged with an appropriate audio or textual warning.
Use of the same user agent with two different accounts providing complementary features introduces the possibility of mismatches between the security profiles of those accounts or features. For example, the SIP aspect and XMPP aspect of the CUSAX service might offer different authentication options (e.g., digest authentication for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] for XMPP as specified in [RFC6120]). Similarly, a CUSAX client might successfully negotiate Transport Layer Security (TLS) [RFC5246] when connecting to the XMPP aspect of the service but not when connecting to the SIP aspect. Such mismatches could introduce the possibility of downgrade attacks. User agent developers and service providers ought to ensure that such mismatches are avoided as much as possible.
Refer to the specifications for the relevant SIP and XMPP features for detailed security considerations applying to each "stack" in a CUSAX client.
This document has no actions for the IANA.
This draft is inspired by the "SIXPAC" work of Markus Isomaki and Simo Veikkolainen. Markus also provided various suggestions for improving the document.
The authors would also like to thank the following persons for their reviews and suggestions: Aaron M. Evans, Sébastien Couture, Olivier Crête, Kevin Gallagher, Adrian Georgescu, Saúl Ibarra Corretgé, Daniel Pocock, Travis Reitterd, and Gonzalo Salgueiro.