draft-ietf-avtext-splicing-for-rtp-04.txt   draft-ietf-avtext-splicing-for-rtp-05.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational December 30, 2011 Intended status: Informational February 7, 2012
Expires: July 2, 2012 Expires: August 10, 2012
Content Splicing for RTP Sessions Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-04 draft-ietf-avtext-splicing-for-rtp-05
Abstract Abstract
This memo outlines RTP splicing. Splicing is a process that replaces This memo outlines RTP splicing. Splicing is a process that replaces
the content of the main multimedia stream with other multimedia the content of the main multimedia stream with other multimedia
content, and delivers the substitutive multimedia content to receiver content, and delivers the substitutive multimedia content to receiver
for a period of time. This memo provides some RTP splicing use for a period of time. This memo provides some RTP splicing use
cases, then we enumerate a set of requirements and analyze whether an cases, then we enumerate a set of requirements and analyze whether an
existing RTP level middlebox can meet these requirements, at last we existing RTP level middlebox can meet these requirements, at last we
provide concrete guidelines for how the chosen middlebox works to provide concrete guidelines for how the chosen middlebox works to
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 2, 2012. This Internet-Draft will expire on August 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RTP Splicing Discussion and Requirements . . . . . . . . . . . 5 3. RTP Splicing Discussion and Requirements . . . . . . . . . . . 5
4. Recommended Solution for RTP Splicing . . . . . . . . . . . . 7 4. Recommended Solution for RTP Splicing . . . . . . . . . . . . 7
4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7 4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7
4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 9 4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 9
4.3. Media Clipping Considerations . . . . . . . . . . . . . . 10 4.3. Media Clipping Considerations . . . . . . . . . . . . . . 10
4.4. Congestion Control Considerations . . . . . . . . . . . . 10 4.4. Congestion Control Considerations . . . . . . . . . . . . 11
4.5. Processing Splicing in User Invisibility Case . . . . . . 13 4.5. Processing Splicing in User Invisibility Case . . . . . . 13
5. Implementation Considerations . . . . . . . . . . . . . . . . 13 5. Implementation Considerations . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. draft-xia-avtext-splicing-for-rtp-01 . . . . . . . . . . . 14 9.1. draft-xia-avtext-splicing-for-rtp-01 . . . . . . . . . . . 14
9.2. draft-xia-avtext-splicing-for-rtp-00 . . . . . . . . . . . 14 9.2. draft-xia-avtext-splicing-for-rtp-00 . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document outlines how splicing can be used for RTP sessions. This document outlines how splicing can be used for RTP sessions.
Splicing is a process that replaces the content of the main RTP Splicing is a process that replaces the content of the main RTP
stream with other multimedia content, and delivers the substitutive stream with other multimedia content, and delivers the substitutive
content to receiver for a period of time. The substitutive content content to receiver for a period of time. The substitutive content
can be provided for example via another RTP stream or local media can be provided for example via another RTP stream or local media
file storage. file storage.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
4. Recommended Solution for RTP Splicing 4. Recommended Solution for RTP Splicing
Given that Splicer is an intermediary node exists between the main Given that Splicer is an intermediary node exists between the main
media source and the RTP receiver and splicing is not a very media source and the RTP receiver and splicing is not a very
complicated processing, there are some chance that any existing RTP- complicated processing, there are some chance that any existing RTP-
level middlebox may has the incidental capability to meet the level middlebox may has the incidental capability to meet the
requirements described in previous section. requirements described in previous section.
Since Splicer needs to select substitutive content or main content as Since Splicer needs to select substitutive content or main content as
the input content at one point of time, an RTP mixer seems to have the input content at one point of time, an RTP mixer seems to have
such capability to do this under its own SSRC. Moreover, mixer such capability to do this under its own SSRC. Moreover, mixer may
includes the CSRC list in outgoing packets to indicate the source(s) include the CSRC list in outgoing packets to indicate the source(s)
of content, this facilitates the system debugging. From this point of content in some use cases like conferencing, this facilitates the
of view, an RTP mixer may have some chance to be Splicer. In next system debugging and loop detection. From this point of view, an RTP
four subsections (from subsection 4.1 to subsection 4.4), we start mixer may have some chance to be Splicer. In next four subsections
analyzing how an RTP mixer handles RTP splicing and how it satisfies (from subsection 4.1 to subsection 4.4), we start analyzing how an
the general requirements listed in section 3. RTP mixer handles RTP splicing and how it satisfies the general
requirements listed in section 3.
In subsection 4.5, we specially consider the special requirement 6 In subsection 4.5, we specially consider the special requirement 6
(i.e., User Invisibility Requirement) since it needs to mask any RTP (i.e., User Invisibility Requirement) since it needs to mask any RTP
splicing clue on receiver (e.g, CSRC list must not be included in splicing clue on receiver (e.g, CSRC list must not be included in
outgoing packets to prevent receiver from identifying the difference outgoing packets to prevent receiver from identifying the difference
between main RTP stream and substitutive RTP stream) when mixer is between main RTP stream and substitutive RTP stream) when mixer is
used. used.
4.1. RTP Processing in RTP Mixer 4.1. RTP Processing in RTP Mixer
Once mixer has learnt when to do splicing, it must get ready for the Once mixer has learnt when to do splicing, it must get ready for the
coming splicing in advance, e.g., fetches the substitutive content coming splicing in advance, e.g., fetches the substitutive content
either from local media file storage or via substitutive RTP stream either from local media file storage or via substitutive RTP stream
earlier than splicing in point. If the substitutive content comes earlier than splicing in point. If the substitutive content comes
from local media file storage, mixer should leave the CSRC list blank from local media file storage, mixer SHOULD leave the CSRC list blank
in the output stream. in the output stream.
Even if splicing does not begin, mixer still needs to receive the Even if splicing does not begin, mixer still needs to receive the
main RTP stream, terminate it and generate a media stream as defined main RTP stream, and generate a media stream as defined in RFC3550.
in RFC3550. Using the main RTP packets, mixer generates the current Using main content, mixer generates the current media stream with its
media stream with its own SSRC, sequence number space and timing own SSRC, sequence number space and timing model. Moreover, mixer
model. Moreover, mixer inserts the SSRC of main RTP stream into CSRC may insert the SSRC of main RTP stream into CSRC list in the current
list in the current media stream. media stream.
When splicing begins, mixer chooses the substitutive RTP stream as When splicing begins, mixer chooses the substitutive RTP stream as
input stream at splicing in point, extracts the payload data (i.e., input stream at splicing in point, and extracts the payload data
substitutive content), encodes substitutive content and outputs it (i.e., substitutive content). After that, mixer encapsulates
instead of main content in the current media stream. Moreover, mixer substitutive content instead of main content as the payload of the
inserts the SSRC of substitutive RTP stream into CSRC list in the current media stream, and then outputs the current media stream to
current media stream. receiver. Moreover, mixer may insert the SSRC of substitutive RTP
stream into CSRC list in the current media stream.
When splicing ends, mixer retrieves the main RTP stream as input When splicing ends, mixer retrieves the main RTP stream as input
stream at splicing out point, extracts the payload data (i.e., main stream at splicing out point, and extracts the payload data (i.e.,
content), encodes main content and outputs it instead of substitutive main content). After that, mixer encapsulates main content instead
content in the current media stream. Moreover, mixer inserts the of substitutive content as the payload of the current media stream,
SSRC of main RTP stream into CSRC list in the current media stream. and then outputs the current media stream to receiver. Moreover,
mixer may insert the SSRC of main RTP stream into CSRC list in the
current media stream.
The whole RTP splicing procedure is perhaps best explained by a The whole RTP splicing procedure is perhaps best explained by a
pseudo code example: pseudo code example:
if (splicing begins) { if (splicing begins) {
the substitutive RTP stream is terminated on mixer and the substitutive RTP stream is terminated on mixer and
substitutive content is encoded by mixer with its own SSRC substitutive content is encapsulated by mixer with its own SSRC
identifier; identifier;
the sequence numbers of the current RTP packets which contain the sequence numbers of the current RTP packets which contain
substitutive content are allocated by mixer and maintain substitutive content are allocated by mixer and maintain
consistent with the sequence numbers of previous current RTP consistent with the sequence numbers of previous current RTP
packets, until the splicing end; packets, until the splicing end;
the timestamp of the current RTP packet increments linearly; the timestamp of the current RTP packet increments linearly;
the CSRC list of the current RTP packet indicates SSRC of the CSRC list of the current RTP packet may include SSRC of
substitutive RTP stream; substitutive RTP stream;
} }
else { else {
the main RTP stream is terminated on mixer and main content is the main RTP stream is terminated on mixer and main content is
encoded by mixer with its own SSRC identifier; encapsulated by mixer with its own SSRC identifier;
the sequence numbers of the current RTP packets which contain main the sequence numbers of the current RTP packets which contain main
content are allocated by mixer and maintain consistent with the content are allocated by mixer and maintain consistent with the
sequence numbers of previous current RTP packets, until the sequence numbers of previous current RTP packets, until the
splicing begins; splicing begins;
the timestamp of the current RTP packets increments linearly; the timestamp of the current RTP packets increments linearly;
the CSRC list the current RTP indicates SSRC of main RTP stream; the CSRC list of the current RTP may include SSRC of main RTP
stream;
} }
Splicing may occur more than one time during the lifetime of main RTP Splicing may occur more than one time during the lifetime of main RTP
stream, this means mixer needs to output main content and stream, this means mixer needs to output 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 current stream is receiver point of view, the only source of the current stream is
mixer wherever the content comes from. mixer wherever the content comes from.
Note that, the substitutive content should be outputted in the range Note that, the substitutive content should be outputted in the range
of splicing duration. Any gap or overlap between main RTP stream and of splicing duration. Any gap or overlap between main RTP stream and
substitutive RTP stream may induce media clipping at splicing point. substitutive RTP stream may induce media clipping at splicing point.
More details about preventing media clipping are introduced in More details about preventing media clipping are introduced in
skipping to change at page 9, line 26 skipping to change at page 9, line 32
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, RTP
receiver can learn the situation on it and can communicate this receiver can learn the situation on it and can communicate this
information to media source via RTCP reception reports. information to media source via RTCP reception reports.
According to the description in section 7.3 of [RFC3550], mixer According to the description in section 7.3 of [RFC3550], mixer
divides RTCP flow between media source and receiver into two separate divides RTCP flow between media source and receiver into two separate
RTCP loops, media source probably has no idea about the situation on RTCP loops, media source probably has no idea about the situation on
receiver. Hence, mixer may use some mechanisms, allowing media receiver. Hence, mixer can use some mechanisms, allowing media
source to at least some degree to have some knowledge of the source to at least some degree to have some knowledge of the
situation on receiver when its content is being passed to receiver. situation on receiver when its content is being passed to receiver.
Because splicing is a processing that mixer selects one media stream Because splicing is a processing that mixer selects one media stream
from multiple streams rather than mixing them, the number of output from multiple streams but neither mixing nor transcoding them, upon
RTP packets containing substitutive content is equal to the number of receiving an RTCP receiver report from downstream receiver, mixer can
input substitutive RTP packets (from substitutive RTP stream) during forward it to original media source with its SSRC identifier intact
splicing, the mixer does not need to modify loss packet fields in (i.e., the SSRC of downstream receiver). Given that the number of
receiver report blocks unless the reporting intervals spans the output RTP packets containing substitutive content is equal to the
splicing point. But mixer needs to change the SSRC field in report number of input substitutive RTP packets (from substitutive RTP
block to the SSRC identifier of original media source and rewrite the stream) during splicing. In the same manner, the number of output
extended highest sequence number field to the corresponding original RTP packets containing main content is equal to the number of input
extended highest sequence number before forwarding the RTCP reception main RTP packets (from main RTP stream) during non-splicing, so mixer
reports to original media source. does not need to modify loss packet fields in Receiver Report Blocks
unless the reporting intervals spans the splicing point. But mixer
needs to change the SSRC field in report block to the SSRC identifier
of original media source and rewrite the extended highest sequence
number field to the corresponding original extended highest sequence
number before forwarding the RTCP receiver report to original media
source.
When a RTCP receiver report spans the splicing point, it reflects the When a RTCP receiver report spans the splicing point, it reflects the
characteristics of the combination of main RTP packets and characteristics of the combination of main RTP packets and
substitutive RTP packets, in which case, mixer needs to divide the substitutive RTP packets, in which case, mixer needs to divide the
receiver report into two separated receiver reports and send them to receiver report into two separated receiver reports and send them to
their original media sources respectively. For each separated their original media sources respectively. For each separated
receiver report, mixer also needs to make the corresponding changes receiver report, mixer also needs to make the corresponding changes
to the packet loss fields in report block besides the SSRC field and to the packet loss fields in report block besides the SSRC field and
the extended highest sequence number field. the extended highest sequence number field.
Based on above RTCP operating mechanism, the media source will see The mixer can also inform the media source of quality with which the
the reception quality of its stream received by mixer, and the content reaches the mixer. This is done by the mixer generating RTCP
reception quality of spliced stream received by RTP receiver. reports for the RTP stream, which it sends upstream towards the media
source. These RTCP reports use the SSRC of the mixer.
Based on above RTCP operating mechanism, the media source whose
content is being passed to receiver, will see the reception quality
of its stream received on mixer, and the reception quality of spliced
stream received on receiver. The media source whose content is not
being passed to receiver, will only see the reception quality of its
stream received on mixer.
If the substitutive content comes from local media file storage ( If the substitutive content comes from local media file storage (
i.e., mixer can be regarded as the substitutive media source), the i.e., mixer can be regarded as the substitutive media source), the
reception reports should be terminated on mixer without any further reception reports received from downstream relate to the substitutive
processing. content should be terminated on mixer without any further processing.
For the media source whose content is terminated on mixer and is not
being passed to receiver, mixer must act as a receiver and send
reception reports to the media source.
4.3. Media Clipping Considerations 4.3. Media Clipping Considerations
This section provides informative guideline about how media clipping This section provides informative guideline about how media clipping
may shape and how mixer deal with the media clipping. may shape and how mixer deal with the media clipping.
If the time slot for substitutive RTP stream mismatches (shorter or If the time slot for substitutive RTP stream mismatches (shorter or
longer than) the duration of the reserved main RTP stream for longer than) the duration of the reserved main RTP stream for
replacing, the media clipping may occur at the splicing point which replacing, the media clipping may occur at the splicing point which
usually is the joint between two independently decodable frames. usually is the joint between two independently decodable frames.
At the splicing in point, mixer can fill the substitutive content up At the splicing in point, mixer can fill up receiver's buffer with
receiver's buffer with several seconds earlier than the presentation substitutive content several seconds earlier than the presentation
time of substitutive content so that smooth playback can be achieved time of substitutive content so that smooth playback can be achieved
without pauses or stuttering on RTP receiver. without pauses or stuttering on RTP receiver.
Compared to buffering method used at splicing in point, things become Compared to buffering method used at splicing in point, things become
somewhat complex at splicing out point. The case that insertion somewhat complex at splicing out point. The case that insertion
duration is shorter than the reserved gap time may cause a little duration is shorter than the reserved gap time may cause a little
playback latency of main RTP stream on RTP receiver, but not playback latency of main RTP stream on RTP receiver, but not
adversely impact the quality of user experience. However, in case adversely impact the quality of user experience. One alternative
that insertion duration is longer than the reserved gap duration, approach is that mixer may pad some blank content (e.g., all black
there exists an overlap of the substitutive RTP stream and the main sequence) to fill up the gap. Another alternative approach is that
RTP stream at splicing out point. In such case, mixer may take a main media source may send filler content (e.g., static channel
ungracefule action, terminating the splicing and switching back to identifier) during splicing, the mixer can switch back to early when
main RTP stream even if this may cause media stuttering on receiver it runs out of substitutive content.
However, in case that insertion duration is longer than the reserved
gap duration, there exists an overlap of the substitutive RTP stream
and the main RTP stream at splicing out point. One straightforward
approach is that mixer takes a ungracefule action, terminating the
splicing and switching back to main RTP stream even if this may cause
media stuttering on receiver. There is an alternative approach which
may be mild but somewhat complex, mixer buffers main content for a
while until substitutive content is finished, and then transmits
buffered main content to receiver at an acceleated bitrate (as
compared to the nominal bitrate of main RTP stream) until its buffer
level returns to normal. At this point in time, mixer transmits main
content to receiver at an nominal bitrate of main RTP stream. Note
that mixer should take into account a variety of parameters, such as
available bandwidth between mixer and receiver, mixer buffer level
and receiver buffer level, to count the accelerated bitrate value.
Another reason to cause media clipping is synchronization delay at Another reason to cause media clipping is synchronization delay at
splicing point if RTP receiver needs to synchronize multiple current splicing point if RTP receiver needs to synchronize multiple current
streams for playback. How to address this issue is discussed in streams for playback. How to address this issue is discussed in
detail in [RFC6051], which provides three feasible approaches to detail in [RFC6051], which provides three feasible approaches to
reduce synchronization delay. reduce synchronization delay.
4.4. Congestion Control Considerations 4.4. Congestion Control Considerations
Provided that the substitutive content has somewhat different Provided that the substitutive content has somewhat different
skipping to change at page 12, line 47 skipping to change at page 13, line 33
applies its congestion control algorithm and responds Temporary applies its congestion control algorithm and responds Temporary
Maximum Media Stream Bit Rate Notification (TMMBN) to mixer. Maximum Media Stream Bit Rate Notification (TMMBN) to mixer.
If the substitutive content comes from local media file storage, If the substitutive content comes from local media file storage,
mixer must directly reduce the substitutive media bitrate as the mixer must directly reduce the substitutive media bitrate as the
substitutive media source when it detects any congestion on its substitutive media source when it detects any congestion on its
downstream link during splicing. downstream link during splicing.
From above analysis, to reduce the risk of congestion and remain the From above analysis, to reduce the risk of congestion and remain the
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 of main RTP stream. If the substitutive RTP stream comes from
substitutive media source, the source had better has some knowledge substitutive media source, the source 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
Compared to above user visibility case, the primary difference in Mixer will not includes CRSC list in outgoing RTP packets to prevent
this case is mixer MUST NOT include CSRC list in outgoing packets user from detecting the splicing occurred on RTP level. Due to the
(i.e., CSRC count field is set to zero and CSRC list fields are absence of CRSC list in current RTP stream, RTP receiver only
absent). initiates SDES, BYE and APP packets to mixer without any knowledge of
main media source and substitutive media source. This creates a
Therefore, due to the absence of CRSC list in current RTP stream, RTP danger that loops involving those sources could not be detected.
receiver only initiates SDES, BYE and APP packets to mixer without
any knowledge of main media source and substitutive media source.
This creates a danger that loops involving those sources could not be
detected.
5. Implementation Considerations 5. Implementation Considerations
When mixer is used to handle RTP splicing, RTP receiver does not need When mixer is used to handle RTP splicing, RTP receiver does not need
any RTP/RTCP extension for splicing. As a trade-off, additional any RTP/RTCP extension for splicing. As a trade-off, additional
overhead could be induced on mixer which uses its own sequence number overhead could be induced on mixer which uses its own sequence number
space and timing model. So mixer will rewrite RTP sequence number space and timing model. So mixer will rewrite RTP sequence number
and timestamp whatever splicing is active or not, and generate RTCP and timestamp whatever splicing is active or not, and generate RTCP
flows for both sides. In case mixer serves multiple main RTP streams flows for both sides. In case mixer serves multiple main RTP streams
simultaneously, this may lead to more overhead on mixer. simultaneously, this may lead to more overhead on mixer.
In addition, there is a potential issue with loop detection, which In addition, there is a potential issue with loop detection, which
would be problematic if User Invisibility Requirement is required. would be problematic if User Invisibility Requirement is required.
6. Security Considerations 6. Security Considerations
If any payload internal security mechanisms (e.g., SSH, SSL etc) are If any payload internal security mechanisms (e.g., ISMACryp
used, only media source and RTP receiver can learn the security [ISMACryp]) are used, only media source and RTP receiver can learn
keying material generated by such internal security mechanism, any the security keying material generated by such internal security
middlebox (e.g., mixer) between media source and RTP receiver can't mechanism, any middlebox (e.g., mixer) between media source and RTP
get such keying material. Only when regular transport security receiver can't get such keying material. Only when regular transport
mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will process the security mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will
packets passing through it. process the packets passing through it.
The security considerations of the RTP specification [RFC3550], the The security considerations of the RTP specification [RFC3550], the
Extended RTP profile for RTCP-Based Feedback [RFC4585], and the Extended RTP profile for RTCP-Based Feedback [RFC4585], and the
Secure Real-time Transport Protocol [RFC3711] apply. Mixer must be Secure Real-time Transport Protocol [RFC3711] apply. Mixer must be
trusted by main media source and insertion media source, and must be trusted by main media source and insertion media source, and must be
included in the security context. included in the security context.
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
Oran, Cullen Jennings, Ali C Begen, and Ning Zong. Oran, Cullen Jennings, Ali C Begen, Charles Eckel and Ning Zong.
9. Change Log 9. Change Log
9.1. draft-xia-avtext-splicing-for-rtp-01 9.1. draft-xia-avtext-splicing-for-rtp-01
The following are the major changes compared to previous version 00: The following are the major changes compared to previous version 00:
o Use mixer to handle both user visible and invisible splicing. o Use mixer to handle both user visible and invisible splicing.
o Add one subsection to describe media clipping considerations. o Add one subsection to describe media clipping considerations.
skipping to change at page 16, line 17 skipping to change at page 16, line 49
[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", 2001. "Digital Program Insertion Splicing API", 2001.
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), [SCTE35] Society of Cable Telecommunications Engineers (SCTE),
"Digital Program Insertion Cueing Message for Cable", "Digital Program Insertion Cueing Message for Cable",
2004. 2004.
[H.323] ITU-T Recommendation H.323, "Packet-based multimedia [ISMACryp]
communications systems", June 2006. Internet Streaming Media Alliance (ISMA), "ISMA Encryption
and Authentication Specification 2.0", November 2007.
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
 End of changes. 30 change blocks. 
87 lines changed or deleted 115 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/