One document matched: draft-ivov-xmpp-cusax-02.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-02'>
<?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'>
Combined Use of the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (CUSAX)
</title>
<author initials='E.' surname='Ivov' fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
<address>
<postal>
<street></street>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<phone>+33-672-811-555</phone>
<email>emcho@jitsi.org</email>
</address>
</author>
<author initials='E.' surname='Marocco' fullname='Enrico Marocco'>
<organization>Telecom Italia</organization>
<address>
<postal>
<street>Via G. Reiss Romoli, 274</street>
<city>Turin</city>
<code>10148</code>
<country>Italy</country>
</postal>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials='P.' surname='Saint-Andre'
fullname='Peter Saint-Andre'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<date />
<abstract>
<t>
This document describes current practices for combined use of
the Session Initiation Protocol (SIP) and the Extensible
Messaging and Presence Protocol (XMPP). Such practices aim to
provide a single fully featured real-time communication service
by using complementary subsets of features from each of the
protocols. Typically such subsets would include telephony
capabilities from SIP and instant messaging and presence
capabilities from XMPP. This specification does not define any
new protocols or syntax for either SIP or XMPP. However,
implementing it may require modifying or at least reconfiguring
existing client and server-side software. Also, it is not the
purpose of this document to make recommendations as to whether
or not such combined use should be preferred to the mechanisms
provided natively by each protocol like for example SIP's SIMPLE
or XMPP's Jingle. It merely aims to provide guidance to those
who are interested in such a combined use.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
Historically <xref target="RFC3261">SIP</xref> and
<xref target="RFC6120">XMPP</xref> have often been implemented
and deployed with different purposes: from its very start SIP's
primary goal has been to provide a means of conducting "Internet
telephone calls". XMPP on the other hand, has, from its Jabber
days, been mostly used for instant messaging and presence
<xref target="RFC6121"/>, as well as related services such as
groupchat rooms <xref target="XEP-0045"/>.
</t>
<t>
For various reasons, these trends have continued through the
years even after each of the protocols had been equipped to
provide the features it was initially lacking:
</t>
<t>
<list style='symbols'>
<t>
Today, in the context of the SIMPLE working group, the IETF has
defined a number of protocols and protocol extensions that not
only allow for SIP to be used for regular instant messaging and
presence but that also provide mechanisms for elaborated
features such as multi-user chats, server-stored contact lists,
file transfer and others.
</t>
<t>
Similarly, the XMPP community and the XMPP Standards Foundation
have worked on defining a number of XMPP Extension Protocols
(XEPs) that provide XMPP implementations with the means of
establishing end-to-end sessions. These extensions are often
jointly referred to as Jingle and their arguably most popular
use case are audio and video calls.
</t>
</list>
</t>
<t>
Despite these advances, SIP remains the protocol of choice
for telephony-like services, especially in enterprises where
users are accustomed to features such as voice mail, call park,
call queues, conference bridges and many others that are rarely
(if at all) available in Jingle-based software. XMPP implementations, on
the other hand, greatly outnumber and outperform those available
for instant messaging and presence extensions developed in
the SIMPLE WG, such as <xref target="RFC4975">MSRP</xref> and
<xref target="RFC4825">XCAP</xref>.
</t>
<t>
For these reasons, in a number of cases adopters have found
themselves needing a set of features that are not offered by any
single-protocol solution but that separately exist in SIP and
XMPP products. The idea of seamlessly using both protocols
together would hence often appeal to service providers.
</t>
<t>
Most often the combined use of SIP and XMPP ("CUSAX") would
employ SIP exclusively for audio, video, and telephony services
and rely on XMPP for anything else varying from chat, contact
list management, and presence to whiteboarding and exchanging
files.
</t>
<t>
This document explains how such hybrid offerings can be achieved
with a minimum of modifications to existing software while
providing an optimal user experience. It tries to cover points
such as server discovery, determining a SIP AOR while using
XMPP and determining an XMPP Jabber Identifier ("JID") from incoming SIP requests.
Most of the text here pertains to client behavior but it also
recommends certain server-side configurations.
</t>
<t>
Note that this document is focused on coexistence of SIP and
XMPP functionality in end-user-oriented clients. By intent it
does not define methods for protocol-level mapping between SIP
and XMPP, as might be used within a server-side gateway between
a SIP network and an XMPP network. A separate series of documents
has been produced that defines such mappings.
</t>
</section>
<section title='Client Bootstrap'>
<t>
One of the main problems of using two distinct protocols when
providing one service is the effect on usability. E-mail
services, for example, have long been affected by the mixed use
of SMTP for outgoing mail and POP3 or IMAP for incoming mail,
making it rather complicated for inexperienced users to
configure a mail client and start using it with a new service.
As a result, Internet service providers often need to provide
configuration instructions for various mail clients. Client
developers and communication device manufacturers on the other
hand often ship with a number of wizards that enable users to
easily set up a new account for a number of popular e-mail
services. While this may improve the situation to some extent,
the user experience is still clearly sub-optimal.
</t>
<t>
While it should be possible for CUSAX users to manually
configure their separate SIP and XMPP accounts, dual-stack
SIP/XMPP clients ought to provide means of online provisioning.
While the specifics of such mechanisms are outside the scope of
this specification, they should make it possible for a service
provider to remotely configure the clients based on minimal
user input (e.g., only a user ID and password).
</t>
<t>
Because many of the features that a CUSAX client would privilege
in one protocol would also be available in the other, clients
should make it possible for such features to be disabled for a
specific account. In particular, it is suggested that clients
allow for audio/video calling features to be disabled for XMPP
accounts. Additionally, instant messaging and presence features
should also be made optional for SIP accounts.
</t>
<t>
The main advantage of the above would be that clients would be
able to continue to function properly and use the complete
feature set of stand-alone SIP and XMPP accounts.
</t>
<t>
Once client bootstrap has completed, clients need to log in
independently to the SIP and XMPP accounts that make up the
CUSAX "service" and then maintain both these connections. In
order to improve user experience, when reporting connection
status clients may also wish to present the CUSAX XMPP
connection as an "instant messaging" or a "chat" account.
Similarly they could also depict the SIP CUSAX connection as a
"Voice and Video" or a "Telephony" connection. The exact naming
is of course entirely up to implementers. The point is that, in
cases where SIP and XMPP are components of a service offered by
a single provider, such presentation could help users better
understand why they are being shown two different connections
for what they perceive as a single service. It could alleviate
especially situations where one of these connections is
disrupted while the other one is successfully maintained.
</t>
</section>
<section title='Operation'>
<t>
Once a CUSAX client has been provisioned/configured to connect
to the corresponding SIP and XMPP services it would proceed by
retrieving its XMPP roster. In order for CUSAX to function
properly, XMPP service administrators should make sure that at
least one of the <xref target="RFC6350">vCard</xref> "tel"
fields for each contact is properly populated with a SIP URI or
a phone number when an XMPP protocol for vCard storage (e.g.,
<xref target='XEP-0054'/> or <xref target='XEP-0292'/>) is used.
There are no limitations as to the form of that number (e.g. it
does not need to respect any equivalence with the XMPP JID).
However, it ought to be reachable through the SIP aspect of this
CUSAX service.
</t>
<t>
To ensure that the foregoing approach is always respected,
service providers might consider (1) preventing clients (and
hence users) from modifying the vCard "tel" fields or (2)
applying some form of validation before recording changes. Of
course such validation would be feasible mostly in cases where
one single provider controls both the XMPP and the SIP service
since such providers would "know" (e.g., based on use of a common
user database for both services) what SIP AOR corresponds to
a given XMPP user.
</t>
<t>
When rendering the XMPP roster CUSAX clients should make sure
that users are presented with a "Call" option for each roster
entry that has a properly set "tel" field even if calling has
been disabled for that particular XMPP account. The usefulness
of such a feature is not limited to CUSAX. After all, numbers
are entered in vCards in order to be dialed and called. Hence,
as long as an XMPP client is equipped with accounts that have
calling features it may wish to present the user with the
option of using these accounts to reach numbers from an XMPP
vCard. In order to improve usability, in cases where clients are
provisioned with only a single telephony-capable account they
ought to do so immediately upon user request without asking for
confirmation. This way CUSAX users whose only account with
calling capabilities would often be the SIP part of their
service, would have a better user experience. If on the other
hand, the CUSAX client is aware of multiple telephony-capable
accounts, it ought to present the user with the choice of
reaching the phone number through any of them (including the
source XMPP account where the vCard was obtained) in order to
guarantee proper operation for XMPP accounts that are not part
of a CUSAX deployment.
</t>
<t>
In addition to discovering phone numbers from vCards, clients
may also check presence broadcasts and the appropriate Personal
Eventing Protocol nodes as described in <xref target="XEP-0152">
XEP-0152: Reachability Addresses</xref>.
</t>
<t>
The client should use XMPP for all other forms of communication
with the contacts from its roster, which will occur naturally
because they were retrieved through XMPP and only voice/video
features were disabled in the XMPP stack.
</t>
<t>
When receiving SIP calls, clients may wish to determine the
identity of the caller and bind it to a roster entry so that
users could revert to chatting or other forms of communication
that require XMPP. To do so clients could search their roster
for an entry whose vCard has a "tel" field matching the
originator of the call.
</t>
<t>
An alternate mechanism would be for CUSAX clients to add to
their SIP invite requests a Contact header containing the
XMPP URI corresponding to their JID as per
<xref target="RFC5122"/>.
</t>
</section>
<section title='Federation'>
<t>
An alternate mechanism would be for CUSAX clients to add to
</t>
</section>
<section title='Security Considerations'>
<t>
Use of the same user agent with two different accounts providing
complementary features introduces the possibility of mismatches
between the security profiles of those accounts or features.
For example, the SIP aspect and XMPP aspect of the CUSAX service
might offer different authentication options (e.g., digest
authentication for SIP as specified in <xref target='RFC3261'/>
and SCRAM authentication <xref target='RFC5802'/> for XMPP as
specified in <xref target='RFC6120'/>). Similarly, a CUSAX client
might successfully negotiate Transport Layer Security (TLS)
<xref target='RFC5246'/> when connecting to the XMPP aspect of
the service but not when connecting to the SIP aspect. Such
mismatches could introduce the possibility of downgrade attacks.
User agent developers and service providers ought to ensure
that such mismatches are avoided as much as possible.
</t>
<t>
Refer to the specifications for the relevant SIP and XMPP
features for detailed security considerations applying to
each "stack" in a CUSAX client.
</t>
</section>
<section title='Acknowledgements'>
<t>
This draft is inspired by work from Markus Isomaki and Simo
Veikkolainen.
</t>
</section>
</middle>
<back>
<references title='Informative References'>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3489"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.4474"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5122"?>
<?rfc include="reference.RFC.4787"?>
<?rfc include="reference.RFC.4825"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5246"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5751"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.5802"?>
<?rfc include="reference.RFC.5853"?>
<?rfc include="reference.RFC.6120"?>
<?rfc include="reference.RFC.6121"?>
<?rfc include="reference.RFC.6189"?>
<?rfc include="reference.RFC.6350"?>
<reference anchor="XEP-0045">
<front>
<title>Multi-User Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="08" month="February" year="2012"/>
</front>
<seriesInfo name="XSF XEP" value="0045"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0045.html"/>
</reference>
<reference anchor="XEP-0054">
<front>
<title>vcard-temp</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="16" month="July" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0054"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0054.html"/>
</reference>
<reference anchor="XEP-0152">
<front>
<title>XEP-0152: Reachability Addresses</title>
<author initials='J.' surname='Hildebrand'
fullname='J. Hildebrand'>
<organization abbrev='Cisco'>
Cisco
</organization>
</author>
<author initials='P.' surname='Saint-Andre'
fullname='Peter Saint-Andre'>
<organization abbrev='Cisco'>
Cisco
</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="XEP" value="XEP-0152" />
</reference>
<reference anchor="XEP-0292">
<front>
<title>vCard4 Over XMPP</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="S." surname="Mizzi" fullname="Samantha Mizzi">
<organization/>
<address>
<email>samizzi@cisco.com</email>
</address>
</author>
<date day="09" month="October" year="2011"/>
</front>
<seriesInfo name="XSF XEP" value="0292"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0292.html"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:23 |