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
|
<pre>Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7198 Cisco
Category: Standards Track C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
<span class="h1">Duplicating RTP Streams</span>
Abstract
Packet loss is undesirable for real-time multimedia sessions but can
occur due to a variety of reasons including unplanned network
outages. In unicast transmissions, recovering from such an outage
can be difficult depending on the outage duration, due to the
potentially large number of missing packets. In multicast
transmissions, recovery is even more challenging as many receivers
could be impacted by the outage. For this challenge, one solution
that does not incur unbounded delay is to duplicate the packets and
send them in separate redundant streams, provided that the underlying
network satisfies certain requirements. This document explains how
Real-time Transport Protocol (RTP) streams can be duplicated without
breaking RTP or RTP Control Protocol (RTCP) rules.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7198">http://www.rfc-editor.org/info/rfc7198</a>.
<span class="grey">Begen & Perkins Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology and Requirements Notation . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Use Cases for Dual Streaming . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Temporal Redundancy . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Spatial Redundancy . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Dual Streaming over a Single Path or Multiple Paths . . . <a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Requirements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. RTCP Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Signaling Considerations . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. RTCP Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Signaling Considerations . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. Use of RTP and RTCP with Temporal and Spatial Redundancy . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Congestion Control Considerations . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">Begen & Perkins Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Real-time Transport Protocol (RTP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] is widely used today
for delivering IPTV traffic and other real-time multimedia sessions.
Many of these applications support very large numbers of receivers
and rely on intra-domain UDP/IP multicast for efficient distribution
of traffic within the network.
While this combination has proved successful, there does exist a
weakness. As [<a href="./rfc2354" title=""Options for Repair of Streaming Media"">RFC2354</a>] noted, packet loss is not avoidable. This
loss might be due to congestion; it might also be a result of an
unplanned outage caused by a flapping link, a link or interface
failure, a software bug, or a maintenance person accidentally cutting
the wrong fiber. Since UDP/IP flows do not provide any means for
detecting loss and retransmitting packets, it is left up to the RTP
layer and the applications to detect, and recover from, packet loss.
In a carefully managed network, congestion should not normally
happen; however, network outages can still happen due to the reasons
listed above. In such a managed network, one technique to recover
from packet loss without incurring unbounded delay is to duplicate
the packets and send them in separate redundant streams. As
described later in this document, the probability that two copies of
the same packet are lost in cases of non-congestive packet loss is
quite small.
Variations on this idea have been implemented and deployed today
[<a href="#ref-IC2011" title=""Toward Lossless Video Transport"">IC2011</a>]. However, duplication of RTP streams without breaking the
RTP and RTCP functionality has not been documented properly. This
document discusses the most common use cases and explains how
duplication can be achieved for RTP streams in such use cases to
address the immediate market needs. In the future, if there will be
a different use case that is not covered by this document, a new
specification that explains how RTP duplication should be done in
such a scenario may be needed.
Stream duplication offers a simple way to protect media flows from
packet loss. It has a comparatively high overhead in terms of
bandwidth, since everything is sent twice, but with a low overhead in
terms of processing. It is also very predictable in its overheads.
Alternative approaches, for example, retransmission-based recovery
[<a href="./rfc4588" title=""RTP Retransmission Payload Format"">RFC4588</a>] or Forward Error Correction [<a href="./rfc6363" title=""Forward Error Correction (FEC) Framework"">RFC6363</a>], may be suitable in
some other cases.
<span class="grey">Begen & Perkins Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Requirements Notation</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Use Cases for Dual Streaming</span>
Dual streaming refers to a technique that involves transmitting two
redundant RTP streams (the original plus its duplicate) of the same
content, with each stream capable of supporting the playback when
there is no packet loss. Therefore, adding an additional RTP stream
provides a protection against packet loss. The level of protection
depends on how the packets are sent and transmitted inside the
network.
It is important to note that dual streaming can easily be extended to
support cases when more than two streams are desired. However, using
three or more streams is rare in practice, due to the high overhead
that it incurs and the little additional protection it provides.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Temporal Redundancy</span>
From a routing perspective, two streams are considered identical if
the following two IP header fields are the same (in addition to the
transport ports), since they will be both routed over the same path:
o IP Source Address
o IP Destination Address
Two routing-plane identical RTP streams might carry the same payload
but can use different Synchronization Sources (SSRCs) to
differentiate the RTP packets belonging to each stream. In the
context of dual RTP streaming, we assume that the sender duplicates
the RTP packets and sends them in separate RTP streams, each with a
unique SSRC. All the redundant streams are transmitted in the same
RTP session.
For example, one main stream and its duplicate stream can be sent to
the same IP destination address and UDP destination port with a
certain delay between them [<a href="./rfc7197" title=""Duplication Delay Attribute in the Session Description Protocol"">RFC7197</a>]. The streams carry the same
payload in their respective RTP packets with identical sequence
numbers. This allows receivers (or other nodes responsible for gap
filling and duplicate suppression) to identify and suppress the
<span class="grey">Begen & Perkins Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
duplicate packets, and subsequently produce a hopefully loss-free and
duplication-free output stream. This process is commonly called
"stream merging" or "de-duplication".
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Spatial Redundancy</span>
An RTP source might be associated with multiple network interfaces,
allowing it to send two redundant streams from two separate source
addresses. Such streams can be routed over diverse or identical
paths, depending on the routing algorithm used inside the network.
At the receiving end, the node responsible for duplicate suppression
can look into various RTP header fields, for example, SSRC and
sequence number, to identify and suppress the duplicate packets.
If source-specific multicast (SSM) transport is used to carry such
redundant streams, there will be a separate SSM session for each
redundant stream since the streams are sourced from different
interfaces (i.e., IP addresses). Thus, the receiving host has to
join each SSM session separately.
Alternatively, the destination host could also have multiple IP
addresses for an RTP source to send the redundant streams to.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Dual Streaming over a Single Path or Multiple Paths</span>
Having described the characteristics of the streams, one can reach
the following conclusions:
1. When two routing-plane identical streams are used, the flow
labels will be the same. This makes it impractical to forward
the packets onto different paths. In order to minimize packet
loss, the packets belonging to one stream are often interleaved
with packets belonging to its duplicate stream, and with a delay,
so that if there is a packet loss, such a delay would allow the
same packet from the duplicate stream to reach the receiver
because the chances that the same packet is lost in transit again
are often small. This is what is also known as "time-shifted
redundancy", "temporal redundancy" or simply "delayed
duplication" [<a href="./rfc7197" title=""Duplication Delay Attribute in the Session Description Protocol"">RFC7197</a>] [<a href="#ref-IC2011" title=""Toward Lossless Video Transport"">IC2011</a>]. This approach can be used with
both types of dual streaming, described in Sections <a href="#section-3.1">3.1</a> and <a href="#section-3.2">3.2</a>.
2. If the two streams have different IP headers, an additional
opportunity arises in that one is able to build a network, with
physically diverse paths, to deliver the two streams concurrently
to the intended receivers. This reduces the delay when packet
loss occurs and needs to be recovered. Additionally, it also
further reduces chances for packet loss. An unrecoverable loss
happens only when two network failures happen in such a way that
<span class="grey">Begen & Perkins Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
the same packet is affected on both paths. This is referred to
as Spatial Diversity or Spatial Redundancy [<a href="#ref-IC2011" title=""Toward Lossless Video Transport"">IC2011</a>]. The
techniques used to build diverse paths are beyond the scope of
this document.
Note that spatial redundancy often offers less delay in
recovering from packet loss, provided that the forwarding delay
of the network paths are more or less the same. (This is often
ensured through careful network design.) For both temporal and
spatial redundancy approaches, packet misordering might still
happen and needs to be handled using the sequence numbers of some
sort (e.g., RTP sequence numbers).
Temporal and spatial redundancy deal with different patterns of
packet loss. The former helps with transient loss (within the
duplication window), while the latter helps with longer-term packet
loss that affects only one of the two redundant paths.
To summarize, dual streaming allows an application and a network to
work together to provide a near-zero-loss transport with a bounded or
minimum delay. The additional advantage includes a predictable
bandwidth overhead that is proportional to the minimum bandwidth
needed for the multimedia session, but independent of the number of
receivers experiencing a packet loss and requesting a retransmission.
For a survey and comparison of similar approaches, refer to [<a href="#ref-IC2011" title=""Toward Lossless Video Transport"">IC2011</a>].
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Requirements</span>
One of the following conditions is currently REQUIRED to hold in
applications using this specification:
o The original and duplicate RTP streams are carried (with their own
SSRCs) in the same "m" line. (There could be other RTP streams
listed in the same "m" line.)
o The original and duplicate RTP streams are carried in separate "m"
lines, and there is no other RTP stream listed in either "m" line.
When the original and duplicate RTP streams are carried in separate
"m" lines in a Session Description Protocol (SDP) description and if
the SDP description has one or more other RTP streams listed in
either "m" line, duplication grouping is not trivial and further
signaling will be needed; this is left for future standardization.
<span class="grey">Begen & Perkins Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Use of RTP and RTCP with Temporal Redundancy</span>
To achieve temporal redundancy, the main and duplicate RTP streams
SHOULD be sent using the sample 5-tuple of transport protocol, source
and destination IP addresses, and source and destination transport
ports. Due to the possible presence of network address and port
translation (NAPT) devices, load balancers, or other middleboxes, use
of anything other than an identical 5-tuple and flow label might also
cause spatial redundancy (which might introduce an additional delay
due to the delta between the path delays), and so it is NOT
RECOMMENDED unless the path is known to be free of such middleboxes.
Since the main and duplicate RTP streams follow an identical path,
they are part of the same RTP session. Accordingly, the sender MUST
choose a different SSRC for the duplicate RTP stream than it chose
for the main RTP stream, following the rules in <a href="./rfc3550#section-8">Section 8 of
[RFC3550]</a>.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. RTCP Considerations</span>
If RTCP is being sent for the main RTP stream, then the sender MUST
also generate RTCP for the duplicate RTP stream. The RTCP for the
duplicate RTP stream is generated exactly as if the duplicate RTP
stream were a regular media stream. The sender MUST NOT duplicate
the RTCP packets sent for the main RTP stream when sending the
duplicate stream; instead, it MUST generate new RTCP reports for the
duplicate stream. The sender MUST use the same RTCP CNAME in the
RTCP reports it sends for both streams, so that the receiver can
synchronize them.
The main and duplicate streams are conceptually synchronized using
the standard mechanism based on RTCP Sender Reports, deriving a
mapping between their timelines. However, the RTP timestamps and
sequence numbers MUST be identical in the main and duplicate streams,
making the mapping quite trivial.
Both the main and duplicate RTP streams, and their corresponding RTCP
reports, will be received. If RTCP is used, receivers MUST generate
RTCP reports for both the main and duplicate streams in the usual
way, treating them as entirely separate media streams.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Signaling Considerations</span>
Signaling is needed to allow the receiver to determine that an RTP
stream is a duplicate of another, rather than a separate stream that
needs to be rendered in parallel. There are two parts to this: an
SDP extension is needed in the offer/answer exchange to negotiate
support for temporal redundancy; and signaling is needed to indicate
<span class="grey">Begen & Perkins Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
which stream is the duplicate. (The latter can be done in-band using
an RTCP extension or out-of-band in the SDP description.)
Out-of-band signaling is needed for both features. The SDP attribute
to signal duplication in the SDP offer/answer exchange ('duplication-
delay') is defined in [<a href="./rfc7197" title=""Duplication Delay Attribute in the Session Description Protocol"">RFC7197</a>]. The required SDP grouping semantics
are defined in [<a href="./rfc7104" title=""Duplication Grouping Semantics in the Session Description Protocol"">RFC7104</a>].
In the following SDP example, a video stream is duplicated, and the
main and duplicate streams are transmitted in two separate SSRCs
(1000 and 1010):
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
<a href="./rfc7104#section-3.2">Section 3.2 of [RFC7104]</a> states that it is advisable that the SSRC
listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent
first, with the other SSRC (i.e., SSRC of 1010) being the time-
delayed duplicate. This is not critical, however, and a receiving
host should size its playout buffer based on the 'duplication-delay'
attribute and play the stream that arrives first in preference, with
the other stream acting as a repair stream, irrespective of the order
in which they are signaled.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Use of RTP and RTCP with Spatial Redundancy</span>
Assuming the network is structured appropriately, when using spatial
redundancy, the duplicate RTP stream is sent using a different source
and/or destination address/port pair. This will be a separate RTP
session from the session conveying the main RTP stream. Thus, the
SSRCs used for the main and duplicate streams MUST be chosen
randomly, following the rules in <a href="./rfc3550#section-8">Section 8 of [RFC3550]</a>.
Accordingly, they will almost certainly not match each other. The
sender MUST, however, use the same RTCP CNAME for both the main and
duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line
is used to indicate duplication.
<span class="grey">Begen & Perkins Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. RTCP Considerations</span>
If RTCP is being sent for the main RTP stream, then the sender MUST
also generate RTCP for the duplicate RTP stream. The RTCP for the
duplicate RTP stream is generated exactly as if the duplicate RTP
stream were a regular media stream. The sender MUST NOT duplicate
the RTCP packets sent for the main RTP stream when sending the
duplicate stream; instead, it MUST generate new RTCP reports for the
duplicate stream. The sender MUST use the same RTCP CNAME in the
RTCP reports it sends for both streams, so that the receiver can
synchronize them.
The main and duplicate streams are conceptually synchronized using
the standard mechanism based on RTCP Sender Reports, deriving a
mapping between their timelines. However, the RTP timestamps and
sequence numbers MUST be identical in the main and duplicate streams,
making the mapping quite trivial.
Both the main and duplicate RTP streams, and their corresponding RTCP
reports, will be received. If RTCP is used, receivers MUST generate
RTCP reports for both the main and duplicate streams in the usual
way, treating them as entirely separate media streams.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Signaling Considerations</span>
The required SDP grouping semantics have been defined in [<a href="./rfc7104" title=""Duplication Grouping Semantics in the Session Description Protocol"">RFC7104</a>].
In the following example, the redundant streams have different IP
destination addresses. The example shows the same UDP port number
and IP source address for each stream, but either or both could have
been different for the two streams.
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
<span class="grey">Begen & Perkins Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Use of RTP and RTCP with Temporal and Spatial Redundancy</span>
This uses the same RTP/RTCP mechanisms from Sections <a href="#section-4">4</a> and <a href="#section-5">5</a>, plus a
combination of signaling provided in each of these sections.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Congestion Control Considerations</span>
Duplicating RTP streams has several considerations in the context of
congestion control. First of all, RTP duplication MUST NOT be used
in cases where the primary cause of packet loss is congestion since
duplication can make congestion only worse. Furthermore, RTP
duplication SHOULD NOT be used where there is a risk of congestion
upon duplicating an RTP stream. Duplication is RECOMMENDED only to
be used for protection against network outages due to a temporary
link or network element failure and where it is known (e.g., through
explicit operator configuration) that there is sufficient network
capacity to carry the duplicated traffic. The capacity requirement
constrains the use of duplication to managed networks and makes it
unsuitable for use on unmanaged public networks.
It is essential that the nodes responsible for the duplication and
de-duplication are aware of the original stream's requirements and
the available capacity inside the network. If there is an adaptation
capability for the original stream, these nodes have to assume the
same adaptation capability for the duplicated stream, too. For
example, if the source doubles the bitrate for the original stream,
the bitrate of the duplicate stream will also be doubled.
Depending on where de-duplication takes place, there could be
different scenarios. When the duplication and de-duplication take
place inside the network before the ultimate endpoints that will
consume the RTP media, the whole process is transparent to these
endpoints. Thus, these endpoints will apply any congestion control,
if applicable, on the de-duplicated RTP stream. This output stream
will have fewer losses than either the original or duplicated stream
will have, and the endpoint will make congestion control decisions
accordingly. However, if de-duplication takes place at the ultimate
endpoint, this endpoint MUST consider the aggregate of the original
and duplicated RTP stream in any congestion control it wants to
apply. The endpoint will observe the losses in each stream
separately, and this information can be used to fine-tune the
duplication process. For example, the duplication interval can be
adjusted based on the duration of a common packet loss in both
streams. In these scenarios, the RTP Monitoring Framework [<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>]
can be used to monitor the duplicated streams in the same way an
ordinary RTP would be monitored.
<span class="grey">Begen & Perkins Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The security considerations of [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>], [<a href="./rfc7104" title=""Duplication Grouping Semantics in the Session Description Protocol"">RFC7104</a>], [<a href="./rfc7197" title=""Duplication Delay Attribute in the Session Description Protocol"">RFC7197</a>], and
any RTP profiles and payload formats in use apply.
Duplication can be performed end-to-end, with the media sender
generating a duplicate RTP stream, and the receiver(s) performing de-
duplication. In such cases, if the original media stream is to be
authenticated (e.g., using Secure RTP (SRTP) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>]), then the
duplicate stream also needs to be authenticated, and duplicate
packets that fail the authentication check need to be discarded.
Stream duplication and de-duplication can also be performed by in-
network middleboxes. Such middleboxes will need to rewrite the RTP
SSRC such that the RTP packets in the duplicate stream have a
different SSRC to the original stream, and such middleboxes will need
to generate and respond to RTCP packets corresponding to the
duplicate stream. This sort of in-network duplication service has
the potential to act as an amplifier for denial-of-service attacks if
the attacker can cause attack traffic to be duplicated. To prevent
this, middleboxes providing the duplication service need to
authenticate the traffic to be duplicated as being from a legitimate
source, for example, using the SRTP profile [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>]. This requires
the middlebox to be part of the security context of the media session
being duplicated, so it has access to the necessary keying material
for authentication. To do this, the middlebox will need to be privy
to the session setup signaling. Details of how that is done will
depend on the type of signaling used (SIP, Real Time Streaming
Protocol (RTSP), WebRTC, etc.), and is not specified here.
Similarly, to prevent packet injection attacks, a de-duplication
middlebox needs to authenticate original and duplicate streams, and
ought not use non-authenticated packets that are received. Again,
this requires the middlebox to be part of the security context and to
have access to the appropriate signaling and keying material.
The use of the encryption features of SRTP does not affect stream de-
duplication middleboxes, since the RTP headers are sent in the clear.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
Thanks to Magnus Westerlund for his suggestions.
<span class="grey">Begen & Perkins Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC7197">RFC7197</a>] Begen, A., Cai, Y., and H. Ou, "Duplication Delay
Attribute in the Session Description Protocol", <a href="./rfc7197">RFC 7197</a>,
April 2014.
[<a id="ref-RFC7104">RFC7104</a>] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
Semantics in the Session Description Protocol", <a href="./rfc7104">RFC 7104</a>,
January 2014.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RFC2354">RFC2354</a>] Perkins, C. and O. Hodson, "Options for Repair of
Streaming Media", <a href="./rfc2354">RFC 2354</a>, June 1998.
[<a id="ref-RFC4588">RFC4588</a>] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", <a href="./rfc4588">RFC 4588</a>,
July 2006.
[<a id="ref-RFC6363">RFC6363</a>] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", <a href="./rfc6363">RFC 6363</a>, October 2011.
[<a id="ref-RFC6792">RFC6792</a>] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", <a href="./rfc6792">RFC 6792</a>, November 2012.
[<a id="ref-IC2011">IC2011</a>] Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
"Toward Lossless Video Transport", IEEE Internet
Computing, Vol. 15, No. 6, pp. 48-57, November 2011.
<span class="grey">Begen & Perkins Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7198">RFC 7198</a> RTP Duplication April 2014</span>
Authors' Addresses
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
UK
EMail: csp@csperkins.org
URI: <a href="http://csperkins.org/">http://csperkins.org/</a>
Begen & Perkins Standards Track [Page 13]
</pre>
|
