draft-ietf-rtcweb-rtp-usage-23.txt		draft-ietf-rtcweb-rtp-usage-24.txt
	RTCWEB Working Group C. S. Perkins		RTCWEB Working Group C. Perkins
	Internet-Draft University of Glasgow		Internet-Draft University of Glasgow
	Intended status: Standards Track M. Westerlund		Intended status: Standards Track M. Westerlund
	Expires: October 01, 2015 Ericsson		Expires: November 30, 2015 Ericsson
	J. Ott		J. Ott
	Aalto University		Aalto University
	March 30, 2015		May 29, 2015
	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-23		draft-ietf-rtcweb-rtp-usage-24
	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 October 01, 2015.		This Internet-Draft will expire on November 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 10		4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9
	4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10		4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10
	4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11		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) . . . . . . . 12		4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11
	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) . . . . . . . . . . . . . 16		5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 15
	5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16		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 . . . . . . . . . . . . . . . . . . . . 17		5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 16
	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 . . . . . . . . . . . . . 18		5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18
	5.2.4. Media Stream Identification . . . . . . . . . . . . . 18		5.2.4. Media Stream Identification . . . . . . . . . . . . . 18
	5.2.5. Coordination of Video Orientation . . . . . . . . . . 18		5.2.5. Coordination of Video Orientation . . . . . . . . . . 18
	6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19		6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 18
	6.1. Negative Acknowledgements and RTP Retransmission . . . . 19		6.1. Negative Acknowledgements and RTP Retransmission . . . . 19
	6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20		6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20
	7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20		7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20
	7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21		7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21
	7.2. Congestion Control Interoperability and Legacy Systems . 22		7.2. Congestion Control Interoperability and Legacy Systems . 21
	8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 23		8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22
	9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23		9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22
	10. Signalling Considerations . . . . . . . . . . . . . . . . . . 24		10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23
	11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25		11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24
	12. RTP Implementation Considerations . . . . . . . . . . . . . . 27		12. RTP Implementation Considerations . . . . . . . . . . . . . . 27
	12.1. Configuration and Use of RTP Sessions . . . . . . . . . 28		12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27
	12.1.1. Use of Multiple Media Sources Within an RTP Session 28		12.1.1. Use of Multiple Media Sources Within an RTP Session 27
	12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 29		12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28
	12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33		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 . . . . . . . . . . . . . . . . . . . . . 35		Identification . . . . . . . . . . . . . . . . . . . . . 35
	12.2.1. Media Source Identification . . . . . . . . . . . . 35		12.2.1. Media Source Identification . . . . . . . . . . . . 35
	12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36		12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36
	12.2.3. Media Synchronisation Context . . . . . . . . . . . 37		12.2.3. Media Synchronisation Context . . . . . . . . . . . 37
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 38		13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	16.1. Normative References . . . . . . . . . . . . . . . . . . 40		16.1. Normative References . . . . . . . . . . . . . . . . . . 39
	16.2. Informative References . . . . . . . . . . . . . . . . . 43		16.2. Informative References . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	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 4, line 29		skipping to change at page 4, line 29
	development of the WebRTC framework provides an opportunity to review		development of the WebRTC framework provides an opportunity to review
	the available RTP features and extensions, and to define a common		the available RTP features and extensions, and to define a common
	baseline RTP feature set for all WebRTC Endpoints. This builds on		baseline RTP feature set for all WebRTC Endpoints. This builds on
	the past 20 years development of RTP to mandate the use of extensions		the past 20 years development of RTP to mandate the use of extensions
	that have shown widespread utility, while still remaining compatible		that have shown widespread utility, while still remaining compatible
	with the wide installed base of RTP implementations where possible.		with the wide installed base of RTP implementations where possible.
	RTP and RTCP extensions that are not discussed in this document can		RTP and RTCP extensions that are not discussed in this document can
	be implemented by WebRTC Endpoints if they are beneficial for new use		be implemented by WebRTC Endpoints if they are beneficial for new use
	cases. However, they are not necessary to address the WebRTC use		cases. However, they are not necessary to address the WebRTC use
	cases and requirements identified in		cases and requirements identified in [RFC7478].
	[I-D.ietf-rtcweb-use-cases-and-requirements].
	While the baseline set of RTP features and extensions defined in this		While the baseline set of RTP features and extensions defined in this
	memo is targeted at the requirements of the WebRTC framework, it is		memo is targeted at the requirements of the WebRTC framework, it is
	expected to be broadly useful for other conferencing-related uses of		expected to be broadly useful for other conferencing-related uses of
	RTP. In particular, it is likely that this set of RTP features and		RTP. In particular, it is likely that this set of RTP features and
	extensions will be appropriate for other desktop or mobile video		extensions will be appropriate for other desktop or mobile video
	conferencing systems, or for room-based high-quality telepresence		conferencing systems, or for room-based high-quality telepresence
	applications.		applications.
	3. Terminology		3. Terminology
	skipping to change at page 7, line 11		skipping to change at page 6, line 52
	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
	media bandwidth, and for configuring the fraction of the RTCP		media bandwidth, and for configuring the fraction of the RTCP
	bandwidth allocated to senders, e.g., using the SDP "b=" line		bandwidth allocated to senders, e.g., using the SDP "b=" line
	[RFC4566][RFC3556].		[RFC4566][RFC3556].
	o Support for the reduced minimum RTCP reporting interval described		o Support for the reduced minimum RTCP reporting interval described
	in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced		in Section 6.2 of [RFC3550]. When using the reduced minimum RTCP
	minimum RTCP reporting interval, the fixed (non-reduced) minimum		reporting interval, the fixed (non-reduced) minimum interval MUST
	interval MUST be used when calculating the participant timeout		be used when calculating the participant timeout interval (see
	interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay		Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending
	before sending the initial compound RTCP packet can be set to zero		the initial compound RTCP packet can be set to zero (see
	(see Section 6.2 of [RFC3550] as updated by		Section 6.2 of [RFC3550] as updated by
	[I-D.ietf-avtcore-rtp-multi-stream]).		[I-D.ietf-avtcore-rtp-multi-stream]).
	o Support for discontinuous transmission. RTP allows endpoints to		o Support for discontinuous transmission. RTP allows endpoints to
	pause and resume transmission at any time. When resuming, the RTP		pause and resume transmission at any time. When resuming, the RTP
	sequence number will increase by one, as usual, while the increase		sequence number will increase by one, as usual, while the increase
	in the RTP timestamp value will depend on the duration of the		in the RTP timestamp value will depend on the duration of the
	pause. Discontinuous transmission is most commonly used with some		pause. Discontinuous transmission is most commonly used with some
	audio payload formats, but is not audio specific, and can be used		audio payload formats, but is not audio specific, and can be used
	with any RTP payload format.		with any RTP payload format.
	skipping to change at page 16, line 47		skipping to change at page 16, line 36
	temporal and spatial resolution, for example to prefer high spatial		temporal and spatial resolution, for example to prefer high spatial
	image quality but low frame rate. Support for TSTR requests and		image quality but low frame rate. Support for TSTR requests and
	notifications is OPTIONAL.		notifications is OPTIONAL.
	5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR)		5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR)
	The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of		The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of
	the Codec Control Messages [RFC5104]. This request and its		the Codec Control Messages [RFC5104]. This request and its
	notification message are used by a media receiver to inform the		notification message are used by a media receiver to inform the
	sending party that there is a current limitation on the amount of		sending party that there is a current limitation on the amount of
	bandwidth available to this receiver. This can be various reasons		bandwidth available to this receiver. There can be various reasons
	for this: for example, an RTP mixer can use this message to limit the		for this: for example, an RTP mixer can use this message to limit the
	media rate of the sender being forwarded by the mixer (without doing		media rate of the sender being forwarded by the mixer (without doing
	media transcoding) to fit the bottlenecks existing towards the other		media transcoding) to fit the bottlenecks existing towards the other
	session participants. WebRTC Endpoints that are sending media are		session participants. WebRTC Endpoints that are sending media are
	REQUIRED to implement support for TMMBR messages, and MUST follow		REQUIRED to implement support for TMMBR messages, and MUST follow
	bandwidth limitations set by a TMMBR message received for their SSRC.		bandwidth limitations set by a TMMBR message received for their SSRC.
	The sending of TMMBR requests is OPTIONAL.		The sending of TMMBR requests is OPTIONAL.
	5.2. Header Extensions		5.2. Header Extensions
	skipping to change at page 21, line 31		skipping to change at page 21, line 8
	bandwidth, or it might be competition with other traffic on the link		bandwidth, or it might be competition with other traffic on the link
	(this can be non-WebRTC traffic, traffic due to other WebRTC flows,		(this can be non-WebRTC traffic, traffic due to other WebRTC flows,
	or even competition with other WebRTC flows in the same session).		or even competition with other WebRTC flows in the same session).
	An effective media congestion control algorithm is therefore an		An effective media congestion control algorithm is therefore an
	essential part of the WebRTC framework. However, at the time of this		essential part of the WebRTC framework. However, at the time of this
	writing, there is no standard congestion control algorithm that can		writing, there is no standard congestion control algorithm that can
	be used for interactive media applications such as WebRTC's flows.		be used for interactive media applications such as WebRTC's flows.
	Some requirements for congestion control algorithms for		Some requirements for congestion control algorithms for
	RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements].		RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements].
	A future version of this memo will mandate the use of a congestion		If a standardized congestion control algorithm that satisfies these
	control algorithm that satisfies these requirements.		requirements is developed in the future, this memo will need to be be
			updated to mandate its use.
	7.1. Boundary Conditions and Circuit Breakers		7.1. Boundary Conditions and Circuit Breakers
	WebRTC Endpoints MUST implement the RTP circuit breaker algorithm		WebRTC Endpoints MUST implement the RTP circuit breaker algorithm
	that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The		that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The
	RTP circuit breaker is designed to enable applications to recognise		RTP circuit breaker is designed to enable applications to recognise
	and react to situations of extreme network congestion. However,		and react to situations of extreme network congestion. However,
	since the RTP circuit breaker might not be triggered until congestion		since the RTP circuit breaker might not be triggered until congestion
	becomes extreme, it cannot be considered a substitute for congestion		becomes extreme, it cannot be considered a substitute for congestion
	control, and applications MUST also implement congestion control to		control, and applications MUST also implement congestion control to
	skipping to change at page 22, line 10		skipping to change at page 21, line 36
	boundaries to which the media bit-rate will conform. The choice of		boundaries to which the media bit-rate will conform. The choice of
	media codecs provides upper- and lower-bounds on the supported bit-		media codecs provides upper- and lower-bounds on the supported bit-
	rates that the application can utilise to provide useful quality, and		rates that the application can utilise to provide useful quality, and
	the packetisation choices that exist. In addition, the signalling		the packetisation choices that exist. In addition, the signalling
	channel can establish maximum media bit-rate boundaries using, for		channel can establish maximum media bit-rate boundaries using, for
	example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF Temporary		example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF Temporary
	Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of		Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of
	this memo). Signalled bandwidth limitations, such as SDP "b=AS:" or		this memo). Signalled bandwidth limitations, such as SDP "b=AS:" or
	"b=CT:" lines received from the peer, MUST be followed when sending		"b=CT:" lines received from the peer, MUST be followed when sending
	RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal		RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal
	its bandwidth limitations, these limitations have to be based on		its bandwidth limitations. These limitations have to be based on
	known bandwidth limitations, for example the capacity of the edge		known bandwidth limitations, for example the capacity of the edge
	links.		links.
	7.2. Congestion Control Interoperability and Legacy Systems		7.2. Congestion Control Interoperability and Legacy Systems
	All endpoints that wish to interwork with WebRTC MUST implement RTCP		All endpoints that wish to interwork with WebRTC MUST implement RTCP
	and provide congestion feedback via the defined RTCP reporting		and provide congestion feedback via the defined RTCP reporting
	mechanisms.		mechanisms.
	When interworking with legacy implementations that support RTCP using		When interworking with legacy implementations that support RTCP using
	skipping to change at page 24, line 33		skipping to change at page 23, line 44
	signalled. Interworking functions might transform this into the		signalled. Interworking functions might transform this into the
	RTP/SAVP profile for a legacy use case, by indicating to the		RTP/SAVP profile for a legacy use case, by indicating to the
	WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr-		WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr-
	int value of 4 seconds.		int value of 4 seconds.
	Transport Information: Source and destination IP address(s) and		Transport Information: Source and destination IP address(s) and
	ports for RTP and RTCP MUST be signalled for each RTP session. In		ports for RTP and RTCP MUST be signalled for each RTP session. In
	WebRTC these transport addresses will be provided by ICE [RFC5245]		WebRTC these transport addresses will be provided by ICE [RFC5245]
	that signals candidates and arrives at nominated candidate address		that signals candidates and arrives at nominated candidate address
	pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such		pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such
	that a single port, i.e. transport-layer flow, is used for RTP		that a single port, i.e. transport-layer flow, is used for RTP and
	and RTCP flows, this MUST be signalled (see Section 4.5).		RTCP flows, this MUST be signalled (see Section 4.5).
	RTP Payload Types, media formats, and format parameters: The mapping		RTP Payload Types, media formats, and format parameters: The mapping
	between media type names (and hence the RTP payload formats to be		between media type names (and hence the RTP payload formats to be
	used), and the RTP payload type numbers MUST be signalled. Each		used), and the RTP payload type numbers MUST be signalled. Each
	media type MAY also have a number of media type parameters that		media type MAY also have a number of media type parameters that
	MUST also be signalled to configure the codec and RTP payload		MUST also be signalled to configure the codec and RTP payload
	format (the "a=fmtp:" line from SDP). Section 4.3 of this memo		format (the "a=fmtp:" line from SDP). Section 4.3 of this memo
	discusses requirements for uniqueness of payload types.		discusses requirements for uniqueness of payload types.
	RTP Extensions: The use of any additional RTP header extensions and		RTP Extensions: The use of any additional RTP header extensions and
	skipping to change at page 25, line 25		skipping to change at page 24, line 27
	RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the		RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the
	end-points will be necessary. This SHALL be done as described in		end-points will be necessary. This SHALL be done as described in
	"Session Description Protocol (SDP) Bandwidth Modifiers for RTP		"Session Description Protocol (SDP) Bandwidth Modifiers for RTP
	Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or		Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or
	something semantically equivalent. This also ensures that the		something semantically equivalent. This also ensures that the
	end-points have a common view of the RTCP bandwidth. A common		end-points have a common view of the RTCP bandwidth. A common
	RTCP bandwidth is important as a too different view of the		RTCP bandwidth is important as a too different view of the
	bandwidths can lead to failure to interoperate.		bandwidths can lead to failure to interoperate.
	These parameters are often expressed in SDP messages conveyed within		These parameters are often expressed in SDP messages conveyed within
	an offer/answer exchange. RTP does not depend on SDP or on the offer		an offer/answer exchange. RTP does not depend on SDP or on the
	/answer model, but does require all the necessary parameters to be		offer/answer model, but does require all the necessary parameters to
	agreed upon, and provided to the RTP implementation. Note that in		be agreed upon, and provided to the RTP implementation. Note that in
	WebRTC it will depend on the signalling model and API how these		WebRTC it will depend on the signalling model and API how these
	parameters need to be configured but they will be need to either be		parameters need to be configured but they will be need to either be
	set in the API or explicitly signalled between the peers.		set in the API or explicitly signalled between the peers.
	11. WebRTC API Considerations		11. WebRTC API Considerations
	The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and		The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and
	Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses		Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses
	the concept of a MediaStream that consists of zero or more		the concept of a MediaStream that consists of zero or more
	MediaStreamTracks. A MediaStreamTrack is an individual stream of		MediaStreamTracks. A MediaStreamTrack is an individual stream of
	skipping to change at page 26, line 48		skipping to change at page 26, line 6
	RTCPeerConnection instances, as specified in Section 4.9. Having two		RTCPeerConnection instances, as specified in Section 4.9. Having two
	communication sessions with the same CNAME could enable tracking of a		communication sessions with the same CNAME could enable tracking of a
	user or device across different services (see Section 4.4.1 of		user or device across different services (see Section 4.4.1 of
	[I-D.ietf-rtcweb-security] for details). A web application can		[I-D.ietf-rtcweb-security] for details). A web application can
	request that the CNAMEs used in different RTCPeerConnections (within		request that the CNAMEs used in different RTCPeerConnections (within
	a same-orign context) be the same, this allows for synchronization of		a same-orign context) be the same, this allows for synchronization of
	the endpoint's RTP packet streams across the different		the endpoint's RTP packet streams across the different
	RTCPeerConnections.		RTCPeerConnections.
	Note: this doesn't result in a tracking issue, since the creation		Note: this doesn't result in a tracking issue, since the creation
	of matching CNAMEs depends on existing tracking.		of matching CNAMEs depends on existing tracking within a single
			origin.
	The above will currently force a WebRTC Endpoint that receives a		The above will currently force a WebRTC Endpoint that receives a
	MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing		MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing
	on any RTCPeerConnection to perform resynchronisation of the stream.		on any RTCPeerConnection to perform resynchronisation of the stream.
			Since the sending party needs to change the CNAME to the one it uses,
	This, as the sending party needs to change the CNAME to the one it		this implies it has to use a local system clock as timebase for the
	uses, which implies that the sender has to use a local system clock		synchronisation. Thus, the relative relation between the timebase of
	as timebase for the synchronisation. Thus, the relative relation		the incoming stream and the system sending out needs to be defined.
	between the timebase of the incoming stream and the system sending		This relation also needs monitoring for clock drift and likely
	out needs to defined. This relation also needs monitoring for clock		adjustments of the synchronisation. The sending entity is also
	drift and likely adjustments of the synchronisation. The sending		responsible for congestion control for its sent streams. In cases of
	entity is also responsible for congestion control for its sent		packet loss the loss of incoming data also needs to be handled. This
	streams. In cases of packet loss the loss of incoming data also		leads to the observation that the method that is least likely to
	needs to be handled. This leads to the observation that the method		cause issues or interruptions in the outgoing source packet stream is
	that is least likely to cause issues or interruptions in the outgoing		a model of full decoding, including repair etc., followed by encoding
	source packet stream is a model of full decoding, including repair		of the media again into the outgoing packet stream. Optimisations of
	etc., followed by encoding of the media again into the outgoing		this method is clearly possible and implementation specific.
	packet stream. Optimisations of this method is clearly possible and
	implementation specific.
	A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks,		A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks,
	where each of different MediaStreamTracks (and their sets of		where each of different MediaStreamTracks (and their sets of
	associated packet streams) uses different CNAMEs. However,		associated packet streams) uses different CNAMEs. However,
	MediaStreamTracks that are received with different CNAMEs have no		MediaStreamTracks that are received with different CNAMEs have no
	defined synchronisation.		defined synchronisation.
	Note: The motivation for supporting reception of multiple CNAMEs		Note: The motivation for supporting reception of multiple CNAMEs
	is to allow for forward compatibility with any future changes that		is to allow for forward compatibility with any future changes that
	enables more efficient stream handling when end-points relay/		enable more efficient stream handling when end-points relay/
	forward streams. It also ensures that end-points can interoperate		forward streams. It also ensures that end-points can interoperate
	with certain types of multi-stream middleboxes or end-points that		with certain types of multi-stream middleboxes or end-points that
	are not WebRTC.		are not WebRTC.
	The binding between the WebRTC MediaStreams, MediaStreamTracks and		The binding between the WebRTC MediaStreams, MediaStreamTracks and
	the SSRC is done as specified in "Cross Session Stream Identification		the SSRC is done as specified in "Cross Session Stream Identification
	in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This		in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This
	document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to		document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to
	map unknown source packet stream SSRCs to MediaStreamTracks and		map unknown source packet stream SSRCs to MediaStreamTracks and
	MediaStreams. This later is relevant to handle some cases of legacy		MediaStreams. This later is relevant to handle some cases of legacy
	skipping to change at page 34, line 26		skipping to change at page 33, line 36
	streams is dependent on the media type and codec used, in regards to		streams is dependent on the media type and codec used, in regards to
	how robust that codec is to packet loss. However, a default policy		how robust that codec is to packet loss. However, a default policy
	might to be to use the same priority for redundant RTP packet stream		might to be to use the same priority for redundant RTP packet stream
	as for the source RTP packet stream.		as for the source RTP packet stream.
	Secondly, the network can prioritize transport-layer flows and sub-		Secondly, the network can prioritize transport-layer flows and sub-
	flows, including RTP packet streams. Typically, differential		flows, including RTP packet streams. Typically, differential
	treatment includes two steps, the first being identifying whether an		treatment includes two steps, the first being identifying whether an
	IP packet belongs to a class that has to be treated differently, the		IP packet belongs to a class that has to be treated differently, the
	second consisting of the actual mechanism to prioritize packets.		second consisting of the actual mechanism to prioritize packets.
	This is done according to three methods:		Three common methods for classifying IP packets are:
	DiffServ: The end-point marks a packet with a DiffServ code point to		DiffServ: The end-point marks a packet with a DiffServ code point to
	indicate to the network that the packet belongs to a particular		indicate to the network that the packet belongs to a particular
	class.		class.
	Flow based: Packets that need to be given a particular treatment are		Flow based: Packets that need to be given a particular treatment are
	identified using a combination of IP and port address.		identified using a combination of IP and port address.
	Deep Packet Inspection: A network classifier (DPI) inspects the		Deep Packet Inspection: A network classifier (DPI) inspects the
	packet and tries to determine if the packet represents a		packet and tries to determine if the packet represents a
	particular application and type that is to be prioritized.		particular application and type that is to be prioritized.
	Flow-based differentiation will provide the same treatment to all		Flow-based differentiation will provide the same treatment to all
	packets within a transport-layer flow, i.e., relative prioritization		packets within a transport-layer flow, i.e., relative prioritization
	is not possible. Moreover, if the resources are limited it might not		is not possible. Moreover, if the resources are limited it might not
	be possible to provide differential treatment compared to best-effort		be possible to provide differential treatment compared to best-effort
	for all the RTP packet streams used in a WebRTC session. When flow-		for all the RTP packet streams used in a WebRTC session. The use of
	based differentiation is available, the WebRTC Endpoint needs to know		flow-based differentiation needs to be coordinated between the WebRTC
	about it so that it can provide the separation of the RTP packet		system and the network(s). The WebRTC endpoint needs to know that
	streams onto different UDP flows to enable a more granular usage of		flow-based differentiation might be used to provide the separation of
	flow based differentiation. That way at least providing different		the RTP packet streams onto different UDP flows to enable a more
	prioritization of audio and video if desired by application.		granular usage of flow based differentiation. The used flows, their
			5-tuples and prioritization will need to be communicated to the
			network so that it can identify the flows correctly to enable
			prioritization. No specific protocol support for this is specified.
	DiffServ assumes that either the end-point or a classifier can mark		DiffServ assumes that either the end-point or a classifier can mark
	the packets with an appropriate DSCP so that the packets are treated		the packets with an appropriate DSCP so that the packets are treated
	according to that marking. If the end-point is to mark the traffic		according to that marking. If the end-point is to mark the traffic
	two requirements arise in the WebRTC context: 1) The WebRTC Endpoint		two requirements arise in the WebRTC context: 1) The WebRTC Endpoint
	has to know which DSCP to use and that it can use them on some set of		has to know which DSCP to use and that it can use them on some set of
	RTP packet streams. 2) The information needs to be propagated to the		RTP packet streams. 2) The information needs to be propagated to the
	operating system when transmitting the packet. Details of this		operating system when transmitting the packet. Details of this
	process are outside the scope of this memo and are further discussed		process are outside the scope of this memo and are further discussed
	in "DSCP and other packet markings for RTCWeb QoS"		in "DSCP and other packet markings for RTCWeb QoS"
	[I-D.ietf-tsvwg-rtcweb-qos].		[I-D.ietf-tsvwg-rtcweb-qos].
			Deep Packet Inspectors will, despite the SRTP media encryption, still
			be fairly capable at classifying the RTP streams. The reason is that
			SRTP leaves the first 12 bytes of the RTP header unencrypted. This
			enables easy RTP stream identification using the SSRC and provides
			the classifier with useful information that can be correlated to
			determine for example the stream's media type. Using packet sizes,
			reception times, packet inter-spacing, RTP timestamp increments and
			sequence numbers, fairly reliable classifications are achieved.
	For packet based marking schemes it might be possible to mark		For packet based marking schemes it might be possible to mark
	individual RTP packets differently based on the relative priority of		individual RTP packets differently based on the relative priority of
	the RTP payload. For example video codecs that have I, P, and B		the RTP payload. For example video codecs that have I, P, and B
	pictures could prioritise any payloads carrying only B frames less,		pictures could prioritise any payloads carrying only B frames less,
	as these are less damaging to loose. However, depending on the QoS		as these are less damaging to loose. However, depending on the QoS
	mechanism and what markings that are applied, this can result in not		mechanism and what markings that are applied, this can result in not
	only different packet drop probabilities but also packet reordering,		only different packet drop probabilities but also packet reordering,
	see [I-D.ietf-tsvwg-rtcweb-qos] for further discussion. As a default		see [I-D.ietf-tsvwg-rtcweb-qos] for further discussion. As a default
	policy all RTP packets related to a RTP packet stream ought to be		policy all RTP packets related to a RTP packet stream ought to be
	provided with the same prioritization; per-packet prioritization is		provided with the same prioritization; per-packet prioritization is
	skipping to change at page 39, line 32		skipping to change at page 39, line 8
	media data rate), or that configure the RTCP reporting interval small		media data rate), or that configure the RTCP reporting interval small
	enough that the RTCP bandwidth would exceed the media bandwidth.		enough that the RTCP bandwidth would exceed the media bandwidth.
	The guidelines in [RFC6562] apply when using variable bit rate (VBR)		The guidelines in [RFC6562] apply when using variable bit rate (VBR)
	audio codecs such as Opus (see Section 4.3 for discussion of mandated		audio codecs such as Opus (see Section 4.3 for discussion of mandated
	audio codecs). The guidelines in [RFC6562] also apply, but are of		audio codecs). The guidelines in [RFC6562] also apply, but are of
	lesser importance, when using the client-to-mixer audio level header		lesser importance, when using the client-to-mixer audio level header
	extensions (Section 5.2.2) or the mixer-to-client audio level header		extensions (Section 5.2.2) or the mixer-to-client audio level header
	extensions (Section 5.2.3). The use of the encryption of the header		extensions (Section 5.2.3). The use of the encryption of the header
	extensions are RECOMMENDED, unless there are known reasons, like RTP		extensions are RECOMMENDED, unless there are known reasons, like RTP
	middleboxes or third party monitoring that will greatly benefit from		middleboxes performing voice activity based source selection or third
	the information, and this has been expressed using API or signalling.		party monitoring that will greatly benefit from the information, and
	If further evidence are produced to show that information leakage is		this has been expressed using API or signalling. If further evidence
	significant from audio level indications, then use of encryption		are produced to show that information leakage is significant from
	needs to be mandated at that time.		audio level indications, then use of encryption needs to be mandated
			at that time.
	14. IANA Considerations		14. IANA Considerations
	This memo makes no request of IANA.		This memo makes no request of IANA.
	Note to RFC Editor: this section is to be removed on publication as		Note to RFC Editor: this section is to be removed on publication as
	an RFC.		an RFC.
	15. Acknowledgements		15. Acknowledgements
	The authors would like to thank Bernard Aboba, Harald Alvestrand,		The authors would like to thank Bernard Aboba, Harald Alvestrand,
	Cary Bran, Ben Campbell, Charles Eckel, Alex Eleftheriadis, Christian		Cary Bran, Ben Campbell, Alissa Cooper, Charles Eckel, Alex
	Groves, Cullen Jennings, Olle Johansson, Suhas Nandakumar, Dan		Eleftheriadis, Christian Groves, Cullen Jennings, Olle Johansson,
	Romascanu, Jim Spring, Martin Thomson, and the other members of the		Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin Thomson, and the
	IETF RTCWEB working group for their valuable feedback.		other members of the IETF RTCWEB working group for their valuable
			feedback.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[I-D.ietf-avtcore-multi-media-rtp-session]		[I-D.ietf-avtcore-multi-media-rtp-session]
	Westerlund, M., Perkins, C., and J. Lennox, "Sending		Westerlund, M., Perkins, C., and J. Lennox, "Sending
	Multiple Types of Media in a Single RTP Session", draft-		Multiple Types of Media in a Single RTP Session", draft-
	ietf-avtcore-multi-media-rtp-session-07 (work in		ietf-avtcore-multi-media-rtp-session-07 (work in
	progress), March 2015.		progress), March 2015.
	[I-D.ietf-avtcore-rtp-circuit-breakers]		[I-D.ietf-avtcore-rtp-circuit-breakers]
	Perkins, C. and V. Singh, "Multimedia Congestion Control:		Perkins, C. and V. Singh, "Multimedia Congestion Control:
	Circuit Breakers for Unicast RTP Sessions", draft-ietf-		Circuit Breakers for Unicast RTP Sessions", draft-ietf-
	avtcore-rtp-circuit-breakers-10 (work in progress), March		avtcore-rtp-circuit-breakers-10 (work in progress), March
	2015.		2015.
	[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
	Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	"Sending Multiple Media Streams in a Single RTP Session:
	Grouping RTCP Reception Statistics and Other Feedback ",
	draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
	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-07 (work in progress),		draft-ietf-avtcore-rtp-multi-stream-07 (work in progress),
	March 2015.		March 2015.
			[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
			Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
			"Sending Multiple Media Streams in a Single RTP Session:
			Grouping RTCP Reception Statistics and Other Feedback",
			draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work
			in progress), February 2015.
	[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-19 (work in progress), March 2015.		negotiation-19 (work in progress), March 2015.
	[I-D.ietf-rtcweb-audio]		[I-D.ietf-rtcweb-audio]
	Valin, J. and C. Bran, "WebRTC Audio Codec and Processing		Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
	Requirements", draft-ietf-rtcweb-audio-07 (work in		Requirements", draft-ietf-rtcweb-audio-08 (work in
	progress), October 2014.		progress), April 2015.
	[I-D.ietf-rtcweb-fec]		[I-D.ietf-rtcweb-fec]
	Uberti, J., "WebRTC Forward Error Correction		Uberti, J., "WebRTC Forward Error Correction
	Requirements", draft-ietf-rtcweb-fec-01 (work in		Requirements", draft-ietf-rtcweb-fec-01 (work in
	progress), March 2015.		progress), March 2015.
	[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-11 (work in progress), March 2015.
	[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-08 (work in progress), February 2015.		ietf-rtcweb-security-08 (work in progress), February 2015.
			[I-D.ietf-rtcweb-security-arch]
			Rescorla, E., "WebRTC Security Architecture", draft-ietf-
			rtcweb-security-arch-11 (work in progress), March 2015.
	[I-D.ietf-rtcweb-video]		[I-D.ietf-rtcweb-video]
	Roach, A., "WebRTC Video Processing and Codec		Roach, A., "WebRTC Video Processing and Codec
	Requirements", draft-ietf-rtcweb-video-05 (work in		Requirements", draft-ietf-rtcweb-video-05 (work in
	progress), March 2015.		progress), March 2015.
	[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
	skipping to change at page 43, line 25		skipping to change at page 42, line 49
	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-06 (work in progress),		ietf-avtcore-rtp-topologies-update-07 (work in progress),
	March 2015.		April 2015.
	[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., Salgueiro, G., and
	"A Taxonomy of Grouping Semantics and Mechanisms for Real-		B. Burman, "A Taxonomy of Grouping Semantics and
	Time Transport Protocol (RTP) Sources", draft-ietf-avtext-		Mechanisms for Real-Time Transport Protocol (RTP)
	rtp-grouping-taxonomy-06 (work in progress), March 2015.		Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work
			in progress), March 2015.
	[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-08		Session Description Protocol", draft-ietf-mmusic-msid-10
	(work in progress), February 2015.		(work in progress), April 2015.
	[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-19 (work in progress), March 2015.
	[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-14 (work in progress), May
	January 2014.		2015.
	[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-09 (work in progress), December 2014.		requirements-09 (work in progress), December 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-13		Browser-based Applications", draft-ietf-rtcweb-overview-13
	(work in progress), November 2014.		(work in progress), November 2014.
	[I-D.ietf-rtcweb-use-cases-and-requirements]
	Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use-cases and Requirements", draft-
	ietf-rtcweb-use-cases-and-requirements-16 (work in
	progress), January 2015.
	[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-03 (work in progress),		draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),
	November 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.
	skipping to change at page 45, line 5		skipping to change at page 44, line 19
	[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP		[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
	Control Protocol (RTCP)", RFC 5968, September 2010.		Control Protocol (RTCP)", RFC 5968, September 2010.
	[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for		[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
	Keeping Alive the NAT Mappings Associated with RTP / RTP		Keeping Alive the NAT Mappings Associated with RTP / RTP
	Control Protocol (RTCP) Flows", RFC 6263, June 2011.		Control Protocol (RTCP) Flows", RFC 6263, June 2011.
	[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the		[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
	RTP Monitoring Framework", RFC 6792, November 2012.		RTP Monitoring Framework", RFC 6792, November 2012.
			[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
			Time Communication Use Cases and Requirements", RFC 7478,
			March 2015.
	[W3C.WD-mediacapture-streams-20130903]		[W3C.WD-mediacapture-streams-20130903]
	Burnett, D., Bergkvist, A., Jennings, C., and A.		Burnett, D., Bergkvist, A., Jennings, C., and A.
	Narayanan, "Media Capture and Streams", World Wide Web		Narayanan, "Media Capture and Streams", World Wide Web
	Consortium WD WD-mediacapture-streams-20130903, September		Consortium WD WD-mediacapture-streams-20130903, September
	2013, <http://www.w3.org/TR/2013/WD-mediacapture-		2013, <http://www.w3.org/TR/2013/
	streams-20130903>.		WD-mediacapture-streams-20130903>.
	[W3C.WD-webrtc-20130910]		[W3C.WD-webrtc-20130910]
	Bergkvist, A., Burnett, D., Jennings, C., and A.		Bergkvist, A., Burnett, D., Jennings, C., and A.
	Narayanan, "WebRTC 1.0: Real-time Communication Between		Narayanan, "WebRTC 1.0: Real-time Communication Between
	Browsers", World Wide Web Consortium WD WD-		Browsers", World Wide Web Consortium WD WD-webrtc-
	webrtc-20130910, September 2013,		20130910, September 2013,
	<http://www.w3.org/TR/2013/WD-webrtc-20130910>.		<http://www.w3.org/TR/2013/WD-webrtc-20130910>.
	Authors' Addresses		Authors' Addresses
	Colin Perkins		Colin Perkins
	University of Glasgow		University of Glasgow
	School of Computing Science		School of Computing Science
	Glasgow G12 8QQ		Glasgow G12 8QQ
	United Kingdom		United Kingdom
End of changes. 42 change blocks.
	112 lines changed or deleted		118 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/