draft-ietf-avtext-splicing-notification-07.txt		draft-ietf-avtext-splicing-notification-08.txt
	AVTEXT Working Group J. Xia		AVTEXT Working Group J. Xia
	INTERNET-DRAFT R. Even		INTERNET-DRAFT R. Even
	Intended Status: Standards Track R. Huang		Intended Status: Standards Track R. Huang
	Expires: November 18, 2016 Huawei		Expires: December 30, 2016 Huawei
	L. Deng		L. Deng
	China Mobile		China Mobile
	May 17, 2016		June 28, 2016
	RTP/RTCP extension for RTP Splicing Notification		RTP/RTCP extension for RTP Splicing Notification
	draft-ietf-avtext-splicing-notification-07		draft-ietf-avtext-splicing-notification-08
	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. The splicer is designed to handle RTP splicing and needs to		time. The splicer is designed to handle RTP splicing and needs to
	know when to start and end the splicing.		know when to start and end the splicing.
	This memo defines two RTP/RTCP extensions to indicate the splicing		This memo defines two RTP/RTCP extensions to indicate the splicing
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2 Overview of RTP Splicing Notification . . . . . . . . . . . . . 4		2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
			2.1 Overview of RTP Splicing . . . . . . . . . . . . . . . . . . 4
			2.2 Overview of Splicing Interval . . . . . . . . . . . . . . . 5
	3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5		3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5
	3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5		3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5
	3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6		3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6
	4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7		4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7
	5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8		5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8		6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9		6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9
	6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9		6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9
	6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10		6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10
	6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12		6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	splicing cases, e.g., advertisement insertion, the splicing duration		splicing cases, e.g., advertisement insertion, the splicing duration
	needs to be inside of the specific, pre-designated time slot. Certain		needs to be inside of the specific, pre-designated time slot. Certain
	timing information about when to start and end the splicing must be		timing information about when to start and end the splicing must be
	first acquired by the splicer in order to start the splicing. This		first acquired by the splicer in order to start the splicing. This
	document refers to this information as the Splicing Interval.		document refers to this information as the Splicing Interval.
	[SCTE35] provides a method that encapsulates the Splicing Interval		[SCTE35] provides a method that encapsulates the Splicing Interval
	inside the MPEG2-TS layer in cable TV systems. When transported in		inside the MPEG2-TS layer in cable TV systems. When transported in
	RTP, an middle box designed as the splicer to decode the RTP packets		RTP, an middle box designed as the splicer to decode the RTP packets
	and search for the Splicing Interval inside the payloads is required.		and search for the Splicing Interval inside the payloads is required.
	The middle box is either a translator or a mixer as described in		The need for such processing increases the workload of the middle box
	[RFC6828]. The need for such processing increases the workload of the		and limits the number of RTP sessions the middle box can support.
	middle box and limits the number of RTP sessions the middle box can
	support.
	The document defines an RTP header extension [RFC5285] used by the		The document defines an RTP header extension [RFC5285] used by the
	main RTP sender to provide the Splicing Interval by including it in		main RTP sender to provide the Splicing Interval by including it in
	the RTP packets.		the RTP packets.
	However, the Splicing Interval conveyed in the RTP header extension		However, the Splicing Interval conveyed in the RTP header extension
	might not reach the splicer successfully. Any splicing un-aware		might not reach the splicer successfully. Any splicing un-aware
	middlebox on the path between the RTP sender might strip this RTP		middlebox on the path between the RTP sender might strip this RTP
	header extension.		header extension.
	To increase robustness against such case, the document also defines a		To increase robustness against such case, the document also defines a
	complementary RTCP packet type to carry the same Splicing Interval to		new RTCP packet type to carry the same Splicing Interval to the
	the splicer.		splicer. Since RTCP is also unreliable and may not be so immediate as
			the in-band way, it's only considered as a complement to the RTP
			header extension.
	1.1 Terminology		1.1 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	In addition, we define following terminologies:		In addition, we define following terminologies:
	Main RTP sender:		Main RTP sender:
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	The NTP-format timestamps, representing the main RTP sender		The NTP-format timestamps, representing the main RTP sender
	wallclock time, for the Splicing-In point and Splicing-Out point		wallclock time, for the Splicing-In point and Splicing-Out point
	per [RFC6828] allowing the splicer to know when to start and end		per [RFC6828] allowing the splicer to know when to start and end
	the RTP splicing.		the RTP splicing.
	Substitutive RTP Sender:		Substitutive RTP Sender:
	The sender of RTP packets carrying the RTP stream that will		The sender of RTP packets carrying the RTP stream that will
	replace the content in the main RTP stream.		replace the content in the main RTP stream.
	2 Overview of RTP Splicing Notification		2 Overview
	A splicer is designed to handle splicing on the RTP layer at the		2.1 Overview of RTP Splicing
	reserved time slots set by the main RTP sender. This implies that the
	splicer must first know the Splicing Interval from the main RTP		RTP Splicing is intended to replace some multimedia content with
	sender before it can start splicing. The splicer can be a mixer as		certain substitutive multimedia content, and then forward it to the
	described in [RFC6828].		receivers for a period of time. This process is authorized by the
			main RTP sender that offers a specific time window for inserting the
			substitutive multimedia content in the main content. A typical usage
			is that IPTV service provider uses its own regional advertising
			content to replace national advertising content, the time window of
			which is explicitly indicated by the IPTV service provider.
			The splicer is a middlebox handling RTP splicing. It receives main
			content and substitutive content simultaneously but only chooses to
			send one of them to the receiver at any point of time. When RTP
			splicing begins, the splicer sends the substitutive content to the
			receivers instead of the main content. When RTP splicing ends, the
			splicer switches back to sending the main content to the receivers.
			This implies that the receiver is explicitly configured to receive
			the traffic via the splicer, and will return any RTCP feedback to it
			in the presence of the splicer.
			The middlebox working as the splicer can be implemented as either an
			RTP mixer or as an RTP translator. If implemented as an RTP mixer,
			[RFC6828] specifies how the splicer can use its own SSRC, sequence
			number space, and timing model when generating the output stream to
			receivers, using the CSRC list to indicate whether the original or
			substitutive content is being delivered. The splicer, on behalf of
			the content provider, can omit the CSRC list from the RTP packets it
			generates. This simplifies the design of the receivers, since they
			don't need to parse the CSRC list, but makes it harder to determine
			when the splicing is taking place (it requires inspection of the RTP
			payload data, rather than just the RTP headers). A splicer working as
			an RTP mixer splits the flow between the sender and receiver into
			two, and requires separate control loops, for RTCP and congestion
			control, see Section 4.4 of [RFC6828].
			A splicer implemented as an RTP translator [RFC3550] will forward the
			RTP packets from the original and substitutive senders with their
			SSRCs intact, but will need to rewrite RTCP sender report packets to
			account for the splicing. In this case, the congestion control loops
			run between original sender and receiver, and between the
			substitutive sender and receiver. The splicer needs to ensure that
			the RTCP feedback message from the receiver are passed to the right
			sender to let the congestion control work.
			2.2 Overview of Splicing Interval
			To handle splicing on the RTP layer at the reserved time slots set by
			the main RTP sender, the splicer must first know the Splicing
			Interval from the main RTP sender before it can start splicing. The
			splicer can be a mixer as described in [RFC6828].
	When a new splicing is forthcoming, the main RTP sender needs to send		When a new splicing is forthcoming, the main RTP sender needs to send
	the Splicing Interval to the splicer. The Splicing Interval SHOULD be		the Splicing Interval to the splicer. The Splicing Interval SHOULD be
	sent more than once to mitigate the possible packet loss. To enable		sent by RTP header extension or RTCP extension message more than once
	the splicer to get the substitutive content before the splicing		to mitigate the possible packet loss. To enable the splicer to get
	starts, the main RTP sender MUST send the Splicing Interval far		the substitutive content before the splicing starts, the main RTP
	ahead. For example, the main RTP sender can estimate when to send the		sender MUST send the Splicing Interval far ahead. For example, the
	Splicing Interval based on the round-trip time (RTT) following the		main RTP sender can estimate when to send the Splicing Interval based
	mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP		on the round-trip time (RTT) following the mechanisms in section
	RR to the main sender.		6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender.
	The substitutive sender also needs to learn the Splicing Interval		The substitutive sender also needs to learn the Splicing Interval
	from the main RTP sender in advance, and thus estimates when to		from the main RTP sender in advance, and thus estimates when to
	transfer the substitutive content to the splicer. The Splicing		transfer the substitutive content to the splicer. The Splicing
	Interval could be transmitted from the main RTP sender to the		Interval could be transmitted from the main RTP sender to the
	substitutive content using some out-of-band mechanisms, for example,		substitutive content using some out-of-band mechanisms, for example,
	a proprietary mechanism to exchange the Splicing Interval, or the		a proprietary mechanism to exchange the Splicing Interval, or the
	substitutive sender is implemented together with the main RTP sender		substitutive sender is implemented together with the main RTP sender
	inside a single device. To ensure the Splicing Interval is valid for		inside a single device. To ensure the Splicing Interval is valid for
	both the main RTP sender and the substitutive RTP sender, the two		both the main RTP sender and the substitutive RTP sender, the two
	skipping to change at page 7, line 27 ¶		skipping to change at page 8, line 27 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Splicing Interval		Figure 2: Splicing Interval
	Using the Two-Byte Header Format		Using the Two-Byte Header Format
	Since the inclusion of an RTP header extension will reduce the		Since the inclusion of an RTP header extension will reduce the
	efficiency of RTP header compression, it is RECOMMENDED that the main		efficiency of RTP header compression, it is RECOMMENDED that the main
	sender inserts the RTP header extensions into only a number of RTP		sender inserts the RTP header extensions into only a number of RTP
	packets, instead of all the RTP packets, prior to the splicing in.		packets, instead of all the RTP packets, prior to the splicing in.
	After the splicer intercepts the RTP header extension and derives the		After the splicer obtains the RTP header extension and derives the
	Splicing Interval, it will generate its own stream and SHOULD NOT		Splicing Interval, it generates its own stream and is not allowed to
	include the RTP header extension in outgoing packets to reduce header		include the RTP header extension in outgoing packets to reduce header
	overhead.		overhead.
	3.2 RTCP Splicing Notification Message		3.2 RTCP Splicing Notification Message
	In addition to the RTP header extension, the main RTP sender includes		In addition to the RTP header extension, the main RTP sender includes
	the Splicing Interval in an RTCP splicing notification message.		the Splicing Interval in an RTCP splicing notification message.
	Whether or not the timestamps are included in the RTP header		Whether or not the timestamps are included in the RTP header
	extension, the main RTP sender MUST send the RTCP splicing		extension, the main RTP sender MUST send the RTCP splicing
	notification message. This provide robustness in the case where a		notification message. This provide robustness in the case where a
	skipping to change at page 9, line 5 ¶		skipping to change at page 10, line 5 ¶
	6.1 in [RFC3550].		6.1 in [RFC3550].
	If the use of non-compound RTCP [RFC5506] was previously negotiated		If the use of non-compound RTCP [RFC5506] was previously negotiated
	between the sender and the splicer, the RTCP splicing notification		between the sender and the splicer, the RTCP splicing notification
	message may be sent as non-compound RTCP packets. In some cases that		message may be sent as non-compound RTCP packets. In some cases that
	the mapping from RTP timestamp to NTP timestamp changes, e.g., clock		the mapping from RTP timestamp to NTP timestamp changes, e.g., clock
	drift happening before the splicing event, it may be required to send		drift happening before the splicing event, it may be required to send
	RTCP SR or even updated Splicing Interval information timely to		RTCP SR or even updated Splicing Interval information timely to
	update the timestamp mapping for accurate splicing.		update the timestamp mapping for accurate splicing.
	When the splicer intercepts the RTCP splicing notification message,		Since the RTCP splicing notification message is intentionally sent by
	it SHOULD NOT forward the message to the down-stream receivers in		the main RTP sender to the splicer, the splicer is not allowed to
	order to reduce RTCP bandwidth consumption. And if the splicer wishes		forward this message to the receivers so as to avoid their useless
	to prevent the downstream receivers from detecting splicing, it MUST		processing and additional RTCP bandwidth consumption in the
	NOT forward the message.		downstream.
	4 Reducing Splicing Latency		4 Reducing Splicing Latency
	When splicing starts or ends, the splicer outputs the multimedia		When splicing starts or ends, the splicer outputs the multimedia
	content from another sender to the receivers. Given that the		content from another sender to the receivers. Given that the
	receivers must first acquire certain information ([RFC6285] refers to		receivers must first acquire certain information ([RFC6285] refers to
	this information as Reference Information) to start processing the		this information as Reference Information) to start processing the
	multimedia data, either the main RTP sender or the substitutive		multimedia data, either the main RTP sender or the substitutive
	sender SHOULD provide the Reference Information together with its		sender SHOULD provide the Reference Information together with its
	multimedia content to reduce the delay caused by acquiring the		multimedia content to reduce the delay caused by acquiring the
	Reference Information. The methods by which the Reference Information		Reference Information. The methods by which the Reference Information
	is distributed to the receivers is out of scope of this memo.		is distributed to the receivers is out of scope of this memo.
	Another latency element is synchronization caused delay. The		Another latency element is synchronization caused delay. The
	receivers must receive enough synchronization metadata prior to		receivers must receive enough synchronization metadata prior to
	synchronizing the separate components of the multimedia streams when		synchronizing the separate components of the multimedia streams when
	splicing starts or ends. Either the main RTP sender or the		splicing starts or ends. Either the main RTP sender or the
	substitutive sender SHOULD send the synchronization metadata early		substitutive sender SHOULD send the synchronization metadata early
	enough so that the receivers can play out the multimedia in a		enough so that the receivers can play out the multimedia in a
	synchronized fashion. The main RTP sender and the substitutive sender		synchronized fashion. The main RTP sender or the substitutive sender
	can be coordinated by some proprietary out-of-band mechanisms to		can estimate when to send the synchronization metadata based on, for
	decide when and whom to send the metadata. If both send the		example, the round-trip time (RTT) following the mechanisms in
	information, the splicer SHOULD pick one based on the current		section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main
	situation, e.g., choosing media sender when synchronizing the main		sender or the substitutive sender. The main RTP sender and the
	media content while choosing the information from the substitutive		substitutive sender can also be coordinated by some proprietary out-
	sender when synchronizing the spliced content. The mechanisms defined		of-band mechanisms to decide when and whom to send the metadata. If
	in [RFC6051] are RECOMMENDED to be adopted to reduce the possible		both send the information, the splicer SHOULD pick one based on the
	synchronization delay.		current situation, e.g., choosing main RTP sender when synchronizing
			the main media content while choosing the information from the
			substitutive sender when synchronizing the spliced content. The
			mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to
			reduce the possible synchronization delay.
	5 Failure Cases		5 Failure Cases
	This section examines the implications of losing RTCP splicing		This section examines the implications of losing RTCP splicing
	notification message and the other failure case, e.g., the RTP header		notification message and the other failure case, e.g., the RTP header
	extension is stripped on the path.		extension is stripped on the path.
	Given that there may be a splicing un-aware middlebox on the path		Given that there may be a splicing un-aware middlebox on the path
	between the main RTP sender and the splicer, the main and the		between the main RTP sender and the splicer, the main and the
	substitutive RTP senders can use one heuristic to verify whether or		substitutive RTP senders can use one heuristic to verify whether or
	skipping to change at page 16, line 37 ¶		skipping to change at page 17, line 37 ¶
	The splicer replaces some content with other content in RTP packet,		The splicer replaces some content with other content in RTP packet,
	thus breaking any RTP-level end-to-end security, such as source		thus breaking any RTP-level end-to-end security, such as source
	authentication and integrity protection. End to end source		authentication and integrity protection. End to end source
	authentication is not possible with any known existing splicing		authentication is not possible with any known existing splicing
	solution. A new solution can theoretically be developed that enables		solution. A new solution can theoretically be developed that enables
	identification of the participating entities and what each provides,		identification of the participating entities and what each provides,
	i.e., the different media sources, main and substituting, and the		i.e., the different media sources, main and substituting, and the
	splicer which provides the RTP-level integration of the media		splicer which provides the RTP-level integration of the media
	payloads in a common timeline and synchronization context.		payloads in a common timeline and synchronization context.
	Since splicer works as a trusted entity, any RTP-level or outside		Since the splicer breaks RTP-level end-to-end security, it needs to
	security mechanism, such as IPsec[RFC4301] or Datagram Transport		be part of the signaling context and the necessary security
	Layer Security [RFC6347], will use a security association between the		associations (e.g., SRTP crypto contexts) established for the RTP
	splicer and the receiver. When using the Secure Real-Time Transport		session participants. When using the Secure Real-Time Transport
	Protocol (SRTP) [RFC3711], the splicer could be provisioned with the		Protocol (SRTP) [RFC3711], the splicer would have to be provisioned
	same security association as the main RTP sender.		with the same security association as the main RTP sender.
	If there is a concern about the confidentiality of the splicing time		If there is a concern about the confidentiality of the splicing time
	information, header extension encryption [RFC6904] SHOULD be used.		information, the header extension defined in this document MUST be
	However, the malicious endpoint may get the splicing time information		also protected, for example, header extension encryption [RFC6904]
	by other means, e.g., inferring from the communication between the		can be used in this case. However, the malicious endpoint may get the
	main and substitutive content sources. To avoid the insertion of		splicing time information by other means, e.g., inferring from the
	invalid substitutive content, the splicer MUST have some mechanisms		communication between the main and substitutive content sources. To
	to authenticate the substitutive stream source.		avoid the insertion of invalid substitutive content, the splicer MUST
			have some mechanisms to authenticate the substitutive stream source.
	For cases that the splicing time information is changed by a		For cases that the splicing time information is changed by a
	malicious endpoint, the splicing, for example, may fail since it will		malicious endpoint, the splicing, for example, may fail since it will
	not be available at the right time for the substitutive media to		not be available at the right time for the substitutive media to
	arrive. Another case is that an attacker may prevent the receivers		arrive. Another case is that an attacker may prevent the receivers
	receiving the content from the main sender by inserting extra		receiving the content from the main sender by inserting extra
	splicing time information. To avoid the above cases happening, the		splicing time information. To avoid the above cases happening, the
	authentication of the RTP header extension for splicing time		authentication of the RTP header extension for splicing time
	information SHOULD be considered.		information SHOULD be considered.
	A malicious endpoint may also break an undetectable splicing. To		When a splicer implemented as a mixer sends the stream to the
	mitigate this effect, the splicer SHOULD NOT forward the splicing		receivers, CSRC list, which can be used to detect RTP-level
	time information RTP header extension defined in Section 4.1 to the		forwarding loops as defined in Section 8.2 of [RFC3550], may be
	receivers. And it MUST NOT forward this header extension when		removed for simplifying the receivers that can not handle multiple
	considering an undetectable splicing.		sources in the RTP stream. Hence, loops may occur to cause packets to
			loop back to upstream of the splicer and may form a serious denial-
			of-service threat. In such a case, non-RTP means, e.g., signaling
			among all the participants, MUST be used to detect and resolve loops.
	8 IANA Considerations		8 IANA Considerations
	8.1 RTCP Control Packet Types		8.1 RTCP Control Packet Types
	Based on the guidelines suggested in [RFC5226], a new RTCP packet		Based on the guidelines suggested in [RFC5226], a new RTCP packet
	format has been registered with the RTCP Control Packet Type (PT)		format has been registered with the RTCP Control Packet Type (PT)
	Registry:		Registry:
	Name: SNM		Name: SNM
	skipping to change at page 17, line 50 ¶		skipping to change at page 19, line 4 ¶
	Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval		Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
	Description: Splicing Interval		Description: Splicing Interval
	Contact: Jinwei Xia <xiajinwei@huawei.com>		Contact: Jinwei Xia <xiajinwei@huawei.com>
	Reference: This document		Reference: This document
	8.3 SDP Grouping Semantic Extension		8.3 SDP Grouping Semantic Extension
	This document request IANA to register the new SDP grouping semantic		This document request IANA to register the new SDP grouping semantic
	extension called "SPLICE".		extension called "SPLICE".
	Semantics: Splice		Semantics: Splice
	Token:SPLICE		Token:SPLICE
	Reference: This document		Reference: This document
	Contact: Jinwei Xia <xiajinwei@huawei.com>
	9 Acknowledgement		9 Acknowledgement
	The authors would like to thank the following individuals who help to		The authors would like to thank the following individuals who help to
	review this document and provide very valuable comments: Colin		review this document and provide very valuable comments: Colin
	Perkins, Bo Burman, Stephen Botzko, Ben Campbell.		Perkins, Bo Burman, Stephen Botzko, Ben Campbell.
	10 References		10 References
	10.1 Normative References		10.1 Normative References
	skipping to change at page 18, line 34 ¶		skipping to change at page 19, line 34 ¶
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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.
	[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
	with the Session Description Protocol (SDP)", RFC 3264,		with the Session Description Protocol (SDP)", RFC 3264,
	June 2002.		June 2002.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.
	[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP		[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
	Header Extensions", RFC 5285, July 2008.		Header Extensions", RFC 5285, July 2008.
	[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description		[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
	Protocol (SDP) Grouping Framework", RFC 5888, June 2010.		Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, June 2010.
	[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP		[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
	Flows", RFC 6051, November 2010.		Flows", RFC 6051, November 2010.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.
	[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP		[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
	Sessions", RFC 7201, April 2014.		Sessions", RFC 7201, April 2014.
	[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,		[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
	November 2015.		November 2015.
	10.2 Informative References		10.2 Informative References
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
End of changes. 19 change blocks.
	65 lines changed or deleted		113 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/