[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 7081

Network Working Group                                            E. Ivov
Internet-Draft                                                     Jitsi
Intended status: Informational                            P. Saint-Andre
Expires: October 06, 2013                            Cisco Systems, Inc.
                                                              E. Marocco
                                                          Telecom Italia
                                                          April 04, 2013


  CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the
           Extensible Messaging and Presence Protocol (XMPP)
                        draft-ivov-xmpp-cusax-04

Abstract

   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.

Status of This Memo

   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 06, 2013.




Ivov, et al.            Expires October 06, 2013                [Page 1]

Internet-Draft        Combined Use of SIP and XMPP            April 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  . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Multi-Party Interactions  . . . . . . . . . . . . . . . . . .   8
   5.  Federation  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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".  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:

   o  Today, in the context of the 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 elaborated features
      such as multi-user chats, server-stored contact lists, file
      transfer and others.



Ivov, et al.            Expires October 06, 2013                [Page 2]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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 and arguably their most popular use
      case is audio and video calling.

   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.




Ivov, et al.            Expires October 06, 2013                [Page 3]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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.

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 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



Ivov, et al.            Expires October 06, 2013                [Page 4]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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.

3.  Operation

   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



Ivov, et al.            Expires October 06, 2013                [Page 5]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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



Ivov, et al.            Expires October 06, 2013                [Page 6]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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.

   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:


   Call-Info: <xmpp:alice@example.com> ;purpose=impp







Ivov, et al.            Expires October 06, 2013                [Page 7]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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 a vCard entry.  If this confirmation succeeds the client
   would not need to search the entire roster and retrieve all vCards.
   Not performing the check would allow any caller (including malicious
   ones) to employ someone else's identity and perform various scams or
   Man-in-the-Middle attacks.

4.  Multi-Party Interactions

   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.

5.  Federation

   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.








Ivov, et al.            Expires October 06, 2013                [Page 8]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   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.

6.  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.  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.

7.  IANA Considerations

   This document has no actions for the IANA.

8.  Informative References

   [I-D.saintandre-impp-call-info]
              Saint-Andre, P., "Instant Messaging and Presence Purpose
              for the Call-Info Header in the Session Initiation
              Protocol (SIP)", draft-saintandre-impp-call-info-00 (work
              in progress), March 2013.




Ivov, et al.            Expires October 06, 2013                [Page 9]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


   [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.

   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

   [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.

   [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.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              August 2011.

   [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-0152]
              Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability
              Addresses", XEP XEP-0152, February 2013.

   [XEP-0292]
              Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP
              0292, October 2011.









Ivov, et al.            Expires October 06, 2013               [Page 10]

Internet-Draft        Combined Use of SIP and XMPP            April 2013


Appendix A.  Acknowledgements

   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, Sebastien Couture, Olivier
   Crete, Kevin Gallagher, Adrian Georgescu, Saul Ibarra Corretge,
   Daniel Pocock, Travis Reitterd, and Gonzalo Salgueiro.

Authors' Addresses

   Emil Ivov
   Jitsi
   Strasbourg  67000
   France

   Phone: +33-672-811-555
   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.            Expires October 06, 2013               [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/