-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ivov-xmpp-cusax-04.xml
605 lines (600 loc) · 27.8 KB
/
draft-ivov-xmpp-cusax-04.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
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
<?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-04'>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
<front>
<title abbrev='Combined Use of SIP and XMPP'>
CUSAX: Combined Use of the Session Initiation Protocol (SIP) and
the Extensible Messaging and Presence Protocol (XMPP)
</title>
<author initials='E.' surname='Ivov' fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
<address>
<postal>
<street></street>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<phone>+33-672-811-555</phone>
<email>[email protected]</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>[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 suggested practices for combined use
of the Session Initiation Protocol (SIP) and the Extensible
Messaging and Presence Protocol (XMPP). Such practices aim to
provide a single fully featured real-time communication service
by using complementary subsets of features from each of the
protocols. Typically such subsets would include telephony
capabilities from SIP and instant messaging and presence
capabilities from XMPP. This specification does not define any
new protocols or syntax for either SIP or XMPP. However,
implementing it may require modifying or at least reconfiguring
existing client and server-side software. Also, it is not the
purpose of this document to make recommendations as to whether
or not such combined use should be preferred to the mechanisms
provided natively by each protocol (for example, SIP's SIMPLE
or XMPP's Jingle). It merely aims to provide guidance to those
who are interested in such a combined use.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
Historically <xref target="RFC3261">SIP</xref> and
<xref target="RFC6120">XMPP</xref> have often been implemented
and deployed with different purposes: from its very start SIP's
primary goal has been to provide a means of conducting "Internet
telephone calls". XMPP on the other hand, has, from its Jabber
days, been mostly used for instant messaging and presence
<xref target="RFC6121"/>, as well as related services such as
groupchat rooms <xref target="XEP-0045"/>.
</t>
<t>
For various reasons, these trends have continued through the
years even after each of the protocols had been equipped to
provide the features it was initially lacking:
</t>
<t>
<list style='symbols'>
<t>
Today, in the context of the SIMPLE working group, the IETF has
defined a number of protocols and protocol extensions that not
only allow for SIP to be used for regular instant messaging and
presence but that also provide mechanisms for elaborated
features such as multi-user chats, server-stored contact lists,
file transfer and others.
</t>
<t>
Similarly, the XMPP community and the XMPP Standards Foundation
have worked on defining a number of XMPP Extension Protocols
(XEPs) that provide XMPP implementations with the means of
establishing end-to-end sessions. These extensions are often
jointly referred to as Jingle and arguably their most popular
use case is audio and video calling.
</t>
</list>
</t>
<t>
Despite these advances, SIP remains the protocol of choice
for telephony-like services, especially in enterprises where
users are accustomed to features such as voice mail, call park,
call queues, conference bridges and many others that are rarely
(if at all) available in Jingle-based software. XMPP
implementations, on the other hand, greatly outnumber and
outperform those available for instant messaging and presence
extensions developed in the SIMPLE WG, such as
<xref target="RFC4975">MSRP</xref> and
<xref target="RFC4825">XCAP</xref>.
</t>
<t>
For these reasons, in a number of cases adopters have found
themselves needing a set of features that are not offered by any
single-protocol solution but that separately exist in SIP and
XMPP products. The idea of seamlessly using both protocols
together would hence often appeal to service providers.
</t>
<t>
Most often the combined use of SIP and XMPP ("CUSAX") would
employ SIP exclusively for audio, video, and telephony services
and rely on XMPP for anything else varying from chat, contact
list management, and presence to whiteboarding and exchanging
files.
</t>
<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 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). 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>
Finally, this document concentrates on use cases where the SIP
services and XMPP services are controlled by one and the same
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 recorded in a vCard).
However, the exact set of rules to follow in such cases is
left to application developers.
</t>
</section>
<section title='Client Bootstrap'>
<t>
One of the main problems of using two distinct protocols when
providing one service is the impact on usability. Email
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 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, 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 and video calling features to be disabled for XMPP
accounts, and that instant messaging and presence features
should also be made optional for SIP accounts.
</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 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 XMPP CUSAX
connection as an "instant messaging" or a "chat" account.
Similarly they could also depict the SIP CUSAX connection as a
"Voice and Video" or a "Telephony" connection. The exact naming
is of course entirely up to implementers. The point is that, in
cases where SIP and XMPP are components of a service offered by
a single provider, such presentation could help users better
understand why they are being shown two different connections
for what they perceive as a single service. It could alleviate
especially situations where one of these connections is
disrupted while the other one is still active.
</t>
</section>
<section title='Operation'>
<t>
Once a CUSAX client has been provisioned/configured to connect
to the corresponding SIP and XMPP services it would proceed by
retrieving its XMPP roster. In order for CUSAX to function
properly, XMPP service administrators should make sure that at
least one of the <xref target="RFC6350">vCard</xref> "tel"
fields for each contact is properly populated with a SIP URI or
a phone number when an XMPP protocol for vCard storage 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.
</t>
<t>
Additionally, clients that have separete triggers (buttons) for
audio and video calls may choose to use the presence or absence
of the "video" tel type defined in <xref target="RFC6350"/> and
enable or disable the possibility for starting video calls
accordingly.
</t>
<t>
To ensure that the foregoing approach is always respected,
service providers might consider (1) preventing clients (and
hence users) from modifying the vCard "tel" fields or (2)
applying some form of validation before storing changes. Of
course such validation would be feasible mostly in cases where
a single provider controls both the XMPP and the SIP service
since such providers would "know" (e.g., based on use of a common
user database for both services) what SIP AOR corresponds to
a given XMPP user.
</t>
<figure anchor='figure-2' title='Example Deployment'>
<artwork><![CDATA[
+--------------+
| Provisioning |-----------+
| Server | |
+--------------+ v
| +----------------+
| | vCard Storage/ |
| | User Directory |
| +----------------+
| / \
| +------------+ +-------------+
| | SIP Server | | XMPP Server |
| +------------+ +-------------+
| \ /
| media \ / instant messaging,
| signaling \ / presence, etc.
| \ /
| +--------------+
+---------------| CUSAX Client |
+--------------+
]]></artwork>
</figure>
<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
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 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 order to provide a similar experience when the user has
multiple telephony-capable accounts, client implementers 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 [email protected] has a
CUSAX relation to [email protected] (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
between the SIP and XMPP accounts of a CUSAX service and the
client is aware of multiple telephony-capable accounts, it ought
to present the user with the choice of reaching the contact
through any of those accounts. This includes the source XMPP account
where the vCard was obtained (in case its telephony capabilities are
not disabled through configuration or provisioning), 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 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>.
</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 audio/video
features were disabled in the XMPP stack.
</t>
<t>
When receiving SIP calls, clients may wish to determine the
identity of the caller and a corresponding XMPP roster entry so
that users could revert to chatting or other forms of
communication that require XMPP. To do so clients could search
their roster for an entry whose vCard has a "tel" field matching
the originator of the call.
</t>
<t>
In addition, in order to avoid the effort of iterating over an
entire roster and retrieving all vCards, CUSAX clients may use
a SIP Call-Info header whose 'purpose' token field parameter
has a value of "impp" as described in
<xref target='I-D.saintandre-impp-call-info'/> such as the
following:
<figure>
<artwork>
<![CDATA[
Call-Info: <xmpp:[email protected]> ;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 a vCard entry. If this confirmation succeeds
the client would not need to search the entire roster and
retrieve all vCards. Not performing the check would allow any
caller (including malicious ones) to employ someone else's
identity and perform various scams or Man-in-the-Middle attacks.
</t>
</section>
<section title='Multi-Party Interactions'>
<t>
This document concentrates on problems related to one-to-one
communication. While it is possible for clients and other
specifications to build upon this and provide suggestions for
improving the Unified Communications user experience in cases
of multi-user chats in conference calling (e.g., ways of mapping
XMPP Multi-User Chatrooms to conference calls and vice versa),
such mechanisms are considered out of scope for this version
of CUSAX.
</t>
</section>
<section title='Federation'>
<t>
In theory there are no technical reasons why federation would
require special behaviour from CUSAX clients. However, it is
worth noting that differences in administration policies may
sometimes lead to potentially confusing user experiences.
</t>
<t>
For example, let's say atlanta.example.com observes the CUSAX
policies described in this specification. All XMPP users at
atlanta.example.com are hence configured to have 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 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:[email protected]. 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 user interface warning or an an audio tone
or 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 extra-domain
numbers are flagged with an appropriate audio or textual warning.
</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='IANA Considerations'>
<t>This document has no actions for the IANA.</t>
</section>
</middle>
<back>
<references title='Informative References'>
<reference anchor='I-D.saintandre-impp-call-info'>
<front>
<title>Instant Messaging and Presence Purpose for the Call-Info Header in the Session Initiation Protocol (SIP)</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='March' day='10' year='2013' />
<abstract><t>This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-impp-call-info-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-impp-call-info-00.txt' />
</reference>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.4825"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.5246"?>
<?rfc include="reference.RFC.5802"?>
<?rfc include="reference.RFC.6120"?>
<?rfc include="reference.RFC.6121"?>
<?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>[email protected]</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>[email protected]</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="February" year="2013" />
</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>[email protected]</email>
</address>
</author>
<author initials="S." surname="Mizzi"
fullname="Samantha Mizzi">
<organization/>
<address>
<email>[email protected]</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>
<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 persons for
their reviews and suggestions: Aaron M. Evans, Sébastien Couture,
Olivier Crête, Kevin Gallagher, Adrian Georgescu, Saúl Ibarra
Corretgé, Daniel Pocock, Travis Reitterd, and Gonzalo Salgueiro.
</t>
</section>
</back>
</rfc>