One document matched: draft-ivov-xmpp-cusax-08.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-08'>
<?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). Such strategies 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 document does not define any
new protocols or syntax for either SIP or XMPP, and by intent
it does not attempt to standardize "best current practices".
However, implementing the suggested strategies outlined in this
document 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>
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-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>
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 explains how such hybrid offerings can be achieved
with a minimum of modifications to existing software 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 it also suggests 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
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.
</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).
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
or obtained from a user directory).
However, the rules to follow in such cases are
left to application developers (although they might be
described in a future document).
</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 <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) at which to connect, 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 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.
</t>
<t>
While it should be possible for CUSAX users to manually
configure their separate SIP and XMPP accounts (often by
means of so-called "wizard" interfaces), service
providers offering CUSAX services to users of dual-stack
SIP/XMPP clients ought to provide means of online provisioning,
typically by means of a web-based service at an HTTP URI
(naturally single-purpose SIP services or XMPP services could
offer online provisioning 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
that space (e.g., perhaps based on technologies such as
WebFinger <xref target='I-D.ietf-appsawg-webfinger'/>).
</t>
<t>
A CUSAX client should make it possible for a user to configure
the software so that a given feature (say, video conferencing
or textual chat) to use by default a given protocol (say, SIP
for video conferencing and XMPP for textual chat). In particular,
it is suggested that CUSAX clients allow for audio and video calling
features to be disabled over XMPP, and for instant messaging and
presence features to be disabled over SIP. It is a matter of
implementation whether a CUSAX client enables a user to override
such defaults in various ways (e.g., by domain, by individual
contact, or by device).
</t>
<t>
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.
</t>
<t>
Once clients have been provisioned, they need to independently
log into the SIP and XMPP accounts that make up the CUSAX
"service" and then maintain both these connections.
</t>
<t>
In order to improve the user experience, when reporting
connection status clients may also wish to present the XMPP
connection as an "instant messaging" or a "chat" account.
Similarly they could also depict 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. Naturally, the
developers of a CUSAX client or the providers of a CUSAX service
might decide not to accept such situations and 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 its contacts
but calling it would fail because their clients is still
connecting to the SIP aspect of their 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 all 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 any form of
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 allow CUSAX clients to fall back and
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 or a phone number
when an XMPP protocol for vCard storage is used (e.g.,
<xref target='XEP-0054'/> or <xref target='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. (The same considerations apply even if
the directory storage format is not vCard.)
</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 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>
</section>
<section title='Service Management'>
<t>
The task of operating and managing a SIP service or an 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 subtle 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, do not provide a way
for the user to start a video call with 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 association
(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
association 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 Relation 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 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).
</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
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
for conference state updates as per <xref target="RFC4575"/>.
A regular SIP user agent would 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) <xref target='XEP-0045'/>
associated with the conference can be announced/discovered through
<service-uris> bearing the "grouptextchat" purpose
<xref target='I-D.ivov-grouptextchat-purpose'/>. Similarly, an
XMPP MUC 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>
Once a CUSAX client joins the MUC associated with a particular
call it should not rely on any synchronization between the two.
Both the SIP conference and the XMPP MUC would function
independently, each issuing and delivering its own state
updates. It is hence 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. It
is therefore important for CUSAX clients to provide a clear
indication to users as to the level of participation of the
various participants. In other words, 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 and the SIP conference.
Permissions, roles, kicks and bans
that are granted and performed in the MUC 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. The details and exact level of such integration is
of course 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 in conference calling.
</t>
</section>
<section title='Federation' anchor="federation">
<t>
In theory there are no technical reasons why federation 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
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 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 charges.
</t>
<t>
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
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) in which case use SIP.
</t>
<t>
Provide on-line 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 on-line 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.
</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>
Optionally, 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
revert to 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
your 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 or a phone
number that are reachable through your 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 your 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='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 contrary to the expectation of
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>
<section title='IANA Considerations'>
<t>This document has no actions for the IANA.</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 <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.I-D.ietf-appsawg-webfinger"?>
<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 month="February" 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>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:27 |