summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7081.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7081.txt')
-rw-r--r--doc/rfc/rfc7081.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7081.txt b/doc/rfc/rfc7081.txt
new file mode 100644
index 0000000..6f8013a
--- /dev/null
+++ b/doc/rfc/rfc7081.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Ivov
+Request for Comments: 7081 Jitsi
+Category: Informational P. Saint-Andre
+ISSN: 2070-1721 Cisco Systems, Inc.
+ E. Marocco
+ Telecom Italia
+ November 2013
+
+
+ CUSAX: Combined Use of the Session Initiation Protocol (SIP)
+ and the Extensible Messaging and Presence Protocol (XMPP)
+
+Abstract
+
+ This document suggests some strategies for the combined use of the
+ Session Initiation Protocol (SIP) and the Extensible Messaging and
+ Presence Protocol (XMPP) both in user-oriented clients and in
+ deployed servers. Such strategies, which mainly consist of
+ configuration changes and minimal software modifications to existing
+ clients and servers, aim to provide a single, full-featured, real-
+ time communication service by using complementary subsets of features
+ from SIP and from XMPP. Typically, such subsets consist of telephony
+ capabilities from SIP and instant messaging and presence capabilities
+ from XMPP. This document does not define any new protocols or syntax
+ for either SIP or XMPP and, by intent, does not attempt to
+ standardize "best current practices". Instead, it merely aims to
+ provide practical guidance to those who are interested in the
+ combined use of SIP and XMPP for real-time communication.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7081.
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 1]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+Copyright Notice
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Client Bootstrap ................................................5
+ 3. Operation .......................................................6
+ 3.1. Server-Side Setup ..........................................7
+ 3.2. Service Management .........................................7
+ 3.3. Client-Side Discovery and Usability ........................8
+ 3.4. Indicating a Relationship between SIP and XMPP Accounts ....9
+ 3.5. Matching Incoming SIP Calls to XMPP JIDs ..................10
+ 4. Multi-Party Interactions .......................................11
+ 5. Federation .....................................................12
+ 6. Summary of Suggested Strategies ................................13
+ 7. Security Considerations ........................................14
+ 8. References .....................................................15
+ 8.1. Normative References ......................................15
+ 8.2. Informative References ....................................16
+ Appendix A. Acknowledgements ......................................18
+
+1. Introduction
+
+ 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". On the other hand, XMPP has, from its
+ Jabber days, been mostly used for instant messaging, presence
+ [RFC6121], and related services such as groupchat rooms [XEP-0045].
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 2]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ 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:
+
+ o In the context of the SIP for Instant Messaging and Presence
+ Leveraging Extensions (SIMPLE) working group, the IETF has defined
+ a number of protocols and protocol extensions that not only allow
+ for SIP to be used for regular instant messaging and presence but
+ that also provide mechanisms for related features such as
+ multi-party chat, server-stored contact lists, and file transfer
+ [RFC6914].
+
+ o Similarly, the XMPP community and the XMPP Standards Foundation
+ have worked on defining a number of XMPP Extension Protocols
+ (XEPs) that provide XMPP implementations with the means of
+ establishing end-to-end sessions. These extensions are often
+ jointly referred to as Jingle [XEP-0166], and arguably their most
+ popular use case is audio and video calling [XEP-0167].
+
+ However, although SIP has been extended for messaging and presence
+ and XMPP has been extended for voice and video, the reality is that
+ SIP remains the protocol of choice for telephony-like services, and
+ XMPP remains the protocol of choice for IM and presence services. As
+ a result, a number of adopters have found themselves needing features
+ that are not offered by any single-protocol solution, but ones that
+ separately exist in SIP and XMPP implementations. The idea of
+ seamlessly using both protocols together would hence often appeal to
+ service providers and users. Most often, such a service 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. Because these
+ services and clients involve the combined use of SIP and XMPP, we
+ label them "CUSAX" for short.
+
+ +------------+ +-------------+
+ | SIP Server | | XMPP Server |
+ +------------+ +-------------+
+ \ /
+ media \ / instant messaging,
+ signaling \ / presence, etc.
+ \ /
+ +--------------+
+ | CUSAX Client |
+ +--------------+
+
+ Figure 1: Division of Responsibilities
+
+
+
+
+
+Ivov, et al. Informational [Page 3]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ This document suggests different configuration options and minimal
+ modifications to existing software so that clients and servers can
+ offer these hybrid services while providing an optimal user
+ experience. It covers server discovery, determining a SIP Address of
+ Record (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 we also suggest certain server-side
+ configurations and operational strategies. The document also
+ discusses significant security considerations that can arise when
+ offering a dual-protocol solution and provides advice for avoiding
+ security mismatches that would result in degraded communications
+ security for end users.
+
+ 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 CUSAX 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.
+
+ This document concentrates on use cases where the SIP services and
+ XMPP services are controlled by one and the same provider, since that
+ assumption greatly simplifies both client implementation and
+ server-side deployment (e.g., a single service provider can enforce
+ common or coordinated policies across both the SIP and XMPP aspects
+ of a CUSAX service, which is not possible if a SIP service is offered
+ by one provider and an XMPP service is offered by another 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
+ or SIP URI found in a vCard or obtained from a user directory).
+ However, the strategies to pursue in such cases are left to
+ application developers.
+
+ This document makes a further simplifying assumption by discussing
+ only the use of a single client, not use of and coordination among
+ multiple endpoints controlled by the same user (e.g., user agents
+ running simultaneously on a laptop computer, tablet, and mobile
+ phone). Although user agents running on separate endpoints might
+ themselves be CUSAX clients or might engage in different aspects of
+ an interaction (e.g., a user might employ her mobile phone for audio
+
+
+
+Ivov, et al. Informational [Page 4]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ and her tablet for video and text chat), such usage complicates the
+ guidelines for developers of user agents and therefore is left as a
+ matter of implementation for now.
+
+ It is important to note that this document does not attempt to
+ standardize "best current practices" in the sense defined in the
+ Internet Standards Process [RFC2026]. Instead, it collects together
+ informational documentation about some strategies that might prove
+ helpful to those who implement and deploy combined SIP/XMPP software
+ and services. With sufficient use and appropriate modification to
+ incorporate the lessons of experience, these strategies might someday
+ form the basis for standardization of best current practices.
+
+2. Client Bootstrap
+
+ 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 Post Office Protocol version 3 (POP3) or IMAP for
+ incoming mail. Although standard service discovery methods (such as
+ the proper DNS records) make it possible for a user agent to locate
+ the right host(s) for connect purposes, they do not provide the kind
+ of detailed information that is needed to actually configure the user
+ agent for use with the service. As a result, it is rather
+ complicated for inexperienced users to configure a mail client and
+ start using it with a new service; and 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
+ so-called "wizard" interfaces that enable users to easily configure
+ accounts with a number of popular email services. Although this may
+ improve the situation to some extent, the user experience is still
+ clearly suboptimal.
+
+ While it should be possible for CUSAX users to manually configure
+ their separate SIP and XMPP accounts (often using "wizards"), service
+ providers offering CUSAX services to users of dual-stack SIP/XMPP
+ clients ought to provide methods for online provisioning, typically
+ by means of a web-based service at an HTTPS URL (naturally, single-
+ purpose SIP services or XMPP services could offer such methods as
+ well, but they can be especially helpful where the two aspects of the
+ CUSAX service need to have several configuration options in common).
+ Although the specifics of such mechanisms are outside the scope of
+ this document, 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). As far as the authors are aware, no
+ open protocol for endpoint configuration is yet available and
+
+
+
+
+Ivov, et al. Informational [Page 5]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ adopted; however, application developers are encouraged to explore
+ the potential for future progress in this space (e.g., perhaps based
+ on technologies such as WebFinger [RFC7033]).
+
+ By default, when a CUSAX client is used in concert with SIP and XMPP
+ accounts that have a CUSAX relationship (see Section 3.4), the client
+ should disable audio and video calling over XMPP and disable instant
+ messaging and presence over SIP. (It is a matter of implementation
+ whether a CUSAX client allows a user to override these defaults in
+ various ways, e.g., by domain, by individual contact, or by device.)
+ The main advantage of this approach is that a client would employ the
+ most relevant features from both SIP and XMPP when used in the
+ context of a CUSAX service. Note that this default configuration
+ does not apply to stand-alone SIP accounts or XMPP accounts, for
+ which other settings are likely to be more appropriate (see
+ Section 3.4 for details).
+
+ Once a client has been provisioned, it needs to independently log
+ into the SIP account and XMPP account that make up the CUSAX
+ "service" and then maintain both connections.
+
+ In order to improve the user experience, when reporting connection
+ status, a CUSAX client may wish to present the XMPP connection as an
+ "instant messaging" or a "chat" account and the SIP 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 (especially when one of the connections is
+ disrupted while the other one is still active). Alternatively, the
+ developers of a CUSAX client or the providers of a CUSAX service
+ might decide to force a client to completely disconnect unless both
+ aspects are successfully connected.
+
+ Clients may also choose to delay their XMPP connection until they
+ have been successfully registered on SIP. This would help avoid the
+ situation where a user appears online to her contacts but calling the
+ user's client would fail because the user's client is still
+ connecting to the SIP aspect of the CUSAX service.
+
+3. Operation
+
+ Once a CUSAX client has been provisioned and authorized to connect to
+ the corresponding SIP and XMPP services, it would proceed by
+ retrieving its XMPP roster.
+
+
+
+
+
+Ivov, et al. Informational [Page 6]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ The client should use XMPP for most forms of communication with the
+ contacts from this roster, which will occur naturally because they
+ were retrieved through XMPP. Audio/video features, however, would
+ typically be disabled in the XMPP stack, so media-related
+ communication based on these features (e.g., direct calls,
+ conferences, desktop streaming, etc.) would happen over SIP. The
+ rest of this section describes deployment, discovery, usability, and
+ linking semantics that enable CUSAX clients to seamlessly use SIP for
+ these features.
+
+3.1. Server-Side Setup
+
+ 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 for the
+ user's address at the SIP audio/video service provided by the CUSAX
+ server. 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.
+ (The same considerations apply even if the directory storage format
+ is not vCard storage over XMPP as described by [XEP-0054] or
+ [XEP-0292].)
+
+ Administrators may also choose to include the "video" tel type
+ defined in [RFC6350] for accounts that would be capable of handling
+ video communication.
+
+ To ensure that the foregoing approach is always respected, service
+ providers might consider validating the values of vCard "tel" fields
+ before storing changes. Of course, such validation would be feasible
+ only 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.
+
+3.2. Service Management
+
+ The task of operating and managing a stand-alone SIP service or XMPP
+ service is not always easy. Combining the two into a unified service
+ introduces additional challenges, including:
+
+ o The necessity of opening additional ports on the client side if
+ SIP functionality is added to an existing XMPP deployment, or vice
+ versa.
+
+
+
+
+
+Ivov, et al. Informational [Page 7]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ o The potential for important differences in security posture across
+ SIP and XMPP (e.g., SIP servers and XMPP servers might support
+ different Transport Layer Security (TLS) ciphersuites).
+
+ o The need for, ideally, a common authentication backend and other
+ infrastructure that is shared across the SIP and XMPP aspects of
+ the combined service.
+
+ o Coordinated monitoring and logging of the SIP and XMPP servers to
+ enable the correlation of incidents and the pinpointing of
+ problems.
+
+ o The difficulty of troubleshooting client-side issues, e.g., if the
+ client loses connectivity for XMPP but maintains its SIP
+ connection.
+
+ Although separation of functionality (SIP for media and XMPP for IM
+ and presence) can help to ease the operational burden to some extent,
+ service providers are urged to address the foregoing challenges and
+ similar issues when preparing to launch a CUSAX service.
+
+ Beyond the issues listed above, service providers might want to be
+ aware of more subtle operational issues that can arise. For example,
+ if a service provider uses different network operators for the SIP
+ service and the XMPP service, end-to-end connectivity might be more
+ reliable or consistent in one service than in the other service.
+ Similar issues can arise when the media path and the signaling path
+ go over different networks, even in stand-alone SIP or XMPP services.
+ Providers of CUSAX services are advised to consider the potential for
+ such topologies to cause operational challenges.
+
+3.3. Client-Side Discovery and Usability
+
+ 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.
+ This is the case even if calling features have been disabled for that
+ particular XMPP account, as advised by this document. The usefulness
+ of such a feature is not limited to CUSAX. After all, numbers are
+ entered in vCards or stored in directories in order to be dialed and
+ called. Hence, as long as an XMPP client has any means of conducting
+ a call, it may wish to make it possible for the user to easily dial
+ any numbers that it learned through whatever means.
+
+ Clients that have separate triggers (e.g., buttons) for audio calls
+ and video calls may choose to use the presence or absence of the
+ "video" tel type defined in [RFC6350] as the basis for choosing
+
+
+
+
+Ivov, et al. Informational [Page 8]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ whether to enable or disable the possibility for starting video calls
+ (i.e., if there is no "video" tel type for a particular contact, the
+ client could disable the "video call" button for that contact).
+
+ In addition to discovering phone numbers from vCards or user
+ directories, 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]. However, these indications are merely hints,
+ and a receiving client ought not associate a SIP address and an XMPP
+ address unless it has some way to verify the relationship (e.g., the
+ vCard of the XMPP account lists the SIP address and the vCard of the
+ SIP account lists the XMPP address, or the relationship is made
+ explicit in a record provided by a trusted directory).
+ Alternatively, or in cases where vCard or directory data is not
+ available, a CUSAX client could take the user's own address book as
+ the canonical source for contact addresses.
+
+3.4. Indicating a Relationship between SIP and XMPP Accounts
+
+ 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 some cases, however, clients will be configured with more than the
+ two XMPP and SIP accounts provisioned by the CUSAX provider. Users
+ are likely to add additional stand-alone XMPP or SIP accounts (or
+ accounts for other communications protocols), any of which might have
+ both telephony and instant messaging capabilities. Such situations
+ can introduce additional ambiguity since all of the telephony-capable
+ accounts could be used for calling the numbers the client has learned
+ from vCards or directories.
+
+ To avoid such confusion, client implementers and CUSAX service
+ providers 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 relationship 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
+
+
+
+Ivov, et al. Informational [Page 9]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ vCard was obtained or a SIP account with another provider).
+ Similarly, the client would preferentially initiate textual chat
+ sessions using her XMPP account.
+
+ If, on the other hand, no relationship has been configured or
+ discovered between a SIP account and an XMPP account, and the client
+ is aware of multiple telephony-capable accounts, it ought to present
+ the user with the option of using XMPP Jingle as one method for
+ engaging in audio and video interactions with a contact who has an
+ XMPP address. This can help to ensure that a CUSAX user can complete
+ audio and video calls with XMPP users who are not part of a CUSAX
+ deployment.
+
+3.5. Matching Incoming SIP Calls to XMPP JIDs
+
+ When receiving a SIP call, a CUSAX client may wish to determine the
+ identity of the caller and a corresponding XMPP roster entry so that
+ the receiving user could revert to chatting or other forms of
+ communication that require XMPP. To do so, a CUSAX client could
+ search the user's roster for an entry whose vCard has a "tel" field
+ matching the originator of the call. In addition, in order to avoid
+ the effort of iterating over the entire roster of the user and
+ retrieving vCards for all of the user's contacts, the receiving
+ client may guess at the identity of the caller based a SIP Call-Info
+ header whose 'purpose' header field parameter has a value of "impp"
+ as described in [RFC6993]. To enable this usage, a sending client
+ would need to include such a Call-Info header in the SIP messages
+ that it sends when initiating a call. An example follows.
+
+ Call-Info: <xmpp:alice@xmpp.example.com> ;purpose=impp
+
+ Note that the information from the Call-Info header should only be
+ used as a cue: the actual AOR-to-JID binding would still need to be
+ confirmed by the vCard of a contact in the receiving user's roster or
+ through some other trusted means (such as an enterprise directory).
+ If this confirmation succeeds, the client would not need to search
+ the entire roster and retrieve all vCards. Not performing the check
+ might enable any caller (including malicious ones) to employ someone
+ else's identity and perform various scams or Man-in-the-Middle
+ attacks.
+
+ However, although an AOR-to-JID binding can be a helpful hint to the
+ user, nothing in the foregoing paragraph ought to be construed as
+ necessarily discouraging users, clients, or service providers from
+ accepting calls originated by entities that are not established
+ contacts of the user (e.g., as reflected in the user's roster); that
+ is a policy matter for the user, client, or service provider.
+
+
+
+
+Ivov, et al. Informational [Page 10]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ It is also worth noting that callers preferring to remain anonymous
+ as per [RFC3325] would not provide Call-Info information.
+
+4. Multi-Party Interactions
+
+ CUSAX clients that support the SIP conferencing framework [RFC4353]
+ can detect when a call they are participating in is actually a
+ conference and can then subscribe to conference state updates as per
+ [RFC4575]. A regular SIP user agent might also use the same
+ conference URI for text communication with the Message Session Relay
+ Protocol (MSRP). However, given that SIP's instant messaging
+ capabilities would normally be disabled (or simply not supported) in
+ CUSAX deployments, an XMPP Multi-User Chat (MUC) room [XEP-0045]
+ associated with the conference can be announced/discovered through
+ <service-uris> bearing the "grouptextchat" purpose [GROUPTEXTCHAT].
+ Similarly, an XMPP MUC room can advertise the SIP URI of an
+ associated service for audio/video interactions using the
+ 'audio-video-uri' field of the "muc#roominfo" data form [XEP-0004] to
+ include extended information [XEP-0128] about the MUC room within
+ XMPP service discovery [XEP-0030]; see [XEP-0045] for an example.
+ These methods would enable a CUSAX-aware SIP conference server to
+ advertise the existence of an associated XMPP chat room and for a
+ CUSAX-aware XMPP chat room to advertise the existence of an
+ associated SIP conference server.
+
+ If a CUSAX client joins the MUC room associated with a particular
+ call, it should not rely on any synchronization between the two.
+ Both the SIP conference and the XMPP MUC room would function
+ independently, each issuing and delivering its own state updates.
+ Hence, it is possible that certain peers would temporarily or
+ permanently be reachable in only one of the two conferences. This
+ would typically be the case with single-stack clients that have only
+ joined the SIP call or the XMPP MUC room. It is therefore important
+ for CUSAX clients to provide a clear indication to users as to the
+ level of involvement of the various participants: i.e., a user needs
+ to be able to easily understand whether a certain participant can
+ receive text messages, audio/video, or both.
+
+ At the level of the CUSAX service, it is also possible to enforce
+ tighter integration between the XMPP MUC room and the SIP conference.
+ Permissions, roles, kicks, and bans that are granted and performed in
+ the MUC room can easily be imitated by the conference focus/mixer
+ into the SIP call. If, for example, a certain MUC member is muted,
+ the conference mixer can choose to also apply the mute on the media
+ stream corresponding to that participant. However, the details and
+ exact level of such integration are entirely up to implementers and
+ service providers.
+
+
+
+
+Ivov, et al. Informational [Page 11]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ The approach above describes one relatively lightweight possibility
+ of combining SIP and XMPP multi-party interaction semantics without
+ requiring tight integration between the two. As with the rest of
+ this document, this approach is by no means normative.
+ Implementations and future documents may define other methods or
+ provide other suggestions for improving the unified communications
+ user experience in cases of multi-user chats and conference calling.
+
+5. Federation
+
+ In theory, there are no technical reasons why federation (i.e.,
+ inter-domain communication) would require special behavior 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 document. 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 Public Switched Telephone Network (PSTN) by simply
+ dialing numbers. She may even be used to these calls being billed to
+ her online account, so she would be 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 of 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 an
+ XMPP-only client. However, Bob has 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 service-generated signal that triggers a user-interface
+ warning in a CUSAX client, an auditory tone, or a spoken message)
+ indicating that a call would incur unexpected charges.
+
+
+
+
+
+Ivov, et al. Informational [Page 12]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ Another scenario arises when a SIP service allows communication only
+ with intra-domain numbers; here, Alice might be prevented from
+ establishing a call with Bob's mobile phone. Providers should
+ therefore make sure that calls to inter-domain numbers are flagged
+ with an appropriate audio or textual warning.
+
+6. Summary of Suggested Strategies
+
+ The following strategies are suggested for CUSAX user agents:
+
+ 1. By default, prefer SIP for audio and video and XMPP for
+ messaging and presence.
+
+ 2. Use XMPP for all forms of communication with the contacts from
+ the XMPP roster, with the exception of features that are based
+ on establishing real-time sessions (e.g., audio/video calls) for
+ which SIP should be used.
+
+ 3. Provide online provisioning options for providers to remotely
+ set up SIP and XMPP accounts so that users wouldn't need to go
+ through a multi-step configuration process.
+
+ 4. Provide online provisioning options for providers to completely
+ disable features for an account associated with a given protocol
+ (SIP or XMPP) if the features are preferred in another protocol
+ (XMPP or SIP).
+
+ 5. Present a "Call" option for each roster entry that has a
+ properly set "tel" field in the vCard or equivalent.
+
+ 6. If the client is provisioned with only a single telephony-
+ capable account, initiate calls immediately upon user request
+ without asking users to indicate an account that the call should
+ go through.
+
+ 7. If no relationship has been configured or discovered between a
+ SIP account and an XMPP account, and the client is aware of
+ multiple telephony-capable accounts, present the user with the
+ choice of reaching the contact through any of those accounts.
+
+ 8. If known, indicate the existence of a special relationship
+ between the SIP and XMPP accounts of a CUSAX service.
+
+ 9. Optionally, present the XMPP connection as an "instant
+ messaging" or a "chat" account and the SIP connection as a
+ "Voice and Video" or a "Telephony" account.
+
+
+
+
+
+Ivov, et al. Informational [Page 13]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ 10. Optionally, determine the identity of the audio/video caller and
+ a corresponding XMPP roster entry so that the user could use
+ textual chatting or other forms of communication that require
+ XMPP.
+
+ 11. Optionally, delay the XMPP connection until after a SIP
+ connection has been successfully registered.
+
+ 12. Optionally, check for alternative communication methods (SIP
+ addresses advertised over XMPP and XMPP addresses advertised
+ over SIP).
+
+ The following strategies are suggested for CUSAX services:
+
+ 1. Use online provisioning and configuration of accounts so that
+ users won't need to set up two separate accounts for the CUSAX
+ service.
+
+ 2. Use online provisioning so that calling features are disabled for
+ all XMPP accounts.
+
+ 3. Ensure that at least one of the vCard "tel" fields for each XMPP
+ user is properly populated with a SIP URI that is reachable
+ through the SIP service.
+
+ 4. Optionally, include the "video" tel type for accounts that are
+ capable of handling video communication.
+
+ 5. Optionally, provision clients with information indicating that
+ specific SIP and XMPP accounts are related in a CUSAX service.
+
+ 6. Optionally, attach a "Call-Info" header with an "impp" purpose to
+ all SIP INVITE messages, so that clients can more rapidly
+ associate a caller with a roster entry and display a "Caller ID".
+
+7. Security Considerations
+
+ 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. Two
+ security mismatches of particular concern are:
+
+ o The SIP aspect and XMPP aspect of a CUSAX service might offer
+ different authentication options (e.g., digest authentication for
+ SIP as specified in [RFC3261] and Salted Challenge Response
+ Authentication Mechanism (SCRAM) authentication [RFC5802] for XMPP
+ as specified in [RFC6120]). Because SIP uses a password-based
+ method (digest) and XMPP uses a pluggable framework for
+
+
+
+Ivov, et al. Informational [Page 14]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ authentication via the Simple Authentication and Security Layer
+ (SASL) technology [RFC4422], it is also possible that the XMPP
+ connection could be authenticated using a password-free method
+ such as client certificates with SASL EXTERNAL, even though a
+ username and password is used for the SIP connection.
+
+ o The Transport Layer Security (TLS) [RFC5246] ciphersuites offered
+ or negotiated on the XMPP side might be different from those on
+ the SIP side because of implementation or configuration
+ differences between the SIP server and the XMPP server. Even more
+ seriously, a CUSAX client might successfully negotiate TLS when
+ connecting to the XMPP aspect of the service but not when
+ connecting to the SIP aspect, or vice versa. In this situation,
+ an end user might think that the combined CUSAX session with the
+ service is protected by TLS, even though only one aspect is
+ protected.
+
+ Security mismatches such as these (as well as others related to end-
+ to-end encryption of messages or media) introduce the possibility of
+ downgrade attacks, eavesdropping, information leakage, and other
+ security vulnerabilities. User agent developers and service
+ providers must ensure that such mismatches are avoided as much as
+ possible (e.g., by enforcing common and strong security
+ configurations and policies across protocols). Specifically, if both
+ protocols are not safeguarded by similar levels of cryptographic
+ protection, the user must be informed of that fact and given the
+ opportunity to bring both up to the same level.
+
+ Section 5 discusses potential issues that may arise due to a mismatch
+ between client capabilities, such as calls being initiated with costs
+ that are not expected by the end user. Such issues could be
+ triggered maliciously, as well as by accident. Implementers
+ therefore need to provide necessary cues to raise user awareness as
+ suggested in Section 5.
+
+ Refer to the specifications for the relevant SIP and XMPP features
+ for detailed security considerations applying to each "stack" in a
+ CUSAX client.
+
+8. References
+
+8.1. Normative References
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
+ Johnston, A., Peterson, J., Sparks, R., Handley, M.,
+ and E. Schooler, "SIP: Session Initiation Protocol",
+ RFC 3261, June 2002.
+
+
+
+
+Ivov, et al. Informational [Page 15]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, March 2011.
+
+ [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Instant Messaging and Presence",
+ RFC 6121, March 2011.
+
+8.2. Informative References
+
+ [GROUPTEXTCHAT] Ivov, E., "A Group Text Chat Purpose for Conference
+ and Service URIs in the Session Initiation Protocol
+ (SIP) Event Package for Conference State", Work
+ in Progress, June 2013.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process --
+ Revision 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
+ Extensions to the Session Initiation Protocol (SIP)
+ for Asserted Identity within Trusted Networks",
+ RFC 3325, November 2002.
+
+ [RFC4353] Rosenberg, J., "A Framework for Conferencing with
+ the Session Initiation Protocol (SIP)", RFC 4353,
+ February 2006.
+
+ [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication
+ and Security Layer (SASL)", RFC 4422, June 2006.
+
+ [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A
+ Session Initiation Protocol (SIP) Event Package for
+ Conference State", RFC 4575, August 2006.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246,
+ August 2008.
+
+ [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N.
+ Williams, "Salted Challenge Response Authentication
+ Mechanism (SCRAM) SASL and GSS-API Mechanisms",
+ RFC 5802, July 2010.
+
+ [RFC6350] Perreault, S., "vCard Format Specification",
+ RFC 6350, August 2011.
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 16]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+ [RFC6914] Rosenberg, J., "SIMPLE Made Simple: An Overview of
+ the IETF Specifications for Instant Messaging and
+ Presence Using the Session Initiation Protocol
+ (SIP)", RFC 6914, April 2013.
+
+ [RFC6993] Saint-Andre, P., "Instant Messaging and Presence
+ Purpose for the Call-Info Header Field in the
+ Session Initiation Protocol (SIP)", RFC 6993,
+ July 2013.
+
+ [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
+ "WebFinger", RFC 7033, September 2013.
+
+ [XEP-0004] Eatmon, R., Hildebrand, J., Miller, J., Muldowney,
+ T., and P. Saint-Andre, "Data Forms", XSF XEP 0004,
+ August 2007.
+
+ [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P.
+ Saint-Andre, "Service Discovery", XSF XEP 0030,
+ June 2008.
+
+ [XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
+ February 2012.
+
+ [XEP-0054] Saint-Andre, P., "vcard-temp", XSF XEP 0054,
+ July 2008.
+
+ [XEP-0128] Saint-Andre, P., "Service Discovery Extensions", XSF
+ XEP 0128, October 2004.
+
+ [XEP-0152] Hildebrand, J. and P. Saint-Andre, "XEP-0152:
+ Reachability Addresses", XEP XEP-0152,
+ September 2013.
+
+ [XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R.,
+ Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166,
+ December 2009.
+
+ [XEP-0167] Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R.,
+ and D. Cionoiu, "Jingle RTP Sessions", XSF XEP 0167,
+ December 2009.
+
+ [XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP",
+ XSF XEP 0292, September 2013.
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 17]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+Appendix A. Acknowledgements
+
+ This document 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 people for their
+ reviews and suggestions: Sebastien Couture, Dan-Christian Bogos,
+ Richard Brady, Olivier Crete, Aaron Evans, Kevin Gallagher, Adrian
+ Georgescu, Saul Ibarra Corretge, David Laban, Gergely Lukacsy,
+ Spencer MacDonald, Murray Mar, Daniel Pocock, Travis Reitter, and
+ Gonzalo Salgueiro.
+
+ Brian Carpenter, Ted Hardie, Paul Hoffman, and Benson Schliesser
+ reviewed the document on behalf of the General Area Review Team, the
+ Applications Area Directorate, the Security Directorate, and the
+ Operations and Management Directorate, respectively.
+
+ Benoit Claise, Barry Leiba, and Pete Resnick provided helpful and
+ substantive feedback during IESG review.
+
+ The document shepherd was Mary Barnes. The sponsoring Area Director
+ was Gonzalo Camarillo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 18]
+
+RFC 7081 Combined Use of SIP and XMPP November 2013
+
+
+Authors' Addresses
+
+ Emil Ivov
+ Jitsi
+ Strasbourg 67000
+ France
+
+ Phone: +33-177-624-330
+ EMail: emcho@jitsi.org
+
+
+ Peter Saint-Andre
+ Cisco Systems, Inc.
+ 1899 Wynkoop Street, Suite 600
+ Denver, CO 80202
+ USA
+
+ Phone: +1-303-308-3282
+ EMail: psaintan@cisco.com
+
+
+ Enrico Marocco
+ Telecom Italia
+ Via G. Reiss Romoli, 274
+ Turin 10148
+ Italy
+
+ EMail: enrico.marocco@telecomitalia.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov, et al. Informational [Page 19]
+