draft-ietf-avtext-splicing-for-rtp-08.txt   draft-ietf-avtext-splicing-for-rtp-09.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational July 9, 2012 Intended status: Informational August 13, 2012
Expires: January 10, 2013 Expires: February 14, 2013
Content Splicing for RTP Sessions Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-08 draft-ietf-avtext-splicing-for-rtp-09
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 local advertisement insertion by
cable operators, replacing a national advertisement content with a cable operators, replacing a national advertisement content with a
local advertisement. 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 a RTP mixer can be used to handle content concrete guidelines for how an RTP mixer can be used to handle
splicing. content splicing.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013. This Internet-Draft will expire on February 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 51 skipping to change at page 3, line 51
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, an intermediary network element, the Splicer
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 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 how splicer learns when to start and end the
splicing is out of scope for this document. splicing is 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
skipping to change at page 4, line 40 skipping to change at page 4, line 40
| 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 current RTP stream can be either main content or content of output RTP stream can be either main content or
substitutive content. substitutive content.
Main Content Main Content
The multimedia content that are conveyed in main RTP stream. Main The multimedia content that are conveyed in main RTP stream. Main
content will be replaced by the substitutive content during 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 main
RTP stream can be replaced by substitutive content for a period of RTP stream can be replaced by substitutive content for a period of
time. 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
The multimedia content that replaces the main content during A RTP stream with new content that will replace the content in the
splicing. The substitutive content can for example be contained main RTP stream. Substitutive RTP stream and main RTP stream are
in an RTP stream from a media sender or fetched from local media two separate streams. If the substitutive content is provided via
file storage. substitutive RTP stream, the substitutive RTP Stream must pass
through the splicer before the substitutive content is delivered
to 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 exist, 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 main
RTP stream. The Splicer sends substitutive content to RTP RTP stream. The splicer sends substitutive content to 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 RTCP traffic between the RTP sender and
the RTP receiver. 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.
skipping to change at page 6, line 30 skipping to change at page 6, line 31
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 RTP/
RTCP protocol, associated profiles, payload formats, and RTCP protocol, associated profiles, payload formats, and
extensions. extensions.
REQ-4: REQ-4:
A content splicer will modify the content of RTP packets, and The splicer will modify the content of RTP packets, and break the
break the end-to-end security, e.g., breaking data integrity and end-to-end security, e.g., breaking data integrity and source
source authentication. If the Splicer is designated to insert authentication. If the Splicer is designated to insert
substitutive content, it must be trusted, i.e., be in the same substitutive content, it must be trusted, i.e., be in the security
security context as the main RTP sender, the substitutive RTP context(s) as the main RTP sender, the substitutive RTP sender,
sender, and the receivers. If encryption is employed, the Splicer and the receivers. If encryption is employed, the splicer must be
must be able to decrypt the inbound RTP packets and re-encrypt the able to 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 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 RTP receiver. In addition, the splicer should
skipping to change at page 7, line 13 skipping to change at page 7, line 13
sender to the receiver. 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 content splicer should be able to modify the RTP stream across The splicer should be able to modify the RTP stream across a
a splicing in or splicing out point such that the splicing point splicing in or splicing out point such that the splicing point is
is not easy to detect in the RTP stream. For the advertisement not easy to be detected in the RTP stream. For the advertisement
insertion use case, it is important to make it difficult for the insertion use case, it is important to make it difficult for the
receiver to detect it. Ensuring the splicing point is not visible receiver to detect where an advertisement insertion is starting or
in the media content may be easy with some codecs, but extremely ending from the RTP packets. Ensuring the splicing point is not
difficult with others; in the worst case, the splicer may need to visible in the media content may be easy with some codecs, but
perform full media transcoding if it has to hide the splicing extremely difficult with others; in the worst case, the splicer
point in the media content. This memo only focusses on making the may need to perform full media transcoding if it has to hide the
splicing invisible at the RTP layer. How (or if) the splicing is splicing point in the media content. This memo only focuses on
made invisible in the media stream is outside the scope of this making the splicing invisible at the RTP layer. How (or if) the
memo. splicing is made invisible in the media stream is outside the
scope of this memo.
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 middlebox: 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 next four
subsections (from subsection 4.1 to subsection 4.4), the document subsections (from subsection 4.1 to subsection 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 subsection 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 take
place. place.
4.1. RTP Processing in RTP Mixer 4.1. RTP Processing in RTP Mixer
A content splicer should be implemented as a mixer that receives the A splicer could be implemented as a mixer that receives the main RTP
main RTP stream and the substitutive content (possibly via a stream and the substitutive content (possibly via a substitutive RTP
substitutive RTP stream), and sends a single output RTP stream to the stream), and sends a single output RTP stream to the receiver(s).
receiver(s). That output RTP stream will contain either the main That output RTP stream will contain either the main content or the
content or the substitutive content. The output RTP stream will come substitutive content. The output RTP stream will come from the
from the mixer, and will have the SSRC of the mixer rather than the mixer, and will have the SSRC of the mixer rather than the main RTP
main RTP sender or the substitutive RTP sender. 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 CSRC list in the output media the SSRC of main RTP stream into CSRC list in the output media
stream. 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 input stream
at splicing in point, and extracts the payload data (i.e., at splicing in point, and extracts the payload data (i.e.,
substitutive content). If the substitutive content comes from local substitutive content). If the substitutive content comes from local
skipping to change at page 9, line 9 skipping to change at page 9, line 10
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 sender and receiver into two separate
RTCP loops, RTP sender has no idea about the situation on the RTCP loops, RTP sender has no idea about the situation on the
receiver. But splicing is a processing that the mixer selects one receiver. But splicing is a processing that the mixer selects one
media stream from multiple streams rather than mixing them, so the media stream from multiple streams rather than mixing them, so the
mixer can leave the SSRC identifier in the RTCP report intact (i.e., mixer can leave the SSRC identifier in the RTCP report intact (i.e.,
the SSRC of downstream receiver), this enables the main RTP sender or the SSRC of downstream receiver), this enables the main RTP sender or
the substitutive RTP sender to learn the situation on the receiver. the substitutive RTP sender to learn the situation on the receiver.
When 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 substitutive RTP stream) during
splicing, in the same manner, the number of output RTP packets splicing, in the same manner, the number of output RTP packets
containing main content is equal to the number of input main RTP containing main content is equal to the number of input main RTP
packets (from main RTP stream) during non-splicing unless the mixer packets (from main RTP stream) during non-splicing unless the mixer
fragment the input RTP packets. This means that the mixer does not fragment the input RTP packets. This means that the mixer does not
need to modify the loss packet fields in reception report blocks in need to modify the loss packet fields in reception report blocks in
RTCP reports. But if the mixer fragments the input RTP packets, it RTCP reports. But if the mixer fragments the input RTP packets, it
may need to modify the loss packet fields to compensate for the may need to modify the loss packet fields to compensate for the
fragmentation. Whether the input RTP packets are fragmented or not, fragmentation. Whether the input RTP packets are fragmented or not,
the mixer still needs to change the SSRC field in report block to the the mixer still needs to change the SSRC field in report block to the
SSRC identifier of the main RTP sender or the substitutive RTP SSRC identifier of the main RTP sender or the substitutive RTP
sender, and rewrite the extended highest sequence number field to the sender, and rewrite the extended highest sequence number field to the
corresponding original extended highest sequence number before corresponding original extended highest sequence number before
forwarding the RTCP report to the main RTP sender or the substitutive forwarding the RTCP report to the main RTP sender or the substitutive
RTP sender. RTP sender.
When 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 report block besides the SSRC field and the
extended highest sequence number field. extended highest sequence number field.
When 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.
The mixer can also inform the main RTP sender or the substitutive RTP Besides forwarding the RTCP reports sent from RTP receiver, the mixer
sender of the reception quality of the content reaches the mixer can also generate its own RTCP reports to inform the main RTP sender
during the time when the content is not sent to the RTP receiver. or the substitutive RTP sender of the reception quality of the
This is done by the mixer generating RTCP reports for the main RTP content reaches the mixer when the content is not sent to the RTP
stream and/or the substitutive RTP stream. These RTCP reports use receiver. These RTCP reports use the SSRC of the mixer. If the
the SSRC of the mixer. If the substitutive content comes from local substitutive content comes from local media file storage, the mixer
media file storage, the mixer does not need to generate RTCP reports does not need to generate RTCP reports for the substitutive stream.
for the substitutive stream.
Based on above RTCP operating mechanism, the RTP sender whose content Based on above RTCP operating mechanism, the RTP sender whose content
is being passed to receiver will see the reception quality of its is being passed to receiver will see the reception quality of its
stream as received by the mixer, and the reception quality of spliced stream as received by the mixer, and the reception quality of spliced
stream as received by the receiver. The RTP sender whose content is stream as received by the receiver. The RTP sender whose content is
not being passed to receiver will only see the reception quality of not being passed to receiver will only see the reception quality of
its stream as received by the mixer. 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 SDES and BYE packets from the receiver to
the sender, and may forward them in inverse direction as defined in the sender, and may forward them in inverse direction as defined in
skipping to change at page 11, line 5 skipping to change at page 11, line 5
substitutive stream, or unless the mixer can vary the length of the substitutive stream, or unless the mixer can vary the length of the
substitutive content. It is the responsibility of the higher layer substitutive content. It is the responsibility of the higher layer
protocols to ensure that the substitutive content is of the same protocols to ensure that the substitutive content is of the same
duration as the main content to be replaced. duration as the main content to be replaced.
If the insertion duration is longer than the reserved gap duration, If the insertion duration is longer than the reserved gap duration,
there will be an overlap between the substitutive RTP stream and the there will be an overlap between the substitutive RTP stream and the
main RTP stream at splicing out point. One straightforward approach main RTP stream at splicing out point. One straightforward approach
is that the mixer takes an ungraceful action, terminating the is that the mixer takes an ungraceful action, terminating the
splicing and switching back to main RTP stream even if this may cause splicing and switching back to main RTP stream even if this may cause
media stuttering on receiver. Alternatively, the splicer may media stuttering on receiver. Alternatively, the mixer may transcode
transcode the substitutive content to play at a faster rate than the substitutive content to play at a faster rate than normal, to
normal, to adjust it to the length of the gap in the main content, adjust it to the length of the gap in the main content, and generate
and generate a new RTP stream for the transcoded content. This is a a new RTP stream for the transcoded content. This is a complex
complex operation, and very specific to the content and media codec operation, and very specific to the content and media codec used.
used.
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.
skipping to change at page 12, line 22 skipping to change at page 12, line 21
[I-D.ietf-avtcore-ecn-for-rtp] from the RTP receiver, it must [I-D.ietf-avtcore-ecn-for-rtp] from the RTP receiver, it must
process them in a similar way to the RTP/AVPF feedback packet or process them in a similar way to the RTP/AVPF feedback packet or
RTCP XR process described in section 4.2 of this memo. RTCP XR process described in 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 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 bring undesirable delay. Fortunately in this memo, the mixer
acting as splicer can rewrite the RTCP packets sent from the RTP acting as splicer can rewrite the RTCP packets sent from the RTP
receiver and forward them to the RTP sender, letting the RTP sender receiver and forward them to the RTP sender, thus letting the RTP
knows that congestion is being experienced on the path between the sender knows that congestion is being experienced on the path between
mixer and the RTP receiver. Then, the RTP sender applies its the mixer and the RTP receiver. Then, the RTP sender applies its
congestion control algorithm and reduces the media bitrate to a value congestion control algorithm and reduces the media bitrate to a value
that is in compliance with congestion control principles for the that is in compliance with congestion control principles for the
slowest link. The congestion control algorithm may be a TCP-friendly slowest link. The congestion control algorithm may be a TCP-friendly
bitrate adaptation algorithm specified in [RFC5348], or a DCCP bitrate adaptation algorithm specified in [RFC5348], or a DCCP
congestion control algorithms defined in [RFC5762]. congestion control algorithms 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.
skipping to change at page 12, line 46 skipping to change at page 12, line 45
bandwidth consumption stable over time, the substitutive RTP stream bandwidth consumption stable over time, the substitutive RTP stream
is recommended to be encoded at an appropriate bitrate to match that is recommended to be encoded at an appropriate bitrate to match that
of main RTP stream. If the substitutive RTP stream comes from the of main RTP stream. If the substitutive RTP stream comes from the
substitutive RTP sender, this sender had better has some knowledge substitutive RTP sender, this sender had better has some knowledge
about the media encoding bitrate of main content in advance. How it about the media encoding bitrate of main content in advance. How it
knows that is out of scope in this draft. knows that is out of scope in this draft.
4.5. Processing Splicing in User Invisibility Case 4.5. Processing Splicing in User Invisibility Case
If it is desirable to prevent receivers from detecting that splicing If it is desirable to prevent receivers from detecting that splicing
has occurred 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 from the main RTP in outgoing RTP packets, and must not forward RTCP messages from the
sender or from the substitutive RTP sender. Due to the absence of main RTP sender or from the substitutive RTP sender. Due to the
CSRC list in the output RTP stream, the RTP receiver only initiates absence of CSRC list in the output RTP stream, the RTP receiver only
SDES, BYE and APP packets to the mixer without any knowledge of the initiates SDES, BYE and APP packets to the mixer without any
main RTP sender and the substitutive RTP sender. knowledge of the main RTP sender and the substitutive RTP sender.
CSRC list identifies the contributing sources, these SSRC identifiers CSRC list identifies the contributing sources, these SSRC identifiers
of contributing sources are kept globally unique for each RTP of contributing sources are kept globally unique for each RTP
session. The uniqueness of SSRC identifier is used to resolve session. The uniqueness of SSRC identifier is used to resolve
collisions and detecting RTP-level forwarding loops as defined in collisions and detecting RTP-level forwarding loops as defined in
section 8.2 of [RFC3550]. The absence of CSRC list in this case will section 8.2 of [RFC3550]. The absence of CSRC list in this case will
create a danger that loops involving those contributing sources could create a danger that loops involving those contributing sources could
not be detected. So Non-RTP means must be used to detect and resolve not be detected. The Loops could occur if either the mixer is
loops if the splicer does not add a CSRC list. misconfigured to form a loop, or a second mixer/translator is added,
causing packets to loop back to upstream of the original mixer. So
Non-RTP means must be used to detect and 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, RTP receiver does not
need any RTP/RTCP extension for splicing. As a trade-off, additional need any RTP/RTCP extension for splicing. As a trade-off, additional
overhead could be induced on the mixer which uses its own sequence overhead could be induced on the mixer which uses its own sequence
number space and timing model. So the mixer will rewrite RTP number space and timing model. So the mixer will rewrite RTP
sequence number and timestamp whatever splicing is active or not, and sequence number and timestamp whatever splicing is active or not, and
generate RTCP flows for both sides. In case the mixer serves generate RTCP flows for both sides. In case the mixer serves
multiple main RTP streams simultaneously, this may lead to more multiple main RTP streams simultaneously, this may lead to more
skipping to change at page 13, line 34 skipping to change at page 13, line 37
If User Invisibility Requirement is required, CSRC list is not If User Invisibility Requirement is required, CSRC list is not
included in outgoing RTP packet, this brings a potential issue with included in outgoing RTP packet, this brings a potential issue with
loop detection as briefly described in section 4.5. 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 replace some content with other content The mixer acting as splicer replaces some content with other content
in RTP packets, thus breaking the end-to-end security, such as in RTP packets, thus breaking any RTP level end-to-end security, such
integrity protection and source authentication. Its behavior looks as integrity protection and source authentication. Thus any RTP
like a middleman attack, but SRTP [RFC3711] can be used to level or outside security mechanism, such as IPsec or DTLS will use a
authenticate the mixer, and provide integrity protection on the path security association between the splicer and the receiver. When
between the mixer and the receivers, but the receiver cannot (and is using SRTP the splicer could be provisioned with the same security
not supposed to be able to) determine what content comes from the association as the main RTP sender. Using a limitation in the SRTP
main RTP sender and what comes from the substitutive RTP sender by security services, the splicer can modify and re-protect the RTP
looking at the RTP layer. packets without enabling the receiver to detect if the data comes
from the original source or from the splicer.
The RTP receiver does not communicate directly with the main RTP
sender or the substitutive RTP sender, and does not have an end-to-
end security relationship with them at the RTP layer. 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 mixer, and between the senders and the mixer, and
not end-to-end. The network operator must delegate authority to the
mixer in exchange for the ability to perform RTP splicing inside the
network.
If encryption is employed, the mixer must be able to decrypt the Security goals to have source authentication all the way from the RTP
inbound RTP packets and re-encrypt the outbound RTP packets. main sender to the receiver through the splicer is not possible with
splicing. 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
senders and the splicer, are not end-to-end. This appears to
invalidate the invisibility goal, but in the common case the receiver
will consider the splicer as the main media source.
If any payload internal security mechanisms (e.g., ISMACryp Commonly no RTP level security mechanism is employed. Instead only
[ISMACryp]) are used, only the RTP sender and the RTP receiver can payload security mechanisms (e.g., ISMACryp [ISMACryp]) are used. If
learn the security keying material generated by such internal any payload internal security mechanisms are used, only the RTP
security mechanism, in which case, any middlebox (e.g., mixer) sender and the RTP receiver can learn the security keying material
between the RTP sender and the RTP receiver can't get such keying generated by such internal security mechanism, in which case, any
material, and thus fail to perform splicing. middlebox (e.g., splicer) between the RTP sender and the RTP receiver
can't get such keying material, and thus fail to perform splicing.
7. IANA Considerations 7. IANA Considerations
No IANA actions are required. No IANA actions are required.
8. Acknowledgments 8. 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
skipping to change at page 14, line 37 skipping to change at page 14, line 38
9. 10. Appendix- Why Mixer Is Chosen 9. 10. Appendix- Why Mixer Is Chosen
Translator and mixer both can realize splicing by changing a set of Translator and mixer both can realize splicing by changing a set of
RTP parameters. RTP parameters.
Translator has no SSRC, hence it is transparent to RTP sender and Translator has no SSRC, hence it is transparent to RTP sender and
receiver. Therefore, RTP sender sees the full path to the receiver receiver. Therefore, RTP sender sees the full path to the receiver
when translator is passing its content. When translator insert the when translator is passing its content. When translator insert the
substitutive content RTP sender could get a report on the path up to substitutive content RTP sender could get a report on the path up to
translator itself. Additionally, if user detectability is not translator itself. Additionally, if splicing does not occur yet,
required, translator does not need to rewrite RTP headers, the translator does not need to rewrite RTP header, the overhead on
overhead on translator can be avoided. translator can be avoided.
If mixer is used to do splicing, it can also allow RTP sender to If mixer is used to do splicing, it can also allow RTP sender to
learn the situation of its content on receiver or on mixer just like learn the situation of its content on receiver or on mixer just like
translator does, which is specified in section 4.2. Compared to translator does, which is specified in section 4.2. Compared to
translator, mixer's outstanding benefit is that it is pretty straight translator, mixer's outstanding benefit is that it is pretty straight
forward to do with bit-rate adaptation to handle varying network forward to do with RTCP messages, for example, bit-rate adaptation to
conditions. But translator needs more considerations and its handle varying network conditions. But translator needs more
implementation is more complex. considerations and its implementation is more complex.
From above analysis, both translator and mixer have their own From above analysis, both translator and mixer have their own
advantages: less overhead or less complexity on handling RTCP. advantages: less overhead or less complexity on handling RTCP.
Through long and sophisticated discussion, the avtext WG members Through long and sophisticated discussion, the avtext WG members
prefer less complexity rather than less overhead and incline to mixer prefer less complexity rather than less overhead and incline to mixer
to do splicing. to do splicing.
If one chooses mixer as splicer, the overhead on mixer must be taken If one chooses mixer as splicer, the overhead on mixer must be taken
into account. If one chooses translator as splicer, the complex RTCP into account even if the splicing does not occur yet.
processing on translator must be taken into account.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[I-D.ietf-avtcore-ecn-for-rtp] [I-D.ietf-avtcore-ecn-for-rtp]
Westerlund, M., "Explicit Congestion Notification (ECN) Westerlund, M., "Explicit Congestion Notification (ECN)
for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work
in progress), May 2012. in progress), May 2012.
10.2. Informative References 10.2. Informative References
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, April 2010. Protocol (DCCP)", RFC 5762, April 2010.
[SCTE30] Society of Cable Telecommunications Engineers (SCTE), [SCTE30] Society of Cable Telecommunications Engineers (SCTE),
"Digital Program Insertion Splicing API", 2009. "Digital Program Insertion Splicing API", 2009.
 End of changes. 32 change blocks. 
109 lines changed or deleted 110 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/