-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-saintandre-sip-xmpp-media.xml
886 lines (845 loc) · 43.1 KB
/
draft-saintandre-sip-xmpp-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
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<rfc category='info' docName='draft-saintandre-sip-xmpp-media-02' 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>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>[email protected]</email>
</address>
</author>
<author initials="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>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</address>
</author>
<date year="2013" month="February" day="20"/>
<area>Applications</area>
<keyword>SIP</keyword>
<keyword>XMPP</keyword>
<keyword>Jingle</keyword>
<abstract>
<t>This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP).</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 calls) over the Internet. SIP itself provides a signalling channel (typically via the User Datagram Protocol <xref target='RFC768'/>), 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 <xref target='RFC3550'/>.</t>
<t>The Extensible Messaging and Presence Protocol <xref target='RFC6120'/> also provides a signalling channel, typically via the Transmission Control Protocol <xref target='RFC793'/>. Given the significant differences between XMPP and SIP, it is difficult to combine the two technologies in a single user agent. Therefore, developers wishing to add media session capabilities to XMPP clients have defined an XMPP-specific negotiation protocol called Jingle <xref target='XEP-0166'/>.</t>
<t>However, Jingle was designed to easily map to SIP for communication through gateways or other transformation mechanisms. Therefore, consistent with existing specifications for mapping between SIP and XMPP (see <xref target='I-D.saintandre-sip-xmpp-core'/> and other related specifications), this document describes a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement SIP and those that implement the XMPP Jingle extensions.</t>
<t>Note: The capitalized 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="Jingle to SIP" anchor="jingle">
<section title="Overview" anchor="jingle-overview">
<t>As mentioned, Jingle was designed in part to enable straightforward protocol mapping between XMPP and SIP. However, given the significantly different technology assumptions underlying XMPP and SIP, Jingle is naturally 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='RFC2616'/>, whereas Jingle messages are pure XML. Mappings between SIP headers and Jingle message syntax are provided below.</t>
<t>The SIP payloads defining session semantics use the Session Description Protocol <xref target='RFC4566'/>, whereas the equivalent Jingle payloads are defined as 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>The SIP signalling channel has traditionally been transported over UDP, whereas the signalling 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>
</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 the generic 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 using RTP over a raw UDP transport.</t>
<figure>
<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='96' name='speex' clockrate='16000'/>
<payload-type id='97' name='speex' clockrate='8000'/>
<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 ip='10.1.1.104' port='13540' generation='0'/>
</transport>
</content>
</jingle>
</iq>
]]></artwork>
</figure>
<t>In the foregoing example, the syntax and semantics of the <jingle/> and <content/> elements are defined in <xref target='XEP-0166'/>, the syntax and semantics of the <description/> element are defined in <xref target='XEP-0167'/>, and the syntax and semantics of the <transport/> element are defined in <xref target='XEP-0177'/>. Other <description/> elements are defined in specifications for the appropriate application types (see for example <xref target='XEP-0167'/>) 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 <xref target='RFC5245'/>).</t>
<t>At the core Jingle layer, the following mappings are defined.</t>
<figure>
<artwork><![CDATA[
+--------------------------------+--------------------------------+
| Jingle | SIP |
+--------------------------------+--------------------------------+
| <jingle/> 'action' | [ see next table ] |
+--------------------------------+--------------------------------+
| <jingle/> 'initiator' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <jingle/> 'responder' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <jingle/> 'sid' | local-part of Call-ID |
+--------------------------------+--------------------------------+
| local-part of 'initiator' | <username> in SDP o= line |
+--------------------------------+--------------------------------+
| <content/> 'creator' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <content/> 'name' | [ no mapping ] |
+--------------------------------+--------------------------------+
| <content/> 'profile' | <proto> in SDP m= line |
+--------------------------------+--------------------------------+
| <content/> 'senders' value of | a= line of sendrecv, recvonly, |
| both, initiator, or responder | or sendonly |
+--------------------------------+--------------------------------+
]]></artwork>
</figure>
<t>The 'senders' attribute is optional in Jingle, thus in case it's absent it's RECOMMENDED that the direction value is considered as 'sendrecv'.</t>
<t>The 'action' attribute of the <jingle/> element has nine allowable values. In general they should be mapped as shown in the following table, with some exceptions as described herein.</t>
<figure>
<artwork><![CDATA[
+-------------------+-----------------+
| Jingle Action | SIP Method |
+-------------------+-----------------+
| content-accept | INVITE response |
| | (1xx or 2xx) |
+-------------------+-----------------+
| content-add | INVITE request |
+-------------------+-----------------+
| content-modify | INVITE request |
+-------------------+-----------------+
| content-remove | INVITE request |
+-------------------+-----------------+
| session-accept | INVITE response |
| | (1xx or 2xx) |
+-------------------+-----------------+
| session-info | [varies] |
+-------------------+-----------------+
| session-initiate | INVITE request |
+-------------------+-----------------+
| session-terminate | BYE |
+-------------------+-----------------+
| transport-info | [varies] |
+-------------------+-----------------+
]]></artwork>
</figure>
</section>
<section title="Audio Application Format" anchor="jingle-syntax-audio">
<t>A Jingle application format for audio exchange via RTP is specified in <xref target='XEP-0167'/>. This application format effectively maps to the "RTP/AVP" profile specified in <xref target='RFC3551'/> and the "RTP/SAVP" profile specified in RFC3711, where the media type is "audio" and the specific mappings to SDP syntax are provided in <xref target='XEP-0167'/>.</t>
</section>
<section title="Video Application Format" anchor="jingle-syntax-video">
<t>A Jingle application format for video exchange via RTP is specified in <xref target='XEP-0167'/>. This application format effectively maps to the "RTP/AVP" profile specified in <xref target='RFC3551'/> and the "RTP/SAVP" profile specified in RFC3711, where the media type is "audio" and the specific mappings to SDP syntax are provided in <xref target='XEP-0167'/>.</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 transport method involves the negotiation of an IP address and port only, and does not provide NAT traversal. 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.</t>
</section>
<section title="ICE-UDP Transport Method" anchor="jingle-syntax-ice">
<t>A more advanced Jingle transport method for exchanging media over UDP is specified in <xref target='XEP-0176'/>. Under ideal conditions this transport method provides NAT traversal by following the Interactive Connectivity Exchange methodology specified in <xref target='RFC5245'/>. The relevant SDP mappings are provided in <xref target='XEP-0176'/>.</t>
<t>When using ICE transport, Jingle endpoints are capable of sending candidates in several transport-info meesages. Since there is no equivalent way to achieve that with SIP, <xref target='XEP-0176'/> defines an offer-answer support mode defined by the "urn:ietf:rfc:3264" feature tag. Implementations conforming to this specification MUST support offfer-answer model with Jingle.</t>
</section>
</section>
<section title="Sample Scenarios" anchor="jingle-scenarios">
<t>The following sections provide sample scenarios (or "call flows") that illustrate the principles of interworking from Jingle to SIP. These scenarios are not exhaustive.</t>
<section title="Basic Voice Chat" anchor="jingle-scenarios-basic">
<t>The protocol flow for a basic voice chat for which an XMPP user ([email protected]) is the iniator and a SIP user ([email protected]) is the responder. The voice chat is consummated through a gateway. To simplify the example, the transport method negotiated is "raw user datagram protocol" as specified in <xref target='XEP-0177'/>.</t>
<figure>
<artwork><![CDATA[
INITIATOR ...XMPP... GATEWAY ...SIP... RESPONDER
| | |
| session-initiate | |
|----------------------->| |
| IQ-result (ack) | |
|<-----------------------| |
| | INVITE |
| |---------------------->|
| | 180 Ringing |
| |<----------------------|
| session-info (ringing) | |
|<-----------------------| |
| IQ-result (ack) | |
|----------------------->| |
| | 200 OK |
| |<----------------------|
| session-accept | |
|<-----------------------| |
| IQ-result (ack) | |
|----------------------->| |
| | ACK |
| |---------------------->|
| MEDIA SESSION |
|<==============================================>|
| | BYE |
| |<----------------------|
| session-terminate | |
|<-----------------------| |
| IQ-result (ack) | |
|----------------------->| |
| | 200 OK |
| |---------------------->|
| | |
]]></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><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 ip='192.0.2.101' port='49172' generation='0'/>
</transport>
</content>
</jingle>
</iq>
]]></artwork></figure>
<t>The gateway returns an XMPP IQ-result to the initiator on behalf of the responder.</t>
<figure><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><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><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><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><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.</t>
<figure><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><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 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><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 may continue the session as long as desired.</t>
<t>Eventually, one of the parties (in this case the responder) terminates the session.</t>
<figure><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: 1 BYE
Content-Length: 0
]]></artwork></figure>
<t>The gateway transforms the SIP BYE into XMPP syntax.</t>
<figure><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'
reasoncode='no-error'
sid='a73sjjvkla37jfea'/>
</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><artwork><![CDATA[
<iq from='[email protected]/v3rsch1kk3l1jk'
id='rv301b47'
to='[email protected]/t3hr0zny'
type='result'/>
]]></artwork></figure>
</section>
</section>
</section>
<section title="SIP to Jingle" anchor="sip">
<t>To follow.</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'/>).</t>
</section>
<section title='IANA Considerations' anchor="iana">
<t>This document has no actions for the IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='I-D.saintandre-sip-xmpp-core'>
<front>
<title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<author initials='A' surname='Houri' fullname='Avshalom Houri'>
<organization />
</author>
<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
<organization />
</author>
<date month='February' day='5' year='2013' />
<abstract><t>As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-sip-xmpp-core-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-core-03.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month='March' year='1997'></date>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
</reference>
<reference anchor='RFC3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date month='June' year='2002' /></front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='ftp://ftp.isi.edu/in-notes/rfc3261.txt' />
</reference>
<reference anchor='RFC3551'>
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'>
<organization /></author>
<date year='2003' month='July' />
<abstract>
<t>This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='STD' value='65' />
<seriesInfo name='RFC' value='3551' />
<format type='TXT' octets='106621' target='ftp://ftp.isi.edu/in-notes/rfc3551.txt' />
<format type='PS' octets='317286' target='ftp://ftp.isi.edu/in-notes/rfc3551.ps' />
<format type='PDF' octets='237831' target='ftp://ftp.isi.edu/in-notes/rfc3551.pdf' />
</reference>
<reference anchor='RFC4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<date year='2006' month='July' />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4566' />
<format type='TXT' octets='108820' target='ftp://ftp.isi.edu/in-notes/rfc4566.txt' />
</reference>
<reference anchor='RFC5245'>
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<date year='2010' month='April' />
<abstract>
<t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5245' />
<format type='TXT' octets='285120' target='http://www.rfc-editor.org/rfc/rfc5245.txt' />
</reference>
<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor="XEP-0166">
<front>
<title>Jingle</title>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="J." surname="Beda" fullname="Joe Beda">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</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>
<email>[email protected]</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
<email>[email protected]</email>
</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='RFC768'>
<front>
<title>User Datagram Protocol</title>
<author initials='J.' surname='Postel' fullname='J. Postel'>
<organization>University of Southern California (USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1980' day='28' month='August' /></front>
<seriesInfo name='STD' value='6' />
<seriesInfo name='RFC' value='768' />
<format type='TXT' octets='5896' target='ftp://ftp.isi.edu/in-notes/rfc768.txt' />
</reference>
<reference anchor='RFC793'>
<front>
<title abbrev='Transmission Control Protocol'>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>University of Southern California (USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal></address></author>
<date year='1981' day='1' month='September' /></front>
<seriesInfo name='STD' value='7' />
<seriesInfo name='RFC' value='793' />
<format type='TXT' octets='172710' target='ftp://ftp.isi.edu/in-notes/rfc793.txt' />
</reference>
<reference anchor='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>[email protected]</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>[email protected]</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>[email protected]</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>[email protected]</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>[email protected]</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>[email protected]</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>[email protected]</email></address></author>
<date month='June' year='1999' />
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='ftp://ftp.isi.edu/in-notes/rfc2616.txt' />
<format type='PS' octets='5529857' target='ftp://ftp.isi.edu/in-notes/rfc2616.ps' />
<format type='PDF' octets='550558' target='ftp://ftp.isi.edu/in-notes/rfc2616.pdf' />
<format type='HTML' octets='498891' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='471630' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<reference anchor='RFC3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'>
<organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'>
<organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
<organization /></author>
<date year='2003' month='July' />
<abstract>
<t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS TRACK] </t></abstract></front>
<seriesInfo name='STD' value='64' />
<seriesInfo name='RFC' value='3550' />
<format type='TXT' octets='259985' target='ftp://ftp.isi.edu/in-notes/rfc3550.txt' />
<format type='PS' octets='630740' target='ftp://ftp.isi.edu/in-notes/rfc3550.ps' />
<format type='PDF' octets='504117' target='ftp://ftp.isi.edu/in-notes/rfc3550.pdf' />
</reference>
</references>
</back>
</rfc>