draft-ivov-xmpp-cusax-09.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-09'>

<?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-177-624-330</phone>
        <email>emcho@jitsi.org</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>
    <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>
    <date />
    <abstract>
      <t>
        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.
      </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>
            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
            related features such as multi-party chat, server-stored
            contact lists, and file transfer <xref target='RFC6914'/>.
          </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 
            <xref target='XEP-0166'/> and
            arguably their most popular use case is audio and video
            calling <xref target='XEP-0167'/>.
          </t>
        </list>
      </t>
      <t>
        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 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.
      </t>
      <figure anchor='figure-1' title='Division of Responsibilities'>
        <artwork><![CDATA[
+------------+      +-------------+
| SIP Server |      | XMPP Server |
+------------+      +-------------+
         \             /
media     \           /  instant messaging,
signaling  \         /   presence, etc.
            \       /
         +--------------+
         | CUSAX Client |
         +--------------+
        ]]></artwork>
      </figure>
      <t>
        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.
      </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). 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.
      </t>
      <t>
        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.
      </t>
      <t>
        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 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.
      </t>
      <t>
        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 <xref target='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.
      </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. Email
        services, for example, have long been affected by the mixed use 
        of SMTP for outgoing mail and 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 sub-optimal.
      </t>
      <t>
        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 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 <xref target='RFC7033'/>).
      </t>
      <t>
        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 
        standalone SIP accounts or XMPP accounts, for which other
        settings are likely to be more appropriate (see 
        Section 3.4 for details).
      </t>
      <t>
        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.
      </t>
      <t>
        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. It could alleviate
        especially situations where one of these 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.
      </t>
      <t>
        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.
      </t>
    </section>
    <section title='Operation'>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <section title='Server-Side Setup'>
        <t>
          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 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 <xref target='XEP-0054'/> or 
          <xref target='XEP-0292'/>.) 
        </t>
        <t>
          Administrators may also choose to include the "video" tel type
          defined in <xref target="RFC6350"/> for accounts that would be
          capable of handling video communication.
        </t>
        <t>
          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.
        </t>
      </section>
      <section title='Service Management'>
        <t>
          The task of operating and managing a standalone SIP service or 
          XMPP service is not always easy.  Combining the two into a unified
          service introduces additional challenges, including:
        </t>
        <t>
          <list style='symbols'>
            <t>
              The necessity of opening additional ports on the client 
              side if SIP functionality is added to an existing XMPP
              deployment or vice-versa.
            </t>
            <t>
              The potential for important differences in security posture
              across SIP and XMPP (e.g., SIP servers and XMPP servers 
              might support different TLS ciphersuites).
            </t>
            <t>
              The need for, ideally, a common authentication backend and
              other infrastructure that is shared across the SIP and XMPP
              aspects of the combined service.
            </t>
            <t>
              Coordinated monitoring and logging of the SIP and XMPP 
              servers to enable the correlation of incidents and the
              pinpointing of problems.
            </t>
            <t>
              The difficulty of troubleshooting client-side issues, e.g. 
              if the client loses connectivity for XMPP but maintains 
              its SIP connection.
            </t>
          </list>
        </t>
        <t>
          Although separation of functionality (SIP for media, 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.
        </t>
        <t>
          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 standalone SIP or XMPP services.  Providers 
          of CUSAX services are advised to consider the potential for such 
          topologies to cause operational challenges.
        </t>
      </section>
      <section title='Client-Side Discovery and Usability'>
        <t>
          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.
        </t>
        <t>
          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 <xref target="RFC6350"/> as 
          the basis for choosing 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).
        </t>
        <t>
          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
          <xref target="XEP-0152">XEP-0152: Reachability Addresses
          </xref>.  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.
        </t>
      </section>
      <section title='Indicating a Relationship Between SIP and XMPP Accounts'>
        <t>
          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".
        </t>
        <t>
          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.
        </t>
        <t>
          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
          vCard was obtained or a SIP account with another provider).
          Similarly, the client would preferentially initiate textual
          chat sessions using her XMPP account.
        </t>
        <t>
          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.
        </t>
      </section>
      <section title='Matching Incoming SIP Calls to XMPP JIDs'>
        <t>
          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 <xref target='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.
          <figure>
            <artwork><![CDATA[
Call-Info: <xmpp:alice@xmpp.example.com> ;purpose=impp
            ]]></artwork>
          </figure>
          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.
        </t>
        <t>
          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. 
        </t>
      </section>
    </section>
    <section title='Multi-Party Interactions'>
      <t>
        CUSAX clients that support the SIP conferencing framework
        <xref target="RFC4353"/> can detect when a call they are
        participating in is actually a conference and can then subscribe
        to conference state updates as per <xref target="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 <xref target='XEP-0045'/> 
        associated with the conference can be announced/discovered through
        &lt;service-uris&gt; bearing the "grouptextchat" purpose
        <xref target='I-D.ivov-grouptextchat-purpose'/>. 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 <xref target='XEP-0004'/> to include 
        extended information <xref target='XEP-0128'/> about the MUC room 
        within XMPP service discovery <xref target='XEP-0030'/>; see
        <xref target='XEP-0045'/> for an example.  These methods would 
        enable a CUSAX-aware SIP conference server to advertise the 
        existence of an associated XMPP chatroom, and for a CUSAX-aware
        XMPP chatroom to advertise the existence of an associated SIP
        conference server.
      </t>
      <t>
        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 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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
    </section>
    <section title='Federation' anchor="federation">
      <t>
        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.
      </t>
      <t>
        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 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 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
        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.
      </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 incurring 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., 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.
      </t>
      <t>
        Another scenario arises when a SIP service allow 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.
      </t>
    </section>
    <section title='Summary of Suggested Strategies'>
      <t>
        The following strategies are suggested for CUSAX user agents:
      </t>
      <t>
        <list style='numbers'>
          <t>
            By default, prefer SIP for audio and video, and XMPP for
            messaging and presence.
          </t>
          <t>
            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.
          </t>
          <t>
            Provide online provisioning options for providers to
            remotely setup SIP and XMPP accounts so that users wouldn't
            need to go through a multi-step configuration process.
          </t>
          <t>
            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).
          </t>
          <t>
            Present a "Call" option for each roster entry that has a
            properly set "tel" field in the vCard or equivalent.
          </t>
          <t>
            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.
          </t>
          <t>
            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.
          </t>
          <t>
            If known, indicate the existence of a special relationship
            between the SIP and XMPP accounts of a CUSAX service.
          </t>
          <t>
            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" acccount.
          </t>
          <t>
            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.
          </t>
          <t>
            Optionally, delay the XMPP connection until after a SIP
            connection has been successfully registered.
          </t>
          <t>
            Optionally, check for alternative communication methods
            (SIP addresses advertised over XMPP, and XMPP addresses
            advertised over SIP).
          </t>
        </list>
      </t>
      <t>The following strategies are suggested for CUSAX services:</t>
      <t>
        <list style='numbers'>
          <t>
            Use online provisioning and configuration of accounts so
            that users won't need to setup two separate accounts for
            the CUSAX service.
          </t>
          <t>
            Use online provisioning so that calling features are
            disabled for all XMPP accounts.
          </t>
          <t>
            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.
          </t>
          <t>
            Optionally, include the "video" tel type for accounts that
            are capable of handling video communication.
          </t>
          <t>
            Optionally, provision clients with information indicating
            that specific SIP and XMPP accounts are related in a CUSAX
            service.
          </t>
          <t>
            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".
          </t>
        </list>
      </t>
    </section>
    <section title='IANA Considerations'>
      <t>This document has no actions for the IANA.</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.  Two
        security mismatches of particular concern are:
      </t>
      <t>
        <list style='symbols'>
          <t>
            The SIP aspect and XMPP aspect of a 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'/>).  Because SIP uses a
            password-based method (digest) and XMPP uses a 
            pluggable framework for authentication via the Simple 
            Authentication and Security Layer (SASL) technology
            <xref target='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.
          </t>
          <t>
            The Transport Layer Security (TLS) <xref target='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.
          </t>
        </list>
      </t>
      <t>
        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.
      </t>
      <t>
        <xref target="federation"/> 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
        <xref target="federation"/>.
      </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>
    </section>
  </middle>
  <back>
    <references title='Normative References'>
      <?rfc include="reference.RFC.3261"?>
      <?rfc include="reference.RFC.6120"?>
      <?rfc include="reference.RFC.6121"?>
    </references>
    <references title='Informative References'>
      <reference anchor='I-D.ivov-grouptextchat-purpose'>
        <front>
          <title>
            A Group Text Chat Purpose for Conference and Service URIs in
            the Session
            Initiation Protocol (SIP) Event Package for Conference State
          </title>
          <author initials='E' surname='Ivov' fullname='Emil Ivov'>
            <organization/>
          </author>
          <date month='June' day='18' year='2013'/>
          <abstract>
            <t>
              This document defines and registers a value of
              "grouptextchat"
              ("Group Text Chat") value for the URI &lt;purpose> element
              of
              SIP's Conference Event Package [RFC4575].
            </t>
          </abstract>
        </front>
        <seriesInfo name='Internet-Draft'
                    value='draft-ivov-grouptextchat-purpose-03'/>
        <format type='TXT'
                target='http://www.ietf.org/internet-drafts/draft-ivov-grouptextchat-purpose-03.txt'/>
      </reference>
      <?rfc include="reference.RFC.2026"?>
      <?rfc include="reference.RFC.4353"?>
      <?rfc include="reference.RFC.4422"?>
      <?rfc include="reference.RFC.4575"?>
      <?rfc include="reference.RFC.5246"?>
      <?rfc include="reference.RFC.5802"?>
      <?rfc include="reference.RFC.6350"?>
      <?rfc include="reference.RFC.6914"?>
      <?rfc include="reference.RFC.6993"?>
      <?rfc include="reference.RFC.7033"?>

      <reference anchor="XEP-0004">
        <front>
          <title>Data Forms</title>
          <author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
            <organization/>
            <address>
              <email>reatmon@jabber.org</email>
            </address>
          </author>
          <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
            <organization/>
            <address>
              <email>jhildebr@cisco.com</email>
            </address>
          </author>
          <author initials="J." surname="Miller" fullname="Jeremie Miller">
            <organization/>
            <address>
              <email>jer@jabber.org</email>
            </address>
          </author>
          <author initials="T." surname="Muldowney" fullname="Thomas Muldowney">
            <organization/>
            <address>
              <email>temas@jabber.org</email>
            </address>
          </author>
          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
            <organization/>
            <address>
              <email>stpeter@jabber.org</email>
            </address>
          </author>
          <date day="13" month="August" year="2007"/>
        </front>
        <seriesInfo name="XSF XEP" value="0004"/>
        <format type="HTML" target="http://xmpp.org/extensions/xep-0004.html"/>
      </reference>
      <reference anchor="XEP-0030">
        <front>
          <title>Service Discovery</title>
          <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
            <organization/>
            <address>
              <email>jhildebr@cisco.com</email>
            </address>
          </author>
          <author initials="P." surname="Millard" fullname="Peter Millard">
            <organization/>
            <address>
              <email/>
            </address>
          </author>
          <author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
            <organization/>
            <address>
              <email>reatmon@jabber.org</email>
            </address>
          </author>
          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
            <organization/>
            <address>
              <email>stpeter@jabber.org</email>
            </address>
          </author>
          <date day="06" month="June" year="2008"/>
        </front>
        <seriesInfo name="XSF XEP" value="0030"/>
        <format type="HTML" target="http://xmpp.org/extensions/xep-0030.html"/>
      </reference>
      <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-0128">
        <front>
          <title>Service Discovery Extensions</title>
          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
            <organization/>
            <address>
              <email>stpeter@jabber.org</email>
            </address>
          </author>
          <date day="20" month="October" year="2004"/>
        </front>
        <seriesInfo name="XSF XEP" value="0128"/>
        <format type="HTML" target="http://xmpp.org/extensions/xep-0128.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 day="25" month="September" year="2013" />
        </front>
        <seriesInfo name="XEP" value="XEP-0152" />
      </reference>
<reference anchor="XEP-0166">
  <front>
    <title>Jingle</title>
    <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
      <organization/>
      <address>
        <email>scottlu@google.com</email>
      </address>
    </author>
    <author initials="J." surname="Beda" fullname="Joe Beda">
      <organization/>
      <address>
        <email>jbeda@google.com</email>
      </address>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="R." surname="McQueen" fullname="Robert McQueen">
      <organization/>
      <address>
        <email>robert.mcqueen@collabora.co.uk</email>
      </address>
    </author>
    <author initials="S." surname="Egan" fullname="Sean Egan">
      <organization/>
      <address>
        <email>seanegan@google.com</email>
      </address>
    </author>
    <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
      <organization/>
      <address>
        <email>jhildebr@cisco.com</email>
      </address>
    </author>
    <date day="23" month="December" year="2009"/>
  </front>
  <seriesInfo name="XSF XEP" value="0166"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0166.html"/>
</reference>
<reference anchor="XEP-0167">
  <front>
    <title>Jingle RTP Sessions</title>
    <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
      <organization/>
      <address>
        <email>scottlu@google.com</email>
      </address>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="S." surname="Egan" fullname="Sean Egan">
      <organization/>
      <address>
        <email>seanegan@google.com</email>
      </address>
    </author>
    <author initials="R." surname="McQueen" fullname="Robert McQueen">
      <organization/>
      <address>
        <email>robert.mcqueen@collabora.co.uk</email>
      </address>
    </author>
    <author initials="D." surname="Cionoiu" fullname="Diana Cionoiu">
      <organization/>
      <address>
        <email>diana@null.ro</email>
      </address>
    </author>
    <date day="23" month="December" year="2009"/>
  </front>
  <seriesInfo name="XSF XEP" value="0167"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0167.html"/>
</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="12" month="September" year="2013"/>
        </front>
        <seriesInfo name="XSF XEP" value="0292"/>
        <format type="HTML"
                target="http://xmpp.org/extensions/xep-0292.html"/>
      </reference>
    </references>
    <section title='Acknowledgements'>
      <t>
        This draft is inspired by the "SIXPAC" work of Markus Isomaki
        and Simo Veikkolainen. Markus also provided various suggestions
        for improving the document.
      </t>
      <t>
        The authors would also like to thank the following people for
        their reviews and suggestions: Sébastien Couture, Dan-Christian
        Bogos, Richard Brady, Olivier Crête, Aaron Evans, 
        Kevin Gallagher, Adrian Georgescu, Saúl Ibarra Corretgé, David
        Laban, Gergely Lukacsy, Murray Mar, Daniel Pocock, Travis
        Reitter, and Gonzalo Salgueiro.
      </t>
      <t>
        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.
      </t>
      <t>
        Benoit Claise, Barry Leiba, and Pete Resnick provided helpful and
        substantive feedback during IESG review.
      </t>
      <t>
        The document shepherd was Mary Barnes.  The sponsoring Area 
        Director was Gonzalo Camarillo.</t>
    </section>
  </back>
</rfc>