draft-ivov-xmpp-cusax-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc category='info' ipr='trust200902'
     docName='draft-ivov-xmpp-cusax-03'>

<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>

  <front>

    <title abbrev='Combined Use of SIP and XMPP'>
      CUSAX: Combined Use of the Session Initiation Protocol (SIP) and
      the Extensible Messaging and Presence Protocol (XMPP)
    </title>
    <author initials='E.' surname='Ivov' fullname='Emil Ivov'>
      <organization abbrev='Jitsi'>Jitsi</organization>
      <address>
        <postal>
          <street></street>
          <city>Strasbourg</city>
          <code>67000</code>
          <country>France</country>
        </postal>
        <phone>+33-672-811-555</phone>
        <email>emcho@jitsi.org</email>
      </address>
    </author>
    <author initials='E.' surname='Marocco' fullname='Enrico Marocco'>
      <organization>Telecom Italia</organization>
      <address>
        <postal>
          <street>Via G. Reiss Romoli, 274</street>
          <city>Turin</city>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <email>enrico.marocco@telecomitalia.it</email>
      </address>
    </author>
    <author initials='P.' surname='Saint-Andre' 
            fullname='Peter Saint-Andre'>
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1899 Wynkoop Street, Suite 600</street>
          <city>Denver</city>
          <region>CO</region>
          <code>80202</code>
          <country>USA</country>
        </postal>
        <phone>+1-303-308-3282</phone>
        <email>psaintan@cisco.com</email>
      </address>
    </author>
    <date />
    <abstract>
      <t>
        This document describes recommended 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.
      </t>
    </abstract>
  </front>
  <middle>
    <section title='Introduction'>
      <t>
        Historically <xref target="RFC3261">SIP</xref> and 
        <xref target="RFC6120">XMPP</xref> 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
        <xref target="RFC6121"/>, as well as related services such as
        groupchat rooms <xref target="XEP-0045"/>.
      </t>
      <t>
        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:
      </t>
      <t>
        <list style='symbols'>
          <t>
        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.
          </t>
          <t>
        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.
          </t>
        </list>
      </t>
      <t>
        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 <xref target="RFC4975">MSRP</xref> and 
        <xref target="RFC4825">XCAP</xref>.  
      </t>
      <t>
        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.      
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        Finally, this document concentrates on use cases where the SIP
        and the XMPP services are controlled by one an the same
        provider. This document being 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 means to its users to
        easily start a call to a phone number recorded in a vCard. The
        exact set of rules to follow in such cases is left to
        application developers.
      </t>
    </section>
    <section title='Client Bootstrap'>
      <t>
        One of the main problems of using two distinct protocols when
        providing one service is the impact on usability. E-mail
        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 e-mail 
        services. While this may improve the situation to some extent, 
        the user experience is still clearly sub-optimal.
      </t>
      <t>
        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).
      </t>
      <t>
        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/video calling features to be disabled for XMPP
        accounts. Additionally, instant messaging and presence features 
        should also be made optional for SIP accounts.
      </t>
      <t>
        The main advantage of the above would be that clients would be
        able to continue to function properly and use the complete 
        feature set of stand-alone SIP and XMPP accounts. 
      </t>
      <t>
        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 CUSAX XMPP 
        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.
      </t>
    </section>
    <section title='Operation'>
      <t>
        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 <xref target="RFC6350">vCard</xref> "tel" 
        fields for each contact is properly populated with a SIP URI or 
        a phone number when an XMPP protocol for vCard storage (e.g., 
        <xref target='XEP-0054'/> or <xref target='XEP-0292'/>) is used.
        There are no limitations as to the form of that number. For
        example while maintaining a certain consistency between SIP AORs
        and XMPP JIDs, it 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.
      </t>
      <t>
        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 <xref target="RFC6350"/> and
        enable or disable the possibility for starting video calls
        accordingly.
      </t>
      <t>
        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.
      </t>
      <t>  
        When rendering the XMPP roster 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 do so immediately upon user request without asking for 
        confirmation. This way CUSAX users whose only account with 
        calling capabilities would often be the SIP part of their 
        service, would have a better user experience. If on the other 
        hand, the CUSAX client is aware of multiple telephony-capable 
        accounts, it ought to present the user with the choice of 
        reaching the phone number through any of them (including the 
        source XMPP account where the vCard was obtained) in order to 
        guarantee proper operation for XMPP accounts that are not part 
        of a CUSAX deployment.
      </t>
      <t> 
        In addition to discovering phone numbers from vCards, clients
        may also check presence broadcasts and the appropriate Personal
        Eventing Protocol nodes as described in <xref target="XEP-0152">
        XEP-0152: Reachability Addresses</xref>. 
      </t>
      <t> 
        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 voice/video
        features were disabled in the XMPP stack.
      </t>
      <t>
        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.
      </t>
      <t>
        In addition, in order to avoid the effort of iterating over an
        entire roster and retrieving all vCards, when running in trusted
        SIP domains <xref target="RFC5876"/> CUSAX clients may use XMPP
        JIDs that appear in P-Asserted-Identity headers
        <xref target="RFC5122"/>. Using P-Preferred-Identity headers in
        non-trusted domains is also a possibility, however only 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.
      </t>
    </section>
    <section title='Context'>
      <t>
        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.
      </t>
    </section>
    <section title='Federation'>
      <t>
        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.
      </t>
      <t>
        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 vCard-s 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.
      </t>
      <t>
        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.
      </t>
      <t>
        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 unexpected charges for such calls.
      </t>
      <t>
        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. an audio tone or message) indicating that
        a call would incur charges.
      </t>
      <t>
        A slightly less disturbing scenario, where a SIP service would
        only allow communication with intra-domain numbers would simply
        prevent Alice from establishing a call with SIP's mobile.
        Providers should hence make sure that calls to extra-domain
        numbers for with an appropriate audio or text error-message.
      </t>
    </section>
    <section title='Security Considerations'>
      <t>
        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 <xref target='RFC3261'/>
        and SCRAM authentication <xref target='RFC5802'/> for XMPP as
        specified in <xref target='RFC6120'/>). Similarly, a CUSAX client
        might successfully negotiate Transport Layer Security (TLS) 
        <xref target='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.
      </t>
      <t>
        Refer to the specifications for the relevant SIP and XMPP 
        features for detailed security considerations applying to 
        each "stack" in a CUSAX client.
      </t>
      <t>
        It is important to note that blind use of the P-Asserted-Domain
        and P-Preferred-Identity headers MUST NOT happen outside of
        trusted SIP domains, or otherwise it would be
      </t>
    </section>
    <section title='IANA Considerations'>
      <t>This document has no actions for the IANA.</t>
    </section>
    <section title='Acknowledgements'>
      <t>
        This draft is inspired by the SIXPAC work from Markus Isomaki
        and Simo Veikkolainen. Markus also provided various suggestions
        for improving the documentation.
      </t>
      <t>
        The authors would also like to thank the following persons for
        their reviews and suggestions for improving this specification:
        Adrian Georgescu, Daniel Pocock, Gonzalo
        Salgueiro, Kevin Gallagher, Olivier Crete, Saúl Ibarra Corretgé,
        Sébastien Couture and Travis Reitter.
      </t>
    </section>
  </middle>
  <back>
    <references title='Informative References'>
      <?rfc include="reference.RFC.3261"?>
      <?rfc include="reference.RFC.3264"?>
      <?rfc include="reference.RFC.3489"?>
      <?rfc include="reference.RFC.3711"?>
      <?rfc include="reference.RFC.4474"?>
      <?rfc include="reference.RFC.4566"?>
      <?rfc include="reference.RFC.5122"?>
      <?rfc include="reference.RFC.4787"?>
      <?rfc include="reference.RFC.4825"?>
      <?rfc include="reference.RFC.4975"?>
      <?rfc include="reference.RFC.5245"?>
      <?rfc include="reference.RFC.5246"?>
      <?rfc include="reference.RFC.5389"?>
      <?rfc include="reference.RFC.5751"?>
      <?rfc include="reference.RFC.5766"?>
      <?rfc include="reference.RFC.5802"?>
      <?rfc include="reference.RFC.5853"?>
      <?rfc include="reference.RFC.5876"?>
      <?rfc include="reference.RFC.6120"?>
      <?rfc include="reference.RFC.6121"?>
      <?rfc include="reference.RFC.6189"?>
      <?rfc include="reference.RFC.6350"?>
      <reference anchor="XEP-0045">
        <front>
          <title>Multi-User Chat</title>
          <author initials="P." surname="Saint-Andre"
                  fullname="Peter Saint-Andre">
            <organization/>
            <address>
              <email>stpeter@jabber.org</email>
            </address>
          </author>
          <date day="08" month="February" year="2012"/>
        </front>
        <seriesInfo name="XSF XEP" value="0045"/>
        <format type="HTML"
                target="http://xmpp.org/extensions/xep-0045.html"/>
      </reference>
      <reference anchor="XEP-0054">
        <front>
          <title>vcard-temp</title>
          <author initials="P." surname="Saint-Andre"
                  fullname="Peter Saint-Andre">
            <organization/>
            <address>
              <email>stpeter@jabber.org</email>
            </address>
          </author>
          <date day="16" month="July" year="2008"/>
        </front>
        <seriesInfo name="XSF XEP" value="0054"/>
        <format type="HTML"
                target="http://xmpp.org/extensions/xep-0054.html"/>
      </reference>
      <reference anchor="XEP-0152">
        <front>
        <title>XEP-0152: Reachability Addresses</title>
        <author initials='J.' surname='Hildebrand'
                    fullname='J. Hildebrand'>
                <organization abbrev='Cisco'>
                Cisco
                </organization>
        </author>
        <author initials='P.' surname='Saint-Andre'
                    fullname='Peter Saint-Andre'>
                <organization abbrev='Cisco'>
                Cisco
                </organization>
        </author>
        <date month="October" year="2008" />
        </front>
        <seriesInfo name="XEP" value="XEP-0152" />
      </reference>
      <reference anchor="XEP-0292">
        <front>
          <title>vCard4 Over XMPP</title>
          <author initials="P." surname="Saint-Andre"
                  fullname="Peter Saint-Andre">
            <organization/>
            <address>
              <email>stpeter@jabber.org</email>
            </address>
          </author>
          <author initials="S." surname="Mizzi"
                  fullname="Samantha Mizzi">
            <organization/>
            <address>
              <email>samizzi@cisco.com</email>
            </address>
          </author>
          <date day="09" month="October" year="2011"/>
        </front>
        <seriesInfo name="XSF XEP" value="0292"/>
        <format type="HTML"
                target="http://xmpp.org/extensions/xep-0292.html"/>
      </reference>
    </references>
  </back>
</rfc>