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/