-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0371.xml
1079 lines (1060 loc) · 64.3 KB
/
xep-0371.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
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle ICE Transport Method</title>
<abstract>This specification defines a Jingle transport method that results in sending media data using datagram associations via the User Datagram Protocol (UDP) or using end-to-end connections via the Transport Control Protocol (TCP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology (which provides robust NAT traversal for media traffic) and also supports the ability to exchange candidates throughout the life of the session, consistent with so-called "Trickle ICE" (draft-ietf-ice-trickle).</abstract>
&LEGALNOTICE;
<number>0371</number>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0166</spec>
<spec>RFC 8445</spec>
<spec>RFC 6544</spec>
<spec>draft-ietf-ice-trickle</spec>
</dependencies>
<supersedes>
<spec>XEP-0176</spec>
</supersedes>
<supersededby/>
<shortname>jingle-ice</shortname>
&stpeter;
<revision>
<version>0.3.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2020-05-14</date>
<initials>rion</initials>
<remark>
<ul>
<li>Replaced RFC 5245 with RFC 8445</li>
<li>Introduced ice2 transport attribute for backward compatibility</li>
<li>Clarified ICE restart procedure</li>
<li>Clarified remote-candidate usage</li>
<li>Changed remote-candidate notification procedure (sent all at once now)</li>
<li>Replaced wrong reference to RFC 6455 with correct one: RFC 6544</li>
<li>Allow sharing <gathering-complete/> element with remaining candidates</li>
</ul>
</remark>
</revision>
<revision>
<version>0.2.1</version>
<date>2019-07-30</date>
<initials>fippo</initials>
<remark>Fix reference to gathering-complete element in text.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2017-09-11</date>
<initials>XEP Editor (jwi)</initials>
<remark>Defer due to lack of activity.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2016-01-21</date>
<initials>XEP Editor (asw)</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2015-12-30</date>
<initials>psa</initials>
<remark>
<ul>
<li>Added a 'tcptype' attribute to support ICE-TCP (&rfc6544;) instead of overloading the existing 'type' attribute, with values of "active", "passive", and "so".</li>
<li>Modified the syntax of the end-of-candidates indication so that it is wrapped in a <transport/> element in the same namespace.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2015-12-16</date>
<initials>psa</initials>
<remark>
<ul>
<li>Forked from XEP-0176 (see that specification for older revision history).</li>
<li>Added support for ICE-TCP (&rfc6544;), specifically by allowing a value of "tcp" for the 'protocol' attribute and values of "tcp-active", "tcp-passive", and "tcp-so" for the 'type' attribute.</li>
<li>Changed title from ICE-UDP to ICE, but retained namespace name for backward compatibility.</li>
<li>Corrected data type of foundation attribute from xs:unsignedByte to xs:string.</li>
<li>Added a note about not mapping ice-options because it is not needed in XMPP.</li>
<li>Specified that the <transport/> element is extensible by adding xs:any to the schema.</li>
<li>Changed the normativity of the 'generation' attribute from required to optional because it is not absolutely necessary for ICE restarts.</li>
<li>Added informational message to indicate completion of sending ICE candidates (the "end-of-candidates indication") as in WebRTC and ORTC.</li>
<li>Verified compatibility with IETF "Trickle ICE" specification.</li>
</ul>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications.</p>
<p>The current document defines a transport method for establishing and managing data exchanges between XMPP entities by means of the Interactive Connectivity Establishment (ICE) methodology specified in &rfc8445;. The Jingle usage of ICE was also the first technology to send ICE candidates incrementally, a technique that has since become known as "Trickle ICE" &trickle;.</p>
<p>The process for ICE negotiation is largely the same in Jingle as it is in &rfc8445;. There are several differences:</p>
<ul>
<li>Instead of using the Session Initiation Protocol (SIP) as the signalling channel, Jingle uses XMPP as the signalling channel.</li>
<li>Syntax from the Session Description Protocol (see &rfc4566;) is mapped to an XML syntax suitable for sending over the XMPP signalling channel.</li>
<li>In Jingle, lists of "preferred" candidates are typically sent in the Jingle session-initiate and session-accept messages, in a way that is consistent with the SDP offer / answer model described in &rfc3264; and the process described in &rfc8445;.</li>
<li>Candidates can also be sent in separate transport-info messages either before sending or receiving the session-accept message (to expedite negotiation) or after media begins to flow (to find modify existing candidates, find superior candidates, or adjust to changing network conditions). This usage, which has been part of the Jingle ICE transport method since 2005, has since come to be known as "Trickle ICE"; as defined here the usage is consistent with the IETF specification for Trickle ICE &trickle;.</li>
</ul>
<p>As originally defined in XEP-0166 and then &xep0176; the use of ICE in Jingle applied only to negotiations that established a User Datagram Protocol association (see &rfc0768;) and thus resulted in a Jingle datagram transport suitable for media applications where some packet loss is tolerable (e.g., audio and video). However, since the publication of &rfc6544; in 2012 it has also been possible to exchange Transmission Control Protocol (see &rfc0793;) candidates during ICE negotiation. Therefore this document expands the use of ICE in Jingle to also establish a TCP connection and thus result in a Jingle stream transport suitable for media applications where packet loss cannot be tolerated (e.g., file transfer). To reduce the possibility of confusion, the expanded definition provided here is specified in a new XEP, which is intended to supersede XEP-0176.</p>
</section1>
<section1 topic='Glossary' anchor='terms'>
<p>The reader is referred to &rfc8445; and draft-ietf-ice-trickle for a description of various terms used in the context of ICE. Those terms are not reproduced here.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The Jingle transport method defined herein is designed to meet the following requirements:</p>
<ol>
<li>Make it possible to establish and manage out-of-band connections between two XMPP entities, even if they are behind Network Address Translators (NATs) or firewalls.</li>
<li>Enable use of UDP or TCP as the transport protocol.</li>
<li>Make it relatively easy to implement support in standard Jabber/XMPP clients.</li>
<li>Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.</li>
</ol>
</section1>
<section1 topic='Jingle Conformance' anchor='conformance'>
<p>In accordance with Section 10 of <cite>XEP-0166</cite>, this document specifies the following information related to the Jingle ICE transport method:</p>
<ol>
<li><p>The transport negotiation process is defined in the <link url='#protocol'>Protocol Description</link> section of this document.</p></li>
<li><p>The semantics of the &TRANSPORT; element are defined in the <link url='#protocol-negotiate'>ICE Negotiation</link> section of this document.</p></li>
<li><p>Depending on the kinds of candidates exchanged, successful negotiation of this method results in use of a datagram transport (suitable for applications where some packet loss is tolerable, such as audio and video) or of a streaming transport (suitable for applications where packet loss is not tolerable, such as file transfer).</p></li>
<li><p>If multiple components are to be communicated by the application type that uses the transport, the transport shall support those components and assign identifiers for them as described in the specification that defines the application type.</p></li>
</ol>
</section1>
<section1 topic='Protocol Description' anchor='protocol'>
<section2 topic='Overall Flow' anchor='protocol-flow'>
<p>The overall protocol flow for negotiation of the Jingle ICE Transport Method is as follows (note: many of these events happen simultaneously, not in sequence).</p>
<code><![CDATA[
INITIATOR RESPONDER
| |
| Jingle session-initiate stanza |
| (with zero or more candidates) |
|------------------------------------->|
| Jingle ack (XMPP IQ-result) |
|<-------------------------------------|
| Jingle session-accept stanza |
| (with one or more candidates) |
|<-------------------------------------|
| Jingle ack (XMPP IQ-result) |
|------------------------------------->|
| multiple STUN Binding Requests |
|<====================================>|
| multiple STUN Binding Results |
|<====================================>|
|<=========MEDIA NOW FLOWS============>|
| optional Jingle transport-info |
| stanzas (one candidate per stanza) |
|<------------------------------------>|
| |
]]></code>
<p>Note: The examples in this document follow the scenario described in Section 15 of &rfc8445;, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".</p>
</section2>
<section2 topic='Session Initiation' anchor='protocol-initiate'>
<p>In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in <cite>XEP-0166</cite>. If the initiator wishes to negotiate the ICE transport method for an application format, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace &VNOTE;. This element SHOULD in turn contain one &CANDIDATE; element for each of the initiator's higher-priority transport candidates as determined in accordance with the ICE methodology, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).</p>
<example caption="Initiation"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='ixt174g9'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<payload-type id='0' name='PCMU' />
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'
ice2='true'>
<candidate component='1'
foundation='2B78DADC1A9E'
generation='0'
id='el0747fg11'
ip='10.0.1.1'
network='1'
port='8998'
priority='2130706431'
protocol='udp'
type='host'/>
<candidate component='1'
foundation='58AA96B8FA5A'
generation='0'
id='y3s2b30v3r'
ip='192.0.2.3'
network='1'
port='45664'
priority='1694498815'
protocol='udp'
rel-addr='10.0.1.1'
rel-port='8998'
type='srflx'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
</section2>
<section2 topic='Syntax' anchor='protocol-syntax'>
<p>The &TRANSPORT; element's 'pwd' and 'ufrag' attributes MUST be included whenever sending one or more candidates to the other party, e.g., in a session-initiate, session-accept, transport-info, content-add, or transport-replace message. The values for these attributes are separately generated for both the initiator and the responder, in accordance with &rfc8445; and as shown in the examples.</p>
<p>'ice2' attribute tells about compliancy with &rfc8445;. If the attribute is not set or set to 'false' in &TRANSPORT; element, the recipient can assume &rfc5245;. The value of the attribute may not be changed during lifetime of the transport instance, but it's not an error to skip the attribute in consequent transport-info updates.</p>
<p>The attributes of the <transport/> element are as follows.</p>
<table caption='Transport Attributes'>
<tr>
<th>Name</th>
<th>Description</th>
<th>SDP Syntax</th>
<th>Example</th>
</tr>
<tr>
<td>pwd</td>
<td>A Password as defined in &rfc8445;.</td>
<td>a=ice-pwd line</td>
<td>asd88fgpdd777uzjYhagZg</td>
</tr>
<tr>
<td>ufrag</td>
<td>A Username Fragment as defined in &rfc8445;.</td>
<td>a=ice-ufrag line</td>
<td>8hhy</td>
</tr>
<tr>
<td>ice2</td>
<td>ice2 option as defined in &rfc8445;.</td>
<td>a=ice-options:ice2</td>
<td>true</td>
</tr>
</table>
<p>The attributes of the <candidate/> element are as follows.</p>
<table caption='Candidate Attributes'>
<tr>
<th>Name</th>
<th>Description</th>
<th>SDP Syntax</th>
<th>Example</th>
</tr>
<tr>
<td>component</td>
<td>A Component ID as defined in &rfc8445;.</td>
<td>Component ID value in a=candidate line</td>
<td>1</td>
</tr>
<tr>
<td>foundation</td>
<td>A Foundation as defined in &rfc8445;. (Note that version 1.0 of this specification container an error, whereby the data type for the Jingle 'foundation' attribute was defined as xs:unsignedByte; in version 1.1 this was corrected to xs:string, however some existing implementations might not use or expect strings.)</td>
<td>Foundation value in a=candidate line</td>
<td>2B78DADC1A9E</td>
</tr>
<tr>
<td>generation</td>
<td>An index, starting at 0, that enables the parties to keep track of updates to the candidate throughout the life of the session. For details, see the <link url='#protocol-restarts'>ICE Restarts</link> section of this document.</td>
<td>extended name/value pair in a=candidate line</td>
<td>0</td>
</tr>
<tr>
<td>id</td>
<td>A unique identifier for the candidate.</td>
<td>N/A</td>
<td>el0747fg11</td>
</tr>
<tr>
<td>ip</td>
<td>The Internet Protocol (IP) address for the candidate transport mechanism; this can be either an IPv4 address or an IPv6 address.</td>
<td>IP Address value in a=candidate line</td>
<td>192.0.2.3</td>
</tr>
<tr>
<td>network</td>
<td>An index, starting at 0, referencing which network this candidate is on for a given peer (used for diagnostic purposes if the calling hardware has more than one Network Interface Card).</td>
<td>N/A</td>
<td>0</td>
</tr>
<tr>
<td>port</td>
<td>The port at the candidate IP address.</td>
<td>Port value in a=candidate line</td>
<td>45664</td>
</tr>
<tr>
<td>priority</td>
<td>A Priority as defined in &rfc8445;.
<note>In accordance with the rules specified in Section 5.1.2 of &rfc8445;, the priority values shown in the examples within this document have been calculated as follows. The "type preference" for host candidates is stipulated to be "126", "110" for peer reflexive and for server reflexive candidates "100". The "local preference" for network 0 is stipulated to be "4096", for network 1 "2048", and for network 2 "1024".</note>
</td>
<td>Priority value in a=candidate line</td>
<td>2130706431</td>
</tr>
<tr>
<td>protocol</td>
<td>The protocol to be used. The values allowed by this specification are "udp" (see &rfc8445;) and "tcp" (see &rfc6544;).</td>
<td>Transport protocol field in a=candidate line</td>
<td>udp</td>
</tr>
<tr>
<td>rel-addr</td>
<td>A related address as defined in &rfc8445;.</td>
<td>Value of raddr attribute in a=candidate line</td>
<td>10.0.1.1</td>
</tr>
<tr>
<td>rel-port</td>
<td>A related port as defined in &rfc8445;.</td>
<td>Value of rport attribute in a=candidate line</td>
<td>8998</td>
</tr>
<tr>
<td>tcptype</td>
<td>A TCP candidate type as defined in &rfc6544;. The allowable values are "active" for TCP active candidates, "passive" for TCP passive candidates, and "so" for TCP simultaneous-open candidates.</td>
<td>Value of tcptype attribute in a=candidate line</td>
<td>so</td>
</tr>
<tr>
<td>type</td>
<td>An ICE candidate type as defined in &rfc8445;. The allowable values are "host" for host candidates, "prflx" for peer reflexive candidates, "relay" for relayed candidates, and "srflx" for server reflexive candidates. Note that TCP candidate types (&rfc6544;) are handled via the 'tcptype' attribute.</td>
<td>Value of typ attribute in a=candidate line</td>
<td>srflx</td>
</tr>
</table>
</section2>
<section2 topic='Response' anchor='protocol-response'>
<p>As described in <cite>XEP-0166</cite>, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.</p>
<example caption="Responder acknowledges receipt of session-initiate request"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='ixt174g9'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'/>
]]></example>
<p>Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g., because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message MUST contain a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace, which SHOULD in turn contain one &CANDIDATE; element for each ICE candidate generated by or known to the responder, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).</p>
<p>Note: See the <link url='#security'>Security Considerations</link> section of this document regarding the exposure of IP addresses by the responder's client.</p>
<example caption="Responder accepts the session request"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='rw782g55'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
responder='juliet@capulet.example/yn0cl4bnw0yr3vym'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='YH75Fviy6338Vbrhrlp8Yh'
ufrag='9uB6'>
<candidate component='1'
foundation='2B78DADC1A9E'
generation='0'
id='or2ii2syr1'
ip='192.0.2.1'
network='0'
port='3478'
priority='2130706431'
protocol='udp'
type='host'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
</section2>
<section2 topic='Candidate Negotiation' anchor='protocol-candidates'>
<p>The initiator and responder negotiate connectivity over ICE by exchanging XML-formatted transport candidates for the channel. This negotiation proceeds immediately in order to maximize the possibility that connectivity can be established (and therefore media can be exchanged) as quickly as possible. In order to expedite session establishment, the initiator SHOULD include transport candidates in its session-initiate message but MAY also send additional transport candidates as soon as it learns of them, even before receiving the IQ-result that acknowledges the session-initiate message (i.e., the initiator MUST consider the session to be live as soon as it sends the session-initiate message). <note>Given in-order delivery as mandated by &xmppcore;, the responder will receive such transport-info messages after receiving the session-initiate message; if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist.</note></p>
<p>The first step in negotiating connectivity is for each party to send transport candidates to the other party. <note>The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a lite implementation as specified in &rfc8445;.</note> These candidates SHOULD be gathered by following the procedure specified in Section 5.1.1 of &rfc8445; (typically by communicating with a standalone STUN server in order to discover the client's public IP address and port) and prioritized by following the procedure specified in Section 5.1.2 of &rfc8445;.</p>
<p>Each candidate shall be sent as a <candidate/> child of a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace. The &TRANSPORT; element is sent via a Jingle message of type session-initiate, session-accept, or transport-info.</p>
<p>Either party MAY include multiple <candidate/> elements in one &TRANSPORT; element, especially in the session-initiate and session-accept messages sent at the beginning of the session negotiation. Including multiple candidates in the session-initiate and session-accept messages can help to ensure interoperability with entities that implement the SDP offer/answer model described in <cite>RFC 3264</cite>; in particular, an entity SHOULD include multiple candidates in its session-initiate or session-accept message if the other party advertises support for the "urn:ietf:rfc:3264" service discovery feature as described in the <link url='#support-sdp'>SDP Offer / Answer Support</link> section of this document. However, including one candidate per subsequent transport-info message typically results in a faster negotiation because the candidates most likely to succeed are sent first (in the session-info and session-accept messages) and it is not necessary to gather all candidates before beginning to send any candidates; furthermore, because certain candidates can be more "expensive" in terms of bandwidth or processing power, either party might not want to advertise the existence of such candidates unless it is necessary to do so after other candidates have failed.</p>
<p>If the party that receives a candidate in a Jingle message can successfully process a given candidate or set of candidates, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an IQ-error). At this point, the receiving entity is only indicating receipt of the candidate or set of candidates, not telling the other party that the candidate will be used.</p>
<p>The initiator can keep sending candidates (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable transport candidates. The responder can also keep sending potential candidates, which the initiator will acknowledge.</p>
</section2>
<section2 topic='Connectivity Checks' anchor='protocol-checks'>
<p>As the initiator and responder receive candidates, they probe the candidates for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &rfc8445;. The following business rules apply:</p>
<ol>
<li>Each party sends a STUN Binding Request (see &rfc5389;) from each local candidate it generated to each remote candidate it received.</li>
<li>In accordance with &rfc8445;, the STUN Binding Requests MUST include the PRIORITY attribute (computed according to Section 7.1.2.1. of &rfc8445;).</li>
<li>For the purposes of the Jingle ICE Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.</li>
<li>The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.</li>
<li>The STUN Binding Requests generated by the initiator MUST include the ICE-CONTROLLING attribute.</li>
<li>The STUN Binding Requests generated by the responder MUST include the ICE-CONTROLLED attribute.</li>
<li>The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks. As in &rfc8445;, the username in the STUN Binding Request is of the form "ufrag-of-peer:ufrag-of-sender" and the password is the value of the 'pwd' attribute provided by the peer. <note>Thus when Romeo sends a STUN Binding Request to Juliet the credentials will be STUN username "9uB6:8hhy" (ufrag provided by Juliet concatenated with ufrag provided by Romeo) and password "YH75Fviy6338Vbrhrlp8Yh" (pwd provided by Juliet) whereas when Juliet sends a STUN Binding Request to Romeo the credentials will be STUN username "8hhy:9uB6" (ufrag provided by Romeo concatenated with ufrag provided by Juliet) and password "asd88fgpdd777uzjYhagZg" (pwd provided by Romeo).</note></li>
</ol>
<p>When it receives a STUN Binding Request, each party MUST return a STUN Binding Response, which indicates either an error case or the success case. As described in Section 7.2.5.3 of &rfc8445;, a connectivity check succeeds if <em>all</em> of the following are true:</p>
<ol>
<li>The Binding request generated a success response.</li>
<li>The source and destination transport addresses in the Binding request and response are symmetric.</li>
</ol>
<p>For the candidates exchanged in the previous section, the connectivity checks would be as follows (this diagram mirrors the example from section 15.1 of &rfc8445;).</p>
<code><![CDATA[
ENTITY IP Address Mnemonic name
--------------------------------------------------
ICE Agent L (Initiator): 10.0.1.1 L-PRIV-1
ICE Agent R (Responder): 192.0.2.1 R-PUB-1
STUN Server: 192.0.2.2 STUN-PUB-1
NAT (Public): 192.0.2.3 NAT-PUB-1
L NAT STUN R
|STUN alloc. | | |
|(1) STUN Req | | |
|S=$L-PRIV-1 | | |
|D=$STUN-PUB-1 | | |
|------------->| | |
| |(2) STUN Req | |
| |S=$NAT-PUB-1 | |
| |D=$STUN-PUB-1 | |
| |------------->| |
| |(3) STUN Res | |
| |S=$STUN-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<-------------| |
|(4) STUN Res | | |
|S=$STUN-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|(5) L's Candidate Information| |
|------------------------------------------->|
| | | | STUN
| | | | alloc.
| | |(6) STUN Req |
| | |S=$R-PUB-1 |
| | |D=$STUN-PUB-1 |
| | |<-------------|
| | |(7) STUN Res |
| | |S=$STUN-PUB-1 |
| | |D=$R-PUB-1 |
| | |MA=$R-PUB-1 |
| | |------------->|
|(8) R's Candidate Information| |
|<-------------------------------------------|
| | (9) Bind Req |Begin
| | S=$R-PUB-1 |Connectivity
| | D=$L-PRIV-1 |Checks
| | <-------------------|
| | Dropped |
|(10) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|------------->| | |
| |(11) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |---------------------------->|
| |(12) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(13) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|Data | | |
|===========================================>|
| | | |
| |(14) Bind Req | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |<----------------------------|
|(15) Bind Req | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|<-------------| | |
|(16) Bind Res | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | |
|------------->| | |
| |(17) Bind Res | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | |
| |---------------------------->|
|Data | | |
|<===========================================|
| | | |
.......
| | | |
|(18) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|USE-CAND | | |
|------------->| | |
| |(19) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |USE-CAND | |
| |---------------------------->|
| |(20) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(21) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
| | | |
]]></code>
<p>Note: aggressive nomination described in RFC 5245 is not used anymore in the updated &rfc8445;. From now on the initiator MUST nominate just one valid candidate pair.</p>
</section2>
<section2 topic='End-of-Candidates Indication' anchor='protocol-end'>
<p>As explained in the Trickle ICE specification, when a party has completed gathering of ICE candidates it will send an "end-of-candidates indication" to the other party. In Jingle, this takes the form of an informational message as described under <link url='#info'>Informational Messages</link>. This specificaton defines only a standalone "end-of-candidates indication" (i.e., not a way to indicate ICE completion in an offer or answer).</p>
</section2>
<section2 topic='Acceptance of Successful Candidate' anchor='protocol-acceptance'>
<p>If, based on STUN connectivity checks, the parties determine that they will be able to exchange media (i.e., each component has "nominated" candidate pair and ICE processing is "completed"), they proceed with optional remote-candidate notification after which ICE transport is considered to be established. By this moment the parties may exchange media data already since it's allowed even before the candidate pairs nomination according to &rfc8445;</p>
<p>Once the parties have connectivity and therefore the initiator has completed ICE for the media stream as explained in &rfc8445;, the initiator MAY communicate the in-use (nominated) candidate pairs in the signalling channel by sending a transport-info message that contains a <remote-candidate/> element for each component of the data stream (this maps to the SDP "remote-candidates" attribute as described in Appendix B of draft-ietf-mmusic-ice-sip-sdp specification, i.e., remote candidates are "the actual candidates at R that were selected by the offerer").</p>
<p>Note, while in SIP this message is MUST it's just MAY for XMPP. The difference comes from a SIP problem (offer updates) which doesn't exist in XMPP. Basically there is no <strong>transport-info</strong> or any other message which represents candidates of a valid pair and therefore the race condition is not possible. Even so if the responder advertises "urn:ietf:rfc:3264" disco feature and hence may serve as a Jingle-to-SIP proxy the message MUST be sent.</p>
<example caption="Initiator communicates in-use candidate"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='pd81b49s'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<remote-candidate component='1'
ip='10.0.1.2'
port='9001'/>
<remote-candidate component='2'
ip='10.0.1.2'
port='9002'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>(In accordance with Jingle core, the responder will also acknowledge the transport-info message.)</p>
<p>In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in <cite>XEP-0166</cite>, or alternatively it may do content-remove or transport-replace.</p>
</section2>
<section2 topic='Negotiating a New Candidate' anchor='protocol-renegotiate'>
<p>Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message.</p>
<example caption="Initiator sends a subsequent candidate"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='uh3g1f48'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<candidate component='1'
foundation='2B78DADC1A9E'
generation='0'
id='m3110wc4nd'
ip='2001:db8::9:1'
network='0'
port='9001'
priority='21149780477'
protocol='udp'
type='host'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The receiving party MUST acknowledge receipt of the candidate.</p>
<example caption="Recipient acknowledges receipt"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='uh3g1f48'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'/>
]]></example>
<p>The parties would check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, they MAY then use the new candidate in subsequent communications.</p>
</section2>
<section2 topic='ICE Restarts' anchor='protocol-restarts'>
<p>At any time, either party MAY restart the process of ICE negotiation by sending a candidate with a 'generation' value that is greater than the previous generation of candidates; when it does so, it MUST generate new values for the 'pwd' and 'ufrag' attributes, consistent with the definition of an ICE restart in Section 9 of &rfc8445; (because an ICE restart is signalled by a change in the 'pwd' and 'ufrag' attributes, strictly speaking the 'generation' attribute is not absolutely necessary). As explained in &rfc8445;, typically the ICE negotiation would be restarted to change the media target (e.g., an IP address change for one of the parties) and certain third-party-call-control scenarios.</p>
<example caption="Initiator restarts ICE negotiation"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='kl23fs71'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='bv71hdn38hgb39hf6xlk33'
ufrag='g7qs'>
<candidate component='1'
foundation='2B78DADC1A9E'
generation='1'
id='y3s2b30v3r'
ip='192.0.2.3'
network='1'
port='45665'
priority='1694498815'
protocol='udp'
type='srflx'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The recipient then acknowledges receipt.</p>
<example caption="Recipient acknowledges transport-info"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='kl23fs71'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'/>
]]></example>
<p>The parties would then exchange new candidates to renegotiate connectivity and would check the new candidates for connectivity, as described previously. If the parties determine that media can flow over one of the new candidates, they can then use the successful candidate in subsequent communications. However, while ICE is being renegotiated the parties can continue to send media with the existing candidate-in-use.</p>
<p>Note: If a party has already sent ICE restart and receives any transport-info message before <iq/> stanza of type "result", the transport-info messages have to be acknowledged with <iq/> stanzas of type "result" but dropped afterwards. After the restart was acknowledged, the other party MAY send the same candidates again as a part of the new ICE session. It's also possible both parties will send ICE restart simultaneously. In this case session initiator MUST respond with <tie-break/> error (see &xep0166;).</p>
</section2>
</section1>
<section1 topic='Fallback to Raw UDP' anchor='fallback'>
<p>It can happen that the responder does not support ICE, in which case it can be necessary to fall back to use of the &xep0177;. One typical scenario is communication between an ICE-aware Jingle endpoint and a non-ICE-aware SIP endpoint through a Jingle-to-SIP gateway, as follows:</p>
<ol>
<li>The Jingle endpoint sends a session-initiate request to the SIP endpoint, specifying a transport method of ICE.</li>
<li>Based on capabilities information, the gateway knows that the SIP endpoint does not support ICE, so it enables the endpoints to use its media relay. It does this by:
<ul>
<li>Sending a transport-replace message to the Jingle endpoint on behalf of the SIP endpoint, specifying a transport method of Raw UDP and a candidate whose IP address and port are hosted at the gateway.</li>
<li>Sending SIP INVITE to the SIP endpoint on behalf of the Jingle endpoint, speciying an IP address and port at the gateway.</li>
</ul>
</li>
</ol>
<p>The session flow is as follows.</p>
<code><![CDATA[
Romeo Gateway Juliet
| | |
| session-initiate | |
| (audio definition) | |
|------------------------>| |
| ack | |
|<------------------------| |
| transport-replace | |
| (Raw UDP) | |
|<------------------------| |
| ack | |
|------------------------>| |
| transport-accept | |
|------------------------>| |
| ack | |
|<------------------------| SIP INVITE |
| |------------------------>|
| | 200 OK |
| |<------------------------|
| session-accept | |
|<------------------------| |
| ack | |
|------------------------>| |
| MEDIA SESSION |
|<=================================================>|
| | SIP BYE |
| |<------------------------|
| session-terminate | |
|<------------------------| |
| ack | |
|------------------------>| ack |
| |------------------------>|
| | |
]]></code>
<p>The protocol flow is as follows, showing only the stanzas sent between Romeo and the gateway (acting on Juliet's behalf).</p>
<example caption="Initiator sends session-initiate"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='p01hf63x'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'
ice2='true'>
<candidate component='1'
foundation='2B78DADC1A9E'
generation='0'
id='el0747fg11'
ip='10.0.1.1'
network='1'
port='8998'
priority='2130706431'
protocol='udp'
type='host'/>
<candidate component='1'
foundation='58AA96B8FA5A'
generation='0'
id='y3s2b30v3r'
ip='192.0.2.3'
network='1'
port='45664'
priority='1694498815'
protocol='udp'
rel-addr='10.0.1.1'
rel-port='8998'
type='srflx'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<example caption="Responder acknowledges session-initiate"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='p01hf63x'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'/>
]]></example>
<p>Immediately the gateway sends a transport-replace message to Romeo, specifying a transport of Raw UDP with a candidate whose IP address and port identify a media relay at the gateway.</p>
<example caption="Gateway sends transport-replace on behalf of responder"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='hy2gd714'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-replace'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice1'>
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
<candidate generation='0'
id='a9j3mnbtu1'
ip='10.1.1.104'
port='13540'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>Romeo then acknowledges the transport-replace message and immediately also sends a transport-accept.</p>
<example caption="Initiator acknowledges transport-replace"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='hy2gd714'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='result'/>
]]></example>
<example caption="Initiator accepts new transport"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='rb391gs5'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-accept'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='responder' name='voice2'>
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
<candidate generation='0'
id='a9j3mnbtu1'
ip='10.1.1.104'
port='13540'/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The gateway then acknowledges the acceptance on behalf of Juliet.</p>
<example caption="Gateway acknowledges transport-accept"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='rb391gs5'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'/>
]]></example>
<p>The responder then sends a session-accept through the gateway.</p>
<example caption="Responder sends session-accept"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='ijf61d43'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
responder='juliet@capulet.example/yn0cl4bnw0yr3vym'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='18' name='G729'/>
</description>
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'/>
</content>
</jingle>
</iq>
]]></example>
<example caption="Initiator acknowledges session-accept"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='ijf61d43'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='result'/>
]]></example>
<p>The endpoints now begin to exchange session media, and can continue the session as long as desired.</p>
</section1>
<section1 topic='Informational Messages' anchor='info'>
<p>Informational messages can be sent by either party within the context of Jingle to communicate the status of a Jingle ICE "session". The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:transports:ice:0' namespace.</p>
<p>The only payload element defined so far is the <gathering-complete/> element. This element is used only to signal that gathering of ICE candidates has been completed (i.e., to send an "end-of-candidates indication"), as in the following example.</p>
<example caption="Responder sends end-of-candidates indication"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='xv39z423'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<gathering-complete/>
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The <gathering-complete/> element can be combined with remaining candidates or sent alone.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<section2 topic='ICE Support' anchor='support-ice'>
<p>To advertise its support for the Jingle ICE Transport Method, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:transports:ice:0" for this version (and "urn:xmpp:jingle:transports:ice-udp:1" for the "ICE-UDP" version previously specified in XEP-0176 &VNOTE;.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='cv5x41g9'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service discovery information response"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='cv5x41g9'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:xmpp:jingle:transports:ice:0'/>
<feature var='urn:xmpp:jingle:transports:ice-udp:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:audio'/>
<feature var='urn:xmpp:jingle:apps:rtp:video'/>
</query>
</iq>
]]></example>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section2>
<section2 topic='SDP Offer / Answer Support' anchor='support-sdp'>
<p>If an entity supports the SDP offer / answer model described in <cite>RFC 3264</cite> and therefore prefers to receive multiple candidates in a single transport-info message, it MUST advertise support for the "urn:ietf:rfc:3264" service discovery feature. Typically this feature will be advertised only by gateways between Jingle and SIP.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='ce81f5d6'
to='sip.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service discovery information response"><![CDATA[
<iq from='sip.shakespeare.lit'
id='ce81f5d6'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:ietf:rfc:3264'/>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:xmpp:jingle:transports:ice:0'/>
<feature var='urn:xmpp:jingle:transports:ice-udp:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:audio'/>
<feature var='urn:xmpp:jingle:apps:rtp:video'/>
</query>
</iq>
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>In order to speed the negotiation process so that media can flow as quickly as possible, the initiator SHOULD gather and prioritize candidates in advance, or as soon as the principal begins the process of initiating a session.</p>
</section1>
<section1 topic='Deployment Notes' anchor='deploy'>
<p>This specification applies exclusively to Jingle clients and places no additional requirements on XMPP servers. However, service administrators might wish to deploy a STUN server in order to ease the client-to-client negotiation process and a TURN server for media relaying (see &turn;). Deployment of support for &xep0215; might also be helpful.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Sharing IP Addresses' anchor='security-sharing'>
<p>By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:</p>
<ol>
<li>The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).</li>
<li>The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in <cite>RFC 3921</cite>.</li>
<li>The user has explicitly added the contact to a list of entities who are allowed to access the user's personally-identifying information.</li>
</ol>
</section2>
<section2 topic='Encryption of Media' anchor='security-media'>
<p>A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over a UDP association, such as those described in &xtls;.</p>
<p>Application types that use the Jingle ICE transport method MAY also define their own application-specific encryption methods, such as the Secure Real-time Transport Protocol (SRTP) for RTP exchanges as described in &xep0167;.</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:jingle:transports:ice:0</li>
</ul>
<p>The ®ISTRAR; includes the foregoing namespace in its registry at &NAMESPACES;, as governed by &xep0053;.</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>If an entity supports the SDP offer / answer model described in <cite>RFC 3264</cite> and therefore prefers to receive one transport-info message with multiple candidates, it MUST advertise support for the "urn:ietf:rfc:3264" feature.</p>
<p>The registry submission is as follows.</p>
<code caption='Registry Submission'><![CDATA[
<var>
<name>urn:ietf:rfc:3264</name>
<desc>
Signals support for the SDP offer / answer model
described in RFC 3264
</desc>
<doc>XEP-0176</doc>
</var>
]]></code>
</section2>
<section2 topic='Jingle Transport Methods' anchor='registrar-transports'>
<p>The XMPP Registrar includes "ice" in its registry of Jingle transport methods at &JINGLETRANSPORTS;. The registry submission is as follows:</p>
<code><![CDATA[
<transport>
<name>ice</name>
<desc>
A method for negotiation of out-of-band UDP associations
or TCP connections with built-in NAT and firewall traversal
using the IETF's Interactive Connectivity Establishment (ICE)
methodology.
</desc>
<type>datagram or streaming</type>
<doc>XEP-0176</doc>
</transport>
]]></code>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:jingle:transports:ice:0'
xmlns='urn:xmpp:jingle:transports:ice:0'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0176: http://www.xmpp.org/extensions/xep-0176.html
</xs:documentation>
</xs:annotation>
<xs:element name='transport'>
<xs:complexType>
<xs:choice minOccurs='0'>
<xs:sequence>
<xs:element name='candidate'
type='candidateElementType'
minOccurs='1'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:sequence>
<xs:element name='remote-candidate'
type='remoteCandidateElementType'