draft-ietf-avtext-splicing-for-rtp-13.txt   rfc6828.txt 
AVTEXT Working Group J. Xia Internet Engineering Task Force (IETF) J. Xia
Internet-Draft Huawei Request for Comments: 6828 Huawei
Intended status: Informational November 14, 2012 Category: Informational January 2013
Expires: May 18, 2013 ISSN: 2070-1721
Content Splicing for RTP Sessions Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-13
Abstract Abstract
Content splicing is a process that replaces the content of a main Content splicing is a process that replaces the content of a main
multimedia stream with other multimedia content, and delivers the multimedia stream with other multimedia content and delivers the
substitutive multimedia content to the receivers for a period of substitutive multimedia content to the receivers for a period of
time. Splicing is commonly used for local advertisement insertion by time. Splicing is commonly used for insertion of local
cable operators, replacing a national advertisement content with a advertisements by cable operators, whereby national advertisement
local advertisement. content is replaced with a local advertisement.
This memo describes some use cases for content splicing and a set of This memo describes some use cases for content splicing and a set of
requirements for splicing content delivered by RTP. It provides requirements for splicing content delivered by RTP. It provides
concrete guidelines for how an RTP mixer can be used to handle concrete guidelines for how an RTP mixer can be used to handle
content splicing. content splicing.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on May 18, 2013. 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.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. System Model and Terminology . . . . . . . . . . . . . . . . . 3 2. System Model and Terminology ....................................3
3. Requirements for RTP Splicing . . . . . . . . . . . . . . . . 6 3. Requirements for RTP Splicing ...................................6
4. Content Splicing for RTP sessions . . . . . . . . . . . . . . 7 4. Content Splicing for RTP Sessions ...............................7
4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7 4.1. RTP Processing in RTP Mixer ................................7
4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 8 4.2. RTCP Processing in RTP Mixer ...............................8
4.3. Considerations for Handling Media Clipping at the RTP 4.3. Considerations for Handling Media Clipping at the
Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 10 RTP Layer .................................................10
4.4. Congestion Control Considerations . . . . . . . . . . . . 11 4.4. Congestion Control Considerations .........................11
4.5. Considerations for Implementing Undetectable Splicing . . 12 4.5. Considerations for Implementing Undetectable Splicing .....13
5. Implementation Considerations . . . . . . . . . . . . . . . . 13 5. Implementation Considerations ..................................13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations ........................................14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments ................................................15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References .....................................................15
9. 10. Appendix- Why Mixer Is Chosen . . . . . . . . . . . . . . 15 8.1. Normative References ......................................15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References ....................................15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 Appendix A. Why Mixer Is Chosen ...................................17
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document outlines how content splicing can be used in RTP This document outlines how content splicing can be used in RTP
sessions. Splicing, in general, is a process where part of a sessions. Splicing, in general, is a process where part of a
multimedia content is replaced with other multimedia content, and multimedia content is replaced with other multimedia content and
delivered to the receivers for a period of time. The substitutive delivered to the receivers for a period of time. The substitutive
content can be provided for example via another stream or via local content can be provided, for example, via another stream or via local
media file storage. One representative use case for splicing is media file storage. One representative use case for splicing is
local advertisement insertion, allowing content providers to replace local advertisement insertion. This allows content providers to
the national advertising content with its own regional advertising replace national advertising content with their own regional
content prior to delivering the regional advertising content to the advertising content prior to delivering the regional advertising
receivers. Besides the advertisement insertion use case, there are content to the receivers. Besides the advertisement insertion use
other use cases in which splicing technology can be applied. For case, there are other use cases in which the splicing technology can
example, splicing a recorded video into a video conferencing session, be applied, for example, splicing a recorded video into a video
or implementing a playlist server that stitches pieces of video conferencing session or implementing a playlist server that stitches
together. pieces of video together.
Content splicing is a well-defined operation in MPEG-based cable TV Content splicing is a well-defined operation in MPEG-based cable TV
systems. Indeed, the Society for Cable Telecommunications Engineers systems. Indeed, the Society for Cable Telecommunications Engineers
(SCTE) has created two standards, [SCTE30] and [SCTE35], to (SCTE) has created two standards, [SCTE30] and [SCTE35], to
standardize MPEG2-TS splicing procedure. SCTE 30 creates a standardize MPEG2-TS splicing procedures. SCTE 30 creates a
standardized method for communication between advertisements server standardized method for communication between advertisement server
and splicer, and SCTE 35 supports splicing of MPEG2 transport and splicer, and SCTE 35 supports splicing of MPEG2 transport
streams. streams.
When using multimedia splicing into the internet, the media may be When using multimedia splicing into the Internet, the media may be
transported by RTP. In this case the original media content and transported by RTP. In this case, the original media content and
substitutive media content will use the same time period, but may substitutive media content will use the same time period but may
contain different numbers of RTP packets due to different media contain different numbers of RTP packets due to different media
codecs and entropy coding. This mismatch may require some codecs and entropy coding. This mismatch may require some
adjustments of the RTP header sequence number to maintain adjustments of the RTP header sequence number to maintain
consistency. [RFC3550] provides the tools to enabled seamless consistency. [RFC3550] provides the tools to enable seamless content
content splicing in RTP session, but to date there has been no clear splicing in RTP sessions, but to date there have been no clear
guidelines on how to use these tools. guidelines on how to use these tools.
This memo outlines the requirements for content splicing in RTP This memo outlines the requirements for content splicing in RTP
sessions and describes how an RTP mixer can be used to meet these sessions and describes how an RTP mixer can be used to meet these
requirements. requirements.
2. System Model and Terminology 2. System Model and Terminology
In this document, an intermediary network element, the Splicer In this document, the splicer, an intermediary network element,
handles RTP splicing. The Splicer can receive main content and handles RTP splicing. The splicer can receive main content and
substitutive content simultaneously, but will send one of them at one substitutive content simultaneously but will send one of them at one
point of time. point of time.
When RTP splicing begins, the splicer sends the substitutive content When RTP splicing begins, the splicer sends the substitutive content
to the RTP receiver instead of the main content for a period of time. to the RTP receiver instead of the main content for a period of time.
When RTP splicing ends, the splicer switches back sending the main When RTP splicing ends, the splicer switches back to sending the main
content to the RTP receiver. content to the RTP receiver.
A simplified RTP splicing diagram is depicted in Figure 1, in which A simplified RTP splicing diagram is depicted in Figure 1, in which
only one main content flow and one substitutive content flow are only one main content flow and one substitutive content flow are
given. Actually, the splicer can handle multiple splicing for given. Actually, the splicer can handle multiple splicing for
multiple RTP sessions simultaneously. RTP splicing may happen more multiple RTP sessions simultaneously. RTP splicing may happen more
than once in multiple time slots during the lifetime of the main RTP than once in multiple time slots during the lifetime of the main RTP
stream. The methods how splicer learns when to start and end the stream. The methods by which the splicer learns when to start and
splicing is out of scope for this document. end the splicing are out of scope for this document.
+---------------+ +---------------+
| | Main Content +-----------+ | | Main Content +-----------+
| Main RTP |------------->| | Output Content | Main RTP |------------->| | Output Content
| Content | | Splicer |---------------> | Content | | Splicer |--------------->
+---------------+ ---------->| | +---------------+ ---------->| |
| +-----------+ | +-----------+
| |
| Substitutive Content | Substitutive Content
| |
| |
+-----------------------+ +-----------------------+
| Substitutive RTP | | Substitutive RTP |
| Content | | Content |
| or | | or |
| Local File Storage | | Local File Storage |
+-----------------------+ +-----------------------+
Figure 1: RTP Splicing Architecture Figure 1: RTP Splicing Architecture
This document uses the following terminologies. This document uses the following terminologies.
Output RTP Stream Output RTP Stream
The RTP stream that the RTP receiver is currently receiving. The The RTP stream that the RTP receiver is currently receiving. The
content of output RTP stream can be either main content or content of the output of the RTP stream can be either main content
substitutive content. or substitutive content.
Main Content Main Content
The multimedia content that are conveyed in main RTP stream. Main The multimedia content that is conveyed in the main RTP stream.
content will be replaced by the substitutive content during Main content will be replaced by the substitutive content during
splicing. splicing.
Main RTP Stream Main RTP Stream
The RTP stream that the splicer is receiving. The content of main The RTP stream that the splicer is receiving. The content of the
RTP stream can be replaced by substitutive content for a period of main RTP stream can be replaced by substitutive content for a
time. period of time.
Main RTP Sender Main RTP Sender
The sender of RTP packets carrying the main RTP stream. The sender of RTP packets carrying the main RTP stream.
Substitutive Content Substitutive Content
The multimedia content that replaces the main content during The multimedia content that replaces the main content during
splicing. The substitutive content can for example be contained splicing. The substitutive content can, for example, be contained
in an RTP stream from a media sender or fetched from local media in an RTP stream from a media sender or fetched from local media
file storage. file storage.
Substitutive RTP Stream Substitutive RTP Stream
A RTP stream with new content that will replace the content in the An RTP stream with new content that will replace the content in
main RTP stream. Substitutive RTP stream and main RTP stream are the main RTP stream. The substitutive RTP stream and main RTP
two separate streams. If the substitutive content is provided via stream are two separate streams. If the substitutive content is
substitutive RTP stream, the substitutive RTP Stream must pass provided via a substitutive RTP stream, the substitutive RTP
through the splicer before the substitutive content is delivered stream must pass through the splicer before the substitutive
to receiver. content is delivered to the receiver.
Substitutive RTP Sender Substitutive RTP Sender
The sender of RTP packets carrying the substitutive RTP stream. The sender of RTP packets carrying the substitutive RTP stream.
Splicing In Point Splicing-In Point
A virtual point in the RTP stream, suitable for substitutive A virtual point in the RTP stream, suitable for substitutive
content entry, typically in the boundary between two independently content entry, typically in the boundary between two independently
decodable frames. decodable frames.
Splicing Out Point Splicing-Out Point
A virtual point in the RTP stream, suitable for substitutive A virtual point in the RTP stream, suitable for substitutive
content exist, typically in the boundary between two independently content exit, typically in the boundary between two independently
decodable frames. decodable frames.
Splicer Splicer
An intermediary node that inserts substitutive content into main An intermediary node that inserts substitutive content into a main
RTP stream. The splicer sends substitutive content to RTP RTP stream. The splicer sends substitutive content to the RTP
receiver instead of main content during splicing. It is also receiver instead of main content during splicing. It is also
responsible for processing RTCP traffic between the RTP sender and responsible for processing RTP Control Protocol (RTCP) traffic
the RTP receiver. between the RTP sender and the RTP receiver.
3. Requirements for RTP Splicing 3. Requirements for RTP Splicing
In order to allow seamless content splicing at the RTP layer, the In order to allow seamless content splicing at the RTP layer, the
following requirements must be met. Meeting these will also allow, following requirements must be met. Meeting these will also allow,
but not require, seamless content splicing at layers above RTP. but not require, seamless content splicing at layers above RTP.
REQ-1: REQ-1:
The splicer should be agnostic about the network and transport The splicer should be agnostic about the network and
layer protocols used to deliver the RTP streams. transport-layer protocols used to deliver the RTP streams.
REQ-2: REQ-2:
The splicing operation at the RTP layer must allow splicing at any The splicing operation at the RTP layer must allow splicing at any
point required by the media content, and must not constrain when point required by the media content and must not constrain when
splicing in or splicing out operations can take place. splicing-in or splicing-out operations can take place.
REQ-3: REQ-3:
Splicing of RTP content must be backward compatible with the RTP/ Splicing of RTP content must be backward compatible with the
RTCP protocol, associated profiles, payload formats, and RTP/RTCP protocol, associated profiles, payload formats, and
extensions. extensions.
REQ-4: REQ-4:
The splicer will modify the content of RTP packets, and thus break The splicer will modify the content of RTP packets and thus break
the end-to-end security, at a minimum breaking the data integrity the end-to-end security, at a minimum, breaking the data integrity
and source authentication. If the Splicer is designated to insert and source authentication. If the splicer is designated to insert
substitutive content, it must be trusted, i.e., be in the security substitutive content, it must be trusted, i.e., be in the security
context(s) with the main RTP sender, the substitutive RTP sender, context(s) with the main RTP sender, the substitutive RTP sender,
and the receivers. If encryption is employed, the splicer and the receivers. If encryption is employed, the splicer
commonly must decrypt the inbound RTP packets and re-encrypt the commonly must decrypt the inbound RTP packets and re-encrypt the
outbound RTP packets after splicing. outbound RTP packets after splicing.
REQ-5: REQ-5:
The splicer should rewrite as necessary and forward RTCP messages The splicer should rewrite as necessary and forward RTCP messages
(e.g., including packet loss, jitter, etc.) sent from downstream (e.g., including packet loss, jitter, etc.) sent from a downstream
receiver to the main RTP sender or the substitutive RTP sender, receiver to the main RTP sender or the substitutive RTP sender,
and thus allow the main RTP sender or substitutive RTP sender to and thus allow the main RTP sender or substitutive RTP sender to
learn the performance of the downstream receiver when its content learn the performance of the downstream receiver when its content
is being passed to RTP receiver. In addition, the splicer should is being passed to an RTP receiver. In addition, the splicer
rewrite RTCP messages from the main RTP sender or substitutive RTP should rewrite RTCP messages from the main RTP sender or
sender to the receiver. substitutive RTP sender to the receiver.
REQ-6: REQ-6:
The splicer must not affect other RTP sessions running between the The splicer must not affect other RTP sessions running between the
RTP sender and the RTP receiver, and must be transparent for the RTP sender and the RTP receiver and must be transparent for the
RTP sessions it does not splice. RTP sessions it does not splice.
REQ-7: REQ-7:
The RTP receiver should not be able to detect any splicing points The RTP receiver should not be able to detect any splicing points
in the RTP stream produced by the splicer on RTP protocol level. in the RTP stream produced by the splicer on the RTP protocol
For the advertisement insertion use case, it is important to make level. For the advertisement insertion use case, it is important
it difficult for the RTP receiver to detect where an advertisement to make it difficult for the RTP receiver to detect where an
insertion is starting or ending from the RTP packets, and thus advertisement insertion is starting or ending from the RTP
avoiding the RTP receiver from filtering out the advertisement packets, and thus avoiding the RTP receiver from filtering out the
content. This memo only focuses on making the splicing advertisement content. This memo only focuses on making the
undetectable at the RTP layer. The corresponding processing is splicing undetectable at the RTP layer. The corresponding
depicted in section 4.5. processing is depicted in Section 4.5.
4. Content Splicing for RTP sessions 4. Content Splicing for RTP Sessions
The RTP specification [RFC3550] defines two types of middlebox: RTP The RTP specification [RFC3550] defines two types of middleboxes: RTP
translators and RTP mixers. Splicing is best viewed as a mixing translators and RTP mixers. Splicing is best viewed as a mixing
operation. The splicer generates a new RTP stream that is a mix of 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 the main RTP stream and the substitutive RTP stream. An RTP mixer is
therefore an appropriate model for a content splicer. In next four therefore an appropriate model for a content splicer. In the next
subsections (from subsection 4.1 to subsection 4.4), the document four subsections (from Section 4.1 to Section 4.4), the document
analyzes how the mixer handles RTP splicing and how it satisfies the analyzes how the mixer handles RTP splicing and how it satisfies the
general requirements listed in section 3. In subsection 4.5, 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 take document looks at REQ-7 in order to hide the fact that splicing takes
place. place.
4.1. RTP Processing in RTP Mixer 4.1. RTP Processing in RTP Mixer
A splicer could be implemented as a mixer that receives the main RTP 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 the substitutive content (possibly via a substitutive RTP
stream), and sends a single output RTP stream to the receiver(s). stream), and sends a single output RTP stream to the receiver(s).
That output RTP stream will contain either the main content or the That output RTP stream will contain either the main content or the
substitutive content. The output RTP stream will come from the substitutive content. The output RTP stream will come from the mixer
mixer, and will have the synchronization source (SSRC) of the mixer and will have the synchronization source (SSRC) of the mixer rather
rather than the main RTP sender or the substitutive RTP sender. than the main RTP sender or the substitutive RTP sender.
The mixer uses its own SSRC, sequence number space and timing model The mixer uses its own SSRC, sequence number space, and timing model
when generating the output stream. Moreover, the mixer may insert when generating the output stream. Moreover, the mixer may insert
the SSRC of main RTP stream into contributing source (CSRC) list in the SSRC of the main RTP stream into the contributing source (CSRC)
the output media stream. list in the output media stream.
At the splicing in point, when the substitutive content becomes At the splicing-in point, when the substitutive content becomes
active, the mixer chooses the substitutive RTP stream as input stream active, the mixer chooses the substitutive RTP stream as the input
at splicing in point, and extracts the payload data (i.e., stream and extracts the payload data (i.e., substitutive content).
substitutive content). If the substitutive content comes from local If the substitutive content comes from local media file storage, the
media file storage, the mixer directly fetches the substitutive mixer directly fetches the substitutive content. After that, the
content. After that, the mixer encapsulates substitutive content mixer encapsulates substitutive content instead of main content as
instead of main content as the payload of the output media stream, the payload of the output media stream and then sends the output RTP
and then sends the output RTP media stream to receiver. The mixer media stream to the receiver. The mixer may insert the SSRC of the
may insert the SSRC of substitutive RTP stream into CSRC list in the substitutive RTP stream into the CSRC list in the output media
output media stream. If the substitutive content comes from local stream. If the substitutive content comes from local media file
media file storage, the mixer should leave the CSRC list blank. storage, the mixer should leave the CSRC list blank.
At the splicing out point, when the substitutive content ends, the At the splicing-out point, when the substitutive content ends, the
mixer retrieves the main RTP stream as input stream at splicing out mixer retrieves the main RTP stream as the input stream and extracts
point, and extracts the payload data (i.e., main content). After the payload data (i.e., main content). After that, the mixer
that, the mixer encapsulates main content instead of substitutive encapsulates main content instead of substitutive content as the
content as the payload of the output media stream, and then sends the payload of the output media stream and then sends the output media
output media stream to the receivers. Moreover, the mixer may insert stream to the receivers. Moreover, the mixer may insert the SSRC of
the SSRC of main RTP stream into CSRC list in the output media stream the main RTP stream into the CSRC list in the output media stream as
as before. before.
Note that if the content is too large to fit into RTP packets sent to Note that if the content is too large to fit into RTP packets sent to
RTP receiver, the mixer needs to transcode or perform application- the RTP receiver, the mixer needs to transcode or perform
layer fragmentation. Usually the mixer is deployed as part of a application-layer fragmentation. Usually the mixer is deployed as
managed system and MTU will be carefully managed by this system. part of a managed system and MTU will be carefully managed by this
This document does not raise any new MTU related issues compared to a system. This document does not raise any new MTU related issues
standard mixer described in [RFC3550]. compared to a standard mixer described in [RFC3550].
Splicing may occur more than once during the lifetime of main RTP Splicing may occur more than once during the lifetime of the main RTP
stream, this means the mixer needs to send main content and stream. This means the mixer needs to send main content and
substitutive content in turn with its own SSRC identifier. From substitutive content in turn with its own SSRC identifier. From
receiver point of view, the only source of the output stream is the receiver point of view, the only source of the output stream is the
mixer regardless of where the content is coming from. mixer regardless of where the content is coming from.
4.2. RTCP Processing in RTP Mixer 4.2. RTCP Processing in RTP Mixer
By monitoring available bandwidth and buffer levels and by computing By monitoring available bandwidth and buffer levels and by computing
network metrics such as packet loss, network jitter, and delay, RTP network metrics such as packet loss, network jitter, and delay, an
receiver can learn the network performance and communicate this to RTP receiver can learn the network performance and communicate this
the RTP sender via RTCP reception reports. to the RTP sender via RTCP reception reports.
According to the description in section 7.3 of [RFC3550], the mixer According to the description in Section 7.3 of [RFC3550], the mixer
splits the RTCP flow between sender and receiver into two separate splits the RTCP flow between the sender and receiver into two
RTCP loops, RTP sender has no idea about the situation on the separate RTCP loops; the RTP sender has no idea about the situation
receiver. But splicing is a processing that the mixer selects one on the receiver. But splicing is a process where the mixer selects
media stream from multiple streams rather than mixing them, so the one media stream from multiple streams rather than mixing them, so
mixer can leave the SSRC identifier in the RTCP report intact (i.e., the mixer can leave the SSRC identifier in the RTCP report intact
the SSRC of downstream receiver), this enables the main RTP sender or (i.e., the SSRC of the downstream receiver). This enables the main
the substitutive RTP sender to learn the situation on the receiver. 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 If the RTCP report corresponds to a time interval that is entirely
main content or entirely substitutive content, the number of output main content or entirely substitutive content, the number of output
RTP packets containing substitutive content is equal to the number of RTP packets containing substitutive content is equal to the number of
input substitutive RTP packets (from substitutive RTP stream) during input substitutive RTP packets (from the substitutive RTP stream)
splicing, in the same manner, the number of output RTP packets during splicing. In the same manner, the number of output RTP
containing main content is equal to the number of input main RTP packets containing main content is equal to the number of input main
packets (from main RTP stream) during non-splicing unless the mixer RTP packets (from the main RTP stream) during non-splicing unless the
fragment the input RTP packets. This means that the mixer does not mixer fragments the input RTP packets. This means that the mixer
need to modify the loss packet fields in reception report blocks in does not need to modify the loss packet fields in reception report
RTCP reports. But if the mixer fragments the input RTP packets, it blocks in RTCP reports. But, if the mixer fragments the input RTP
may need to modify the loss packet fields to compensate for the packets, it may need to modify the loss packet fields to compensate
fragmentation. Whether the input RTP packets are fragmented or not, for the fragmentation. Whether the input RTP packets are fragmented
the mixer still needs to change the SSRC field in report block to the or not, the mixer still needs to change the SSRC field in the report
SSRC identifier of the main RTP sender or the substitutive RTP block to the SSRC identifier of the main RTP sender or the
sender, and rewrite the extended highest sequence number field to the substitutive RTP sender and rewrite the extended highest sequence
corresponding original extended highest sequence number before number field to the corresponding original extended highest sequence
forwarding the RTCP report to the main RTP sender or the substitutive number before forwarding the RTCP report to the main RTP sender or
RTP sender. the substitutive RTP sender.
If the RTCP report spans the splicing in point or the splicing out If the RTCP report spans the splicing-in point or the splicing-out
point, it reflects the characteristics of the combination of main RTP point, it reflects the characteristics of the combination of main RTP
packets and substitutive RTP packets. In this case, the mixer needs packets and substitutive RTP packets. In this case, the mixer needs
to divide the RTCP report into two separate RTCP reports and send to divide the RTCP report into two separate RTCP reports and send
them to their original RTP senders respectively. For each RTCP them to their original RTP senders, respectively. For each RTCP
report, the mixer also needs to make the corresponding changes to the report, the mixer also needs to make the corresponding changes to the
packet loss fields in report block besides the SSRC field and the packet loss fields in the report block besides the SSRC field and the
extended highest sequence number field. extended highest sequence number field.
If the mixer receives an RTCP extended report (XR) block, it should 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 rewrite the XR report block in a similar way to the reception report
block in the RTCP report. block in the RTCP report.
Besides forwarding the RTCP reports sent from RTP receiver, the mixer Besides forwarding the RTCP reports sent from the RTP receiver, the
can also generate its own RTCP reports to inform the main RTP sender mixer can also generate its own RTCP reports to inform the main RTP
or the substitutive RTP sender of the reception quality of the sender, or the substitutive RTP sender, of the reception quality of
content reaches the mixer when the content is not sent to the RTP content not sent to the RTP receiver when it reaches the mixer.
receiver. These RTCP reports use the SSRC of the mixer. If the These RTCP reports use the SSRC of the mixer. If the substitutive
substitutive content comes from local media file storage, the mixer content comes from local media file storage, the mixer does not need
does not need to generate RTCP reports for the substitutive stream. to generate RTCP reports for the substitutive stream.
Based on above RTCP operating mechanism, the RTP sender whose content Based on the above RTCP operating mechanism, the RTP sender whose
is being passed to receiver will see the reception quality of its content is being passed to a receiver will see the reception quality
stream as received by the mixer, and the reception quality of spliced of its stream as received by the mixer and the reception quality of
stream as received by the receiver. The RTP sender whose content is the spliced stream as received by the receiver. The RTP sender whose
not being passed to receiver will only see the reception quality of content is not being passed to a receiver will only see the reception
its stream as received by the mixer. quality of its stream as received by the mixer.
The mixer must forward RTCP SDES and BYE packets from the receiver to The mixer must forward RTCP source description (SDES) and BYE packets
the sender, and may forward them in inverse direction as defined in from the receiver to the sender and may forward them in inverse
section 7.3 of [RFC3550]. direction as defined in Section 7.3 of [RFC3550].
Once the mixer receives an RTP/AVPF [RFC4585] transport layer Once the mixer receives an RTP/Audio-Visual Profile with Feedback
feedback packet, it must handle it carefully as the feedback packet (AVPF) [RFC4585] transport-layer feedback packet, it must handle it
may contain the information of the content that come from different carefully, as the feedback packet may contain the information of the
RTP senders. In this case the mixer needs to divide the feedback content that comes from different RTP senders. In this case, the
packet into two separate feedback packets and process the information mixer needs to divide the feedback packet into two separate feedback
in the feedback control information (FCI) in the two feedback packets and process the information in the feedback control
packets, just as the RTCP report process described above. 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 If the substitutive content comes from local media file storage
(i.e., the mixer can be regarded as the substitutive RTP sender), any (i.e., the mixer can be regarded as the substitutive RTP sender), any
RTCP packets received from downstream relate to the substitutive RTCP packets received from downstream related to the substitutive
content must be terminated on the mixer without any further content must be terminated on the mixer without any further
processing. processing.
4.3. Considerations for Handling Media Clipping at the RTP Layer 4.3. Considerations for Handling Media Clipping at the RTP Layer
This section provides informative guidelines on how to handle media This section provides informative guidelines on how to handle media
substitution at both the RTP layer to minimize media impact. Dealing substitution at the RTP layer to minimize media impact. Dealing well
with the media substitution well at the RTP layer is necessary for with the media substitution at the RTP layer is necessary for quality
quality implementations. To perfectly erase any media impact needs implementations. To perfectly erase any media impact needs more
more considerations at the higher layers, how the media substitution considerations at the higher layers. How the media substitution is
is erased at the higher layers are outside of the scope of this memo. erased at the higher layers is outside of the scope of this memo.
If the time duration for any substitutive content mismatches, i.e., If the time duration for any substitutive content mismatches, i.e.,
shorter or longer, than the duration of the main content to be shorter or longer than the duration of the main content to be
replaced, then media degradations may occur at the splicing point and replaced, then media degradations may occur at the splicing point and
thus impact the user's experience. thus impact the user's experience.
If the substitutive content has shorter duration from the main If the substitutive content has shorter duration from the main
content, then there could be a gap in the output RTP stream. The RTP 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 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 an unexpected jump in the RTP timestamp. Such a gap would cause the
receiver to have nothing to play. This may be unavoidable, unless receiver to have nothing to play. This may be unavoidable, unless
the mixer can adjusts the splice in or splice out point to the mixer can adjusts the splice in or splice out point to
compensate. This assumes the splicing mixer can send more of the compensate. This assumes the splicing mixer can send more of the
main RTP stream in place of the shorter substitutive stream, or vary main RTP stream in place of the shorter substitutive stream or vary
the length of the substitutive content. It is the responsibility of the length of the substitutive content. It is the responsibility of
the higher layer protocols and the media providers to ensure that the the higher-layer protocols and the media providers to ensure that the
substitutive content is of very similar duration as the main content substitutive content is of very similar duration as the main content
to be replaced. to be replaced.
If the substitute content has longer duration than the reserved gap If the substitute content has longer duration than the reserved gap
duration, there will be an overlap between the substitutive RTP duration, there will be an overlap between the substitutive RTP
stream and the main RTP stream at the splicing out point. A stream and the main RTP stream at the splicing-out point. A
straightforward approach is that the mixer performs an ungraceful straightforward approach is that the mixer performs an ungraceful
action, terminating the splicing and switching back to main RTP action and terminates the splicing and switches back to the main RTP
stream even if this may cause media stuttering on receiver. stream even if this may cause media stuttering on the receiver.
Alternatively, the mixer may transcode the substitutive content to Alternatively, the mixer may transcode the substitutive content to
play at a faster rate than normal, to adjust it to the length of the 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 gap in the main content and generate a new RTP stream for the
transcoded content. This is a complex operation, and very specific transcoded content. This is a complex operation and very specific to
to the content and media codec used. Additional approaches exists, the content and media codec used. Additional approaches exist; these
these types of issues should be taken into account in both mixer types of issues should be taken into account in both mixer
implementors and media generators to enable smooth substitutions. implementors and media generators to enable smooth substitutions.
4.4. Congestion Control Considerations 4.4. Congestion Control Considerations
If the substitutive content has somewhat different characteristics If the substitutive content has somewhat different characteristics
from the main content it replaces, or if the substitutive content is from the main content it replaces, or if the substitutive content is
encoded with a different codec or has different encoding bitrate, it encoded with a different codec or has different encoding bitrate, it
might overload the network and might cause network congestion on the might overload the network and might cause network congestion on the
path between the mixer and the RTP receiver(s) that would not have path between the mixer and the RTP receiver(s) that would not have
been caused by the main content. been caused by the main content.
To be robust to network congestion and packet loss, a mixer that is To be robust to network congestion and packet loss, a mixer that is
performing splicing must continuously monitor the status of performing splicing must continuously monitor the status of a
downstream network by monitoring any of the following RTCP reports downstream network by monitoring any of the following RTCP reports
that are used: that are used:
1. RTCP receiver reports indicate packet loss [RFC3550]. 1. RTCP receiver reports indicate packet loss [RFC3550].
2. RTCP NACKs for lost packet recovery [RFC4585]. 2. RTCP NACKs for lost packet recovery [RFC4585].
3. RTCP ECN Feedback information [RFC6679]. 3. RTCP Explicit Congestion Notification (ECN) Feedback information
[RFC6679].
Once the mixer detects congestion on its downstream link, it will Once the mixer detects congestion on its downstream link, it will
treat these reports as follows: treat these reports as follows:
1. If the mixer receives the RTCP receiver reports with packet loss 1. If the mixer receives the RTCP receiver reports with packet loss
indication, it will forward the reports to the substitutive RTP indication, it will forward the reports to the substitutive RTP
sender or the main RTP sender as described in section 4.2. sender or the main RTP sender as described in Section 4.2.
2. If mixer receives the RTCP NACK packets defined in [RFC4585] from 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from
RTP receiver for packet loss recovery, it first identifies the the RTP receiver for packet loss recovery, it first identifies
content category of lost packets to which the NACK corresponds. the content category of lost packets to which the NACK
Then, the mixer will generate new RTCP NACK for the lost packets corresponds. Then, the mixer will generate new RTCP NACKs for
with its own SSRC, and make corresponding changes to their the lost packets with its own SSRC and make corresponding changes
sequence numbers to match original, pre-spliced, packets. If the to their sequence numbers to match original, pre-spliced,
lost substitutive content comes from local media file storage, packets. If the lost substitutive content comes from local media
the mixer acting as substitutive RTP sender will directly fetch file storage, the mixer acting as the substitutive RTP sender
the lost substitutive content and retransmit it to RTP receiver. will directly fetch the lost substitutive content and retransmit
The mixer may buffer the sent RTP packets and do the it to the RTP receiver. The mixer may buffer the sent RTP
retransmission. packets and do the retransmission.
It is somewhat complex that the lost packets requested in a It is somewhat complex that the lost packets requested in a
single RTCP NACK message not only contain the main content but single RTCP NACK message not only contain the main content but
also the substitutive content. To address this, the mixer must also the substitutive content. To address this, the mixer must
divide the RTCP NACK packet into two separate RTCP NACK packets: divide the RTCP NACK packet into two separate RTCP NACK packets:
one requests for the lost main content, and another requests for one requests for the lost main content, and another requests for
the lost substitutive content. the lost substitutive content.
3. If an ECN-aware mixer receives RTCP ECN feedbacks (RTCP ECN 3. If an ECN-aware mixer receives RTCP ECN feedback (RTCP ECN
feedback packets or RTCP XR summary reports) defined in [RFC6679] feedback packets or RTCP XR summary reports) defined in [RFC6679]
from the RTP receiver, it must process them in a similar way to from the RTP receiver, it must process them in a similar way to
the RTP/AVPF feedback packet or RTCP XR process described in the RTP/AVPF feedback packet or RTCP XR process described in
section 4.2 of this memo. Section 4.2 of this memo.
These three methods require the mixer to run a congestion control These three methods require the mixer to run a congestion control
loop and bitrate adaptation between itself and RTP receiver. The loop and bitrate adaptation between itself and the RTP receiver. The
mixer can thin or transcode the main RTP stream or the substitutive mixer can thin or transcode the main RTP stream or the substitutive
RTP stream, but such operations are very inefficient and difficult, RTP stream, but such operations are very inefficient and difficult,
and bring undesirable delay. Fortunately in this memo, the mixer and they also bring undesirable delay. Fortunately, as noted in this
acting as splicer can rewrite the RTCP packets sent from the RTP memo, the mixer acting as a splicer can rewrite the RTCP packets sent
receiver and forward them to the RTP sender, thus letting the RTP from the RTP receiver and forward them to the RTP sender, thus
sender knows that congestion is being experienced on the path between letting the RTP sender knows that congestion is being experienced on
the mixer and the RTP receiver. Then, the RTP sender applies its the path between the mixer and the RTP receiver. Then, the RTP
congestion control algorithm and reduces the media bitrate to a value sender applies its congestion control algorithm and reduces the media
that is in compliance with congestion control principles for the bitrate to a value that is in compliance with congestion control
slowest link. The congestion control algorithm may be a TCP-friendly principles for the slowest link. The congestion control algorithm
bitrate adaptation algorithm specified in [RFC5348], or a DCCP may be a TCP-friendly bitrate adaptation algorithm specified in
congestion control algorithms defined in [RFC5762]. [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 If the substitutive content comes from local media file storage, the
mixer must directly reduce the bitrate as if it were the substitutive mixer must directly reduce the bitrate as if it were the substitutive
RTP sender. RTP sender.
From above analysis, to reduce the risk of congestion and remain the From the above analysis, to reduce the risk of congestion and
bandwidth consumption stable over time, the substitutive RTP stream maintain the bandwidth consumption stable over time, the substitutive
is recommended to be encoded at an appropriate bitrate to match that RTP stream is recommended to be encoded at an appropriate bitrate to
of main RTP stream. If the substitutive RTP stream comes from the match that of the main RTP stream. If the substitutive RTP stream
substitutive RTP sender, this sender had better has some knowledge comes from the substitutive RTP sender, this sender should have some
about the media encoding bitrate of main content in advance. How it knowledge about the media encoding bitrate of the main content in
knows that is out of scope in this draft. advance. Acquiring such knowledge is out of scope in this document.
4.5. Considerations for Implementing Undetectable Splicing 4.5. Considerations for Implementing Undetectable Splicing
If it is desirable to prevent receivers from detecting that 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 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 in outgoing RTP packets and must not forward RTCP messages from the
main RTP sender or from the substitutive RTP sender. Due to the main RTP sender or from the substitutive RTP sender. Due to the
absence of CSRC list in the output RTP stream, the RTP receiver only absence of a CSRC list in the output RTP stream, the RTP receiver
initiates SDES, BYE and APP packets to the mixer without any only initiates SDES, BYE, and Application-specific functions (APP)
knowledge of the main RTP sender and the substitutive RTP sender. packets to the mixer without any knowledge of the main RTP sender and
the substitutive RTP sender.
CSRC list identifies the contributing sources, these SSRC identifiers The CSRC list identifies the contributing sources; these SSRC
of contributing sources are kept globally unique for each RTP identifiers of contributing sources are kept globally unique for each
session. The uniqueness of SSRC identifier is used to resolve RTP session. The uniqueness of the SSRC identifier is used to
collisions and detecting RTP-level forwarding loops as defined in resolve collisions and to detect RTP-level forwarding loops as
section 8.2 of [RFC3550]. The absence of CSRC list in this case will defined in Section 8.2 of [RFC3550]. A danger that loops involving
create a danger that loops involving those contributing sources could those contributing sources will not be detected will be created by
not be detected. The loops could occur if either the mixer is the absence of a CSRC list in this case. The loops could occur if
misconfigured to form a loop, or a second mixer/translator is added, either the mixer is misconfigured to form a loop or a second
causing packets to loop back to upstream of the original mixer. An mixer/translator is added, causing packets to loop back to upstream
undetected RTP packet loop is a serious denial of service threat, of the original mixer. An undetected RTP packet loop is a serious
which can consume all available bandwidth or mixer processing denial-of-service threat, which can consume all available bandwidth
resources until the looped packets are dropped as result of or mixer processing resources until the looped packets are dropped as
congestion. So Non-RTP means must be used to detect and resolve a result of congestion. So, non-RTP means must be used to detect and
loops if the mixer does not add a CSRC list. resolve loops if the mixer does not add a CSRC list.
5. Implementation Considerations 5. Implementation Considerations
When the mixer is used to handle RTP splicing, RTP receiver does not When the mixer is used to handle RTP splicing, the RTP receiver does
need any RTP/RTCP extension for splicing. As a trade-off, additional not need any RTP/RTCP extension for splicing. As a trade-off,
overhead could be induced on the mixer which uses its own sequence additional overhead could be induced on the mixer, which uses its own
number space and timing model. So the mixer will rewrite RTP sequence number space and timing model. So the mixer will rewrite
sequence number and timestamp whatever splicing is active or not, and the RTP sequence number and timestamp, whatever splicing is active or
generate RTCP flows for both sides. In case the mixer serves not, and generate RTCP flows for both sides. In case the mixer
multiple main RTP streams simultaneously, this may lead to more serves multiple main RTP streams simultaneously, this may lead to
overhead on the mixer. more overhead on the mixer.
If undetectable splicing requirement is required, CSRC list is not If an undetectable splicing requirement is required, the CSRC list is
included in outgoing RTP packet, this brings a potential issue with not included in the outgoing RTP packet; this brings a potential
loop detection as briefly described in section 4.5. issue with loop detection as briefly described in Section 4.5.
6. Security Considerations 6. Security Considerations
The splicing application is subject to the general security The splicing application is subject to the general security
considerations of the RTP specification [RFC3550]. considerations of the RTP specification [RFC3550].
The mixer acting as splicer replaces some content with other content The mixer acting as splicer replaces some content with other content
in RTP packets, thus breaking any RTP level end-to-end security, such in RTP packets, thus breaking any RTP-level end-to-end security, such
as integrity protection and source authentication. Thus any RTP as integrity protection and source authentication. Thus, any
level or outside security mechanism, such as IPSec or DTLS will use a RTP-level or outside security mechanism, such as IPsec [RFC4301] or
security association between the splicer and the receiver. When Datagram Transport Layer Security [RFC6347], will use a security
using SRTP the splicer could be provisioned with the same security association between the splicer and the receiver. When using the
association as the main RTP sender. Using a limitation in the SRTP Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer
security services regarding source authentication, the splicer can could be provisioned with the same security association as the main
modify and re-protect the RTP packets without enabling the receiver RTP sender. Using a limitation in the SRTP security services
to detect if the data comes from the original source or from the regarding source authentication, the splicer can modify and
splicer. 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 Security goals to have source authentication all the way from the RTP
main sender to the receiver through the splicer is not possible with main sender to the receiver through the splicer is not possible with
splicing and any existing solutions. A new solution can splicing and any existing solutions. A new solution can
theoretically be developed that enables identifying the participating theoretically be developed that enables identifying the participating
entities and what each provides, i.e. the different media sources, entities and what each provides, i.e., the different media sources,
main and substituting, and the splicer providing the RTP level main and substituting, and the splicer providing the RTP-level
integration of the media payloads in a common timeline and integration of the media payloads in a common timeline and
synchronization context. Such a solution would obviously not meet synchronization context. Such a solution would obviously not meet
Req-7 and will be detectable on RTP level. REQ-7 and will be detectable on the RTP level.
The nature of this RTP service offered by a network operator The nature of this RTP service offered by a network operator
employing a content splicer is that the RTP layer security employing a content splicer is that the RTP-layer security
relationship is between the receiver and the splicer, and between the relationship is between the receiver and the splicer, and between the
senders and the splicer, are not end-to-end. This appears to sender and the splicer, but is not end-to-end between the receiver
invalidate the undetectability goal, but in the common case the and the sender. This appears to invalidate the undetectability goal,
receiver will consider the splicer as the main media source. 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., Some RTP deployments use RTP payload security mechanisms (e.g.,
ISMACryp [ISMACryp]). If any payload internal security mechanisms ISMACryp [ISMACryp]). If any payload internal security mechanisms
are used, only the RTP sender and the RTP receiver establish that are used, only the RTP sender and the RTP receiver establish that
security context, in which case, any middlebox (e.g., splicer) security context, in which case any middlebox (e.g., splicer) between
between the RTP sender and the RTP receiver will not get such keying the RTP sender and the RTP receiver will not get such keying
material. This may impact the splicer's possibility to perform material. This may impact the splicer's ability to perform splicing
splicing if it is dependent on RTP payload level hints for finding if it is dependent on RTP payload-level hints for finding the splice
the splice in and out points. However, other potential solutions in and out points. However, other potential solutions exist to
exist to specify or mark where the splicing points exist in the media specify or mark where the splicing points exist in the media streams.
streams. When using RTP payload security mechanisms SRTP or other When using RTP payload security mechanisms, SRTP or other security
security mechanism at RTP or lower layers can be used to provide mechanisms at RTP or lower layers can be used to provide integrity
integrity and source authentication between the splicer and the RTP and source authentication between the splicer and the RTP receiver.
receiver.
7. IANA Considerations
No IANA actions are required.
8. Acknowledgments 7. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
specification and provided very valuable comments: Colin Perkins, specification and provided very valuable comments: Colin Perkins,
Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R.
Oran, Cullen Jennings, Ali C Begen, Charles Eckel and Ning Zong. Oran, Cullen Jennings, Ali C. Begen, Charles Eckel, and Ning Zong.
9. 10. Appendix- Why Mixer Is Chosen 8. References
Translator and mixer both can realize splicing by changing a set of 8.1. Normative References
RTP parameters.
Translator has no SSRC, hence it is transparent to RTP sender and [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
receiver. Therefore, RTP sender sees the full path to the receiver Jacobson, "RTP: A Transport Protocol for Real-Time
when translator is passing its content. When translator insert the Applications", STD 64, RFC 3550, July 2003.
substitutive content RTP sender could get a report on the path up to
translator itself. Additionally, if splicing does not occur yet,
translator does not need to rewrite RTP header, the overhead on
translator can be avoided.
If mixer is used to do splicing, it can also allow RTP sender to [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
learn the situation of its content on receiver or on mixer just like Rey, "Extended RTP Profile for Real-time Transport
translator does, which is specified in section 4.2. Compared to Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
translator, mixer's outstanding benefit is that it is pretty straight RFC 4585, July 2006.
forward to do with RTCP messages, for example, bit-rate adaptation to
handle varying network conditions. But translator needs more
considerations and its implementation is more complex.
From above analysis, both translator and mixer have their own [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
advantages: less overhead or less complexity on handling RTCP. and K. Carlberg, "Explicit Congestion Notification (ECN)
Through long and sophisticated discussion, the avtext WG members for RTP over UDP", RFC 6679, August 2012.
prefer less complexity rather than less overhead and incline to mixer
to do splicing.
If one chooses mixer as splicer, the overhead on mixer must be taken 8.2. Informative References
into account even if the splicing does not occur yet.
10. References [ISMACryp] Internet Streaming Media Alliance (ISMA), "ISMA
Encryption and Authentication Specification 2.0",
November 2007.
10.1. Normative References [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Jacobson, "RTP: A Transport Protocol for Real-Time Internet Protocol", RFC 4301, December 2005.
Applications", STD 64, RFC 3550, July 2003.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
"Extended RTP Profile for Real-time Transport Control Friendly Rate Control (TFRC): Protocol Specification",
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, RFC 5348, September 2008.
July 2006.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
and K. Carlberg, "Explicit Congestion Notification (ECN) Protocol (DCCP)", RFC 5762, April 2010.
for RTP over UDP", RFC 6679, August 2012.
10.2. Informative References [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [SCTE30] Society of Cable Telecommunications Engineers (SCTE),
Norrman, "The Secure Real-time Transport Protocol (SRTP)", "Digital Program Insertion Splicing API", 2009.
RFC 3711, March 2004.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [SCTE35] Society of Cable Telecommunications Engineers (SCTE),
Friendly Rate Control (TFRC): Protocol Specification", "Digital Program Insertion Cueing Message for Cable",
RFC 5348, September 2008. 2011.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Appendix A. Why Mixer Is Chosen
Protocol (DCCP)", RFC 5762, April 2010.
[SCTE30] Society of Cable Telecommunications Engineers (SCTE), Both a translator and mixer can realize splicing by changing a set of
"Digital Program Insertion Splicing API", 2009. RTP parameters.
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), A translator has no SSRC; hence it is transparent to the RTP sender
"Digital Program Insertion Cueing Message for Cable", and receiver. Therefore, the RTP sender sees the full path to the
2011. 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.
[ISMACryp] If a mixer is used to do splicing, it can also allow the RTP sender
Internet Streaming Media Alliance (ISMA), "ISMA Encryption to learn the situation of its content on the receiver or on the mixer
and Authentication Specification 2.0", November 2007. 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 Author's Address
Jinwei Xia Jinwei Xia
Huawei Huawei
Software No.101 Software No.101
Nanjing, Yuhuatai District 210012 Nanjing, Yuhuatai District 210012
China China
Phone: +86-025-86622310 Phone: +86-025-86622310
Email: xiajinwei@huawei.com EMail: xiajinwei@huawei.com
 End of changes. 110 change blocks. 
381 lines changed or deleted 386 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/