diff options
Diffstat (limited to 'doc/rfc/rfc6828.txt')
| -rw-r--r-- | doc/rfc/rfc6828.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc6828.txt b/doc/rfc/rfc6828.txt new file mode 100644 index 0000000..aa88341 --- /dev/null +++ b/doc/rfc/rfc6828.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Xia +Request for Comments: 6828 Huawei +Category: Informational January 2013 +ISSN: 2070-1721 + + + Content Splicing for RTP Sessions + +Abstract + + Content splicing is a process that replaces the content of a main + multimedia stream with other multimedia content and delivers the + substitutive multimedia content to the receivers for a period of + time. Splicing is commonly used for insertion of local + advertisements by cable operators, whereby national advertisement + content is replaced with a local advertisement. + + This memo describes some use cases for content splicing and a set of + requirements for splicing content delivered by RTP. It provides + concrete guidelines for how an RTP mixer can be used to handle + content splicing. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6828. + + + + + + + + + + + + + + +Xia Informational [Page 1] + +RFC 6828 RTP Splicing January 2013 + + +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) 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 + + 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 ...................................17 + +1. Introduction + + This document outlines how content splicing can be used in RTP + sessions. Splicing, in general, is a process where part of a + multimedia content is replaced with other multimedia content and + delivered to the receivers for a period of time. The substitutive + content can be provided, for example, via another stream or via local + media file storage. One representative use case for splicing is + local advertisement insertion. This allows content providers to + replace national advertising content with their own regional + advertising content prior to delivering the regional advertising + content to the receivers. Besides the advertisement insertion use + case, there are other use cases in which the splicing technology can + + + +Xia Informational [Page 2] + +RFC 6828 RTP Splicing January 2013 + + + be applied, for example, splicing a recorded video into a video + conferencing session or implementing a playlist server that stitches + pieces of video together. + + Content splicing is a well-defined operation in MPEG-based cable TV + systems. Indeed, the Society for Cable Telecommunications Engineers + (SCTE) has created two standards, [SCTE30] and [SCTE35], to + standardize MPEG2-TS splicing procedures. SCTE 30 creates a + standardized method for communication between advertisement server + and splicer, and SCTE 35 supports splicing of MPEG2 transport + streams. + + When using multimedia splicing into the Internet, the media may be + transported by RTP. In this case, the original media content and + substitutive media content will use the same time period but may + contain different numbers of RTP packets due to different media + codecs and entropy coding. This mismatch may require some + adjustments of the RTP header sequence number to maintain + consistency. [RFC3550] provides the tools to enable seamless content + splicing in RTP sessions, but to date there have been no clear + guidelines on how to use these tools. + + This memo outlines the requirements for content splicing in RTP + sessions and describes how an RTP mixer can be used to meet these + requirements. + +2. System Model and Terminology + + In this document, the splicer, an intermediary network element, + handles RTP splicing. The splicer can receive main content and + substitutive content simultaneously but will send one of them at one + point of time. + + 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 RTP splicing ends, the splicer switches back to sending the main + content to the RTP receiver. + + A simplified RTP splicing diagram is depicted in Figure 1, in which + only one main content flow and one substitutive content flow are + given. Actually, the splicer can handle multiple splicing for + multiple RTP sessions simultaneously. RTP splicing may happen more + than once in multiple time slots during the lifetime of the main RTP + stream. The methods by which the splicer learns when to start and + end the splicing are out of scope for this document. + + + + + + +Xia Informational [Page 3] + +RFC 6828 RTP Splicing January 2013 + + + +---------------+ + | | Main Content +-----------+ + | Main RTP |------------->| | Output Content + | Content | | Splicer |---------------> + +---------------+ ---------->| | + | +-----------+ + | + | Substitutive Content + | + | + +-----------------------+ + | Substitutive RTP | + | Content | + | or | + | Local File Storage | + +-----------------------+ + + Figure 1: RTP Splicing Architecture + + This document uses the following terminologies. + + Output RTP Stream + + The RTP stream that the RTP receiver is currently receiving. The + content of the output of the RTP stream can be either main content + or substitutive content. + + Main Content + + The multimedia content that is conveyed in the main RTP stream. + Main content will be replaced by the substitutive content during + splicing. + + Main RTP Stream + + The RTP stream that the splicer is receiving. The content of the + main RTP stream can be replaced by substitutive content for a + period of time. + + Main RTP Sender + + The sender of RTP packets carrying the main RTP stream. + + + + + + + + + +Xia Informational [Page 4] + +RFC 6828 RTP Splicing January 2013 + + + Substitutive Content + + The multimedia content that replaces the main content during + splicing. The substitutive content can, for example, be contained + in an RTP stream from a media sender or 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 main RTP + stream are two separate streams. If the substitutive content is + provided via a substitutive RTP stream, the substitutive RTP + stream must pass through the splicer before the substitutive + content is delivered to the receiver. + + Substitutive RTP Sender + + The sender of RTP packets carrying the substitutive RTP stream. + + Splicing-In Point + + A virtual point in the RTP stream, suitable for substitutive + content entry, typically in the boundary between two independently + decodable frames. + + Splicing-Out Point + + A virtual point in the RTP stream, suitable for substitutive + content exit, typically in the boundary between two independently + decodable frames. + + Splicer + + An intermediary node that inserts substitutive content into a main + RTP stream. The splicer sends substitutive content to the RTP + receiver instead of main content during splicing. It is also + responsible for processing RTP Control Protocol (RTCP) traffic + between the RTP sender and the RTP receiver. + + + + + + + + + + + + +Xia Informational [Page 5] + +RFC 6828 RTP Splicing January 2013 + + +3. Requirements for RTP Splicing + + In order to allow seamless content splicing at the RTP layer, the + following requirements must be met. Meeting these will also allow, + but not require, seamless content 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: + + 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. + + + + + + + +Xia Informational [Page 6] + +RFC 6828 RTP Splicing January 2013 + + + 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. + + + + + + +Xia Informational [Page 7] + +RFC 6828 RTP Splicing January 2013 + + + 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 + + + + +Xia Informational [Page 8] + +RFC 6828 RTP Splicing January 2013 + + + (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. + + + + + + + + +Xia Informational [Page 9] + +RFC 6828 RTP Splicing January 2013 + + + 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 + + This section provides informative guidelines on how to handle media + substitution at the RTP layer to minimize media impact. Dealing well + with the media substitution at the RTP layer is necessary for quality + implementations. To perfectly erase any media impact needs more + considerations at the higher layers. How the media substitution is + erased at the higher layers is outside of the scope of this memo. + + If the time duration for any substitutive content mismatches, i.e., + shorter or longer than the duration of the main content to be + replaced, then media degradations may occur at the splicing point and + thus impact the user's experience. + + If the substitutive content has shorter duration from the main + content, then there could be a gap in the output RTP stream. The RTP + sequence number will be contiguous across this gap, but there will be + an unexpected jump in the RTP timestamp. Such a gap would cause the + receiver to have nothing to play. This may be unavoidable, unless + the mixer can adjusts the splice in or splice out point to + compensate. This assumes the splicing mixer can send more of the + main RTP stream in place of the shorter substitutive stream or vary + + + +Xia Informational [Page 10] + +RFC 6828 RTP Splicing January 2013 + + + the length of the substitutive content. It is the responsibility of + the higher-layer protocols and the media providers to ensure that the + substitutive content is of very similar duration as the main content + to be replaced. + + If the substitute content has longer duration 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. A + straightforward approach is that the mixer performs an ungraceful + action and terminates the splicing and switches back to the main RTP + stream even if this may cause media stuttering on the receiver. + Alternatively, the mixer may transcode the substitutive content to + play at a faster rate than normal, to adjust it to the length of the + gap in the main content and generate a new RTP stream for the + transcoded content. This is a complex operation and very specific to + the content and media codec used. Additional approaches exist; these + types of issues should be taken into account in both mixer + implementors and media generators to enable smooth substitutions. + +4.4. Congestion Control Considerations + + If the substitutive content has somewhat different characteristics + from the main content it replaces, or if the substitutive content is + encoded with a different codec or has different encoding bitrate, it + might overload the network and might cause network congestion on the + path between the mixer and the RTP receiver(s) that would not have + been caused by the main content. + + To be robust to network congestion and packet loss, a mixer that is + performing splicing must continuously monitor the status of a + downstream network by monitoring any of the following RTCP reports + that are used: + + 1. RTCP receiver reports indicate packet loss [RFC3550]. + + 2. RTCP NACKs for lost packet recovery [RFC4585]. + + 3. RTCP Explicit Congestion Notification (ECN) Feedback information + [RFC6679]. + + + + + + + + + + + + +Xia Informational [Page 11] + +RFC 6828 RTP Splicing January 2013 + + + Once the mixer detects congestion on its downstream link, it will + treat these reports as follows: + + 1. If the mixer receives the RTCP receiver reports with packet loss + indication, it will forward the reports to the substitutive RTP + sender or the main RTP sender as described in Section 4.2. + + 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from + the RTP receiver for packet loss recovery, it first identifies + the content category of lost packets to which the NACK + corresponds. Then, the mixer will generate new RTCP NACKs for + the lost packets with its own SSRC and make corresponding changes + to their sequence numbers to match original, pre-spliced, + packets. If the lost substitutive content comes from local media + file storage, the mixer acting as the substitutive RTP sender + will directly fetch the lost substitutive content and retransmit + it to the RTP receiver. The mixer may buffer the sent RTP + packets and do the retransmission. + + It is somewhat complex that the lost packets requested in a + single RTCP NACK message not only contain the main content but + also the substitutive content. To address this, the mixer must + divide the RTCP NACK packet into two separate RTCP NACK packets: + one requests for the lost main content, and another requests for + the lost substitutive content. + + 3. 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 such 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, thus + letting the RTP sender knows 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 is in compliance 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]. + + + + +Xia Informational [Page 12] + +RFC 6828 RTP Splicing January 2013 + + + 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 the above analysis, to reduce the risk of congestion and + maintain the bandwidth consumption stable over time, the substitutive + RTP stream is recommended to be encoded at an appropriate bitrate to + match that of the main RTP stream. If the substitutive RTP stream + comes from the substitutive RTP sender, this sender should have some + knowledge about the media encoding bitrate of the main content in + advance. Acquiring such knowledge is out of scope in this document. + +4.5. Considerations for Implementing Undetectable Splicing + + If it is desirable to prevent receivers from detecting that splicing + is occurring at the RTP layer, the mixer must not include a CSRC list + in outgoing RTP packets and must not forward RTCP messages from the + main RTP sender or from the substitutive RTP sender. Due to the + absence of a CSRC list in the output RTP stream, the RTP receiver + only initiates SDES, BYE, and Application-specific functions (APP) + packets to the mixer without any knowledge of the main RTP sender and + the substitutive RTP sender. + + The CSRC list identifies the contributing sources; these SSRC + identifiers of contributing sources are kept globally unique for each + RTP session. The uniqueness of the SSRC identifier is used to + resolve collisions and to detect RTP-level forwarding loops as + defined in Section 8.2 of [RFC3550]. A danger that loops involving + those contributing sources will not be detected will be created by + the absence of a CSRC list in this case. The loops could occur if + either the mixer is misconfigured to form a loop or a second + mixer/translator is added, causing packets to loop back to upstream + of the original mixer. An undetected RTP packet loop is a serious + denial-of-service threat, which can consume all available bandwidth + or mixer processing resources until the looped packets are dropped as + a result of congestion. So, non-RTP means must be used to detect and + resolve loops if the mixer does not add a CSRC list. + +5. Implementation Considerations + + When the mixer is used to handle RTP splicing, the RTP receiver does + not need any RTP/RTCP extension for splicing. As a trade-off, + additional overhead could be induced on the mixer, which uses its own + sequence number space and timing model. So the mixer will rewrite + the RTP sequence number and timestamp, whatever splicing is active or + not, and generate RTCP flows for both sides. In case the mixer + serves multiple main RTP streams simultaneously, this may lead to + more overhead on the mixer. + + + +Xia Informational [Page 13] + +RFC 6828 RTP Splicing January 2013 + + + If an undetectable splicing requirement is required, the CSRC list is + not included in the outgoing RTP packet; this 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 splicer replaces some content with other content + in RTP packets, thus breaking any RTP-level end-to-end security, such + as integrity protection and source authentication. Thus, 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. Using a limitation in the SRTP security services + regarding source authentication, the splicer can modify and + re-protect the RTP packets without enabling the receiver to detect if + the data comes from the original source or from the splicer. + + Security goals to have source authentication all the way from the RTP + main sender to the receiver through the splicer is not possible with + splicing and any existing solutions. A new solution can + theoretically be developed that enables identifying the participating + entities and what each provides, i.e., 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 will be detectable on 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 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., splicer) between + the RTP sender and the RTP receiver will not get such keying + material. This may impact the splicer's ability to perform splicing + if it is dependent on RTP payload-level hints for finding the splice + in and out points. However, other potential solutions exist to + + + +Xia Informational [Page 14] + +RFC 6828 RTP Splicing January 2013 + + + specify or mark where the splicing points exist in the media streams. + When using RTP payload security mechanisms, SRTP or other security + mechanisms at RTP or lower layers can be used to provide integrity + and source authentication between the splicer and the RTP receiver. + +7. Acknowledgments + + The following individuals have reviewed the earlier versions of this + specification and provided very 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. + +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. + + + +Xia Informational [Page 15] + +RFC 6828 RTP Splicing January 2013 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Xia Informational [Page 16] + +RFC 6828 RTP Splicing January 2013 + + +Appendix A. Why Mixer Is Chosen + + Both a translator and mixer can realize splicing by changing a set of + RTP parameters. + + A translator has no SSRC; hence it is transparent to the RTP sender + and receiver. Therefore, the RTP sender sees the full path to the + receiver when the translator is passing its content. When a + translator inserts the substitutive content, the RTP sender could get + a report on the path up to the translator itself. Additionally, if + splicing does not occur yet, the translator does not need to rewrite + the RTP header, and the overhead on the translator can be avoided. + + If a mixer is used to do splicing, it can also allow the RTP sender + to learn the situation of its content on the receiver or on the mixer + just like the translator does, which is specified in Section 4.2. + Compared to the translator, the mixer's outstanding benefit is that + it is 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. + + From the above analysis, both the translator and mixer have their own + advantages: less overhead or less complexity on handling RTCP. After + long and sophisticated discussions, the avtext WG members decided + that they prefer less complexity rather than less overhead and are + inclined to choose a mixer to do splicing. + + 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 + + + + + + + + + + +Xia Informational [Page 17] + |