draft-ietf-rtcweb-rtp-usage-20.txt		draft-ietf-rtcweb-rtp-usage-21.txt
	RTCWEB Working Group C. S. Perkins		RTCWEB Working Group C. S. Perkins
	Internet-Draft University of Glasgow		Internet-Draft University of Glasgow
	Intended status: Standards Track M. Westerlund		Intended status: Standards Track M. Westerlund
	Expires: May 14, 2015 Ericsson		Expires: May 30, 2015 Ericsson
	J. Ott		J. Ott
	Aalto University		Aalto University
	November 10, 2014		November 26, 2014
	Web Real-Time Communication (WebRTC): Media Transport and Use of RTP		Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
	draft-ietf-rtcweb-rtp-usage-20		draft-ietf-rtcweb-rtp-usage-21
	Abstract		Abstract
	The Web Real-Time Communication (WebRTC) framework provides support		The Web Real-Time Communication (WebRTC) framework provides support
	for direct interactive rich communication using audio, video, text,		for direct interactive rich communication using audio, video, text,
	collaboration, games, etc. between two peers' web-browsers. This		collaboration, games, etc. between two peers' web-browsers. This
	memo describes the media transport aspects of the WebRTC framework.		memo describes the media transport aspects of the WebRTC framework.
	It specifies how the Real-time Transport Protocol (RTP) is used in		It specifies how the Real-time Transport Protocol (RTP) is used in
	the WebRTC context, and gives requirements for which RTP features,		the WebRTC context, and gives requirements for which RTP features,
	profiles, and extensions need to be supported.		profiles, and extensions need to be supported.
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 May 14, 2015.		This Internet-Draft will expire on May 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 2, line 19		skipping to change at page 2, line 19
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5		4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5
	4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5		4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7		4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7
	4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8		4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8
	4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9		4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 10
	4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10		4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10
	4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10		4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11
	4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11		4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11
	4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11		4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 12
	4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12		4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12
	4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13		4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13
	5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13		5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13
	5.1. Conferencing Extensions and Topologies . . . . . . . . . 13		5.1. Conferencing Extensions and Topologies . . . . . . . . . 13
	5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15		5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15
	5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15		5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15
	5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 15		5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 16
	5.1.4. Reference Picture Selection Indication (RPSI) . . . . 15		5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16
	5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16		5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16
	5.1.6. Temporary Maximum Media Stream Bit Rate Request		5.1.6. Temporary Maximum Media Stream Bit Rate Request
	(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16		(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 16		5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 17
	5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17		5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17
	5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17		5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17
	5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 17		5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18
	6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 18		5.2.4. Media Stream Identification . . . . . . . . . . . . . 18
	6.1. Negative Acknowledgements and RTP Retransmission . . . . 18		5.2.5. Coordination of Video Orientation . . . . . . . . . . 18
	6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 19		6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19
	7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 19		6.1. Negative Acknowledgements and RTP Retransmission . . . . 19
	7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 20		6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20
	7.2. Congestion Control Interoperability and Legacy Systems . 21		7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20
	8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22		7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21
	9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22		7.2. Congestion Control Interoperability and Legacy Systems . 22
	10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22		8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 23
	11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24		9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23
	12. RTP Implementation Considerations . . . . . . . . . . . . . . 26		10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23
	12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26		11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25
	12.1.1. Use of Multiple Media Sources Within an RTP Session 26		12. RTP Implementation Considerations . . . . . . . . . . . . . . 27
	12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28		12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27
	12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32		12.1.1. Use of Multiple Media Sources Within an RTP Session 27
			12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 29
			12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33
	12.2. Media Source, RTP Packet Streams, and Participant		12.2. Media Source, RTP Packet Streams, and Participant
	Identification . . . . . . . . . . . . . . . . . . . . . 34		Identification . . . . . . . . . . . . . . . . . . . . . 35
	12.2.1. Media Source Identification . . . . . . . . . . . . 34		12.2.1. Media Source Identification . . . . . . . . . . . . 35
	12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 35		12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36
	12.2.3. Media Synchronisation Context . . . . . . . . . . . 36		12.2.3. Media Synchronisation Context . . . . . . . . . . . 37
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 36		13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	16.1. Normative References . . . . . . . . . . . . . . . . . . 38		16.1. Normative References . . . . . . . . . . . . . . . . . . 39
	16.2. Informative References . . . . . . . . . . . . . . . . . 41		16.2. Informative References . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	1. Introduction		1. Introduction
	The Real-time Transport Protocol (RTP) [RFC3550] provides a framework		The Real-time Transport Protocol (RTP) [RFC3550] provides a framework
	for delivery of audio and video teleconferencing data and other real-		for delivery of audio and video teleconferencing data and other real-
	time media applications. Previous work has defined the RTP protocol,		time media applications. Previous work has defined the RTP protocol,
	along with numerous profiles, payload formats, and other extensions.		along with numerous profiles, payload formats, and other extensions.
	When combined with appropriate signalling, these form the basis for		When combined with appropriate signalling, these form the basis for
	many teleconferencing systems.		many teleconferencing systems.
	skipping to change at page 6, line 32		skipping to change at page 6, line 40
	WebRTC devices through a gateway, receivers MUST support multiple		WebRTC devices through a gateway, receivers MUST support multiple
	synchronisation contexts, indicated by the use of multiple RTCP		synchronisation contexts, indicated by the use of multiple RTCP
	CNAMEs in an RTP session. This specification requires the usage		CNAMEs in an RTP session. This specification requires the usage
	of a single CNAME when sending RTP Packet Streams in some		of a single CNAME when sending RTP Packet Streams in some
	circumstances, see Section 4.9.		circumstances, see Section 4.9.
	o Support for sending and receiving RTCP SR, RR, SDES, and BYE		o Support for sending and receiving RTCP SR, RR, SDES, and BYE
	packet types, with OPTIONAL support for other RTCP packet types		packet types, with OPTIONAL support for other RTCP packet types
	unless mandated by other parts of this specification. Note that		unless mandated by other parts of this specification. Note that
	additional RTCP Packet types are used by the RTP/SAVPF Profile		additional RTCP Packet types are used by the RTP/SAVPF Profile
	(Section 4.2) and the other RTCP extensions (Section 5).		(Section 4.2) and the other RTCP extensions (Section 5). WebRTC
			endpoints that implement the SDP bundle negotiation extension will
			use the SDP grouping framework 'mid' attribute to identify media
			streams. Such endpoints MUST implement the RTCP SDES MID item
			described in [I-D.ietf-mmusic-sdp-bundle-negotiation].
	o Support for multiple end-points in a single RTP session, and for		o Support for multiple end-points in a single RTP session, and for
	scaling the RTCP transmission interval according to the number of		scaling the RTCP transmission interval according to the number of
	participants in the session; support for randomised RTCP		participants in the session; support for randomised RTCP
	transmission intervals to avoid synchronisation of RTCP reports;		transmission intervals to avoid synchronisation of RTCP reports;
	support for RTCP timer reconsideration (Section 6.3.6 of		support for RTCP timer reconsideration (Section 6.3.6 of
	[RFC3550]) and reverse reconsideration (Section 6.3.4 of		[RFC3550]) and reverse reconsideration (Section 6.3.4 of
	[RFC3550]).		[RFC3550]).
	o Support for configuring the RTCP bandwidth as a fraction of the		o Support for configuring the RTCP bandwidth as a fraction of the
	skipping to change at page 8, line 26		skipping to change at page 8, line 36
	a limited form of source authentication. WebRTC Endpoints MUST NOT		a limited form of source authentication. WebRTC Endpoints MUST NOT
	send packets using the basic RTP/AVP profile or the RTP/AVPF profile;		send packets using the basic RTP/AVP profile or the RTP/AVPF profile;
	they MUST employ the full RTP/SAVPF profile to protect all RTP and		they MUST employ the full RTP/SAVPF profile to protect all RTP and
	RTCP packets that are generated (i.e., implementations MUST use SRTP		RTCP packets that are generated (i.e., implementations MUST use SRTP
	and SRTCP). The RTP/SAVPF profile MUST be configured using the		and SRTCP). The RTP/SAVPF profile MUST be configured using the
	cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and		cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and
	other parameters described in [I-D.ietf-rtcweb-security-arch].		other parameters described in [I-D.ietf-rtcweb-security-arch].
	4.3. Choice of RTP Payload Formats		4.3. Choice of RTP Payload Formats
	The set of mandatory to implement codecs and RTP payload formats for		Mandatory to implement audio codecs and RTP payload formats for
	WebRTC is not specified in this memo, instead they are defined in		WebRTC endpoints are defined in [I-D.ietf-rtcweb-audio]. Mandatory
	separate specifications, such as [I-D.ietf-rtcweb-audio].		to implement video codecs and RTP payload formats for WebRTC
	Implementations can support any codec for which an RTP payload format		endpoints are defined in [I-D.ietf-rtcweb-video]. WebRTC endpoints
	and associated signalling is defined. Implementation cannot assume		MAY additionally implement any other codec for which an RTP payload
	that the other participants in an RTP session understand any RTP		format and associated signalling has been defined.
	payload format, no matter how common; the mapping between RTP payload
	type numbers and specific configurations of particular RTP payload		WebRTC Endpoints cannot assume that the other participants in an RTP
	formats MUST be agreed before those payload types/formats can be		session understand any RTP payload format, no matter how common. The
	used. In an SDP context, this can be done using the "a=rtpmap:" and		mapping between RTP payload type numbers and specific configurations
	"a=fmtp:" attributes associated with an "m=" line, along with any		of particular RTP payload formats MUST be agreed before those payload
	other SDP attributes needed to configure the RTP payload format.		types/formats can be used. In an SDP context, this can be done using
			the "a=rtpmap:" and "a=fmtp:" attributes associated with an "m="
			line, along with any other SDP attributes needed to configure the RTP
			payload format.
	End-points can signal support for multiple RTP payload formats, or		End-points can signal support for multiple RTP payload formats, or
	multiple configurations of a single RTP payload format, as long as		multiple configurations of a single RTP payload format, as long as
	each unique RTP payload format configuration uses a different RTP		each unique RTP payload format configuration uses a different RTP
	payload type number. As outlined in Section 4.8, the RTP payload		payload type number. As outlined in Section 4.8, the RTP payload
	type number is sometimes used to associate an RTP packet stream with		type number is sometimes used to associate an RTP packet stream with
	a signalling context. This association is possible provided unique		a signalling context. This association is possible provided unique
	RTP payload type numbers are used in each context. For example, an		RTP payload type numbers are used in each context. For example, an
	RTP packet stream can be associated with an SDP "m=" line by		RTP packet stream can be associated with an SDP "m=" line by
	comparing the RTP payload type numbers used by the RTP packet stream		comparing the RTP payload type numbers used by the RTP packet stream
	skipping to change at page 17, line 19		skipping to change at page 17, line 37
	compromising interoperability.		compromising interoperability.
	5.2.1. Rapid Synchronisation		5.2.1. Rapid Synchronisation
	Many RTP sessions require synchronisation between audio, video, and		Many RTP sessions require synchronisation between audio, video, and
	other content. This synchronisation is performed by receivers, using		other content. This synchronisation is performed by receivers, using
	information contained in RTCP SR packets, as described in the RTP		information contained in RTCP SR packets, as described in the RTP
	specification [RFC3550]. This basic mechanism can be slow, however,		specification [RFC3550]. This basic mechanism can be slow, however,
	so it is RECOMMENDED that the rapid RTP synchronisation extensions		so it is RECOMMENDED that the rapid RTP synchronisation extensions
	described in [RFC6051] be implemented in addition to RTCP SR-based		described in [RFC6051] be implemented in addition to RTCP SR-based
	synchronisation. The rapid synchronisation extensions use the		synchronisation.
	general RTP header extension mechanism [RFC5285], which requires
	signalling, but are otherwise backwards compatible.		This header extension uses the [RFC5285] generic header extension
			framework, and so needs to be negotiated before it can be used.
	5.2.2. Client-to-Mixer Audio Level		5.2.2. Client-to-Mixer Audio Level
	The Client to Mixer Audio Level extension [RFC6464] is an RTP header		The Client to Mixer Audio Level extension [RFC6464] is an RTP header
	extension used by an endpoint to inform a mixer about the level of		extension used by an endpoint to inform a mixer about the level of
	audio activity in the packet to which the header is attached. This		audio activity in the packet to which the header is attached. This
	enables an RTP middlebox to make mixing or selection decisions		enables an RTP middlebox to make mixing or selection decisions
	without decoding or detailed inspection of the payload, reducing the		without decoding or detailed inspection of the payload, reducing the
	complexity in some types of mixers. It can also save decoding		complexity in some types of mixers. It can also save decoding
	resources in receivers, which can choose to decode only the most		resources in receivers, which can choose to decode only the most
	relevant RTP packet streams based on audio activity levels.		relevant RTP packet streams based on audio activity levels.
	The Client-to-Mixer Audio Level [RFC6464] header extension is		The Client-to-Mixer Audio Level [RFC6464] header extension MUST be
	RECOMMENDED to be implemented. If this header extension is		implemented. It is REQUIRED that implementations are capable of
	implemented, it is REQUIRED that implementations are capable of
	encrypting the header extension according to [RFC6904] since the		encrypting the header extension according to [RFC6904] since the
	information contained in these header extensions can be considered		information contained in these header extensions can be considered
	sensitive. The use of this encryption is RECOMMENDED, however usage		sensitive. The use of this encryption is RECOMMENDED, however usage
	of the encryption can be explicitly disabled through API or		of the encryption can be explicitly disabled through API or
	signalling.		signalling.
			This header extension uses the [RFC5285] generic header extension
			framework, and so needs to be negotiated before it can be used.
	5.2.3. Mixer-to-Client Audio Level		5.2.3. Mixer-to-Client Audio Level
	The Mixer to Client Audio Level header extension [RFC6465] provides		The Mixer to Client Audio Level header extension [RFC6465] provides
	an endpoint with the audio level of the different sources mixed into		an endpoint with the audio level of the different sources mixed into
	a common source stream by a RTP mixer. This enables a user interface		a common source stream by a RTP mixer. This enables a user interface
	to indicate the relative activity level of each session participant,		to indicate the relative activity level of each session participant,
	rather than just being included or not based on the CSRC field. This		rather than just being included or not based on the CSRC field. This
	is a pure optimisation of non critical functions, and is hence		is a pure optimisation of non critical functions, and is hence
	OPTIONAL to implement. If this header extension is implemented, it		OPTIONAL to implement. If this header extension is implemented, it
	is REQUIRED that implementations are capable of encrypting the header		is REQUIRED that implementations are capable of encrypting the header
	extension according to [RFC6904] since the information contained in		extension according to [RFC6904] since the information contained in
	these header extensions can be considered sensitive. It is further		these header extensions can be considered sensitive. It is further
	RECOMMENDED that this encryption is used, unless the encryption has		RECOMMENDED that this encryption is used, unless the encryption has
	been explicitly disabled through API or signalling.		been explicitly disabled through API or signalling.
			This header extension uses the [RFC5285] generic header extension
			framework, and so needs to be negotiated before it can be used.
			5.2.4. Media Stream Identification
			WebRTC endpoints that implement the SDP bundle negotiation extension
			will use the SDP grouping framework 'mid' attribute to identify media
			streams. Such endpoints MUST implement the RTP MID header extension
			described in [I-D.ietf-mmusic-sdp-bundle-negotiation].
			This header extension uses the [RFC5285] generic header extension
			framework, and so needs to be negotiated before it can be used.
			5.2.5. Coordination of Video Orientation
			WebRTC endpoints that send or receive video MUST implement the
			coordination of video orientation (CVO) RTP header extension as
			described in Section 4 of [I-D.ietf-rtcweb-video].
			This header extension uses the [RFC5285] generic header extension
			framework, and so needs to be negotiated before it can be used.
	6. WebRTC Use of RTP: Improving Transport Robustness		6. WebRTC Use of RTP: Improving Transport Robustness
	There are tools that can make RTP packet streams robust against		There are tools that can make RTP packet streams robust against
	packet loss and reduce the impact of loss on media quality. However,		packet loss and reduce the impact of loss on media quality. However,
	they generally add some overhead compared to a non-robust stream.		they generally add some overhead compared to a non-robust stream.
	The overhead needs to be considered, and the aggregate bit-rate MUST		The overhead needs to be considered, and the aggregate bit-rate MUST
	be rate controlled to avoid causing network congestion (see		be rate controlled to avoid causing network congestion (see
	Section 7). As a result, improving robustness might require a lower		Section 7). As a result, improving robustness might require a lower
	base encoding quality, but has the potential to deliver that quality		base encoding quality, but has the potential to deliver that quality
	with fewer errors. The mechanisms described in the following sub-		with fewer errors. The mechanisms described in the following sub-
	skipping to change at page 19, line 30		skipping to change at page 20, line 40
	6.2. Forward Error Correction (FEC)		6.2. Forward Error Correction (FEC)
	The use of Forward Error Correction (FEC) can provide an effective		The use of Forward Error Correction (FEC) can provide an effective
	protection against some degree of packet loss, at the cost of steady		protection against some degree of packet loss, at the cost of steady
	bandwidth overhead. There are several FEC schemes that are defined		bandwidth overhead. There are several FEC schemes that are defined
	for use with RTP. Some of these schemes are specific to a particular		for use with RTP. Some of these schemes are specific to a particular
	RTP payload format, others operate across RTP packets and can be used		RTP payload format, others operate across RTP packets and can be used
	with any payload format. It needs to be noted that using redundant		with any payload format. It needs to be noted that using redundant
	encoding or FEC will lead to increased play out delay, which needs to		encoding or FEC will lead to increased play out delay, which needs to
	be considered when choosing the redundancy or FEC formats and their		be considered when choosing FEC schemes and their parameters.
	respective parameters.
	If an RTP payload format negotiated for use in a RTCPeerConnection
	supports redundant transmission or FEC as a standard feature of that
	payload format, then that support MAY be used in the
	RTCPeerConnection, subject to any appropriate signalling.
	There are several block-based FEC schemes that are designed for use		WebRTC endpoints MUST follow the recommendations for FEC use given in
	with RTP independent of the chosen RTP payload format. At the time		[I-D.uberti-rtcweb-fec]. WebRTC endpoints MAY support other types of
	of this writing there is no consensus on which, if any, of these FEC		FEC, but these MUST be negotiated before they are used.
	schemes is appropriate for use in WebRTC. Accordingly, this memo
	makes no recommendation on the choice of block-based FEC for WebRTC
	use.
	7. WebRTC Use of RTP: Rate Control and Media Adaptation		7. WebRTC Use of RTP: Rate Control and Media Adaptation
	WebRTC will be used in heterogeneous network environments using a		WebRTC will be used in heterogeneous network environments using a
	variety set of link technologies, including both wired and wireless		variety set of link technologies, including both wired and wireless
	links, to interconnect potentially large groups of users around the		links, to interconnect potentially large groups of users around the
	world. As a result, the network paths between users can have widely		world. As a result, the network paths between users can have widely
	varying one-way delays, available bit-rates, load levels, and traffic		varying one-way delays, available bit-rates, load levels, and traffic
	mixtures. Individual end-points can send one or more RTP packet		mixtures. Individual end-points can send one or more RTP packet
	streams to each participant, and there can be several participants.		streams to each participant, and there can be several participants.
	skipping to change at page 39, line 22		skipping to change at page 40, line 22
	Grouping RTCP Reception Statistics and Other Feedback ",		Grouping RTCP Reception Statistics and Other Feedback ",
	draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work		draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
	in progress), July 2013.		in progress), July 2013.
	[I-D.ietf-avtcore-rtp-multi-stream]		[I-D.ietf-avtcore-rtp-multi-stream]
	Lennox, J., Westerlund, M., Wu, W., and C. Perkins,		Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
	"Sending Multiple Media Streams in a Single RTP Session",		"Sending Multiple Media Streams in a Single RTP Session",
	draft-ietf-avtcore-rtp-multi-stream-06 (work in progress),		draft-ietf-avtcore-rtp-multi-stream-06 (work in progress),
	October 2014.		October 2014.
			[I-D.ietf-mmusic-sdp-bundle-negotiation]
			Holmberg, C., Alvestrand, H., and C. Jennings,
			"Negotiating Media Multiplexing Using the Session
			Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
			negotiation-12 (work in progress), October 2014.
			[I-D.ietf-rtcweb-audio]
			Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
			Requirements", draft-ietf-rtcweb-audio-07 (work in
			progress), October 2014.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-10 (work in progress), July 2014.		rtcweb-security-arch-10 (work in progress), July 2014.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-07 (work in progress), July 2014.		ietf-rtcweb-security-07 (work in progress), July 2014.
			[I-D.ietf-rtcweb-video]
			Roach, A., "WebRTC Video Processing and Codec
			Requirements", draft-ietf-rtcweb-video-02 (work in
			progress), October 2014.
			[I-D.uberti-rtcweb-fec]
			Uberti, J., "WebRTC Forward Error Correction
			Requirements", draft-uberti-rtcweb-fec-00 (work in
			progress), October 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP		[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
	Payload Format Specifications", BCP 36, RFC 2736, December		Payload Format Specifications", BCP 36, RFC 2736, December
	1999.		1999.
	[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.
	skipping to change at page 41, line 38		skipping to change at page 43, line 11
	16.2. Informative References		16.2. Informative References
	[I-D.ietf-avtcore-multiplex-guidelines]		[I-D.ietf-avtcore-multiplex-guidelines]
	Westerlund, M., Perkins, C., and H. Alvestrand,		Westerlund, M., Perkins, C., and H. Alvestrand,
	"Guidelines for using the Multiplexing Features of RTP to		"Guidelines for using the Multiplexing Features of RTP to
	Support Multiple Media Streams", draft-ietf-avtcore-		Support Multiple Media Streams", draft-ietf-avtcore-
	multiplex-guidelines-03 (work in progress), October 2014.		multiplex-guidelines-03 (work in progress), October 2014.
	[I-D.ietf-avtcore-rtp-topologies-update]		[I-D.ietf-avtcore-rtp-topologies-update]
	Westerlund, M. and S. Wenger, "RTP Topologies", draft-		Westerlund, M. and S. Wenger, "RTP Topologies", draft-
	ietf-avtcore-rtp-topologies-update-04 (work in progress),		ietf-avtcore-rtp-topologies-update-05 (work in progress),
	August 2014.		November 2014.
	[I-D.ietf-avtext-rtp-grouping-taxonomy]		[I-D.ietf-avtext-rtp-grouping-taxonomy]
	Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,		Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
	"A Taxonomy of Grouping Semantics and Mechanisms for Real-		"A Taxonomy of Grouping Semantics and Mechanisms for Real-
	Time Transport Protocol (RTP) Sources", draft-ietf-avtext-		Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
	rtp-grouping-taxonomy-02 (work in progress), June 2014.		rtp-grouping-taxonomy-03 (work in progress), November
			2014.
	[I-D.ietf-mmusic-msid]		[I-D.ietf-mmusic-msid]
	Alvestrand, H., "WebRTC MediaStream Identification in the		Alvestrand, H., "WebRTC MediaStream Identification in the
	Session Description Protocol", draft-ietf-mmusic-msid-07		Session Description Protocol", draft-ietf-mmusic-msid-07
	(work in progress), October 2014.		(work in progress), October 2014.
	[I-D.ietf-mmusic-sdp-bundle-negotiation]		[I-D.ietf-mmusic-sdp-bundle-negotiation]
	Holmberg, C., Alvestrand, H., and C. Jennings,		Holmberg, C., Alvestrand, H., and C. Jennings,
	"Negotiating Media Multiplexing Using the Session		"Negotiating Media Multiplexing Using the Session
	Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-		Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
	negotiation-12 (work in progress), October 2014.		negotiation-12 (work in progress), October 2014.
	[I-D.ietf-payload-rtp-howto]		[I-D.ietf-payload-rtp-howto]
	Westerlund, M., "How to Write an RTP Payload Format",		Westerlund, M., "How to Write an RTP Payload Format",
	draft-ietf-payload-rtp-howto-13 (work in progress),		draft-ietf-payload-rtp-howto-13 (work in progress),
	January 2014.		January 2014.
	[I-D.ietf-rmcat-cc-requirements]		[I-D.ietf-rmcat-cc-requirements]
	Jesup, R. and Z. Sarker, "Congestion Control Requirements		Jesup, R. and Z. Sarker, "Congestion Control Requirements
	for Interactive Real-Time Media", draft-ietf-rmcat-cc-		for Interactive Real-Time Media", draft-ietf-rmcat-cc-
	requirements-07 (work in progress), October 2014.		requirements-08 (work in progress), November 2014.
	[I-D.ietf-rtcweb-audio]
	Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
	Requirements", draft-ietf-rtcweb-audio-07 (work in
	progress), October 2014.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-12		Browser-based Applications", draft-ietf-rtcweb-overview-12
	(work in progress), October 2014.		(work in progress), October 2014.
	[I-D.ietf-rtcweb-use-cases-and-requirements]		[I-D.ietf-rtcweb-use-cases-and-requirements]
	Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use-cases and Requirements", draft-		Time Communication Use-cases and Requirements", draft-
	ietf-rtcweb-use-cases-and-requirements-14 (work in		ietf-rtcweb-use-cases-and-requirements-14 (work in
	progress), February 2014.		progress), February 2014.
	[I-D.ietf-tsvwg-rtcweb-qos]		[I-D.ietf-tsvwg-rtcweb-qos]
	Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.		Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
	Polk, "DSCP and other packet markings for RTCWeb QoS",		Polk, "DSCP and other packet markings for RTCWeb QoS",
	draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June		draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),
	2014.		November 2014.
	[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control		[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
	Protocol Extended Reports (RTCP XR)", RFC 3611, November		Protocol Extended Reports (RTCP XR)", RFC 3611, November
	2003.		2003.
	[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient		[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
	Stream Loss-Tolerant Authentication (TESLA) in the Secure		Stream Loss-Tolerant Authentication (TESLA) in the Secure
	Real-time Transport Protocol (SRTP)", RFC 4383, February		Real-time Transport Protocol (SRTP)", RFC 4383, February
	2006.		2006.
End of changes. 25 change blocks.
	80 lines changed or deleted		122 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/