-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-avtcore-mprtp-01.html
1645 lines (1554 loc) · 112 KB
/
draft-ietf-avtcore-mprtp-01.html
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Multipath RTP (MPRTP)</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Requirements Language"/>
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terminology"/>
<link href="#rfc.section.1.3" rel="Chapter" title="1.3 Use-cases"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Goals"/>
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Functional goals"/>
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Compatibility goals"/>
<link href="#rfc.section.3" rel="Chapter" title="3 RTP Topologies"/>
<link href="#rfc.section.4" rel="Chapter" title="4 MPRTP Architecture"/>
<link href="#rfc.section.5" rel="Chapter" title="5 Example Media Flow Diagrams"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Streaming use-case"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Conversational use-case"/>
<link href="#rfc.section.6" rel="Chapter" title="6 MPRTP Functional Blocks"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Available Mechanisms within the Functional Blocks"/>
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Session Setup"/>
<link href="#rfc.section.7.1.1" rel="Chapter" title="7.1.1 Connectivity Checks"/>
<link href="#rfc.section.7.1.2" rel="Chapter" title="7.1.2 Adding New or Updating Interfaces"/>
<link href="#rfc.section.7.1.3" rel="Chapter" title="7.1.3 In-band vs. Out-of-band Signaling"/>
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Expanding RTP"/>
<link href="#rfc.section.7.3" rel="Chapter" title="7.3 Expanding RTCP"/>
<link href="#rfc.section.7.4" rel="Chapter" title="7.4 Failure Handling and Teardown"/>
<link href="#rfc.section.8" rel="Chapter" title="8 MPRTP Protocol"/>
<link href="#rfc.section.8.1" rel="Chapter" title="8.1 Overview"/>
<link href="#rfc.section.8.1.1" rel="Chapter" title="8.1.1 Gather or Discovering Candidates"/>
<link href="#rfc.section.8.1.2" rel="Chapter" title="8.1.2 NAT Traversal"/>
<link href="#rfc.section.8.1.3" rel="Chapter" title="8.1.3 Choosing between In-band (in RTCP) and Out-of-band (in SDP) Interface Advertisement"/>
<link href="#rfc.section.8.1.4" rel="Chapter" title="8.1.4 In-band Interface Advertisement"/>
<link href="#rfc.section.8.1.5" rel="Chapter" title="8.1.5 Subflow ID Assignment"/>
<link href="#rfc.section.8.1.6" rel="Chapter" title="8.1.6 Active and Passive Subflows"/>
<link href="#rfc.section.8.2" rel="Chapter" title="8.2 RTP Transmission"/>
<link href="#rfc.section.8.3" rel="Chapter" title="8.3 Playout Considerations at the Receiver"/>
<link href="#rfc.section.8.4" rel="Chapter" title="8.4 Subflow-specific RTCP Statistics and RTCP Aggregation"/>
<link href="#rfc.section.8.5" rel="Chapter" title="8.5 RTCP Transmission"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Packet Formats"/>
<link href="#rfc.section.9.1" rel="Chapter" title="9.1 RTP Header Extension for MPRTP"/>
<link href="#rfc.section.9.1.1" rel="Chapter" title="9.1.1 MPRTP RTP Extension for a Subflow"/>
<link href="#rfc.section.9.2" rel="Chapter" title="9.2 RTCP Extension for MPRTP (MPRTCP)"/>
<link href="#rfc.section.9.2.1" rel="Chapter" title="9.2.1 MPRTCP Extension for Subflow Reporting"/>
<link href="#rfc.section.9.2.1.1" rel="Chapter" title="9.2.1.1 MPRTCP for Subflow-specific SR, RR and XR"/>
<link href="#rfc.section.9.3" rel="Chapter" title="9.3 MPRTCP Extension for Interface advertisement"/>
<link href="#rfc.section.10" rel="Chapter" title="10 RTCP Timing reconsiderations for MPRTCP"/>
<link href="#rfc.section.11" rel="Chapter" title="11 SDP Considerations"/>
<link href="#rfc.section.11.1" rel="Chapter" title="11.1 Signaling MPRTP Header Extension in SDP"/>
<link href="#rfc.section.11.2" rel="Chapter" title="11.2 Signaling MPRTP capability in SDP"/>
<link href="#rfc.section.11.3" rel="Chapter" title="11.3 MPRTP with ICE"/>
<link href="#rfc.section.11.4" rel="Chapter" title="11.4 Increased Throughput"/>
<link href="#rfc.section.11.5" rel="Chapter" title="11.5 Offer/Answer"/>
<link href="#rfc.section.11.5.1" rel="Chapter" title="11.5.1 In-band Signaling Example"/>
<link href="#rfc.section.12" rel="Chapter" title="12 IANA Considerations"/>
<link href="#rfc.section.12.1" rel="Chapter" title="12.1 MPRTP Header Extension"/>
<link href="#rfc.section.12.2" rel="Chapter" title="12.2 MPRTCP Packet Type"/>
<link href="#rfc.section.12.3" rel="Chapter" title="12.3 SDP Attributes"/>
<link href="#rfc.section.12.3.1" rel="Chapter" title="12.3.1 "mprtp" attribute"/>
<link href="#rfc.section.13" rel="Chapter" title="13 Security Considerations"/>
<link href="#rfc.section.14" rel="Chapter" title="14 Acknowledgements"/>
<link href="#rfc.references" rel="Chapter" title="15 References"/>
<link href="#rfc.references.1" rel="Chapter" title="15.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="15.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Interoperating with Legacy Applications"/>
<link href="#rfc.appendix.B" rel="Chapter" title="B Change Log"/>
<link href="#rfc.appendix.B.1" rel="Chapter" title="B.1 Changes in draft-ietf-avtcore-mprtp-00"/>
<link href="#rfc.appendix.B.2" rel="Chapter" title="B.2 Changes in draft-singh-avtcore-mprtp-10"/>
<link href="#rfc.appendix.B.3" rel="Chapter" title="B.3 Changes in draft-singh-avtcore-mprtp-09"/>
<link href="#rfc.appendix.B.4" rel="Chapter" title="B.4 Changes in draft-singh-avtcore-mprtp-08"/>
<link href="#rfc.appendix.B.5" rel="Chapter" title="B.5 Changes in draft-singh-avtcore-mprtp-06 and -07"/>
<link href="#rfc.appendix.B.6" rel="Chapter" title="B.6 Changes in draft-singh-avtcore-mprtp-05"/>
<link href="#rfc.appendix.B.7" rel="Chapter" title="B.7 Changes in draft-singh-avtcore-mprtp-04"/>
<link href="#rfc.appendix.B.8" rel="Chapter" title="B.8 Changes in draft-singh-avtcore-mprtp-03"/>
<link href="#rfc.appendix.B.9" rel="Chapter" title="B.9 Changes in draft-singh-avtcore-mprtp-02"/>
<link href="#rfc.appendix.B.10" rel="Chapter" title="B.10 Changes in draft-singh-avtcore-mprtp-01"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.4.8 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. Eggert" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-avtcore-mprtp-01" />
<meta name="dct.issued" scheme="ISO8601" content="2015-7-6" />
<meta name="dct.abstract" content="The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints." />
<meta name="description" content="The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">AVT Core Working Group</td>
<td class="right">V. Singh</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">T. Karkkainen</td>
</tr>
<tr>
<td class="left">Intended status: Experimental</td>
<td class="right">J. Ott</td>
</tr>
<tr>
<td class="left">Expires: January 7, 2016</td>
<td class="right">S. Ahsan</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Aalto University</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">L. Eggert</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">NetApp</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">July 6, 2015</td>
</tr>
</tbody>
</table>
<p class="title">Multipath RTP (MPRTP)<br />
<span class="filename">draft-ietf-avtcore-mprtp-01</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on January 7, 2016.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>1.1. <a href="#rfc.section.1.1">Requirements Language</a></li>
<li>1.2. <a href="#rfc.section.1.2">Terminology</a></li>
<li>1.3. <a href="#rfc.section.1.3">Use-cases</a></li>
<li>2. <a href="#rfc.section.2">Goals</a></li>
<li>2.1. <a href="#rfc.section.2.1">Functional goals</a></li>
<li>2.2. <a href="#rfc.section.2.2">Compatibility goals</a></li>
<li>3. <a href="#rfc.section.3">RTP Topologies</a></li>
<li>4. <a href="#rfc.section.4">MPRTP Architecture</a></li>
<li>5. <a href="#rfc.section.5">Example Media Flow Diagrams</a></li>
<li>5.1. <a href="#rfc.section.5.1">Streaming use-case</a></li>
<li>5.2. <a href="#rfc.section.5.2">Conversational use-case</a></li>
<li>6. <a href="#rfc.section.6">MPRTP Functional Blocks</a></li>
<li>7. <a href="#rfc.section.7">Available Mechanisms within the Functional Blocks</a></li>
<li>7.1. <a href="#rfc.section.7.1">Session Setup</a></li>
<li>7.1.1. <a href="#rfc.section.7.1.1">Connectivity Checks</a></li>
<li>7.1.2. <a href="#rfc.section.7.1.2">Adding New or Updating Interfaces</a></li>
<li>7.1.3. <a href="#rfc.section.7.1.3">In-band vs. Out-of-band Signaling</a></li>
<li>7.2. <a href="#rfc.section.7.2">Expanding RTP</a></li>
<li>7.3. <a href="#rfc.section.7.3">Expanding RTCP</a></li>
<li>7.4. <a href="#rfc.section.7.4">Failure Handling and Teardown</a></li>
<li>8. <a href="#rfc.section.8">MPRTP Protocol</a></li>
<li>8.1. <a href="#rfc.section.8.1">Overview</a></li>
<li>8.1.1. <a href="#rfc.section.8.1.1">Gather or Discovering Candidates</a></li>
<li>8.1.2. <a href="#rfc.section.8.1.2">NAT Traversal</a></li>
<li>8.1.3. <a href="#rfc.section.8.1.3">Choosing between In-band (in RTCP) and Out-of-band (in SDP) Interface Advertisement</a></li>
<li>8.1.4. <a href="#rfc.section.8.1.4">In-band Interface Advertisement</a></li>
<li>8.1.5. <a href="#rfc.section.8.1.5">Subflow ID Assignment</a></li>
<li>8.1.6. <a href="#rfc.section.8.1.6">Active and Passive Subflows</a></li>
<li>8.2. <a href="#rfc.section.8.2">RTP Transmission</a></li>
<li>8.3. <a href="#rfc.section.8.3">Playout Considerations at the Receiver</a></li>
<li>8.4. <a href="#rfc.section.8.4">Subflow-specific RTCP Statistics and RTCP Aggregation</a></li>
<li>8.5. <a href="#rfc.section.8.5">RTCP Transmission</a></li>
<li>9. <a href="#rfc.section.9">Packet Formats</a></li>
<li>9.1. <a href="#rfc.section.9.1">RTP Header Extension for MPRTP</a></li>
<li>9.1.1. <a href="#rfc.section.9.1.1">MPRTP RTP Extension for a Subflow</a></li>
<li>9.2. <a href="#rfc.section.9.2">RTCP Extension for MPRTP (MPRTCP)</a></li>
<li>9.2.1. <a href="#rfc.section.9.2.1">MPRTCP Extension for Subflow Reporting</a></li>
<li>9.2.1.1. <a href="#rfc.section.9.2.1.1">MPRTCP for Subflow-specific SR, RR and XR</a></li>
<li>9.3. <a href="#rfc.section.9.3">MPRTCP Extension for Interface advertisement</a></li>
<li>10. <a href="#rfc.section.10">RTCP Timing reconsiderations for MPRTCP</a></li>
<li>11. <a href="#rfc.section.11">SDP Considerations</a></li>
<li>11.1. <a href="#rfc.section.11.1">Signaling MPRTP Header Extension in SDP</a></li>
<li>11.2. <a href="#rfc.section.11.2">Signaling MPRTP capability in SDP</a></li>
<li>11.3. <a href="#rfc.section.11.3">MPRTP with ICE</a></li>
<li>11.4. <a href="#rfc.section.11.4">Increased Throughput</a></li>
<li>11.5. <a href="#rfc.section.11.5">Offer/Answer</a></li>
<li>11.5.1. <a href="#rfc.section.11.5.1">In-band Signaling Example</a></li>
<li>12. <a href="#rfc.section.12">IANA Considerations</a></li>
<li>12.1. <a href="#rfc.section.12.1">MPRTP Header Extension</a></li>
<li>12.2. <a href="#rfc.section.12.2">MPRTCP Packet Type</a></li>
<li>12.3. <a href="#rfc.section.12.3">SDP Attributes</a></li>
<li>12.3.1. <a href="#rfc.section.12.3.1">"mprtp" attribute</a></li>
<li>13. <a href="#rfc.section.13">Security Considerations</a></li>
<li>14. <a href="#rfc.section.14">Acknowledgements</a></li>
<li>15. <a href="#rfc.references">References</a></li>
<li>15.1. <a href="#rfc.references.1">Normative References</a></li>
<li>15.2. <a href="#rfc.references.2">Informative References</a></li>
<li>Appendix A. <a href="#rfc.appendix.A">Interoperating with Legacy Applications</a></li>
<li>Appendix B. <a href="#rfc.appendix.B">Change Log</a></li>
<li>B.1. <a href="#rfc.appendix.B.1">Changes in draft-ietf-avtcore-mprtp-00</a></li>
<li>B.2. <a href="#rfc.appendix.B.2">Changes in draft-singh-avtcore-mprtp-10</a></li>
<li>B.3. <a href="#rfc.appendix.B.3">Changes in draft-singh-avtcore-mprtp-09</a></li>
<li>B.4. <a href="#rfc.appendix.B.4">Changes in draft-singh-avtcore-mprtp-08</a></li>
<li>B.5. <a href="#rfc.appendix.B.5">Changes in draft-singh-avtcore-mprtp-06 and -07</a></li>
<li>B.6. <a href="#rfc.appendix.B.6">Changes in draft-singh-avtcore-mprtp-05</a></li>
<li>B.7. <a href="#rfc.appendix.B.7">Changes in draft-singh-avtcore-mprtp-04</a></li>
<li>B.8. <a href="#rfc.appendix.B.8">Changes in draft-singh-avtcore-mprtp-03</a></li>
<li>B.9. <a href="#rfc.appendix.B.9">Changes in draft-singh-avtcore-mprtp-02</a></li>
<li>B.10. <a href="#rfc.appendix.B.10">Changes in draft-singh-avtcore-mprtp-01</a></li>
<li><a href="#rfc.authors">Authors' Addresses</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> Introduction</h1>
<p id="rfc.section.1.p.1">Multi-homed endpoints are becoming common in today's Internet, e.g., devices that support multiple wireless access technologies such as 3G and Wireless LAN. This means that there is often more than one network path available between two endpoints. Transport protocols, such as RTP, have not been designed to take advantage of the availability of multiple concurrent paths and therefore cannot benefit from the increased capacity and reliability that can be achieved by pooling their respective capacities.</p>
<p id="rfc.section.1.p.2">Multipath RTP (MPRTP) is an OPTIONAL extension to <a href="#RFC3550">RTP</a> <cite title="NONE">[RFC3550]</cite> that allows splitting a single RTP stream into multiple subflows that are transmitted over different paths. In effect, this pools the resource capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension to RTCP, it is used along with MPRTP to report per-path sender and receiver characteristics.</p>
<p id="rfc.section.1.p.3">Other IETF transport protocols that are capable of using multiple paths include <a href="#RFC4960">SCTP</a> <cite title="NONE">[RFC4960]</cite>, <a href="#RFC6182">MPTCP</a> <cite title="NONE">[RFC6182]</cite> and <a href="#RFC5533">SHIM6</a> <cite title="NONE">[RFC5533]</cite>. However, these protocols are not suitable for real-time communications.</p>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> Requirements Language</h1>
<p id="rfc.section.1.1.p.1">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 <a href="#RFC2119">[RFC2119]</a>.</p>
<h1 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2.</a> Terminology</h1>
<p/>
<ul>
<li>Endpoint: host either initiating or terminating an RTP flow.</li>
<li>Interface: logical or physical component that is capable of acquiring a unique IP address.</li>
<li>Path: sequence of links between a sender and a receiver. Typically, defined by a set of source and destination addresses.</li>
<li>Subflow: flow of RTP packets along a specific path, i.e., a subset of the packets belonging to an RTP stream. The combination of all RTP subflows forms the complete RTP stream. Typically, a subflow would map to a unique path, i.e., each combination of IP addresses and port pairs (5-tuple, including protocol) is a unique subflow.</li>
</ul>
<h1 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3.</a> Use-cases</h1>
<p id="rfc.section.1.3.p.1">The primary use-case for MPRTP is transporting high bit-rate streaming multimedia content between endpoints, where at least one is multi-homed. Such endpoints could be residential IPTV devices that connect to the Internet through two different Internet service providers (ISPs), or mobile devices that connect to the Internet through 3G and WLAN interfaces. By allowing RTP to use multiple paths for transmission, the following gains can be achieved: </p>
<ul>
<li>Higher quality: Pooling the resource capacity of multiple Internet paths allows higher bit-rate and higher quality codecs to be used. From the application perspective, the available bandwidth between the two endpoints increases.</li>
<li>Load balancing: Transmitting an RTP stream over multiple paths reduces the bandwidth usage on a single path, which in turn reduces the impact of the media stream on other traffic on that path.</li>
<li>Fault tolerance: When multiple paths are used in conjunction with redundancy mechanisms (FEC, re-transmissions, etc.), outages on one path have less impact on the overall perceived quality of the stream.</li>
</ul>
<p> </p>
<p id="rfc.section.1.3.p.2">A secondary use-case for MPRTP is transporting Voice over IP (VoIP) calls to a device with multiple interfaces. Again, such an endpoint could be a mobile device with multiple wireless interfaces. In this case, little is to be gained from resource pooling, i.e., higher capacity or load balancing, because a single path should be easily capable of handling the required load. However, using multiple concurrent subflows can improve fault tolerance, because traffic can shift between the subflows when path outages occur. This results in very fast transport-layer handovers that do not require support from signaling. </p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> Goals</h1>
<p id="rfc.section.2.p.1">This section outlines the basic goals that multipath RTP aims to meet. These are broadly classified as Functional goals and Compatibility goals.</p>
<h1 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a> Functional goals</h1>
<p id="rfc.section.2.1.p.1">Allow unicast RTP session to be split into multiple subflows in order to be carried over multiple paths. This may prove beneficial in case of video streaming. </p>
<ul>
<li>Increased Throughput: Cumulative capacity of the two paths may meet the requirements of the multimedia session. Therefore, MPRTP MUST support concurrent use of the multiple paths. </li>
<li>Improved Reliability: MPRTP SHOULD be able to send redundant packets or re-transmit packets along any available path to increase reliability.</li>
</ul>
<p> The protocol SHOULD be able to open new subflows for an existing session when new paths appear and MUST be able to close subflows when paths disappear.</p>
<h1 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2.</a> Compatibility goals</h1>
<p id="rfc.section.2.2.p.1">MPRTP MUST be backwards compatible; an MPRTP stream needs to fall back to be compatible with legacy RTP stacks if MPRTP support is not successfully negotiated. </p>
<ul>
<li>Application Compatibility: MPRTP service model MUST be backwards compatible with existing RTP applications, i.e., an MPRTP stack MUST be able to work with legacy RTP applications and not require changes to them. Therefore, the basic RTP APIs MUST remain unchanged, but an MPRTP stack MAY provide extended APIs so that the application can configure any additional features provided by the MPRTP stack.</li>
<li>Network Compatibility: individual RTP subflows MUST themselves be well-formed RTP flows, so that they are able to traverse NATs and firewalls. This MUST be the case even when interfaces appear after session initiation. <a href="#RFC5245">Interactive Connectivity Establishment (ICE)</a> <cite title="NONE">[RFC5245]</cite> MAY be used for discovering new interfaces or performing connectivity checks.</li>
</ul>
<p> </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> RTP Topologies</h1>
<p><a href="#RFC5117">RFC 5117</a> <cite title="NONE">[RFC5117]</cite> describes a number of scenarios using mixers and translators in single-party (point-to-point), and multi-party (point-to-multipoint) scenarios. <a href="#RFC3550">RFC 3550</a> <cite title="NONE">[RFC3550]</cite> (Section 2.3 and 7.x) discuss in detail the impact of mixers and translators on RTP and RTCP packets. MPRTP assumes that if a mixer or translator exists in the network, then either all of the multiple paths or none of the multiple paths go via this component. </p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> MPRTP Architecture</h1>
<p id="rfc.section.4.p.1">In a typical scenario, an RTP session uses a single path. In an MPRTP scenario, an RTP session uses multiple subflows that each use a different path. <a href="#fig-mprtp-streaming">Figure 1</a> shows the difference. </p>
<div id="rfc.figure.1"/>
<div id="fig-mprtp-streaming"/>
<pre>
+--------------+ Signaling +--------------+
| |------------------------------------>| |
| Client |<------------------------------------| Server |
| | Single RTP flow | |
+--------------+ +--------------+
+--------------+ Signaling +--------------+
| |------------------------------------>| |
| Client |<------------------------------------| Server |
| |<------------------------------------| |
+--------------+ MPRTP subflows +--------------+
</pre>
<p class="figure">Figure 1: Comparison between traditional RTP streaming and MPRTP</p>
<div id="rfc.figure.2"/>
<div id="fig-mprtp-archit"/>
<pre>
+-----------------------+ +-------------------------------+
| Application | | Application |
+-----------------------+ +-------------------------------+
| | | MPRTP |
+ RTP + +- - - - - - - -+- - - - - - - -+
| | | RTP subflow | RTP subflow |
+-----------------------+ +---------------+---------------+
| UDP | | UDP | UDP |
+-----------------------+ +---------------+---------------+
| IP | | IP | IP |
+-----------------------+ +---------------+---------------+
</pre>
<p class="figure">Figure 2: MPRTP Architecture</p>
<p><a href="#fig-mprtp-archit">Figure 2</a> illustrates the differences between the standard RTP stack and the MPRTP stack. MPRTP receives a normal RTP session from the application and splits it into multiple RTP subflows. Each subflow is then sent along a different path to the receiver. To the network, each subflow appears as an independent, well-formed RTP flow. At the receiver, the subflows are combined to recreate the original RTP session. The MPRTP layer performs the following functions: </p>
<ul>
<li>Path Management: The layer is aware of alternate paths to the other host, which may, for example, be the peer's multiple interfaces. This enables the endpoint to transmit differently marked packets along separate paths. MPRTP also selects interfaces to send and receive data. Furthermore, it manages the port and IP address pair bindings for each subflow. </li>
<li>Packet Scheduling: the layer splits a single RTP flow into multiple subflows and sends them across multiple interfaces (paths). The splitting MAY BE done using different path characteristics.</li>
<li>Subflow recombination: the layer creates the original stream by recombining the independent subflows. Therefore, the multipath subflows appear as a single RTP stream to applications.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Example Media Flow Diagrams</h1>
<p id="rfc.section.5.p.1">There may be many complex technical scenarios for MPRTP, however, this memo only considers the following two scenarios: 1) a unidirectional media flow that represents the streaming use-case, and 2) a bidirectional media flow that represents a conversational use-case.</p>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> Streaming use-case</h1>
<p id="rfc.section.5.1.p.1">In the unidirectional scenario, the receiver (client) initiates a multimedia session with the sender (server). The receiver or the sender may have multiple interfaces and both endpoints are MPRTP-capable. <a href="#fig-mprtp-unidir">Figure 3</a> shows this scenario. In this case, host A has multiple interfaces. Host B performs connectivity checks on host A's multiple interfaces. If the interfaces are reachable, then host B streams multimedia data along multiple paths to host A. Moreover, host B also sends RTCP Sender Reports (SR) for each subflow and host A responds with a normal RTCP Receiver Report (RR) for the overall session as well as the receiver statistics for each subflow. Host B distributes the packets across the subflows based on the individually measured path characteristics.</p>
<p id="rfc.section.5.1.p.2">Alternatively, to reduce media startup time, host B may start streaming multimedia data to host A's initiating interface and then perform connectivity checks for the other interfaces. This method of updating a single path session to a multipath session is called "multipath session upgrade". </p>
<div id="rfc.figure.3"/>
<div id="fig-mprtp-unidir"/>
<pre>
Host A Host B
----------------------- ----------
Interface A1 Interface A2 Interface B1
----------------------- ----------
| |
|------------------------------------->| Session setup with
|<-------------------------------------| multiple interfaces
| | |
| | |
| (RTP data B1->A1, B1->A2) |
|<=====================================|
| |<========================|
| | |
Note: there may be more scenarios.
</pre>
<p class="figure">Figure 3: Unidirectional media flow</p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> Conversational use-case</h1>
<p id="rfc.section.5.2.p.1">In the bidirectional scenario, multimedia data flows in both directions. The two hosts exchange their lists of interfaces with each other and perform connectivity checks. Communication begins after each host finds suitable address, port pairs. Interfaces that receive data send back RTCP receiver statistics for that path (based on the 5-tuple). The hosts balance their multimedia stream across multiple paths based on the per path reception statistics and its own volume of traffic. <a href="#fig-mprtp-bidir">Figure 4</a> describes an example of a bidirectional flow.</p>
<div id="rfc.figure.4"/>
<div id="fig-mprtp-bidir"/>
<pre>
Host A Host B
--------------------------- ---------------------------
Interface A1 Interface A2 Interface B1 Interface B2
--------------------------- ---------------------------
| | | |
| | | |Session setup
|----------------------------------->| |with multiple
|<-----------------------------------| |interfaces
| | | |
| | | |
| (RTP data B1<->A1, B2<->A2) | |
|<===================================| |
| |<===================================|
|===================================>| |
| |===================================>|
| | | |
Note: the address pairs may have other permutations,
and they may be symmetric or asymmetric combinations.
</pre>
<p class="figure">Figure 4: Bidirectional flow</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> MPRTP Functional Blocks</h1>
<p id="rfc.section.6.p.1">This section describes some of the functional blocks needed for MPRTP. We then investigate each block and consider available mechanisms in the next section. </p>
<ol>
<li>Session Setup: Interfaces may appear or disappear at anytime during the session. To preserve backward compatibility with legacy applications, a multipath session MUST look like a bundle of individual RTP sessions. A multipath session may be upgraded from a typical single path session, as and when new interfaces appear or disappear. However, it is also possible to setup a multipath session from the beginning, if the interfaces are available at the start of the multimedia session.</li>
<li>Expanding RTP: For a multipath session, each subflow MUST look like an independent RTP flow, so that individual RTCP messages can be generated per subflow. Furthermore, MPRTP splits the single multimedia stream into multiple subflows based on path characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth-delay product etc.) and dynamically adjusts the load on each link.</li>
<li>Adding Interfaces: Interfaces on the host need to be regularly discovered and advertised. This can be done at session setup and/or during the session. Discovering interfaces is outside the scope of this document.</li>
<li>Expanding RTCP: MPRTP MUST provide per path RTCP reports for monitoring the quality of the path, for load balancing, or for congestion control, etc. To maintain backward compatibility with legacy applications, the receiver MUST also send aggregate RTCP reports along with the per-path reports.</li>
<li>Maintenance and Failure Handling: In a multi-homed endpoint interfaces may appear and disappear. If this occurs at the sender, it has to re-adjust the load on the available links. On the other hand, if this occurs at the receiver, then the multimedia data transmitted by the sender to those interfaces is lost. This data may be re-transmitted along a different path i.e., to a different interface on the receiver. Furthermore, the endpoint has to either explicitly signal the disappearance of an interface, or the other endpoint has to detect it (by lack of media packets, RTCP feedback, or keep-alive packets).</li>
<li>Teardown: The MPRTP layer releases the occupied ports on the interfaces.</li>
</ol>
<p> </p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> Available Mechanisms within the Functional Blocks</h1>
<p id="rfc.section.7.p.1">This section discusses some of the possible alternatives for each functional block mentioned in the previous section.</p>
<h1 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1.</a> Session Setup</h1>
<p id="rfc.section.7.1.p.1">MPRTP session can be set up in many possible ways e.g., during handshake, or upgraded mid-session. The capability exchange may be done using out-of-band signaling (e.g., <a href="#RFC3264">Session Description Protocol (SDP)</a> <cite title="NONE">[RFC3264]</cite> in <a href="#RFC3261">Session Initiation Protocol (SIP)</a> <cite title="NONE">[RFC3261]</cite>, <a href="#I-D.ietf-mmusic-rfc2326bis">Real-Time Streaming Protocol (RTSP)</a> <cite title="NONE">[I-D.ietf-mmusic-rfc2326bis]</cite>) or in-band signaling (e.g., RTP/RTCP header extension, Session Traversal Utilities for NAT (STUN) messages).</p>
<h1 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1.</a> Connectivity Checks</h1>
<p id="rfc.section.7.1.1.p.1">The endpoint SHOULD be capable of performing connectivity checks (e.g., using <a href="#RFC5245">ICE</a> <cite title="NONE">[RFC5245]</cite>). If the IP addresses of the endpoints are reachable (e.g., globally addressable, same network etc) then connectivity checks are not needed. </p>
<h1 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2.</a> Adding New or Updating Interfaces</h1>
<p id="rfc.section.7.1.2.p.1">Interfaces can appear and disappear during a session, the endpoint MUST be capable of advertising the changes in its set of usable interfaces. Additionally, the application or OS may define a policy on when and/or what interfaces are usable. However, MPRTP requires a method to advertise or notify the other endpoint about the updated set of usable interfaces.</p>
<h1 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3.</a> In-band vs. Out-of-band Signaling</h1>
<p id="rfc.section.7.1.3.p.1">MTRTP nodes will generally use a signaling protocol to establish their MPRTP session. With the existence of such a signaling relationship, two alternatives become available to exchange information about the available interfaces on each side for extending RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and out-of-band signaling. </p>
<p id="rfc.section.7.1.3.p.2">In-band signaling refers to using mechanisms of RTP/RTCP itself to communicate interface addresses, e.g., a dedicated RTCP extensions along the lines of the one defined to communicate information about the feedback target for RTP over SSM <a href="#RFC5760">[RFC5760]</a>. In-band signaling does not rely on the availability of a separate signaling connection and the information flows along the same path as the media streams, thus minimizing dependencies. Moreover, if the media channel is secured (e.g., by means of SRTP), the signaling is implicitly protected as well if SRTCP encryption and authentication are chosen. In-band signaling is also expected to take a direct path to the peer, avoiding any signaling overlay-induced indirections and associated processing overheads in signaling elements -- avoiding such may be especially worthwhile if frequent updates may occur as in the case of mobile users. Finally, RTCP is usually sent sufficiently frequently (in point-to-point settings) to provide enough opportunities for transmission and (in case of loss) retransmission of the corresponding RTCP packets. </p>
<p id="rfc.section.7.1.3.p.3">Examples for in-band signaling include RTCP extensions as noted above or suitable extensions to <a href="#I-D.wing-mmusic-ice-mobility">STUN</a> <cite title="NONE">[I-D.wing-mmusic-ice-mobility]</cite>. </p>
<p id="rfc.section.7.1.3.p.4">Out-of-band signaling refers to using a separate signaling connection (via SIP, RTSP, or HTTP) to exchange interface information, e.g., expressed in SDP. Clear benefits are that signaling occurs at setup time anyway and that experience and SDP syntax (and procedures) are available that can be re-used or easily adapted to provide the necessary capabilities. In contrast to RTCP, SDP offers a reliable communication channel so that no separate retransmissions logic is necessary. In SDP, especially when combined with ICE, connectivity check mechanisms including sophisticated rules are readily available. While SDP is not inherently protected, suitable security may need to be applied anyway to the basic session setup. </p>
<p id="rfc.section.7.1.3.p.5">Examples for out-of-band signaling are dedicated extensions to SDP; those may be combined with ICE. </p>
<p id="rfc.section.7.1.3.p.6">Both types of mechanisms have their pros and cons for middleboxes. With in-band signaling, control packets take the same path as the media packets and they can be directly inspected by middleboxes so that the elements operating on the signaling channel do not need to understand new SDP. With out-of-band signaling, only the middleboxes processing the signaling need to be modified and those on the data forwarding path can remain untouched. </p>
<p id="rfc.section.7.1.3.p.7">Overall, it may appear sensible to provide a combination of both mechanisms: out-of-band signaling for session setup and initial interface negotiation and in-band signaling to deal with frequent changes in interface state (and for the potential case, albeit rather theoretical case of MPRTP communication without a signaling channel). </p>
<p id="rfc.section.7.1.3.p.8">In its present version, this document explores both options to provide a broad understanding of how the corresponding mechanisms would look like. </p>
<h1 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2.</a> Expanding RTP</h1>
<p><a href="#RFC3550">RTCP</a> <cite title="NONE">[RFC3550]</cite> is generated per media session. However, with MPRTP, the media sender spreads the RTP load across several interfaces. The media sender SHOULD make the path selection, load balancing and fault tolerance decisions based on the characteristics of each path. Therefore, apart from normal RTP sequence numbers defined in <a href="#RFC3550">[RFC3550]</a>, the MPRTP sender MUST add subflow-specific sequence numbers to help calculate fractional losses, jitter, RTT, playout time, etc., for each path, and a subflow identifier to associate the characteristics with a path. The RTP header extension for MPRTP is shown in <a href="#sec-mprtp-pkt-format-hdrext">Section 9.1</a>. </p>
<h1 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3.</a> Expanding RTCP</h1>
<p id="rfc.section.7.3.p.1">To provide accurate per path information an MPRTP endpoint MUST send (SR/RR) report for each unique subflow along with the overall session RTCP report. Therefore, the additional subflow reporting affects the RTCP bandwidth and the RTCP reporting interval. RTCP report scheduling for each subflow may cause a problem for RTCP recombination and reconstruction in cases when 1) RTCP for a subflow is lost, and 2) RTCP for a subflow arrives later than the other subflows. (There may be other cases as well.)</p>
<p id="rfc.section.7.3.p.2">The sender distributes the media across different paths using the per path RTCP reports. However, this document doesn't cover algorithms for congestion control or load balancing.</p>
<h1 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4.</a> Failure Handling and Teardown</h1>
<p id="rfc.section.7.4.p.1">An MPRTP endpoint MUST keep alive subflows that have been negotiated but no media is sent on them. Moreover, using the information in the subflow reports, a sender can monitor an active subflow for failure (errors, unreachability, congestion) and decide not to use (make the active subflow passive), or teardown the subflow.</p>
<p id="rfc.section.7.4.p.2">If an interface disappears, the endpoint MUST send an updated interface advertisement without the interface and release the the associated subflows.</p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#sec-mprtp-proto" id="sec-mprtp-proto">MPRTP Protocol</a></h1>
<div id="rfc.figure.5"/>
<div id="fig-mprtp-new-subflow"/>
<pre>
Host A Host B
----------------------- -----------------------
Interface A1 Interface A2 Interface B1 Interface B2
----------------------- -----------------------
| | | |
| | (1) | |
|--------------------------------------->| |
|<---------------------------------------| |
| | (2) | |
|<=======================================| |
|<=======================================| (3) |
| | (4) | |
|<- - - - - - - - - - - - - - - - - - - -| |
|<- - - - - - - - - - - - - - - - - - - -| |
|<- - - - - - - - - - - - - - - - - - - -| |
| | (5) | |
|- - - - - - - - - - - - - - - - - - - ->| |
|<=======================================| (6) |
|<=======================================| |
| |<========================================|
|<=======================================| |
| |<========================================|
Key:
| Interface
---> Signaling Protocol
<=== RTP Packets
- -> RTCP Packet
</pre>
<p class="figure">Figure 5: MPRTP New Interface</p>
<h1 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1.</a> <a href="#sec-mprtp-proto-overview" id="sec-mprtp-proto-overview">Overview</a></h1>
<p id="rfc.section.8.1.p.1">The bullet points explain the different steps shown in <a href="#fig-mprtp-new-subflow">Figure 5</a> for upgrading a single path multimedia session to multipath session. </p>
<ul class="empty">
<li>(1) The first two interactions between the hosts represents the establishment of a normal RTP session. This may performed e.g. using SIP or RTSP.</li>
<li>(2) When the RTP session has been established, host B streams media using its interface B1 to host A at interface A1.</li>
<li>(3) Host B supports sending media using MPRTP and becomes aware of an additional interface B2.</li>
<li>(4) Host B advertises the multiple interface addresses.</li>
<li>(5) Host A supports receiving media using MPRTP and becomes aware of an additional interface A2.</li>
<li>Side note, even if an MPRTP-capable host has only one interface, it MUST respond to the advertisement with its single interface.</li>
<li>(6) Each host receives information about the additional interfaces and the appropriate endpoints starts to stream the multimedia content using the additional paths.</li>
<li>If needed, each endpoint will need to independently perform connectivity checks (not shown in figure) and ascertain reachability before using the paths.</li>
</ul>
<p> </p>
<h1 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1.</a> <a href="#sec-mprtp-gather-candidates" id="sec-mprtp-gather-candidates">Gather or Discovering Candidates</a></h1>
<p id="rfc.section.8.1.1.p.1">The endpoint periodically polls the operating system or is notified when an additional interface appears. If the endpoint wants to use the additional interface for MPRTP it MUST advertise it to the other peers. The endpoint may also use <a href="#RFC5245">ICE</a> <cite title="NONE">[RFC5245]</cite> to gather additional candidates.</p>
<h1 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2.</a> <a href="#sec-mprtp-nat-traversal" id="sec-mprtp-nat-traversal">NAT Traversal</a></h1>
<p id="rfc.section.8.1.2.p.1">After gathering their interface candidates, the endpoints decide internally if they wish to perform connectivity checks.</p>
<p>
<a id="note-iceornot" class="info">[note-iceornot]<span class="info">Editor: Legacy applications do not require ICE for session establishment, therefore, MPRTP should not require it as well.</span></a>
</p>
<p id="rfc.section.8.1.2.p.3">If the endpoint chooses to perform connectivity checks then it MUST first advertise the gathered candidates as ICE candidates in SDP during session setup and let ICE perform the connectivity checks. As soon as a sufficient number of connectivity checks succeed, the endpoint can use the successful candidates to advertise its MPRTP interface candidates.</p>
<p id="rfc.section.8.1.2.p.4">Alternatively, if the endpoint supports <a href="#I-D.wing-mmusic-ice-mobility">mobility extensions for ICE</a> <cite title="NONE">[I-D.wing-mmusic-ice-mobility]</cite>, it can let the ICE agent gather and perform the connectivity checks. When the connectivity checks succeed, the ICE agent should notify the MPRTP layer of these new paths (5-tuples), these new paths are then used by MPRTP to send media packets depending on the scheduling algorithm. </p>
<p id="rfc.section.8.1.2.p.5">If an endpoint supports <a href="#I-D.reddy-mmusic-ice-best-interface-pcp">Interface selection via PCP Flow Extension</a> <cite title="NONE">[I-D.reddy-mmusic-ice-best-interface-pcp]</cite>, it will receive notifications when new interfaces become available and additionally when the link quality of a currently available interface changes. The application can advertise and perform connectivity checks with the new interface and in the case of changes in link quality pass the information to the scheduling algorithm for better application performance. </p>
<p id="rfc.section.8.1.2.p.6">[Editors note: The interaction between the RTP agent and ICE agent is needed for implementing a scheduling algorithm or congestion control. See details of a scheduling algorithm in <a href="#ACM-MPRTP">[ACM-MPRTP]</a>.]</p>
<h1 id="rfc.section.8.1.3"><a href="#rfc.section.8.1.3">8.1.3.</a> <a href="#sec-mprtp-subflow-advert" id="sec-mprtp-subflow-advert">Choosing between In-band (in RTCP) and Out-of-band (in SDP) Interface Advertisement</a></h1>
<p id="rfc.section.8.1.3.p.1">If there is no media flowing at the moment and the application wants to use the interfaces from the start of the session, it should advertise them in SDP (See <a href="#I-D.singh-mmusic-mprtp-sdp-extension">[I-D.singh-mmusic-mprtp-sdp-extension]</a>). Alternatively, the endpoint can setup the session as a single path media session and upgrade the session to multipath by advertising the session in-band (See <a href="#sec-mprtp-rtcp-subflow-advert">Section 8.1.4</a> or <a href="#I-D.wing-mmusic-ice-mobility">[I-D.wing-mmusic-ice-mobility]</a>). Moreover, if an interface appears and disappears, the endpoint SHOULD prefer to advertise it in-band because the endpoint would not have to wait for a response from the other endpoint before starting to use the interface. However, if there is a conflict between an in-band and out-of-band advertisement, i.e., the endpoint receives an in-band advertisement while it has a pending out-of-band advertisement, or vice versa then the session is setup using out-of-band mechanisms.</p>
<h1 id="rfc.section.8.1.4"><a href="#rfc.section.8.1.4">8.1.4.</a> <a href="#sec-mprtp-rtcp-subflow-advert" id="sec-mprtp-rtcp-subflow-advert">In-band Interface Advertisement</a></h1>
<p id="rfc.section.8.1.4.p.1">To advertise the multiple interfaces in RTCP, an MPRTP-capable endpoint MUST add the MPRTP Interface Advertisement defined in <a href="#fig-mp-rtcp-header-ia">Figure 13</a> with the RTCP Sender Report (SR). Each unique address is encapsulated in an Interface Advertisement block and contains the IP address, RTP and RTCP port addresses. The Interface Advertisement blocks are ordered based on a decreasing priority level. On receiving the MPRTP Interface Advertisement, an MPRTP-capable receiver MUST respond with the set of interfaces (subset or all available) it wants to use.</p>
<p id="rfc.section.8.1.4.p.2">If the sender and receiver have only one interface, then the endpoints MUST indicate the negotiated single path IP, RTP port and RTCP port addresses.</p>
<h1 id="rfc.section.8.1.5"><a href="#rfc.section.8.1.5">8.1.5.</a> <a href="#sec-mprtp-subflow-id" id="sec-mprtp-subflow-id">Subflow ID Assignment</a></h1>
<p id="rfc.section.8.1.5.p.1">After interface advertisements have been exchanged, the endpoint MUST associate a Subflow ID to each unique subflow. Each combination of sender and receiver IP addresses and port pairs (5-tuple) is a unique subflow. If the connectivity checks have been performed then the endpoint MUST only use the subflows for which the connectivity checks have succeeded.</p>
<h1 id="rfc.section.8.1.6"><a href="#rfc.section.8.1.6">8.1.6.</a> <a href="#sec-mprtp-proto-subflow-desc" id="sec-mprtp-proto-subflow-desc">Active and Passive Subflows</a></h1>
<p id="rfc.section.8.1.6.p.1">To send and receive data an endpoint MAY use any number of subflows from the set of available subflows. The subflows that carry media data are called active subflows, while those subflows that don't send any media packets (fallback paths) are called passive subflows.</p>
<p id="rfc.section.8.1.6.p.2">An endpoint MUST multiplex the subflow specific RTP and RTCP packets on the same port to keep the NAT bindings alive. This is inline with the recommendation made in RFC6263<a href="#RFC6263">[RFC6263]</a>. Moreover, if an endpoint uses ICE, multiplexing RTP and RTCP reduces the number of components from 2 to 1 per media stream. If no MPRTP or MPRTCP packets are received on a particular subflow at a receiver, the receiver SHOULD remove the subflow from active and passive lists and not send any MPRTCP reports for that subflow. It may keep the bindings in a dead-pool, so that if the 5-tuple or subflow reappears, it can quickly reallocate it based on past history.</p>
<h1 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2.</a> <a href="#sec-mprtp-pkt-trans" id="sec-mprtp-pkt-trans">RTP Transmission</a></h1>
<p id="rfc.section.8.2.p.1">If both endpoints are MPRTP-capable and if they want to use their multiple interfaces for sending the media stream then they MUST use the MPRTP header extensions. They MAY use normal RTP with legacy endpoints (see <a href="#sec-mprtp-back-legacy">Appendix A</a>).</p>
<p id="rfc.section.8.2.p.2">An MPRTP endpoint sends RTP packets with an MPRTP extension that maps the media packet to a specific subflow (see <a href="#fig-mprtp-header-subflow">Figure 8</a>). The MPRTP layer SHOULD associate an RTP packet with a subflow based on a scheduling strategy. The scheduling strategy may either choose to augment the paths to create higher throughput or use the alternate paths for enhancing resilience or error-repair. Due to the changes in path characteristics, the endpoint should be able change its scheduling strategy during an ongoing session. The MPRTP sender MUST also populate the subflow specific fields described in the MPRTP extension header (see <a href="#sec-mprtp-pkt-format-hdrext-rtp">Section 9.1.1</a>).</p>
<p><a href="#ACM-MPRTP">[ACM-MPRTP]</a> describes and evaluates a scheduling algorithm for video over multiple interfaces. The video is encoded at a single target bit rate and is evaluated in various network scenarios, as discussed in <a href="#I-D.ietf-rmcat-eval-criteria">[I-D.ietf-rmcat-eval-criteria]</a>. </p>
<h1 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3.</a> <a href="#sec-mprtp-playout" id="sec-mprtp-playout">Playout Considerations at the Receiver</a></h1>
<p id="rfc.section.8.3.p.1">A media receiver, irrespective of MPRTP support or not, should be able to playback the media stream because the received RTP packets are compliant to <a href="#RFC3550">[RFC3550]</a>, i.e., a non-MPRTP receiver will ignore the MPRTP header and still be able to playback the RTP packets. However, the variation of jitter and loss per path may affect proper playout. The receiver can compensate for the jitter by modifying the playout delay (i.e., by calculating skew across all paths) of the received RTP packets. For example, an adaptive playout algorithm is discussed in <a href="#ACM-MPRTP">[ACM-MPRTP]</a>.</p>
<h1 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4.</a> <a href="#sec-mprtp-rtcp-agg" id="sec-mprtp-rtcp-agg">Subflow-specific RTCP Statistics and RTCP Aggregation</a></h1>
<p id="rfc.section.8.4.p.1">Aggregate RTCP provides the overall media statistics and follows the normal RTCP defined in RFC3550 <a href="#RFC3550">[RFC3550]</a>. However, subflow specific RTCP provides the per path media statistics because the aggregate RTCP report may not provide sufficient per path information to an MPRTP scheduler. Specifically, the scheduler should be aware of each path's RTT and loss-rate, which an aggregate RTCP cannot provide.</p>
<p id="rfc.section.8.4.p.2">The aggregate RTCP report (i.e., the regularly scheduled RTCP report) MUST be sent compounded as described in <a href="#RFC5506">[RFC5506]</a>, however, the subflow-specific RTCP reports MAY be sent non-compounded. Further, each subflow and the aggregate RTCP report MUST follow the timing rules defined in <a href="#RFC4585">[RFC4585]</a>. </p>
<p id="rfc.section.8.4.p.3">The RTCP reporting interval is locally implemented and the scheduling of the RTCP reports may depend on the the behavior of each path. For instance, the RTCP interval may be different for a passive path than an active path to keep port bindings alive. Additionally, an endpoint may decide to share the RTCP reporting bit rate equally across all its paths or schedule based on the receiver rate on each path.</p>
<h1 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5.</a> <a href="#sec-mp-rtcp-pkt-trans" id="sec-mp-rtcp-pkt-trans">RTCP Transmission</a></h1>
<p id="rfc.section.8.5.p.1">The sender sends an RTCP SR on each active path. For each SR the receiver gets, it echoes one back to the same IP address-port pair that sent the SR. The receiver tries to choose the symmetric path and if the routing is symmetric then the per-path RTT calculations will work out correctly. However, even if the paths are not symmetric, the sender would at maximum, under-estimate the RTT of the path by a factor of half of the actual path RTT.</p>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#sec-mprtp-pkt-format" id="sec-mprtp-pkt-format">Packet Formats</a></h1>
<p id="rfc.section.9.p.1">In this section we define the protocol structures described in the previous sections.</p>
<h1 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1.</a> <a href="#sec-mprtp-pkt-format-hdrext" id="sec-mprtp-pkt-format-hdrext">RTP Header Extension for MPRTP</a></h1>
<p id="rfc.section.9.1.p.1">The MPRTP header extension is used to distribute a single RTP stream over multiple subflows.</p>
<p id="rfc.section.9.1.p.2">The header conforms to the one-byte RTP header extension defined in <a href="#RFC5285">[RFC5285]</a>. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length, see Section 5.3.1 of <a href="#RFC3550">[RFC3550]</a> for details).</p>
<p id="rfc.section.9.1.p.3">The RTP header for each subflow is defined below:</p>
<div id="rfc.figure.6"/>
<div id="fig-mprtp-header-gen"/>
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | LEN | MPID |LENGTH | MPRTP header data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p class="figure">Figure 6: Generic MPRTP header extension</p>
<div id="rfc.figure.7"/>
<div id="table-mprtp-rtp-extn"/>
<pre>
+---------------+--------------------------------------------------+
| MPID ID | Use |
| Value | |
+---------------+--------------------------------------------------+
| 0x0 | Subflow RTP Header. For this case the Length is |
| | set to 4 |
+---------------+--------------------------------------------------+
</pre>
<p class="figure">Figure 7: RTP header extension values for MPRTP (H-Ext ID)</p>
<p/>
<ul class="empty">
<li>MPID: <ul class="empty"><li>The MPID field corresponds to the type of MPRTP packet. Namely: </li></ul><p> </p></li>
<li>length <ul class="empty"><li>The 4-bit length field is the length of extension data in bytes not including the H-Ext ID and length fields. The value zero indicates there is no data following.</li></ul><p> </p></li>
<li>MPRTP header data <ul class="empty"><li>Carries the MPID specific data as described in the following sub-sections.</li></ul><p> </p></li>
</ul>
<h1 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1.</a> <a href="#sec-mprtp-pkt-format-hdrext-rtp" id="sec-mprtp-pkt-format-hdrext-rtp">MPRTP RTP Extension for a Subflow</a></h1>
<p id="rfc.section.9.1.1.p.1">The RTP header for each subflow is defined below:</p>
<div id="rfc.figure.8"/>
<div id="fig-mprtp-header-subflow"/>
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | LEN=4 | 0x0 | LEN=4 | Subflow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific Seq Number | Pad (0) | Pad (0) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p class="figure">Figure 8: MPRTP header for subflow</p>
<p/>
<ul class="empty">
<li>MP ID = 0x0 <ul class="empty"><li>Indicates that the MPRTP header extension carries subflow specific information.</li></ul><p> </p></li>
<li>length = 4</li>
<li>Subflow ID: Identifier of the subflow. Every RTP packet belonging to the same subflow carries the same unique subflow identifier.</li>
<li>Flow-Specific Sequence Number (FSSN): Sequence of the packet in the subflow. Each subflow has its own strictly monotonically increasing sequence number space.</li>
</ul>
<h1 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2.</a> <a href="#sec-pkt-format-mprtcp-gen" id="sec-pkt-format-mprtcp-gen">RTCP Extension for MPRTP (MPRTCP)</a></h1>
<p id="rfc.section.9.2.p.1">The MPRTP RTCP header extension is used to 1) provide RTCP feedback per subflow to determine the characteristics of each path, and 2) advertise each interface.</p>
<div id="rfc.figure.9"/>
<div id="fig-mp-rtcp-header"/>
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=MPRTCP=211 | encaps_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type | block length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP Reports |
| ... |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
</pre>
<p class="figure">Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to normal SR/RR]</p>
<div id="rfc.figure.10"/>
<div id="table-mprtp-rtcp-extn"/>
<pre>
+---------------+--------------------------------------------------+
| MPRTCP_Type | Use |
| Value | |
+---------------+--------------------------------------------------+
| 0 | Subflow Specific Report |
| 1 | Interface Advertisement (IPv4 Address) |
| 2 | Interface Advertisement (IPv4 Address) |
| 3 | Interface Advertisement (DNS Address) |
+---------------+--------------------------------------------------+
</pre>
<p class="figure">Figure 10: RTP header extension values for MPRTP (MPRTCP_Type)</p>
<p/>
<ul class="empty">
<li>MPRTCP: 8 bits <ul class="empty"><li>Contains the constant 211 to identify this as an Multipath RTCP packet.</li></ul><p> </p></li>
<li>encaps_length: 16 bits <ul class="empty"><li>As described for the RTCP packet (see Section 6.4.1 of the RTP specification <a href="#RFC3550">[RFC3550]</a>), the length of this is in 32-bit words minus one, including the header and any padding. </li><li>The encaps_length covers all MPRTCP_Type report blocks included within this report. </li></ul><p> </p></li>
<li>MPRTCP_Type: 8-bits <ul class="empty"><li>The MPRTCP_Type field corresponds to the type of MPRTP RTCP packet. Namely: </li></ul><p> </p></li>
<li>block length: 8-bits <ul class="empty"><li>The 8-bit length field is the length of the encapsulated MPRTCP reports in 32-bit word length (i.e., length * 4 bytes) including the MPRTCP_Type and length fields. The value zero is invalid and the report block MUST be ignored.</li></ul><p> </p></li>
<li>MPRTCP Reports: variable size <ul class="empty"><li>Defined later in <a href="#sec-mprtp-pkt-format-subflow-rtcp">9.2.1</a> and <a href="#sec-mprtp-pkt-format-rtcp-ia">9.3</a>.</li></ul><p> </p></li>
</ul>
<h1 id="rfc.section.9.2.1"><a href="#rfc.section.9.2.1">9.2.1.</a> <a href="#sec-mprtp-pkt-format-subflow-rtcp" id="sec-mprtp-pkt-format-subflow-rtcp">MPRTCP Extension for Subflow Reporting</a></h1>
<p id="rfc.section.9.2.1.p.1">When sending a report for a specific subflow the sender or receiver MUST add only the reports associated with that 5-tuple. Each subflow is reported independently using the following MPRTCP Feedback header.</p>
<div id="rfc.figure.11"/>
<div id="fig-mp-rtcp-header-generic"/>
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=MPRTCP=211 | encaps_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |