draft-ietf-avtext-splicing-for-rtp-03.txt   draft-ietf-avtext-splicing-for-rtp-04.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational December 22, 2011 Intended status: Informational December 30, 2011
Expires: June 24, 2012 Expires: July 2, 2012
Content Splicing for RTP Sessions Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-03 draft-ietf-avtext-splicing-for-rtp-04
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 June 24, 2012. This Internet-Draft will expire on July 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 6, line 36 skipping to change at page 6, line 36
Splicer SHOULD allow the media source to learn the performance of Splicer SHOULD allow the media source to learn the performance of
the downstream receiver when its content is being passed to RTP the downstream receiver when its content is being passed to RTP
receiver. receiver.
In a number of deployment scenarios, especially advertisement In a number of deployment scenarios, especially advertisement
insertion, there may be one specific requirement. Given that it is insertion, there may be one specific requirement. Given that it is
unacceptable for advertisers that their advertising content is not unacceptable for advertisers that their advertising content is not
delivered to user, this may require RTP splicing to be operated delivered to user, this may require RTP splicing to be operated
within the following constraint: within the following constraint:
REQ-6:
If Splicer intends to prevent RTP receiver from identifying and If Splicer intends to prevent RTP receiver from identifying and
filtering the substitutive content, it SHOULD eliminate the filtering the substitutive content, it SHOULD eliminate the
visibility of splicing process on RTP level from RTP receiver visibility of splicing process on RTP level from RTP receiver
point of view. point of view.
However, substitutive content and main content are encoded by However, substitutive content and main content are encoded by
different encoders and have different parameter sets. In such different encoders and have different parameter sets. In such
case, a full media transcoding must be done on Splicer to ensure case, a full media transcoding must be done on Splicer to ensure
the completely invisible impact on RTP receiver, but this may be the completely invisible impact on RTP receiver, but this may be
prohibitively expensive and complex. As a trade-off, it is prohibitively expensive and complex. As a trade-off, it is
skipping to change at page 7, line 33 skipping to change at page 7, line 33
such capability to do this under its own SSRC. Moreover, mixer such capability to do this under its own SSRC. Moreover, mixer
includes the CSRC list in outgoing packets to indicate the source(s) includes the CSRC list in outgoing packets to indicate the source(s)
of content, this facilitates the system debugging. From this point of content, this facilitates the system debugging. From this point
of view, an RTP mixer may have some chance to be Splicer. In next of view, an RTP mixer may have some chance to be Splicer. In next
four subsections (from subsection 4.1 to subsection 4.4), we start four subsections (from subsection 4.1 to subsection 4.4), we start
analyzing how an RTP mixer handles RTP splicing and how it satisfies analyzing how an RTP mixer handles RTP splicing and how it satisfies
the general requirements listed in section 3. 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 user (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 user 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
skipping to change at page 9, line 6 skipping to change at page 9, line 6
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 the current RTP indicates 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 user substitutive content in turn with its own SSRC identifier. From
point of view, the only source of the current stream is mixer receiver point of view, the only source of the current stream is
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
section 4.3. section 4.3.
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
 End of changes. 6 change blocks. 
9 lines changed or deleted 11 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/