-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-ietf-stox-media.xml
1111 lines (1066 loc) · 66 KB
/
draft-ietf-stox-media.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 rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc768 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY rfc793 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2198 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2198.xml">
<!ENTITY rfc3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3264 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3555 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3555.xml">
<!ENTITY rfc3862 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3862.xml">
<!ENTITY rfc3923 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3923.xml">
<!ENTITY rfc4855 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml">
<!ENTITY rfc4856 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4856.xml">
<!ENTITY rfc3711 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc3959 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3959.xml">
<!ENTITY rfc3960 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3960.xml">
<!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc4733 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4733.xml">
<!ENTITY rfc4585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc5124 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY rfc5245 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY rfc5547 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5547.xml">
<!ENTITY rfc5766 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml">
<!ENTITY rfc5768 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5768.xml">
<!ENTITY rfc5888 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5888.xml">
<!ENTITY rfc6120 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.xml">
<!ENTITY rfc7081 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7081.xml">
<!ENTITY rfc7230 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY rfc7247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7247.xml">
<!ENTITY rfc7395 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7395.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2"?>
<rfc category='std' docName='draft-ietf-stox-media-07' ipr='trust200902'>
<front>
<title abbrev="SIP-XMPP Interworking: Media Sessions">
Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): Media Sessions
</title>
<author initials='P.' surname='Saint-Andre'
fullname='Peter Saint-Andre'>
<organization>&yet</organization>
<address>
<uri>https://andyet.com/</uri>
</address>
</author>
<author initials="S." surname="Ibarra"
fullname="Saul Ibarra Corretge">
<organization>AG Projects</organization>
<address>
<postal>
<street>Dr. Leijdsstraat 92</street>
<code>2021RK</code>
<city>Haarlem</city>
<country>The Netherlands</country>
</postal>
</address>
</author>
<author initials='E.' surname='Ivov' fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
<address>
<postal>
<street></street>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<phone>+33-177-624-330</phone>
</address>
</author>
<date/>
<area>Applications</area>
<keyword>SIP</keyword>
<keyword>XMPP</keyword>
<keyword>Jingle</keyword>
<abstract>
<t>
This document defines a bidirectional protocol mapping for use
by gateways that enable the exchange of media signaling
messages between systems that implement the Session Initiation
Protocol (SIP) and systems that implement the Jingle extensions to
the Extensible Messaging and Presence Protocol (XMPP).
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The Session Initiation Protocol <xref target="RFC3261"/> is a widely-deployed technology for the management of media sessions (such as voice and video calls) over the Internet. SIP itself provides a signaling channel via TCP <xref target='RFC0793'/> or UDP <xref target='RFC0768'/>, over which two or more parties can exchange messages for the purpose of negotiating a media session that uses a dedicated media channel such as the Real-time Transport Protocol (RTP) <xref target='RFC3550'/>. The Extensible Messaging and Presence Protocol (XMPP) <xref target='RFC6120'/> also provides a signaling channel, typically via TCP (although bindings for HTTP <xref target='XEP-0124'/> and WebSocket <xref target='RFC7395'/> also exist).</t>
<t>Given the significant differences between XMPP and SIP, traditionally it was difficult to combine the two technologies in a single user agent (although nowadays such implementations are not uncommon, as described in <xref target='RFC7081'/>). Thus in 2005 some developers wishing to add media session capabilities to XMPP clients defined a set of XMPP-specific session negotiation protocol extensions called Jingle (see especially <xref target='XEP-0166'/>, <xref target='XEP-0167'/>, and <xref target='XEP-0176'/>).</t>
<t>Jingle was designed to easily map to SIP for communication through gateways or other transformation mechanisms. Nevertheless, given the significantly different technology assumptions underlying XMPP and SIP, Jingle is different from SIP in several important respects:</t>
<t>
<list style='symbols'>
<t>Base SIP messages and headers use a plaintext format similar in some ways to the Hypertext Transport Protocol <xref target='RFC7230'/>, whereas Jingle messages are pure XML. Mappings between SIP headers and Jingle message syntax are provided below.</t>
<t>SIP payloads for session semantics use the Session Description Protocol <xref target='RFC4566'/>, whereas the equivalent Jingle payloads use XML child elements of the Jingle <content/> element. However, the Jingle specifications defining such child elements specify mappings to SDP for all Jingle syntax, making the mapping relatively straightforward.</t>
<t>SIP messages have historically often been transported over UDP, whereas the signaling channel for Jingle is XMPP over TCP. Mapping between the transport layers typically happens within a gateway using techniques below the application level, and therefore is not addressed in this specification.</t>
</list>
</t>
<t>Consistent with existing specifications for mapping between SIP and XMPP (see <xref target='RFC7247'/>), this document describes a bidirectional protocol mapping for use by gateways that enable the exchange of media signaling messages between systems that implement SIP and systems that implement the XMPP Jingle extensions.</t>
<t>It is important to note that SIP and Jingle sessions could be gatewayed in a very simple way if all media were always routed and potentially even transcoded through the same gateway used for signaling. By contrast, this specification defines a mapping that allows gateways to only intervene at the signaling level, thus letting user agents exchange media in an end-to-end or peer-to-peer manner without intervention by a specialized gateway (naturally, a media relay that supports TURN <xref target='RFC5766'/> might be used). Such signaling-only gateways focus on handling session establishment and control within the context of what users would perceive as "calls". This document is hence primarily dealing with calling scenarios as opposed to generic media sessions or specialized sessions for functionality such as file transfer (see <xref target='RFC5547'/> and <xref target='XEP-0234'/>).</t>
</section>
<section title="Intended Audience" anchor="audience">
<t>The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). We assume that readers are familiar with the core specifications for both SIP <xref target='RFC3261'/> and XMPP <xref target='RFC6120'/>, with the base document for this series <xref target='RFC7247'/>, and with the following media-related specifications:</t>
<t>
<list style='symbols'>
<t>RTP Profile for Audio and Video Conferences with Minimal Control <xref target='RFC3551'/></t>
<t>The Secure Real-time Transport Protocol (SRTP) <xref target='RFC3711'/></t>
<t>SDP: Session Description Protocol <xref target='RFC4566'/></t>
<t>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols <xref target='RFC5245'/></t>
<t>Jingle <xref target='XEP-0166'/></t>
<t>Jingle RTP Sessions <xref target='XEP-0167'/></t>
<t>Jingle ICE-UDP Transport Method <xref target='XEP-0176'/></t>
<t>Jingle Raw UDP Transport Method <xref target='XEP-0177'/></t>
</list>
</t>
</section>
<section title="Terminology" anchor="terms">
<t>A number of technical terms used here are defined in <xref target="RFC3261"/>, <xref target="RFC6120"/>, <xref target='XEP-0166'/>, and <xref target='XEP-0167'/>. The term "JID" is short for "Jabber Identifier".</t>
<t>In flow diagrams, SIP traffic is shown using arrows such as "***>" whereas XMPP traffic is shown using arrows such as "...>".</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
</section>
<section title="Compatibility with Offer/Answer Model and Interactive Connectivity Establishment" anchor="jingle-oa-ice">
<t>Even if Jingle semantics have many similarities with those used in SIP, there are some use cases that cannot be handled in exactly the same way due to the Offer/Answer model used in SIP in conjunction with SDP.</t>
<t>More specifically, mapping SIP and SDP Offer/Answer to XMPP is often complicated due to the difference in how each handles backward compatibility. Jingle, as most other XMPP extensions, relies heavily on the XMPP extension for service discovery <xref target='XEP-0030'/>, which implies that XMPP entities are able to verify the capabilities of their intended peer before attempting to establish a session with it.</t>
<t>SDP Offer/Answer, on the other hand, uses a "least common denominator" approach where every SDP offer needs to be comprehensible by legacy endpoints. Newer, unsupported aspects in this offer can therefore only appear as optional, or their use needs to be limited to subsequent Offer/Answer exchanges once their support has been confirmed.</t>
<t>In particular, many older SIP endpoints do not support Interactive Connectivity Establishmen (ICE) <xref target="RFC5245"/>. A signaling gateway from Jingle to SIP has two primary alternatives for dealing with such endpoints on the SIP side:</t>
<t>
<list style='symbols'>
<t>Require the use of ICE and otherwise fail the call by including the "Require: ice" SIP option tag <xref target='RFC5768'/> in the SIP INVITE that it sends on behalf of the Jingle initiator.</t>
<t>Send an initial SIP INVITE for an ICE connection and, if the SIP endpoint indicates that it cannot handle ICE, send a re-INVITE for a non-ICE connection to the SIP endpoint and a Jingle transport-replace for a Raw UDP connection to the Jingle endpoint. (This will introduce a potentialy large delay and might not result in a much higher percentage of calls succeeding unless the signaling gateway also offers a TURN <xref target='RFC5766'/> service for NAT traversal.) See <xref target='fallback'/> for further discussion.</t>
</list>
</t>
<t>Use of "Trickle ICE" is one significant example where this issue occurs. From the beginning, Jingle supported the trickling of candidates (via Jingle messages of type 'transport-info'), and only years later was this behavior generalized <xref target='I-D.ietf-mmusic-trickle-ice'/> and then ported to SIP <xref target='I-D.ietf-mmusic-trickle-ice-sip'/>. Therefore SIP endpoints need to always behave like so-called "vanilla ICE" agents when sending their first offer and make sure they gather all candidates before sending a SIP INVITE. This is necessary because otherwise ICE agents with no support for trickling of candidates can prematurely declare failure. Jingle endpoints, on the other hand, can verify support for trickling of candidates prior to engaging in a session and adapt their behavior accordingly (and, as noted, trickling of candidates is standard operating procedure in Jingle).</t>
<t>In order to work around this disparity in relation to communication of transport candidates, the Jingle RTP transport method <xref target='XEP-0176'/> defines a mode for supporting traditional Offer/Answer interactions through the "urn:ietf:rfc:3264" feature tag. When an XMPP entity such as a client (or, significantly, a gateway to a SIP system) advertises support for this feature, the entity indicates that it needs to receive multiple transport candidates in the initial offer, instead of receiving them trickled over time. Although implementations conforming to this specification MUST support the Offer/Answer model with Jingle, such endpoints SHOULD NOT actually declare support for the "urn:ietf:rfc:3264" service discovery feature since this would mean that they too would be reachable only through Offer/Answer semantics and not also through trickle-ICE semantics.</t>
<t>The difference in handling of transport candidates also has an impact on ICE restarts (see Section 9.1.1.1 of <xref target='RFC5245'/>). Because Jingle endpoints can send candidates at any time, when communicating directly with other Jingle endpoints they would not initiate an ICE restart simply in order to send a candidate that, for example, changes the media target. However, as part of support for the Offer/Answer model a Jingle endpoint would instead need to initiate an ICE restart when communicating with a SIP endpoint or gateway that does not support trickle ICE. Similarly, a Jingle endpoint needs to support the 'generation' attribute (used to signal an ICE restart) when communicating with a SIP endpoint or gateway that does not support trickle ICE. See also the syntax discussion under <xref target='jingle-syntax-ice'/>.</t>
</section>
<section title="Syntax Mappings" anchor="jingle-syntax">
<section title="Generic Jingle Syntax" anchor="jingle-syntax-generic">
<t>Jingle is designed in a modular fashion, so that session description data is generally carried in a payload within high-level Jingle elements, i.e., the <jingle/> element and its <content/> child. The following example illustrates this structure, where the XMPP stanza is a request to initiate an audio session (via the <content/> and <description/> elements) using a transport of RTP over raw UDP (via the <transport/> element).</t>
<figure>
<preamble>Example 1: Structure of a Jingle session initiation request</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/v3rsch1kk3l1jk'
| id='ne91v36s'
| to='[email protected]/t3hr0zny'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='session-initiate'
| initiator='[email protected]/v3rsch1kk3l1jk'
| sid='a73sjjvkla37jfea'>
| <content creator='initiator'
| media='audio'
| name='this-is-the-audio-content'
| senders='both'>
| <description xmlns='urn:xmpp:jingle:app:rtp:1'>
| <payload-type id='101' name='opus' clockrate='48000'/>
| <payload-type id='18' name='G729'/>
| <payload-type channels='2'
| clockrate='16000'
| id='103'
| name='L16'/>
| <payload-type id='98' name='x-ISAC' clockrate='8000'/>
| </description>
| <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
| <candidate id='v3c18fgg'
| ip='10.1.1.104'
| port='13540'
| generation='0'/>
| </transport>
| </content>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>The syntax and semantics of the <jingle/> and <content/> elements are defined in the core Jingle specification <xref target='XEP-0166'/>, the syntax and semantics of the <description/> element qualified by the 'urn:xmpp:jingle:app:rtp:1' namespace are defined in the Jingle RTP specification <xref target='XEP-0167'/>, and the syntax and semantics of the <transport/> element qualified by the 'urn:xmpp:jingle:transport:raw-udp' namespace are defined in the Jingle Raw UDP specification <xref target='XEP-0177'/>. Other <description/> elements are defined in specifications for the appropriate application types (see for example <xref target='XEP-0234'/> for file transfer) and other <transport/> elements are defined in the specifications for appropriate transport methods (see for example <xref target='XEP-0176'/>, which defines an XMPP profile of ICE <xref target='RFC5245'/>).</t>
<t>At the core Jingle layer, the following mappings are defined.</t>
<figure>
<preamble>Table 1: High-Level Mapping from XMPP to SIP</preamble>
<artwork><![CDATA[
+--------------------------------+--------------------------------+
| Jingle | SIP |
+--------------------------------+--------------------------------+
| <jingle/> 'action' | [ see next table ] |
+--------------------------------+--------------------------------+
| <jingle/> 'initiator' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <jingle/> 'responder' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <jingle/> 'sid' | local-part of Dialog ID |
+--------------------------------+--------------------------------+
| local-part of 'initiator' | <username> in SDP o= line |
+--------------------------------+--------------------------------+
| <content/> 'creator' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <content/> 'name' | no mandatory mapping (1) |
+--------------------------------+--------------------------------+
| <content/> 'senders' value of | a= line of sendrecv, recvonly, |
| both, initiator, responder, or | sendonly, or inactive |
| none | |
+--------------------------------+--------------------------------+
]]></artwork>
</figure>
<t>
<list style='numbers'>
<t>In can be appropriate to map to the a=mid value defined in <xref target='RFC5888'/>.</t>
</list>
</t>
<t>The 'senders' attribute is optional in Jingle, with a default value of "both"; thus in case the attribute is absent the SDP direction value MUST be considered as 'sendrecv'.</t>
<t>The 'action' attribute of the <jingle/> element has 15 allowable values. In general they should be mapped as shown in the following table, with some exceptions as described below.</t>
<figure>
<preamble>Table 2: Mapping of Jingle Actions to SIP Methods</preamble>
<artwork><![CDATA[
+-------------------+------------------------------+
| Jingle Action | SIP Method |
+-------------------+------------------------------+
| content-accept | INVITE response (1xx or 2xx) |
+-------------------+------------------------------+
| content-add | INVITE request |
+-------------------+------------------------------+
| content-modify | re-INVITE request |
+-------------------+------------------------------+
| content-reject | unused in this mapping |
+-------------------+------------------------------+
| content-remove | INVITE request |
+-------------------+------------------------------+
| description-info | unused in this mapping |
+-------------------+------------------------------+
| security-info | unused in this mapping |
+-------------------+------------------------------+
| session-accept | INVITE response (1xx or 2xx) |
+-------------------+------------------------------+
| session-info | see note (1) below |
+-------------------+------------------------------+
| session-initiate | INVITE request |
+-------------------+------------------------------+
| session-terminate | BYE |
+-------------------+------------------------------+
| transport-accept | unused in this mapping |
+-------------------+------------------------------+
| transport-info | see note (2) below |
+-------------------+------------------------------+
| transport-reject | unused in this mapping |
+-------------------+------------------------------+
| transport-replace | unused in this mapping |
+-------------------+------------------------------+
]]></artwork>
</figure>
<t>
<list style='numbers'>
<t>The Jingle session-info action can be used for multiple purposes, such as putting the session on hold or sending a ringing indication. In particular, a session-info action of type ‘ringing’ SHOULD be mapped to a 180 SIP provisional response. The use of session-info for the purpose of session hold is described in <xref target='call-hold'/>.</t>
<t>In Jingle the transport-info action is used to exchange transport candidates after the initial offer, as documented in <xref target='XEP-0176'/>. This usage has been generalized as "Trickle ICE" <xref target='I-D.ietf-mmusic-trickle-ice'/> and has also been extended to SIP <xref target='I-D.ietf-mmusic-trickle-ice-sip'/>. Therefore a Jingle action of transport-info SHOULD be mapped to a SIP INFO request, but only in cases where it is reasonable to assume that the SIP endpoint or gateway supports trickle ICE. See <xref target='jingle-oa-ice'/> for further discussion.</t>
</list>
</t>
</section>
<section title="Application Formats" anchor="jingle-syntax-application-formats">
<t>Jingle application formats for audio and video exchange via RTP are specified in <xref target='XEP-0167'/>. These application formats effectively map to the "RTP/AVP" profile specified in <xref target='RFC3551'/> and the "RTP/SAVP" profile specified in <xref target='RFC3711'/>, where the media types are "audio" and "video" and the specific mappings to SDP syntax are provided in <xref target='XEP-0167'/>.</t>
<t>(As stated in <xref target='XEP-0167'/>, future versions of that specification might define how to use other RTP profiles such as "RTP/AVPF" and "RTP/SAVPF" as defined in <xref target='RFC4585'/> and <xref target='RFC5124'/> respectively.)</t>
</section>
<section title="Raw UDP Transport Method" anchor="jingle-syntax-udp">
<t>A basic Jingle transport method for exchanging media over UDP is specified in <xref target='XEP-0177'/>. This "Raw UDP" transport method involves the negotiation of an IP address and port only. It does not provide NAT traversal, effectively leaving the task to intermediary entities (which might be a media relay associated with but functionally independent of a signaling gateway). The Jingle 'ip' attribute maps to the connection-address parameter of the SDP c= line and the 'port' attribute maps to the port parameter of the SDP m= line. Use of SIP without ICE would generally map to use of Raw UDP on the XMPP side of a session.</t>
</section>
<section title="ICE-UDP Transport Method" anchor="jingle-syntax-ice">
<t>A more advanced Jingle transport method for exchanging media over UDP uses Interactive Connectivity Establishment and is specified in <xref target='XEP-0176'/>. By following the ICE methodology specified in <xref target='RFC5245'/>, ideally this transport method provides NAT traversal for media.</t>
<t>The relevant SDP mappings are provided in <xref target='XEP-0176'/>. However, those who implement signaling gateways need to be aware of a few syntax incompatibilities that need to be addressed by gateways conforming to this specification:</t>
<t>
<list style='symbols'>
<t>
The 'foundation' attribute is defined as a number in
Jingle (unsigned byte) whereas ICE
<xref target='RFC5245'/> defines it as a string, which
can contain letters, digits and the '+' and '/' symbols.
Gateway applications MUST therefore convert ICE
originating foundations into integer numbers and they
MUST guarantee that such a conversion preserves
foundation uniqueness. The exact mechanism for the
conversion is undefined.
</t>
<t>
Jingle defines a 'generation' attribute which is used
to determine if an ICE restart is required. This
attribute has no counterpart in SIP because ICE restarts are
initiated by detecting a change in the ICE 'ufrag' and
'pwd' (see Section 9.1.1.1 of <xref target='RFC5245'/>).
Gateways MUST therefore increase the
generation number when they detect such a change.
</t>
<t>
The 'id' attribute defined by Jingle has no SIP
counterpart; thus applications are free to choose means
to generate unique identifiers across the different
candidates of an ICE generation.
</t>
<t>The 'network' attribute defined by Jingle has no
counterpart in SIP and SHOULD be ignored.
</t>
</list>
</t>
</section>
</section>
<section title="Transport Fallback" anchor="fallback">
<t>Most Jingle endpoints will first attempt to use ICE as specified for Jingle in <xref target='XEP-0176'/> (since that is most likely to result in NAT traversal) and only if that does not succeed will they fall back to raw UDP <xref target='XEP-0177'/>. This fallback approach is described in the Jingle ICE specification <xref target='XEP-0176'/>.</t>
<t>However, that approach depends on the use of XMPP service discovery <xref target='XEP-0030'/>. Because SIP does not have a method for determining endpoint capabilities, SIP endpoints use what can be termed "single-exchange fallback": they first try one method and if that fails they then send a re-INVITE with the second method.</t>
<t>One way to map single-exchange fallback to Jingle is for the Jingle endpoint to attempt ICE first and send a transport-replace if the SIP answer indicates no support for ICE, then send a SIP re-INVITE with the addresses in the transport-accept. Unfortunately, this approach will result a fairly substantial post-answer delay before media can flow.</t>
<t>Because such delays usually result in an unacceptable user experience, the trend for many calling applications is to first send only a candidate that is known beforehand to be highly likely to result in NAT traversal, which is almost always a candidate at a media relay (i.e., an ICE candidate of type "relay"). Such applications will then offer and perhaps switch to a host candidate, peer reflexive candidate, or server reflexive candidate only after media is flowing via the relayed candidate. This approach obviates the need for transport fallback from ICE to raw UDP during call setup, and instead works around the problem by using trickle ICE (for those endpoints that support it) or re-INVITEs with updated transport candidates after call setup has been completed.</t>
</section>
<section title="Call Hold" anchor="call-hold">
<t>The Offer/Answer model <xref target="RFC3264"/> stipulates that streams are placed on hold by setting their direction to "sendonly". A session is placed on hold by doing this for all the streams it contains. The same semantics are also supported by Jingle through the "senders" element and its "initiator" and "responder" values (the Jingle specification also defines a value of "none", which maps to an a= value of "inactive", and a default value of "both", which maps to an a= value of "sendrecv").</t>
<t>The following example shows how the responder would put the call on hold (i.e., temporarily stop listening to media sent by the initiator) using a Jingle content-modify action and a modified value for the 'senders' attribute (here a value of "responder" is used to indicate that the responder might continue to send media, such as hold music).</t>
<figure>
<preamble>Example 2: Call hold via 'senders' attribute</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/balcony'
| id='hz73n2l9'
| to='[email protected]/orchard'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='content-modify'
| initiator='[email protected]/orchard'
| sid='a73sjjvkla37jfea'>
| <content creator='initiator'
| media='audio'
| name='this-is-the-audio-content'
| senders='responder'/>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>In addition to these semantics, however, the Jingle RTP Sessions specification <xref target='XEP-0167'/> also defines a more concise way for achieving the same end, which consists in sending a "hold" command within a "session-info" action, as shown in the following example.</t>
<figure>
<preamble>Example 3: Call hold via session-info action</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/balcony'
| id='xv39z423'
| to='[email protected]/orchard'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='session-info'
| initiator='[email protected]/orchard'
| sid='a73sjjvkla37jfea'>
| <hold xmlns='urn:xmpp:jingle:apps:rtp:info:1'/>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>Gateways that receive either of the foregoing hold notifications from their Jingle side MUST generate a new offer on their SIP side, placing all streams in a "sendonly" state.</t>
<t>When relaying offers from SIP to XMPP, gateways are not required to translate "sendonly" attributes into a "hold" command as this would not always be possible (e.g., when not all streams have the same direction). Additionally, such conversions might introduce complications in case further offers placing a session on hold also contain other session modifications.</t>
<t>It is possible that, after one entity has put the other on hold, the second entity might put the first entity on hold. In this case, the effective direction would then be "inactive" in SDP and "none" in Jingle.</t>
</section>
<section title="Early Media" anchor="early-media">
<t><xref target="RFC3959"/> and <xref target="RFC3960"/> describe a number of scenarios relying on "early media". While similar attempts have also been made for XMPP, support for early media is not currently widely supported in Jingle implementations. Therefore, gateways SHOULD NOT forward SDP answers from SIP to Jingle until a final response has been received, except in cases where the gateway is in a position to confirm specific support for early media by the endpoint (one approach to such support can be found in <xref target="XEP-0269"/> but it has not yet been standardized).</t>
<t>Gateways MUST however store early media SDP answers when they are sent inside a reliable provisional response. In such cases, a subsequent final response can follow without an actual answer and the one from the provisional response will need to be forwarded to the Jingle endpoint.</t>
</section>
<section title="Detecting Endless Loops" anchor="loops">
<t><xref target="RFC3261"/> defines a "Max-Forwards" header that allows intermediate entities such as SIP proxies to detect and prevent loops from occurring. The specifics of XMPP make such a prevention mechanism unnecessary for XMPP-only environments. With the introduction of SIP-to-XMPP gatewaying, however, it would be possible for loops to occur where messages are being repeatedly forwarded from XMPP to SIP to XMPP to SIP. This can happen not only between two endpoints, but also with the addition of a third endpoint into the mix (e.g., because one of the two original endpoints forwards a call to a third endpoint, thus converting a "spiral" into a loop).</t>
<t>To compensate for the lack of a "Max-Forwards" header in SIP, gateways MUST therefore keep track of all SIP transactions and Jingle sessions that they are currently serving and they MUST block re-entrant messages. Although the specifics of such tracking are a matter of implementation, the broad requirements is to consistently translate SIP dialog IDs into Jingle session ID, and vice versa, or generate an internal identifier for each session (e.g., by concatenating or hashing the combination of the SIP dialog ID and the Jingle session ID).</t>
</section>
<section title="SDP Format-Specific Parameters" anchor="fmtp">
<t>The SDP specification <xref target="RFC4566"/> defines "a=fmtp" attributes for the transmission of format-specific parameters as a single transparent string. Such strings can be used to convey either a single value or a sequence of parameters, separated by semi-colons, commas, or whatever delimiters are chosen by a particular payload type specification.</t>
<t>The Jingle RTP application format <xref target="XEP-0167"/>, on the other hand, defines a <parameter/> element as follows:</t>
<figure>
<artwork><![CDATA[
<parameter name="paramName" value="paramValue"/>
]]></artwork>
</figure>
<t>A sequence of parameters is thus transmitted as an array of distinct name/value pairs, at least in the context of the Jingle RTP extension.</t>
<t>These differences make it difficult to devise a generic mechanism that accurately translates format parameters from Jingle RTP to SDP without the specifics of the payload being known to the gateway. In general this is not a major problem because most of the media type definitions supported in existing Jingle implementations follow the semicolon-separated parameter model (e.g., typical audio and video codecs). Possible exceptions include:</t>
<t>
<list style='symbols'>
<t>The RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals (i.e., the "audio/telephone-event" payload type). As noted in Section 2.5.1.1 of <xref target='RFC4733'/>, in SDP the "events" parameter is assumed to indicate support for DTMF events 0-15 even if the parameter is not included; a gateway SHOULD explicitly indicate this support in a Jingle parameter with name='events' and value='0-15'.</t>
<t>The RTP Payload for Redundant Audio Data (i.e., the "audio/red" payload type). Although this payload type is defined in <xref target='RFC2198'/>, the SDP representation is specified in Section 4.1.21 of <xref target='RFC3555'/> (note that this representation was not updated by <xref target='RFC4856'/>). In particular, the "pt" parameter can be mapped to a=fmtp lines as described in the payload type registration.</t>
</list>
</t>
<t>For implementations that wish to provide a general-purpose translation method, this specification makes the following recommendations:</t>
<t>
<list style='numbers'>
<t>Gateways that are aware of the formats in use SHOULD parse all format parameters and generate <parameter/> arrays and "a=fmtp" values accordingly.</t>
<t>When translating Jingle RTP to SIP, gateways that have no explicit support for the formats that are being negotiated SHOULD convert the list of <parameter/> elements into a single string, containing a sequence of "name=value" pairs, separated by a semi-colon and a space (i.e. "; ").</t>
<t>When translating SIP to Jingle RTP, gateways that have no explicit support for the formats that are being negotiated SHOULD tokenize the "a=fmtp" format string using one delimiter from the following list: ";", "; ", ",", ", ". The resulting tokens SHOULD then be parsed as "name=value" pairs. If this process does actually yield any such pairs, they SHOULD be used for generating the respective <parameter/> elements. If some of the tokens cannot be parsed into a "name=value" pair because they do not conform to the convention suggested in <xref target='RFC4855'/>, or in case the format string could not be tokenized with the above delimiters, the remaining strings SHOULD be used as a value for the "value" attribute of the <parameter/> element and the corresponding "name" attribute SHOULD be left empty.</t>
</list>
</t>
<t>Here is a relatively simple example of the foregoing transformations, using the aforementioned example of the "audio/telephone-event" payload type (wherein the "events" parameter is implicitly named in the SDP):</t>
<figure>
<preamble>SDP with format data (audio/telephone-event)</preamble>
<artwork><![CDATA[
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
]]></artwork>
</figure>
<figure>
<preamble>Jingle transformation (audio/telephone-event)</preamble>
<artwork><![CDATA[
<parameter name="events" value="0-15,66,70"/>
]]></artwork>
</figure>
<t>A more complicated example would be handling of the "audio/red" payload type (wherein the "pt" parameter can be mapped to a=fmtp lines as described in <xref target="RFC3555"/>):</t>
<figure>
<preamble>SDP with format data (audio/red)</preamble>
<artwork><![CDATA[
m=audio 49170 RTP/AVP 99 0 103
a=rtpmap:99 RED/8000
a=fmtp:99 0/103
a=rtpmap:103 G729D/8000
a=fmtp:103 annexb=yes
]]></artwork>
</figure>
<figure>
<preamble>Jingle transformation (audio/red)</preamble>
<artwork><![CDATA[
<parameter name="pt" value="0,103"/>
<parameter name="annexb" value="yes"/>
]]></artwork>
</figure>
</section>
<section title="Dialog Forking" anchor="forking">
<t>The core SIP specification <xref target="RFC3261"/> defines semantics for dialog forking. Such semantics have not been defined for Jingle and need to be hidden from XMPP endpoints.</t>
<t>To achieve this, a SIP-to-XMPP gateway MUST NOT forward more than one provisional response on the Jingle side. Typically they would do so only for the first provisional response they receive and ignore the rest. This provisional response SHOULD be forwarded as if it originated from a "user@host" address (i.e., a "bare JID") corresponding to the AOR URI found in the "From" header of the SIP provisional response. The gateway MUST NOT attempt to translate GRUUs into full JIDs because it cannot know at this stage which of the dialogs established by these provisional responses will be used for the actual session.</t>
<t>Likewise, a gateway conforming to this specification MUST NOT forward more than a single final response received through SIP to the Jingle side. The gateway SHOULD terminate the SIP sessions whose received final response was not forwarded to the Jingle side.</t>
</section>
<section title="Sample Call Flow" anchor="callflow">
<t>The section illustrates the protocol flow of a basic voice chat session in which an XMPP user ([email protected]) is the initiator and a SIP user ([email protected]) is the responder. The signaling is communicated through a gateway. To simplify the example, the Jingle transport method negotiated is "raw UDP" as specified in <xref target='XEP-0177'/>.</t>
<figure>
<artwork><![CDATA[
XMPP XMPP SIP SIP
User Server Server User
| + X2S GW | |
| | | |
| (F1) XMPP | | |
| session- | | |
| initiate | | |
|...........>| | |
| (F2) XMPP | | |
| IQ-result | | |
|<...........| | |
| | (F3) SIP | |
| | INVITE | |
| |***********>| |
| | | (F4) SIP |
| | | INVITE |
| | |**********>|
| | | (F5) SIP |
| | | 180 |
| | | ringing |
| | |<**********|
| | (F6) SIP | |
| | 180 ringing| |
| |<***********| |
| (F7) XMPP | | |
| session- | | |
| info | | |
| (ringing) | | |
|<...........| | |
| (F8) XMPP | | |
| IQ-result | | |
|...........>| | |
| | | (F9) SIP |
| | | 200 OK |
| | |<**********|
| | (F10) SIP | |
| | 200 OK | |
| |<***********| |
| (F11) XMPP | | |
| session- | | |
| accept | | |
|<...........| | |
| (F12) XMPP | | |
| IQ-result | | |
|...........>| | |
| | (F13) SIP | |
| | ACK | |
| |***********>| |
| | | (F14) SIP |
| | | ACK |
| | |**********>|
| | | |
|<=======MEDIA SESSION OVER RTP======>|
| | | |
| | | (F15) SIP |
| | | BYE |
| | |<**********|
| | (F16) SIP | |
| | BYE | |
| |<***********| |
| (F17) XMPP | | |
| session- | | |
| terminate | | |
|<...........| | |
| (F18) XMPP | | |
| IQ-result | | |
|...........>| | |
]]></artwork>
</figure>
<t>The packet flow is as follows.</t>
<t>First the XMPP user sends a Jingle session-initiation request to the SIP user.</t>
<figure>
<preamble>Example 4: Jingle session-initiate (F1)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/t3hr0zny'
| id='hu2s61f4'
| from='[email protected]/v3rsch1kk3l1jk'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='session-initiate'
| initiator='[email protected]/t3hr0zny'
| sid='a73sjjvkla37jfea'>
| <content creator='initiator'
| media='audio'
| name='this-is-the-audio-content'>
| <description xmlns='urn:xmpp:jingle:app:rtp:1'>
| <payload-type id='96' name='speex' clockrate='16000'/>
| <payload-type id='97' name='speex' clockrate='8000'/>
| <payload-type id='18' name='G729'/>
| </description>
| <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
| <candidate component='1' generation='0' id='u3gscv289p'
| ip='192.0.2.101' port='49172'/>
| </transport>
| </content>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>The gateway returns an XMPP IQ-result to the initiator on behalf of the responder.</t>
<figure>
<preamble>Example 5: XMPP IQ-result from gateway (F2)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/t3hr0zny'
| id='hu2s61f4'
| to='[email protected]/v3rsch1kk3l1jk'
| type='result'/>
]]></artwork>
</figure>
<t>The gateway transforms the Jingle session-initiate action into a SIP INVITE.</t>
<figure>
<preamble>Example 6: SIP transformation of Jingle session-initiate (F3)</preamble>
<artwork><![CDATA[
| INVITE sip:[email protected] SIP/2.0
| Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
| Max-Forwards: 70
| From: Juliet Capulet <sip:[email protected]>;tag=t3hr0zny
| To: Romeo Montague <sip:[email protected]>
| Call-ID: [email protected]
| CSeq: 1 INVITE
| Contact: <sip:[email protected];transport=tcp>
| Content-Type: application/sdp
| Content-Length: 184
| v=0
| o=alice 2890844526 2890844526 IN IP4 client.example.com
| s=-
| c=IN IP4 192.0.2.101
| t=0 0
| m=audio 49172 RTP/AVP 18 96 97
| a=rtpmap:96 sppex/16000
| a=rtpmap:97 speex/8000
| a=rtpmap:18 G729
]]></artwork>
</figure>
<t>The responder returns a SIP 180 Ringing message.</t>
<figure>
<preamble>Example 7: SIP 180 Ringing message (F5)</preamble>
<artwork><![CDATA[
| SIP/2.0 180 Ringing
| Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
| received=192.0.2.101
| From: Juliet Capulet <sip:[email protected]>;tag=t3hr0zny
| To: Romeo Montague <sip:[email protected]>;tag=v3rsch1kk3l1jk
| Call-ID: [email protected]
| CSeq: 1 INVITE
| Contact: <sip:[email protected];transport=tcp>
| Content-Length: 0
]]></artwork>
</figure>
<t>The gateway transforms the ringing message into XMPP syntax.</t>
<figure>
<preamble>Example 8: XMPP transformation of SIP 180 Ringing message (F7)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/v3rsch1kk3l1jk'
| id='ol3ba71g'
| to='[email protected]/t3hr0zny'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='session-info'
| initiator='[email protected]/t3hr0zny'
| sid='a73sjjvkla37jfea'>
| <ringing xmlns='urn:xmpp:jingle:apps:rtp:info:1'/>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>The initiator returns an IQ-result acknowledging receipt of the ringing message, which is used only by the gateway and not transformed into SIP syntax.</t>
<figure>
<preamble>Example 9: XMPP entity acknowledges ringing message (F8)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/t3hr0zny'
| id='ol3ba71g'
| to='[email protected]/v3rsch1kk3l1jk'
| type='result'/>
]]></artwork>
</figure>
<t>The responder sends a SIP 200 OK to the initiator in order to accept the session initiation request.</t>
<figure>
<preamble>Example 10: SIP user accepts session request (F9)</preamble>
<artwork><![CDATA[
| SIP/2.0 200 OK
| Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
| received=192.0.2.101
| From: Juliet Capulet <sip:[email protected]>;tag=t3hr0zny
| To: Romeo Montague <sip:[email protected]>;tag=v3rsch1kk3l1jk
| Call-ID: [email protected]
| CSeq: 1 INVITE
| Contact: <sip:[email protected];transport=tcp>
| Content-Type: application/sdp
| Content-Length: 147
|
| v=0
| o=romeo 2890844527 2890844527 IN IP4 client.example.net
| s=-
| c=IN IP4 192.0.2.201
| t=0 0
| m=audio 3456 RTP/AVP 97
| a=rtpmap:97 speex/8000
]]></artwork>
</figure>
<t>The gateway transforms the 200 OK into a Jingle session-accept action.</t>
<figure>
<preamble>Example 11: XMPP transformation of SIP 200 OK (F11)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/v3rsch1kk3l1jk'
| id='pd1bf839'
| to='[email protected]/t3hr0zny'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='session-accept'
| initiator='[email protected]/t3hr0zny'
| responder='[email protected]/v3rsch1kk3l1jk'
| sid='a73sjjvkla37jfea'>
| <content creator='initiator'
| media='audio'
| name='this-is-the-audio-content'>
| <description xmlns='urn:xmpp:jingle:app:rtp:1'>
| <payload-type id='97' name='speex' clockrate='8000'/>
| </description>
| <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
| <candidate id='9eg13am7' ip='192.0.2.101'
| port='49172' generation='0'/>
| </transport>
| </content>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>If the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept action.</t>
<figure>
<preamble>Example 12: XMPP user acknowledges session-accept (F12)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/v3rsch1kk3l1jk'
| id='pd1bf839'
| to='[email protected]/t3hr0zny'
| type='result'/>
]]></artwork>
</figure>
<t>The parties now begin to exchange media. In this case they would exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the <payloadtype/> children).</t>
<t>The parties can continue the session as long as desired.</t>
<t>Eventually, one of the parties (in this case the responder) terminates the session.</t>
<figure>
<preamble>Example 13: SIP user ends session (F15)</preamble>
<artwork><![CDATA[
| BYE sip:[email protected] SIP/2.0
| Via: SIP/2.0/TCP client.example.net:5060;branch=z9hG4bKnashds7
| Max-Forwards: 70
| From: Romeo Montague <sip:[email protected]>;tag=8321234356
| To: Juliet Capulet <sip:[email protected]>;tag=9fxced76sl
| Call-ID: [email protected]
| CSeq: 4 BYE
| Content-Length: 0
]]></artwork>
</figure>
<t>The gateway transforms the SIP BYE into XMPP syntax.</t>
<figure>
<preamble>Example 14: XMPP transformation of SIP BYE (F17)</preamble>
<artwork><![CDATA[
| <iq from='[email protected]/v3rsch1kk3l1jk'
| id='rv301b47'
| to='[email protected]/t3hr0zny'
| type='set'>
| <jingle xmlns='urn:xmpp:jingle:1'
| action='session-terminate'
| initiator='[email protected]/t3hr0zny'
| sid='a73sjjvkla37jfea'/>
| <reason>
| <success/>
| </reason>
| </jingle>
| </iq>
]]></artwork>
</figure>
<t>The initiator returns an IQ-result acknowledging receipt of the session termination, which is used only by the gateway and not transformed into SIP syntax.</t>
<figure>
<preamble>Example 15: XMPP user acknowledges end of session (F18)</preamble>
<artwork><![CDATA[
<iq from='[email protected]/v3rsch1kk3l1jk'
id='rv301b47'
to='[email protected]/t3hr0zny'
type='result'/>
]]></artwork>
</figure>
</section>
<section title='IANA Considerations' anchor="iana">
<t>This document requests no actions by the IANA.</t>
</section>
<section title='Security Considerations' anchor="sec">
<t>Detailed security considerations for session management are given for SIP in <xref target='RFC3261'/> and for XMPP in <xref target='XEP-0166'/> (see also <xref target='RFC6120'/>). The security considerations provided in <xref target='RFC7247'/> also apply.</t>
<t>The addition of gateways to the security model of media signaling introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between media endpoints that interface through a gateway can be provided only if common formats are supported. Specification of those common formats is out of scope for this document and, unfortunately, no generalized method for end-to-end encryption of signaling messages has yet been defined, even outside of recognized standards development organizations (e.g., <xref target="RFC3862"/> and <xref target='RFC3923'/> are not widely implemented and Off-the-Record Messaging <xref target='OTR'/> can handle only human-readable chat messages, not structured signaling payloads).</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3261;
&rfc3551;
&rfc4855;
&rfc3711;
&rfc4566;
&rfc4733;
&rfc5245;
&rfc6120;
&rfc7247;
<reference anchor="XEP-0030">
<front>
<title>Service Discovery</title>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
</address>
</author>
<author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
<organization/>
<address>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
</address>
</author>
<date day="6" month="June" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0030"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0030.html"/>
</reference>
<reference anchor="XEP-0166">
<front>
<title>Jingle</title>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
</address>
</author>
<author initials="J." surname="Beda" fullname="Joe Beda">
<organization/>
<address>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
</address>
</author>
<date day="20" month="June" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0166"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0166.html"/>
</reference>
<reference anchor="XEP-0167">
<front>
<title>Jingle RTP Sessions</title>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
</address>
</author>
<date day="17" month="February" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0167"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0167.html"/>
</reference>
<reference anchor="XEP-0176">
<front>
<title>Jingle ICE-UDP Transport Method</title>
<author initials="J." surname="Beda" fullname="Joe Beda">
<organization/>
<address>
</address>
</author>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
</address>
</author>
<date day="26" month="February" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0176"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0176.html"/>
</reference>
<reference anchor="XEP-0177">
<front>
<title>Jingle Raw UDP Transport</title>
<author initials="J." surname="Beda" fullname="Joe Beda">
<organization/>
<address>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
</address>
</author>
<date day="11" month="February" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0177"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0177.html"/>
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.ietf-mmusic-trickle-ice'>
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol</title>
<author initials='E' surname='Ivov' fullname='Emil Ivov'>
<organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<author initials='J' surname='Uberti' fullname='Justin Uberti'>
<organization />
</author>
<date month='January' day='15' year='2015' />
<abstract><t>This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The above mechanism is also referred to as "trickle ICE".</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-trickle-ice-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-02.txt' />
</reference>
<reference anchor='I-D.ietf-mmusic-trickle-ice-sip'>
<front>
<title>A Session Initiation Protocol (SIP) usage for Trickle ICE</title>
<author initials='E' surname='Ivov' fullname='Emil Ivov'>
<organization />
</author>
<author initials='E' surname='Marocco' fullname='Enrico Marocco'>
<organization />
</author>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<date month='July' day='6' year='2015' />
<abstract><t>The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking. This document defines usage semantics for Trickle ICE with SIP.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-trickle-ice-sip-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-02.txt' />
</reference>
<reference anchor="OTR" target="https://otr.cypherpunks.ca/">
<front>
<title>Off-the-Record Messaging</title>
<author surname="Ian Goldberg"/>
<date/>
</front>