RFC 6828
Content Splicing for RTP Sessions
RFC 6828: Content Splicing for RTP Sessions 🎀
Okay bestie, the title block first! 💖 This one is RFC 6828, called Content Splicing for RTP Sessions. J. Xia from Huawei wrote it, it came out in January 2013, and it's Informational (so it's not a Standards Track spec, just here to share knowledge ✨). It has ISSN 2070-1721, and it doesn't obsolete or update any other RFCs. Clean slate, no drama 💅
Abstract
Okay so, content splicing is when you swap out the content of a main multimedia stream for different multimedia content, and then send that replacement stuff to receivers for a while 🎬 Cable operators do this a lot for local ads. Like, national ads get swapped out for a local one, and it's giving very targeted 📺
This memo covers some use cases for splicing and a set of requirements for splicing content that's delivered over RTP. It also gives concrete guidelines on how an RTP mixer can handle splicing. Iconic 🦋
Status of This Memo
Real talk, this doc is not an Internet Standards Track specification. It's published for informational purposes only 🌸
It's a product of the Internet Engineering Task Force (IETF), so it does represent the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). BUT not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that.
If you want the current status, errata, or a way to give feedback, check http://www.rfc-editor.org/info/rfc6828. 🫶
Copyright Notice
Copyright (c) 2013 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're in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. 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 ....................................................2
2. System Model and Terminology ....................................3
3. Requirements for RTP Splicing ...................................6
4. Content Splicing for RTP Sessions ...............................7
4.1. RTP Processing in RTP Mixer ................................7
4.2. RTCP Processing in RTP Mixer ...............................8
4.3. Considerations for Handling Media Clipping at the
RTP Layer .................................................10
4.4. Congestion Control Considerations .........................11
4.5. Considerations for Implementing Undetectable Splicing .....13
5. Implementation Considerations ..................................13
6. Security Considerations ........................................14
7. Acknowledgments ................................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
Appendix A. Why Mixer Is Chosen ...................................171. Introduction ✨
Okay so this doc lays out how content splicing can be used in RTP sessions 🎀 Splicing, in general, is when part of some multimedia content gets replaced with other multimedia content, and that gets delivered to receivers for a period of time. The replacement can come from another stream or from local media file storage.
The big use case is local advertisement insertion. Content providers can swap national ads for their own regional ones before sending the regional content to receivers. But splicing isn't just for ads 👀 You could also splice a recorded video into a video conference, or build a playlist server that stitches pieces of video together. Main character energy 🎬
Splicing is already a well-defined thing in MPEG-based cable TV systems. The Society for Cable Telecommunications Engineers (SCTE) made two standards, [SCTE30] and [SCTE35], for MPEG2-TS splicing procedures. [SCTE30] gives a standard way for the advertisement server and the splicer to talk to each other, and [SCTE35] supports splicing MPEG2 transport streams 💜
Now, when splicing goes onto the Internet, the media may be carried by RTP. Here's the tricky bit: the original and substitutive content cover the same time period, but they might have different numbers of RTP packets because of different media codecs and entropy coding. That mismatch may mean you have to adjust the RTP header sequence number to keep things consistent 🙈 [RFC3550] gives you the tools to do seamless content splicing in RTP sessions, but so far there haven't been any clear guidelines on how to actually use those tools. Honestly, that's the gap this doc fills 🫶
So, this memo outlines the requirements for content splicing in RTP sessions and describes how an RTP mixer can be used to meet them 🌸
2. System Model and Terminology 🧚
Let's set up the cast. The splicer is an intermediary network element that handles RTP splicing 💅 It can receive main content and substitutive content at the same time, but it only sends one of them at any given moment.
When RTP splicing begins, the splicer sends the substitutive content to the RTP receiver instead of the main content for a period of time. When splicing ends, the splicer switches back to sending the main content to the RTP receiver. Simple, but so iconic 🔥
Figure 1 shows a simplified version, with only one main content flow and one substitutive content flow. In reality, the splicer can handle multiple splices for multiple RTP sessions at once 🌈 Splicing can also happen more than once, in multiple time slots, during the lifetime of the main RTP stream. How the splicer finds out when to start and stop splicing is out of scope for this document, so we're not getting into that here 🙈
+---------------+
| | Main Content +-----------+
| Main RTP |------------->| | Output Content
| Content | | Splicer |--------------->
+---------------+ ---------->| |
| +-----------+
|
| Substitutive Content
|
|
+-----------------------+
| Substitutive RTP |
| Content |
| or |
| Local File Storage |
+-----------------------+
Figure 1: RTP Splicing ArchitectureOkay, now the vocab list, because these terms are the foundation of everything after this 📝
Output RTP Stream 🎀
The RTP stream that the RTP receiver is currently receiving. Its content can be either main content or substitutive content, depending on what's going on right now.
Main Content 🎬
The multimedia content carried in the main RTP stream. Main content gets replaced by substitutive content during splicing.
Main RTP Stream 🌸
The RTP stream that the splicer is receiving. Its content can be replaced by substitutive content for a period of time.
Main RTP Sender 💌
The sender of the RTP packets carrying the main RTP stream.
Substitutive Content 🦋
The multimedia content that replaces the main content during splicing. Substitutive content can, for example, come from an RTP stream from a media sender, or it can be fetched from local media file storage.
Substitutive RTP Stream ✨
An RTP stream with new content that will replace the content in the main RTP stream. The substitutive RTP stream and the main RTP stream are two separate streams. And here's a key detail: if the substitutive content comes via a substitutive RTP stream, that substitutive RTP stream must pass through the splicer before the substitutive content is delivered to the receiver 👀
Substitutive RTP Sender 🧁
The sender of the RTP packets carrying the substitutive RTP stream.
Splicing-In Point 🚪
A virtual point in the RTP stream, suitable for substitutive content to come in. It's typically at the boundary between two independently decodable frames 💫
Splicing-Out Point 🚪
A virtual point in the RTP stream, suitable for substitutive content to exit. It's typically at the boundary between two independently decodable frames too 💫
Splicer 🧚♀️
An intermediary node that inserts substitutive content into a main RTP stream. During splicing, the splicer sends substitutive content to the RTP receiver instead of main content. It's also responsible for processing RTP Control Protocol (RTCP) traffic between the RTP sender and the RTP receiver. So yes, the splicer is basically doing a lot of work behind the scenes 💅
3. Requirements for RTP Splicing ✨
okay so, to get seamless content splicing at the RTP layer, these requirements have to be met 💅. Meeting them will also allow (but not require!) seamless splicing at layers above RTP 🦋
REQ-1:
The splicer should be agnostic about the network and transport-layer protocols used to deliver the RTP streams. 🌸
REQ-2:
The splicing operation at the RTP layer must allow splicing at any point required by the media content and must not constrain when splicing-in or splicing-out operations can take place. ⏯️
REQ-3:
Splicing of RTP content must be backward compatible with the RTP/RTCP protocol, associated profiles, payload formats, and extensions. 🎀
REQ-4:
okay this one is important 😭 The splicer will modify the content of RTP packets and thus break the end-to-end security, at a minimum, breaking the data integrity and source authentication. If the splicer is designated to insert substitutive content, it must be trusted, i.e., be in the security context(s) with the main RTP sender, the substitutive RTP sender, and the receivers. If encryption is employed, the splicer commonly must decrypt the inbound RTP packets and re-encrypt the outbound RTP packets after splicing. 🔐
REQ-5:
The splicer should rewrite as necessary and forward RTCP messages (e.g., including packet loss, jitter, etc.) sent from a downstream receiver to the main RTP sender or the substitutive RTP sender, and thus allow the main RTP sender or substitutive RTP sender to learn the performance of the downstream receiver when its content is being passed to an RTP receiver. In addition, the splicer should rewrite RTCP messages from the main RTP sender or substitutive RTP sender to the receiver. 📬
REQ-6:
The splicer must not affect other RTP sessions running between the RTP sender and the RTP receiver and must be transparent for the RTP sessions it does not splice. 🧚
REQ-7:
The RTP receiver should not be able to detect any splicing points in the RTP stream produced by the splicer on the RTP protocol level. For the advertisement insertion use case, it is important to make it difficult for the RTP receiver to detect where an advertisement insertion is starting or ending from the RTP packets, and thus avoiding the RTP receiver from filtering out the advertisement content. This memo only focuses on making the splicing undetectable at the RTP layer. The corresponding processing is depicted in Section 4.5. 🕵️♀️💜
4. Content Splicing for RTP Sessions 🎬
The RTP specification [RFC3550] defines two types of middleboxes: RTP translators and RTP mixers. Splicing is best viewed as a mixing operation. The splicer generates a new RTP stream that is a mix of the main RTP stream and the substitutive RTP stream. An RTP mixer is therefore an appropriate model for a content splicer. In the next four subsections (from Section 4.1 to Section 4.4), the document analyzes how the mixer handles RTP splicing and how it satisfies the general requirements listed in Section 3. In Section 4.5, the document looks at REQ-7 in order to hide the fact that splicing takes place. 🫶
4.1. RTP Processing in RTP Mixer 🔀
A splicer could be implemented as a mixer that receives the main RTP stream and the substitutive content (possibly via a substitutive RTP stream), and sends a single output RTP stream to the receiver(s). That output RTP stream will contain either the main content or the substitutive content. The output RTP stream will come from the mixer and will have the synchronization source (SSRC) of the mixer rather than the main RTP sender or the substitutive RTP sender. 🍓
The mixer uses its own SSRC, sequence number space, and timing model when generating the output stream. Moreover, the mixer may insert the SSRC of the main RTP stream into the contributing source (CSRC) list in the output media stream.
At the splicing-in point, when the substitutive content becomes active, the mixer chooses the substitutive RTP stream as the input stream and extracts the payload data (i.e., substitutive content). If the substitutive content comes from local media file storage, the mixer directly fetches the substitutive content. After that, the mixer encapsulates substitutive content instead of main content as the payload of the output media stream and then sends the output RTP media stream to the receiver. The mixer may insert the SSRC of the substitutive RTP stream into the CSRC list in the output media stream. If the substitutive content comes from local media file storage, the mixer should leave the CSRC list blank. 🎞️
At the splicing-out point, when the substitutive content ends, the mixer retrieves the main RTP stream as the input stream and extracts the payload data (i.e., main content). After that, the mixer encapsulates main content instead of substitutive content as the payload of the output media stream and then sends the output media stream to the receivers. Moreover, the mixer may insert the SSRC of the main RTP stream into the CSRC list in the output media stream as before. 🔁
Note that if the content is too large to fit into RTP packets sent to the RTP receiver, the mixer needs to transcode or perform application-layer fragmentation. Usually the mixer is deployed as part of a managed system and MTU will be carefully managed by this system. This document does not raise any new MTU related issues compared to a standard mixer described in [RFC3550]. 📦
Splicing may occur more than once during the lifetime of the main RTP stream. This means the mixer needs to send main content and substitutive content in turn with its own SSRC identifier. From receiver point of view, the only source of the output stream is the mixer regardless of where the content is coming from. 👑
4.2. RTCP Processing in RTP Mixer 📊
By monitoring available bandwidth and buffer levels and by computing network metrics such as packet loss, network jitter, and delay, an RTP receiver can learn the network performance and communicate this to the RTP sender via RTCP reception reports. 🌈
According to the description in Section 7.3 of [RFC3550], the mixer splits the RTCP flow between the sender and receiver into two separate RTCP loops; the RTP sender has no idea about the situation on the receiver. But splicing is a process where the mixer selects one media stream from multiple streams rather than mixing them, so the mixer can leave the SSRC identifier in the RTCP report intact (i.e., the SSRC of the downstream receiver). This enables the main RTP sender or the substitutive RTP sender to learn the situation on the receiver. 👀
If the RTCP report corresponds to a time interval that is entirely main content or entirely substitutive content, the number of output RTP packets containing substitutive content is equal to the number of input substitutive RTP packets (from the substitutive RTP stream) during splicing. In the same manner, the number of output RTP packets containing main content is equal to the number of input main RTP packets (from the main RTP stream) during non-splicing unless the mixer fragments the input RTP packets. This means that the mixer does not need to modify the loss packet fields in reception report blocks in RTCP reports. But, if the mixer fragments the input RTP packets, it may need to modify the loss packet fields to compensate for the fragmentation. Whether the input RTP packets are fragmented or not, the mixer still needs to change the SSRC field in the report block to the SSRC identifier of the main RTP sender or the substitutive RTP sender and rewrite the extended highest sequence number field to the corresponding original extended highest sequence number before forwarding the RTCP report to the main RTP sender or the substitutive RTP sender. 🧮
If the RTCP report spans the splicing-in point or the splicing-out point, it reflects the characteristics of the combination of main RTP packets and substitutive RTP packets. In this case, the mixer needs to divide the RTCP report into two separate RTCP reports and send them to their original RTP senders, respectively. For each RTCP report, the mixer also needs to make the corresponding changes to the packet loss fields in the report block besides the SSRC field and the extended highest sequence number field. ✂️
If the mixer receives an RTCP extended report (XR) block, it should rewrite the XR report block in a similar way to the reception report block in the RTCP report. 💫
Besides forwarding the RTCP reports sent from the RTP receiver, the mixer can also generate its own RTCP reports to inform the main RTP sender, or the substitutive RTP sender, of the reception quality of content not sent to the RTP receiver when it reaches the mixer. These RTCP reports use the SSRC of the mixer. If the substitutive content comes from local media file storage, the mixer does not need to generate RTCP reports for the substitutive stream. 🪄
Based on the above RTCP operating mechanism, the RTP sender whose content is being passed to a receiver will see the reception quality of its stream as received by the mixer and the reception quality of the spliced stream as received by the receiver. The RTP sender whose content is not being passed to a receiver will only see the reception quality of its stream as received by the mixer. 🎯
The mixer must forward RTCP source description (SDES) and BYE packets from the receiver to the sender and may forward them in inverse direction as defined in Section 7.3 of [RFC3550]. 📨
Once the mixer receives an RTP/Audio-Visual Profile with Feedback (AVPF) [RFC4585] transport-layer feedback packet, it must handle it carefully, as the feedback packet may contain the information of the content that comes from different RTP senders. In this case, the mixer needs to divide the feedback packet into two separate feedback packets and process the information in the feedback control information (FCI) in the two feedback packets, just as in the RTCP report process described above. 🧠
If the substitutive content comes from local media file storage (i.e., the mixer can be regarded as the substitutive RTP sender), any RTCP packets received from downstream related to the substitutive content must be terminated on the mixer without any further processing. 🛑
4.3. Considerations for Handling Media Clipping at the RTP Layer ✨
okay so this section is all about giving you informative tips for handling media substitution at the RTP layer 💅 Getting this part right is kinda necessary for a quality implementation 🫶 Erasing every trace of the media impact needs more work at the higher layers, though, and how that gets handled up there is outside the scope of this memo 🦋
If the substitutive content's duration doesn't match the main content it's replacing, whether it's shorter or longer, media degradations may show up at the splicing point and mess with the user's experience 😭
If the substitutive content is shorter than the main content, there could be a gap in the output RTP stream 🙈 The RTP sequence number stays contiguous across that gap, but the RTP timestamp takes an unexpected jump. That gap leaves the receiver with nothing to play, which is so not ideal 💀 This may be unavoidable unless the mixer can adjust the splice-in or splice-out point to compensate. That assumes the splicing mixer can send more of the main RTP stream in place of the shorter substitutive stream, or can vary the length of the substitutive content 🎀 It is the responsibility of the higher-layer protocols and the media providers to make sure the substitutive content has a very similar duration to the main content being replaced 👑
If the substitutive content is longer than the reserved gap duration, there will be an overlap between the substitutive RTP stream and the main RTP stream at the splicing-out point 😭 The straightforward move is for the mixer to do an ungraceful action: it terminates the splicing and switches back to the main RTP stream, even though this may cause media stuttering on the receiver 💅 Another option is for the mixer to transcode the substitutive content so it plays faster than normal, fitting the length of the gap in the main content, and then generate a new RTP stream for the transcoded content 🧚 This is a complex operation and very specific to the content and the media codec used 💀 There are additional approaches too 🌈 These kinds of issues should be taken into account by both mixer implementors and media generators so substitutions stay smooth ✨
4.4. Congestion Control Considerations 🌸
okay this one is lowkey important 😭 If the substitutive content has somewhat different characteristics from the main content it replaces, or if it's encoded with a different codec or a different encoding bitrate, it might overload the network 💀 That could cause network congestion on the path between the mixer and the RTP receiver(s) that wouldn't have happened with the main content alone 🙈
To be robust against network congestion and packet loss, a mixer that is performing splicing must continuously monitor the status of a downstream network. It does this by watching any of the following RTCP reports that are used:
- RTCP receiver reports indicate packet loss [RFC3550].
- RTCP NACKs for lost packet recovery [RFC4585].
- RTCP Explicit Congestion Notification (ECN) Feedback information [RFC6679].
Once the mixer detects congestion on its downstream link, it treats these reports as follows 🫶
- If the mixer receives the RTCP receiver reports with packet loss indication, it forwards the reports to the substitutive RTP sender or the main RTP sender, as described in Section 4.2 🦋
- If the mixer receives the RTCP NACK packets defined in [RFC4585] from the RTP receiver for packet loss recovery, it first identifies the content category of the lost packets that the NACK corresponds to 🔥 Then the mixer generates new RTCP NACKs for the lost packets, using its own SSRC, and makes corresponding changes to their sequence numbers so they match the original, pre-spliced packets 🧚 If the lost substitutive content comes from local media file storage, the mixer, acting as the substitutive RTP sender, directly fetches the lost substitutive content and retransmits it to the RTP receiver 💖 The mixer may buffer the sent RTP packets and do the retransmission from that buffer 🌈
It's kinda complex that the lost packets requested in a single RTCP NACK message can contain both the main content and the substitutive content 💀 To handle that, the mixer must divide the RTCP NACK packet into two separate RTCP NACK packets: one requests the lost main content, and the other requests the lost substitutive content 🙈
- If an ECN-aware mixer receives RTCP ECN feedback (RTCP ECN feedback packets or RTCP XR summary reports) defined in [RFC6679] from the RTP receiver, it must process them in a similar way to the RTP/AVPF feedback packet or RTCP XR process described in Section 4.2 of this memo 👑
These three methods require the mixer to run a congestion control loop and bitrate adaptation between itself and the RTP receiver 🎀 The mixer can thin or transcode the main RTP stream or the substitutive RTP stream, but those operations are very inefficient and difficult, and they also bring undesirable delay 😭 Fortunately, as noted in this memo, the mixer acting as a splicer can rewrite the RTCP packets sent from the RTP receiver and forward them to the RTP sender ✨ That lets the RTP sender know that congestion is being experienced on the path between the mixer and the RTP receiver 🦋 Then the RTP sender applies its congestion control algorithm and reduces the media bitrate to a value that complies with congestion control principles for the slowest link 💅 The congestion control algorithm may be a TCP-friendly bitrate adaptation algorithm specified in [RFC5348], or a Datagram Congestion Control Protocol (DCCP) congestion control algorithm defined in [RFC5762] 🌸
If the substitutive content comes from local media file storage, the mixer must directly reduce the bitrate as if it were the substitutive RTP sender 🧚
From all of the above, to reduce the risk of congestion and keep bandwidth consumption stable over time, the substitutive RTP stream is recommended to be encoded at an appropriate bitrate that matches the main RTP stream 💖 If the substitutive RTP stream comes from the substitutive RTP sender, that sender should have some knowledge of the media encoding bitrate of the main content in advance 🌈 Acquiring that knowledge is out of scope for this document 🙈
4.5. Considerations for Implementing Undetectable Splicing 🕵️♀️
so if you want receivers to not be able to detect that splicing is happening at the RTP layer, the mixer must not include a CSRC list in outgoing RTP packets, and it must not forward RTCP messages from the main RTP sender or from the substitutive RTP sender 🫣 Since there's no CSRC list in the output RTP stream, the RTP receiver only initiates SDES, BYE, and Application-specific functions (APP) packets to the mixer, with no knowledge of the main RTP sender or the substitutive RTP sender 🎀
The CSRC list identifies the contributing sources, and these SSRC identifiers of contributing sources are kept globally unique for each RTP session 💜 That uniqueness is what gets used to resolve collisions and to detect RTP-level forwarding loops, as defined in Section 8.2 of [RFC3550] ✨ But a danger is created when there's no CSRC list: loops involving those contributing sources won't be detected 😭 Loops could happen if the mixer is misconfigured to form a loop, or if a second mixer/translator is added and causes packets to loop back to upstream of the original mixer 💀 An undetected RTP packet loop is a serious denial-of-service threat, because it can consume all available bandwidth or mixer processing resources until the looped packets get dropped as a result of congestion 🔥 So, if the mixer doesn't add a CSRC list, non-RTP means must be used to detect and resolve loops 👑
5. Implementation Considerations 🛠️
when the mixer is used to handle RTP splicing, the RTP receiver doesn't need any RTP/RTCP extension for splicing 🦋 The trade-off is that extra overhead could land on the mixer, since it uses its own sequence number space and timing model 🌸 So the mixer will rewrite the RTP sequence number and timestamp whether splicing is active or not, and it will generate RTCP flows for both sides 💅 If the mixer serves multiple main RTP streams at the same time, this may mean even more overhead on the mixer 😭
If an undetectable splicing requirement is needed, the CSRC list is not included in the outgoing RTP packet 🙈 That brings a potential issue with loop detection, as briefly described in Section 4.5 💀
6. Security Considerations 🔐
the splicing application is subject to the general security considerations of the RTP specification [RFC3550] 💖
The mixer acting as a splicer replaces some content with other content in RTP packets, which breaks any RTP-level end-to-end security, such as integrity protection and source authentication 😱 So any RTP-level or outside security mechanism, such as IPsec [RFC4301] or Datagram Transport Layer Security [RFC6347], will use a security association between the splicer and the receiver 🫶 When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned with the same security association as the main RTP sender 🎀 Because of a limitation in the SRTP security services regarding source authentication, the splicer can modify and re-protect the RTP packets without the receiver being able to detect whether the data comes from the original source or from the splicer 🕵️♀️
⚠️ Security goals of having source authentication all the way from the RTP main sender through the splicer to the receiver are not possible with splicing and any existing solutions 😭 A new solution could theoretically be developed that enables identifying the participating entities and what each one provides, meaning the different media sources (main and substituting) and the splicer providing the RTP-level integration of the media payloads in a common timeline and synchronization context. Such a solution would obviously not meet REQ-7 and would be detectable at the RTP level 💀
The nature of this RTP service, offered by a network operator employing a content splicer, is that the RTP-layer security relationship is between the receiver and the splicer, and between the sender and the splicer, but it is not end-to-end between the receiver and the sender 🙈 This appears to invalidate the undetectability goal, but in the common case the receiver will consider the splicer as the main media source 🦋
Some RTP deployments use RTP payload security mechanisms (e.g., ISMACryp [ISMACryp]) 🔒 If any payload-internal security mechanisms are used, only the RTP sender and the RTP receiver establish that security context, in which case any middlebox (e.g., a splicer) between the RTP sender and the RTP receiver will not get that keying material 😭 This may affect the splicer's ability to perform splicing if it depends on RTP payload-level hints for finding the splice-in and splice-out points 🌸 However, other potential solutions exist to specify or mark where the splicing points are in the media streams ✨ When using RTP payload security mechanisms, SRTP or other security mechanisms at the RTP or lower layers can be used to provide integrity and source authentication between the splicer and the RTP receiver 💜
7. Acknowledgments ✨
okay bestie, big thank-you moment 🫶 these lovely people reviewed the earlier versions of this spec and dropped some seriously valuable comments: Colin Perkins, Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R. Oran, Cullen Jennings, Ali C. Begen, Charles Eckel, and Ning Zong. iconic team 💅💖
8. References 📚
8.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. 🎀
- [RFC4585]: Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 🦋
- [RFC6679]: Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012. ✨
8.2. Informative References 🌸
- [ISMACryp]: Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication Specification 2.0", November 2007. 🍓
- [RFC3711]: Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐
- [RFC4301]: Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 🌈
- [RFC5348]: Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. 🧚
- [RFC5762]: Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010. 💜
- [RFC6347]: Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 🔥
- [SCTE30]: Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Splicing API", 2009. 📺
- [SCTE35]: Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Cueing Message for Cable", 2011. 📺
Appendix A. Why Mixer Is Chosen 🎀
okay so this one is the big "why did we pick mixer??" explainer and it's giving pure design drama 🙈
Both a translator and a mixer can pull off splicing by changing a set of RTP parameters. ✨
A translator has no SSRC, so it's totally transparent to the RTP sender and receiver. 🦋 That means the RTP sender sees the full path all the way to the receiver when the translator is passing its content along. When a translator inserts the substitutive content, the RTP sender could get a report on the path up to the translator itself. Also, if splicing hasn't happened yet, the translator doesn't need to rewrite the RTP header, so the overhead on the translator can be avoided. 💅
If a mixer is used to do splicing, it can also let the RTP sender learn what's going on with its content on the receiver or on the mixer, just like a translator does. This is specified in Section 4.2. 🧚 The mixer's outstanding benefit is that it's pretty straightforward to do with RTCP messages, for example bit-rate adaptation to handle varying network conditions. 🌈 But the translator needs more considerations, and its implementation is more complex. 🙃
So basically, both options have their own perks: less overhead or less complexity when handling RTCP. ✨ After long and sophisticated discussions, the avtext WG members decided they'd rather have less complexity than less overhead, and they were inclined to choose a mixer to do splicing. 🫶 Yay for choosing the simpler path! 🎉
If one chooses a mixer as splicer, the overhead on the mixer must be taken into account even if the splicing has not occurred yet. 💀
Author's Address 🌸
Jinwei Xia 👑 Huawei Software No.101 Nanjing, Yuhuatai District 210012 China
Phone: +86-025-86622310 EMail: xiajinwei@huawei.com 💌
📦 where this page comes from
- ietf: rfc6828 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms