-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ivov-xmpp-cusax-00.xml
323 lines (318 loc) · 14.4 KB
/
draft-ivov-xmpp-cusax-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category='bcp' ipr='trust200902'
docName='draft-ivov-xmpp-cusax-00'>
<?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>
<email>[email protected]</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>[email protected]</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 complimenting subsets of features from each of the
protocols. Typically such subsets would include telephony
oriented ones from SIP and instant messaging and presence
capabilities from XMPP. This specification does not define any
new protocols or syntax for neither SIP nor 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 its instant messaging and presence
capabilities.
</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>
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>
<t>
Yet, 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 servers. XMPP implementations on
the other hand, greatly outnumber and outperform those available
for protocols recommended by SIMPLE, such as [MSRP] and [XCAP].
</t>
<t>
For these reasons in a number of cases, adopters may find
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 such combined use would employ SIP exclusively for
audio, video and telephony services and it would rely on XMPP
for anything else varying from chat, roster management and
presence to exchanging files.
</t>
<t>
This document explains how the above could be achieved with a
minimum amount of modifications on 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 an XMPP JID from incoming SIP requests. Most of the
text here pertains to client behavior but it also recommends
certain server-side configurations.
</t>
</section>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>.
</t>
</section>
<section title='Client Bootstrap'>
<t>
One of the main problems of using two distinct protocols when
providing one service is how it affects usability. E-mail
services for example have long been affected by the mixed use of
SMTP on for outgoing mail and POP3 and IMAP for incoming, making
it rather complicated for inexperienced users to configure a
mail client and start using it with a new service. As a result
mailing list services often need to provide configuration
instructions for various mail clients. Client developers and
communications device manufacturers on the other hand often ship
with a number of wizards that allow to easily set up a new
account for a number of popular e-mail services. While this may
improve the situation to some extent, 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, it is
RECOMMENDED that dual stack SIP/XMPP clients provide means of
online provisioning. While the specifics of such mechanisms are
not in the scope of this specification, they should make it
possible for service providers to remotely configure the clients
based on minimal user input (e.g. user id and password).
</t>
<t>
Given that many of the features that CUSAX 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. Specifically it is RECOMMENDED that clients
allow for audio/video calling features to be disabled for XMPP
accounts. Additionally instant messaging and presence features
MAY 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 SHOULD log
independently to the SIP and XMPP accounts that make up the
CUSAX service and should 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 implementors. The point is that such
presentation could help users better understand why they are
being shown two different connections for a single service. It
could even 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 [VCARD] "tel" fields for each contact is
properly populated with a SIP URI or a phone number. 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). It SHOULD
however be reachable through the SIP counterpart of this CUSAX
service.
</t>
<t>
In order to make sure that the above is always respected,
service maintainers MAY prevent clients (and hence users) from
modifying the VCARD "tel" fields or they MAY apply some form of
validation before recording changes.
</t>
<t>
When rendering the XMPP roaster 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
SHOULD 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 be having better user experience. If on the other
hand, the CUSAX client is aware of multiple telephony-capable
accounts, it SHOULD 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>
The client should use XMPP for all other forms of communication
with the contacts from its roster so it should and this should
occur naturally given that they were retrieved through XMPP.
</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 their
XMPP JID, but at this point we are not really sure if that's '
such a good idea. (After all Contact headers carry URIs and
JIDs are not URIs).
</t>
</section>
<section title='Security Considerations'>
<t>
TBD
</t>
</section>
<section title='Acknowledgements'>
<t>
This draft is inspired by work from Markus Isomaki and Simo
Veikkolainen.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.6120"?>
<?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.4787"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5751"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.5853"?>
<?rfc include="reference.RFC.6189"?>
<reference anchor="XEP-0177">
<front>
<title>XEP-0177: Jingle Raw UDP Transport Method</title>
<author initials='J.' surname='Beda'
fullname='Joe Beda'>
<organization abbrev='Google'>
Google
</organization>
</author>
<author initials='P.' surname='Saint-Andre'
fullname='Peter Saint-Andre'>
<organization abbrev='Cisco'>
Cisco
</organization>
</author>
<author initials='J.' surname='Hildebrand'
fullname='J. Hildebrand'>
<organization abbrev='Cisco'>
Cisco
</organization>
</author>
<author initials='S.' surname='Egan'
fullname='Sean Egan'>
<organization abbrev='Google'>
Google
</organization>
</author>
<date month="December" year="2009" />
</front>
<seriesInfo name="XEP" value="XEP-0177" />
</reference>
</references>
</back>
</rfc>