draft-ietf-avtext-splicing-for-rtp-05.txt   draft-ietf-avtext-splicing-for-rtp-06.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational February 7, 2012 Intended status: Informational February 17, 2012
Expires: August 10, 2012 Expires: August 20, 2012
Content Splicing for RTP Sessions Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-05 draft-ietf-avtext-splicing-for-rtp-06
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 August 10, 2012. This Internet-Draft will expire on August 20, 2012.
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 5, line 46 skipping to change at page 5, line 46
than once in case that substitutive content will be dispersedly than once in case that substitutive content will be dispersedly
inserted in multiple time slots during the lifetime of the main RTP inserted in multiple time slots during the lifetime of the main RTP
stream. stream.
When realizing splicing technology on RTP layer, there are a set of When realizing splicing technology on RTP layer, there are a set of
requirements that must be satisfied to at least some degree on requirements that must be satisfied to at least some degree on
Splicer: Splicer:
REQ-1: REQ-1:
Splicer MUST operate in either unicast or multicast session Splicer must operate in either unicast or multicast session
environment. environment.
REQ-2: REQ-2:
Splicer SHOULD NOT cause perceptible media clipping at the Splicer should not cause perceptible media clipping at the
splicing point and adverse impact on the quality of user splicing point and adverse impact on the quality of user
experience. experience.
REQ-3: REQ-3:
Splicer MUST be backward compatible with RTP/RTCP protocols, and Splicer must be backward compatible with RTP/RTCP protocols, and
its associated profiles and extensions to those protocols. For its associated profiles and extensions to those protocols. For
example, Splicer MUST be robust to packet loss, network congestion example, Splicer must be robust to packet loss, network congestion
etc. etc.
REQ-4: REQ-4:
Splicer MUST be trusted by media source and receiver, and has the Splicer must be trusted by media source and receiver, and has the
valid security context with media source and RTP receiver valid security context with media source and RTP receiver
respectively. respectively.
REQ-5: REQ-5:
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: 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
RECOMMENDED to minimize the splicing visibility on RTP receiver, recommended to minimize the splicing visibility on RTP receiver,
i.e., maintaining RTP header parameters consistent but leaving the i.e., maintaining RTP header parameters consistent but leaving the
RTP payload untranscoded. If one wants to realize complete RTP payload untranscoded. If one wants to realize complete
invisibility, the cost of transcoding must be taken into account. invisibility, the cost of transcoding must be taken into account.
Henceforth, we refer to the minimum and complete invisibility Henceforth, we refer to the minimum and complete invisibility
requirement as User Invisibility Requirement. requirement as User Invisibility Requirement.
To improve the versatility of existing implementations and better To improve the versatility of existing implementations and better
interoperability, it is RECOMMENDED to use existing tools in RTP/RTCP interoperability, it is recommended to use existing tools in RTP/RTCP
protocol family to realize RTP splicing without any protocol protocol family to realize RTP splicing without any protocol
extension unless the existing tools are incompetent for splicing. extension unless the existing tools are incompetent for splicing.
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.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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, and generate a media stream as defined in RFC3550. main RTP stream, and generate a media stream as defined in RFC3550.
Using main content, mixer generates the current media stream with its Using main content, mixer generates the current media stream with its
own SSRC, sequence number space and timing model. Moreover, mixer own SSRC, sequence number space and timing model. Moreover, mixer
may insert the SSRC of main RTP stream into CSRC list in the current may insert the SSRC of main RTP stream into CSRC 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
 End of changes. 13 change blocks. 
14 lines changed or deleted 14 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/