RFC 7198

Duplicating RTP Streams

📅 published April 2014, from ietf

RFC 7198: Duplicating RTP Streams 🎀

Okay bestie, this is RFC 7198, and it's all about duplicating RTP streams 💖 Authors are A. Begen (Cisco) and C. Perkins (University of Glasgow). It's on the Standards Track (ISSN 2070-1721) and it was published in April 2014 ✨ The title block doesn't list any RFCs that it obsoletes or updates, so it's not replacing or patching anything else 🧚

Abstract 💅

Okay so packet loss is a total mood killer for real-time multimedia calls 😭 It can happen for lots of reasons, including unplanned network outages. On unicast, recovering from an outage can be rough depending on how long it lasted, because there could be tons of missing packets. Multicast is even harder, since loads of receivers might get hit by the same outage 💀 A solution that doesn't add unbounded delay is to duplicate the packets and send them down separate redundant streams, as long as the underlying network meets certain requirements 🦋 This doc explains how RTP (Real-time Transport Protocol) streams can be duplicated without breaking the RTP or RTCP (RTP Control Protocol) rules 🫶

Status of This Memo 🌸

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), which means it reflects consensus from the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7198 🧚

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🎀 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💜

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology and Requirements Notation . . . . . . . . . . . .   4
3.  Use Cases for Dual Streaming  . . . . . . . . . . . . . . . .   4
  3.1.  Temporal Redundancy . . . . . . . . . . . . . . . . . . .   4
  3.2.  Spatial Redundancy  . . . . . . . . . . . . . . . . . . .   5
  3.3.  Dual Streaming over a Single Path or Multiple Paths . . .   5
  3.4.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   6
4.  Use of RTP and RTCP with Temporal Redundancy  . . . . . . . .   7
  4.1.  RTCP Considerations . . . . . . . . . . . . . . . . . . .   7
  4.2.  Signaling Considerations  . . . . . . . . . . . . . . . .   7
5.  Use of RTP and RTCP with Spatial Redundancy . . . . . . . . .   8
  5.1.  RTCP Considerations . . . . . . . . . . . . . . . . . . .   9
  5.2.  Signaling Considerations  . . . . . . . . . . . . . . . .   9
6.  Use of RTP and RTCP with Temporal and Spatial Redundancy  . .  10
7.  Congestion Control Considerations . . . . . . . . . . . . . .  10
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
  10.2.  Informative References . . . . . . . . . . . . . . . . .  12

1. Introduction 🦋

RTP [RFC3550] is hugely popular right now for IPTV and other real-time multimedia sessions. A lot of these apps support massive numbers of receivers and lean on intra-domain UDP/IP multicast to distribute traffic efficiently inside the network 🌈

Okay, but there's one weakness. As [RFC2354] pointed out, packet loss is unavoidable 😭 It might come from congestion, or from an unplanned outage like a flapping link, a link or interface failure, a software bug, or a maintenance person accidentally cutting the wrong fiber 💀 UDP/IP flows don't have any way to detect loss or retransmit packets, so it's up to the RTP layer and the applications to detect loss and recover from it 🙈

In a carefully managed network, congestion shouldn't normally happen. Outages can still happen for the reasons above, though ✨ In that kind of managed network, one way to recover from packet loss without unbounded delay is to duplicate the packets and send them in separate redundant streams. As we'll see later, the odds that both copies of the same packet get lost to non-congestive packet loss are pretty tiny 🫶

People have implemented and deployed variations on this idea already [IC2011]. But duplicating RTP streams without breaking RTP and RTCP functionality hasn't been properly documented yet. This doc covers the most common use cases and explains how duplication can work for RTP streams in those cases, so it meets what the market needs right now 👑 If a different use case shows up later that this doc doesn't cover, a new spec might be needed to explain how RTP duplication should work in that scenario 🧚

Stream duplication is a simple way to protect media flows from packet loss 💖 Bandwidth overhead is comparatively high, since everything gets sent twice. Processing overhead is low though, and the overhead is very predictable 🍓 Other approaches, like retransmission-based recovery [RFC4588] or Forward Error Correction [RFC6363], might be a better fit in some other cases 🌸

2. Terminology and Requirements Notation 💜

Here are the key words, which are interpreted as described in [RFC2119]: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 📚

3. Use Cases for Dual Streaming 🎀

Dual streaming is when you send two redundant RTP streams of the same content: the original and its duplicate. Each stream can play back fine on its own when nothing gets lost. So adding that extra stream protects you against packet loss 🫶 How much protection you get depends on how the packets are sent and how they travel through the network 🦋

Dual streaming can also be extended to more than two streams if you want, which is a real bonus ✨ That said, using three or more streams is rare in practice. The overhead is high, and the extra protection is pretty small 💀

3.1. Temporal Redundancy 🌈

From a routing perspective, two streams count as identical if these two IP header fields match (plus the transport ports), because they'll both get routed over the same path 🧚

  • IP Source Address
  • IP Destination Address

Two routing-plane identical RTP streams can carry the same payload but still use different Synchronization Sources (SSRCs) to tell their RTP packets apart 💅 For dual RTP streaming, we assume the sender duplicates the RTP packets and sends them in separate RTP streams, each with its own unique SSRC. All the redundant streams go out in the same RTP session 🍓

For example, a main stream and its duplicate can be sent to the same IP destination address and UDP destination port, with some delay between them [RFC7197] 🦋 Both streams carry the same payload in their RTP packets, with identical sequence numbers 🌸 That lets receivers (or other nodes doing gap filling and duplicate suppression) spot and suppress the duplicate packets, so they end up with an output stream that's hopefully loss-free and duplication-free 💖 People usually call this "stream merging" or "de-duplication" 👑

3.2. Spatial Redundancy 🌊

An RTP source can be linked to several network interfaces, which lets it send two redundant streams from two different source addresses 💜 Those streams might take diverse paths or identical ones, depending on the routing algorithm the network uses 🧚 On the receiving end, the node in charge of duplicate suppression can check RTP header fields like the SSRC and sequence number to find and suppress the duplicate packets 🫶

If source-specific multicast (SSM) transport carries these redundant streams, each redundant stream gets its own separate SSM session. That's because the streams come from different interfaces (aka different IP addresses) 😭 So the receiving host has to join each SSM session separately 🙈

Or, the destination host could have multiple IP addresses for an RTP source to send the redundant streams to instead 🌈

3.3. Dual Streaming over a Single Path or Multiple Paths

okay so now that we know what the streams look like, here are the big takeaways 💅

  1. If two streams are routing-plane identical, their flow labels match 🙈 which makes it impractical to send them down different paths. To keep packet loss low, the packets from one stream get interleaved with the packets from its duplicate and sent with a delay. If a packet gets lost, the same packet from the duplicate stream can still reach the receiver later, because the chances of losing that exact packet again are often small 🫶 This is also called "time-shifted redundancy", "temporal redundancy" or simply "delayed duplication" [RFC7197] [IC2011]. It works with both types of dual streaming from Sections 3.1 and 3.2 ✨
  2. If the two streams have different IP headers, you get a bonus 🦋 You can build a network with physically diverse paths and deliver both streams at the same time. This reduces the delay when loss needs recovering, and it also cuts the chances of packet loss even further. An unrecoverable loss only happens when two network failures hit in just the right way that the same packet is affected on both paths. This is called Spatial Diversity or Spatial Redundancy [IC2011]. The techniques for building those diverse paths are out of scope for this document, sorry not sorry 💀

ngl, spatial redundancy often gives less delay when recovering from loss, as long as the forwarding delays of the network paths are more or less the same. (This is often ensured through careful network design 🧚) For both temporal and spatial redundancy, packet misordering can still happen, so you have to handle it using some kind of sequence numbers (e.g., RTP sequence numbers) 🔢

Temporal and spatial redundancy deal with different loss patterns 👀 Temporal helps with transient loss (inside the duplication window), while spatial helps with longer-term loss that only hits one of the two redundant paths.

To summarize, dual streaming lets the application and the network team up for a near-zero-loss transport with a bounded or minimum delay 🌈 The overhead is also predictable. It is proportional to the minimum bandwidth needed for the multimedia session, but it doesn't change based on how many receivers are losing packets and asking for retransmissions. Main character energy 👑 For a survey and comparison of similar approaches, check out [IC2011].

3.4. Requirements

okay, the rules 📜 One of the following conditions is currently REQUIRED to hold in applications using this specification:

  • 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.)
  • 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 in separate "m" lines in a Session Description Protocol (SDP) description, and that SDP has one or more other RTP streams listed in either "m" line, duplication grouping gets messy 😵‍💫 Further signaling will be needed, and that part is left for future standardization.

4. Use of RTP and RTCP with Temporal Redundancy ⏰

To get temporal redundancy, the main and duplicate RTP streams SHOULD be sent using the identical 5-tuple: transport protocol, source and destination IP addresses, and source and destination transport ports. With NAPT devices, load balancers or other middleboxes in the mix, anything other than an identical 5-tuple and flow label might also cause spatial redundancy 🙃 That can add delay because of the difference in path delays. So it is NOT RECOMMENDED unless the path is known to be free of such middleboxes.

Since the main and duplicate streams follow an identical path, they are part of the same RTP session 💜 So the sender MUST choose a different SSRC for the duplicate stream than it chose for the main stream, following the rules in Section 8 of [RFC3550].

4.1. RTCP Considerations

If RTCP is being sent for the main RTP stream, the sender MUST also generate RTCP for the duplicate RTP stream 📨 That duplicate RTCP is made exactly as if the duplicate were a regular media stream. The sender MUST NOT duplicate the main stream's RTCP packets when sending the duplicate. Instead, it MUST generate new RTCP reports for the duplicate stream. The sender MUST also use the same RTCP CNAME in the RTCP reports for both streams, so the receiver can sync them 🎀

The main and duplicate streams are conceptually synchronized using the standard RTCP Sender Reports mechanism, which derives a mapping between their timelines. But the RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams, which makes that mapping pretty trivial ✨

Both the main and duplicate RTP streams, plus their 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 totally separate media streams 🌸

4.2. Signaling Considerations

The receiver needs signaling to tell that an RTP stream is a duplicate of another stream, and not a separate stream 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. Signaling is also needed to indicate 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 that signals duplication in the SDP offer/answer exchange ('duplication-delay') is defined in [RFC7197]. The required SDP grouping semantics are defined in [RFC7104].

In the example below, a video stream is duplicated, and the main and duplicate streams are sent 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

Section 3.2 of [RFC7104] says 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 isn't critical though 🤷‍♀️ A receiving host should size its playout buffer based on the 'duplication-delay' attribute, and play whichever stream arrives first, with the other stream acting as a repair stream, no matter what order they were signaled in.

5. Use of RTP and RTCP with Spatial Redundancy 🌍

Assuming the network is structured appropriately, the duplicate RTP stream is sent using a different source and/or destination address/port pair when using spatial redundancy. That makes it a separate RTP session from the one carrying the main stream. So the SSRCs for the main and duplicate streams MUST be chosen randomly, following the rules in Section 8 of [RFC3550] 🎲 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.

5.1. RTCP Considerations

If the main RTP stream is getting RTCP, the sender MUST also produce RTCP for the duplicate RTP stream 📝 That duplicate RTCP is generated exactly as though the duplicate were an ordinary media stream. The sender MUST NOT copy over the RTCP packets sent for the main stream when it sends the duplicate. It MUST make fresh RTCP reports for the duplicate instead. The sender MUST use the same RTCP CNAME in the RTCP reports for both streams, so the receiver can line them up 🫧

The main and duplicate streams are conceptually synchronized through the standard RTCP Sender Reports mechanism, which derives a mapping between their timelines. However, the RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams, which keeps that mapping quite trivial 💫

Both the main and duplicate RTP streams, along with their 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 🌷

5.2. Signaling Considerations

The required SDP grouping semantics have been defined in [RFC7104] 📚 In the example below, the redundant streams have different IP destination addresses. Both streams show the same UDP port number and IP source address, 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

6. Use of RTP and RTCP with Temporal and Spatial Redundancy 🎀

This uses the same RTP/RTCP mechanisms from Sections 4 and 5, plus a combo of the signaling covered in each of those sections 🫶

7. Congestion Control Considerations 🚦

okay so duplicating RTP streams comes with a whole list of congestion control vibes we need to talk about 💅 first, RTP duplication MUST NOT be used when congestion is the main reason packets are getting lost, because duplicating makes congestion even worse 😭 and duplication SHOULD NOT be used if there's a risk of congestion when you duplicate the stream 🙈 Duplication is RECOMMENDED only as protection against network outages caused by a temporary link or network element failure, and only where it's known (like through explicit operator configuration) that there's enough network capacity to carry the duplicated traffic 🔥 that capacity rule keeps duplication in managed networks and makes it unsuitable for unmanaged public networks 🫶

the nodes doing the duplication and de-duplication need to really know the original stream's requirements and how much capacity the network has 👑 if the original stream can adapt, these nodes have to assume the same adaptation capability for the duplicate stream too ✨ for example, if the source doubles the bitrate for the original stream, the bitrate of the duplicate stream will also be doubled 🦋

where de-duplication happens changes the story a little 🌈 when duplication and de-duplication happen inside the network before the final endpoints that consume the RTP media, the whole process is transparent to those endpoints 💖 so the endpoints apply any congestion control (if it applies) to the de-duplicated RTP stream 💜 this output stream has fewer losses than either the original or the duplicate stream, and the endpoint makes its congestion control decisions based on that ⭐ but if de-duplication happens at the final endpoint itself, this endpoint MUST consider the aggregate of the original and duplicate RTP streams in any congestion control it wants to apply 😭 the endpoint sees losses in each stream separately, and that info 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 setups, the RTP Monitoring Framework [RFC6792] can be used to monitor the duplicated streams the same way you'd monitor an ordinary RTP stream 💅

8. Security Considerations 🔐

the security considerations of [RFC3550], [RFC7104], [RFC7197], and any RTP profiles and payload formats in use all apply, so pay attention 🫶

duplication can be done end-to-end, where the media sender generates a duplicate RTP stream and the receiver(s) do the de-duplication 💖 in that case, if the original media stream is going to be authenticated (for example using Secure RTP (SRTP) [RFC3711]), 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 done by in-network middleboxes 🧚 those middleboxes will need to rewrite the RTP SSRC so the RTP packets in the duplicate stream have a different SSRC from the original stream, and they'll need to generate and respond to RTCP packets for the duplicate stream too 💜 this kind of in-network duplication service has the potential to act as an amplifier for denial-of-service attacks if an attacker can get attack traffic duplicated, so this is a big deal 😭🔥 to prevent this, middleboxes that provide the duplication service need to authenticate the traffic to be duplicated as coming from a legitimate source, for example using the SRTP profile [RFC3711] 🛡️ this means the middlebox has to be part of the security context of the media session being duplicated, so it can access the keying material it needs for authentication 🔑 to do that, the middlebox needs to be privy to the session setup signaling 👀 how that's done depends on the type of signaling in use (SIP, Real Time Streaming Protocol (RTSP), WebRTC, etc.), and it's not specified here 🤷‍♀️

similarly, to prevent packet injection attacks, a de-duplication middlebox needs to authenticate both the original and duplicate streams, and it ought not use non-authenticated packets that it receives 🙅‍♀️ again, this means the middlebox has to be part of the security context and have access to the right signaling and keying material 🔐

using the encryption features of SRTP doesn't affect stream de-duplication middleboxes, since the RTP headers are sent in the clear 🦋 so no drama there ✨

9. Acknowledgments 🎀

thanks to Magnus Westerlund for his suggestions 🫶💖

10. References 📚

10.1. Normative References

[RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, July 2003.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC7197]  Begen, A., Cai, Y., and H. Ou, "Duplication Delay
           Attribute in the Session Description Protocol", RFC 7197,
           April 2014.

[RFC7104]  Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
           Semantics in the Session Description Protocol", RFC 7104,
           January 2014.

[RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, March 2004.

10.2. Informative References

[RFC2354]  Perkins, C. and O. Hodson, "Options for Repair of
           Streaming Media", RFC 2354, June 1998.

[RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
           Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
           July 2006.

[RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
           Correction (FEC) Framework", RFC 6363, October 2011.

[RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
           RTP Monitoring Framework", RFC 6792, November 2012.

[IC2011]   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.

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:   http://csperkins.org/
📦 where this page comes from