draft-ietf-rtcweb-rtp-usage-09.txt		draft-ietf-rtcweb-rtp-usage-10.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: March 09, 2014 Ericsson		Expires: April 24, 2014 Ericsson
	J. Ott		J. Ott
	Aalto University		Aalto University
	September 05, 2013		October 21, 2013
	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-09		draft-ietf-rtcweb-rtp-usage-10
	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 March 09, 2014.		This Internet-Draft will expire on April 24, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . 6		4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 6
	4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7		4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7
	4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 8		4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9
	4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9		4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9
	4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10		4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10
	4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10		4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10
	4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 10		4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11
	4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11		4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11
	5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 11		5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12
	5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12		5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12
	5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13		5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13
	5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13		5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13
	5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13		5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 14
	5.1.4. Reference Picture Selection Indication (RPSI) . . . . 13		5.1.4. Reference Picture Selection Indication (RPSI) . . . . 14
	5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14		5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14
	5.1.6. Temporary Maximum Media Stream Bit Rate Request		5.1.6. Temporary Maximum Media Stream Bit Rate Request
	(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14		(TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14		5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14
	5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14		5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 15
	5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15		5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15
	5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15		5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 16
	5.2.4. Associating RTP Media Streams and Signalling Contexts 15		5.2.4. Associating RTP Media Streams and Signalling Contexts 16
	6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15		6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16
	6.1. Negative Acknowledgements and RTP Retransmission . . . . 16		6.1. Negative Acknowledgements and RTP Retransmission . . . . 16
	6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17		6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17
	7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 17		7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 18
	7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18		7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18
	7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19		7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19
	7.3. Congestion Control Interoperability and Legacy Systems . 19		7.3. Congestion Control Interoperability and Legacy Systems . 20
	8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20		8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 21
	9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21		9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21
	10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21		10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22
	11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23		11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23
	12. RTP Implementation Considerations . . . . . . . . . . . . . . 23		12. RTP Implementation Considerations . . . . . . . . . . . . . . 24
	12.1. Configuration and Use of RTP Sessions . . . . . . . . . 24		12.1. Configuration and Use of RTP Sessions . . . . . . . . . 24
	12.1.1. Use of Multiple Media Flows Within an RTP Session . 24		12.1.1. Use of Multiple Media Flows Within an RTP Session . 24
	12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 25		12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 26
	12.1.3. Differentiated Treatment of Flows . . . . . . . . . 30		12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31
	12.2. Source, Flow, and Participant Identification . . . . . . 31		12.2. Source, Flow, and Participant Identification . . . . . . 32
	12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 31		12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 32
	12.2.2. Media Streams: SSRC Collision Detection . . . . . . 32		12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33
	12.2.3. Media Synchronisation Context . . . . . . . . . . . 33		12.2.3. Media Synchronisation Context . . . . . . . . . . . 34
	12.2.4. Correlation of Media Streams . . . . . . . . . . . . 34		12.2.4. Correlation of Media Streams . . . . . . . . . . . . 34
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 34		13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35		15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
	16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35		16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	17.1. Normative References . . . . . . . . . . . . . . . . . . 35		17.1. Normative References . . . . . . . . . . . . . . . . . . 36
	17.2. Informative References . . . . . . . . . . . . . . . . . 38		17.2. Informative References . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	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 9		skipping to change at page 4, line 9
	robustness to network problems, while Section 7 describes congestion		robustness to network problems, while Section 7 describes congestion
	control and rate adaptation mechanisms. The discussion of mandated		control and rate adaptation mechanisms. The discussion of mandated
	RTP mechanisms concludes in Section 8 with a review of performance		RTP mechanisms concludes in Section 8 with a review of performance
	monitoring and network management tools that can be used in the		monitoring and network management tools that can be used in the
	WebRTC context. Section 9 gives some guidelines for future		WebRTC context. Section 9 gives some guidelines for future
	incorporation of other RTP and RTP Control Protocol (RTCP) extensions		incorporation of other RTP and RTP Control Protocol (RTCP) extensions
	into this framework. Section 10 describes requirements placed on the		into this framework. Section 10 describes requirements placed on the
	signalling channel. Section 11 discusses the relationship between		signalling channel. Section 11 discusses the relationship between
	features of the RTP framework and the WebRTC application programming		features of the RTP framework and the WebRTC application programming
	interface (API), and Section 12 discusses RTP implementation		interface (API), and Section 12 discusses RTP implementation
	considerations. This memo concludes with an appendix discussing		considerations. The memo concludes with security considerations
	several different RTP Topologies, and how they affect the RTP		(Section 13) and IANA considerations (Section 14).
	session(s) and various implementation details of possible realization
	of central nodes.
	2. Rationale		2. Rationale
	The RTP framework comprises the RTP data transfer protocol, the RTP		The RTP framework comprises the RTP data transfer protocol, the RTP
	control protocol, and numerous RTP payload formats, profiles, and		control protocol, and numerous RTP payload formats, profiles, and
	extensions. This range of add-ons has allowed RTP to meet various		extensions. This range of add-ons has allowed RTP to meet various
	needs that were not envisaged by the original protocol designers, and		needs that were not envisaged by the original protocol designers, and
	to support many new media encodings, but raises the question of what		to support many new media encodings, but raises the question of what
	extensions are to be supported by new implementations. The		extensions are to be supported by new implementations. The
	development of the WebRTC framework provides an opportunity for us to		development of the WebRTC framework provides an opportunity for us to
	skipping to change at page 6, line 30		skipping to change at page 6, line 23
	o Support for reception of RTP data packets containing CSRC lists,		o Support for reception of RTP data packets containing CSRC lists,
	as generated by RTP mixers, and RTCP packets relating to CSRCs.		as generated by RTP mixers, and RTCP packets relating to CSRCs.
	o Support for sending correct synchronization information in the		o Support for sending correct synchronization information in the
	RTCP Sender Reports, to allow a receiver to implement lip-sync,		RTCP Sender Reports, to allow a receiver to implement lip-sync,
	with RECOMMENDED support for the rapid RTP synchronisation		with RECOMMENDED support for the rapid RTP synchronisation
	extensions (see Section 5.2.1).		extensions (see Section 5.2.1).
	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;
	implementations MUST ignore unknown RTCP packet types.		implementations MUST ignore unknown RTCP packet types. Note that
			additional RTCP Packet types are needed by the RTP/SAVPF Profile
			(Section 4.2) and the other RTCP extensions (Section 5).
	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.		support for RTCP timer reconsideration.
	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.
	skipping to change at page 7, line 37		skipping to change at page 7, line 37
	4 seconds).		4 seconds).
	The secure RTP profile [RFC3711] is needed to provide media		The secure RTP profile [RFC3711] is needed to provide media
	encryption, integrity protection, replay protection and a limited		encryption, integrity protection, replay protection and a limited
	form of source authentication. WebRTC implementations MUST NOT send		form of source authentication. WebRTC implementations MUST NOT send
	packets using the basic RTP/AVP profile or the RTP/AVPF profile; they		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 RTCP		MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP
	packets that are generated. The default and mandatory to implement		packets that are generated. The default and mandatory to implement
	transforms listed in Section 5 of [RFC3711] SHALL apply.		transforms listed in Section 5 of [RFC3711] SHALL apply.
	Implementations MUST support DTLS-SRTP [RFC5764] for key-management.		The keying mechanism(s) to be used with the RTP/SAVPF profile are
	Other key management schemes MAY be supported.		defined in Section 5.5 of [I-D.ietf-rtcweb-security-arch] or its
			replacement.
	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		The set of mandatory to implement codecs and RTP payload formats for
	WebRTC is not specified in this memo. Implementations can support		WebRTC is not specified in this memo. Implementations can support
	any codec for which an RTP payload format and associated signalling		any codec for which an RTP payload format and associated signalling
	is defined. Implementation cannot assume that the other participants		is defined. Implementation cannot assume that the other participants
	in an RTP session understand any RTP payload format, no matter how		in an RTP session understand any RTP payload format, no matter how
	common; the mapping between RTP payload type numbers and specific		common; the mapping between RTP payload type numbers and specific
	configurations of particular RTP payload formats MUST be agreed		configurations of particular RTP payload formats MUST be agreed
	before those payload types/formats can be used. In an SDP context,		before those payload types/formats can be used. In an SDP context,
	this can be done using the "a=rtpmap:" and "a=fmtp:" attributes		this can be done using the "a=rtpmap:" and "a=fmtp:" attributes
	associated with an "m=" line.		associated with an "m=" line.
	skipping to change at page 9, line 35		skipping to change at page 9, line 46
	sessions on a single transport-layer flow. This gives advantages in		sessions on a single transport-layer flow. This gives advantages in
	some gateway scenarios, and makes it easy to distinguish groups of		some gateway scenarios, and makes it easy to distinguish groups of
	RTP media streams that might need distinct processing. One way of		RTP media streams that might need distinct processing. One way of
	doing this is described in		doing this is described in
	[I-D.westerlund-avtcore-transport-multiplexing]. At the time of this		[I-D.westerlund-avtcore-transport-multiplexing]. At the time of this
	writing, there is no consensus to use a shim-based approach in WebRTC		writing, there is no consensus to use a shim-based approach in WebRTC
	implementations.		implementations.
	Further discussion about when different RTP session structures and		Further discussion about when different RTP session structures and
	multiplexing methods are suitable can be found in		multiplexing methods are suitable can be found in
	[I-D.westerlund-avtcore-multiplex-architecture].		[I-D.ietf-avtcore-multiplex-guidelines].
	4.5. RTP and RTCP Multiplexing		4.5. RTP and RTCP Multiplexing
	Historically, RTP and RTCP have been run on separate transport layer		Historically, RTP and RTCP have been run on separate transport layer
	addresses (e.g., two UDP ports for each RTP session, one port for RTP		addresses (e.g., two UDP ports for each RTP session, one port for RTP
	and one port for RTCP). With the increased use of Network Address/		and one port for RTCP). With the increased use of Network Address/
	Port Translation (NAPT) this has become problematic, since		Port Translation (NAPT) this has become problematic, since
	maintaining multiple NAT bindings can be costly. It also complicates		maintaining multiple NAT bindings can be costly. It also complicates
	firewall administration, since multiple ports need to be opened to		firewall administration, since multiple ports need to be opened to
	allow RTP traffic. To reduce these costs and session set-up times,		allow RTP traffic. To reduce these costs and session set-up times,
	skipping to change at page 11, line 35		skipping to change at page 12, line 5
	4.9. Generation of the RTCP Canonical Name (CNAME)		4.9. Generation of the RTCP Canonical Name (CNAME)
	The RTCP Canonical Name (CNAME) provides a persistent transport-level		The RTCP Canonical Name (CNAME) provides a persistent transport-level
	identifier for an RTP endpoint. While the Synchronisation Source		identifier for an RTP endpoint. While the Synchronisation Source
	(SSRC) identifier for an RTP endpoint can change if a collision is		(SSRC) identifier for an RTP endpoint can change if a collision is
	detected, or when the RTP application is restarted, its RTCP CNAME is		detected, or when the RTP application is restarted, its RTCP CNAME is
	meant to stay unchanged, so that RTP endpoints can be uniquely		meant to stay unchanged, so that RTP endpoints can be uniquely
	identified and associated with their RTP media streams within a set		identified and associated with their RTP media streams within a set
	of related RTP sessions. For proper functionality, each RTP endpoint		of related RTP sessions. For proper functionality, each RTP endpoint
	needs to have a unique RTCP CNAME value.		needs to have at least one unique RTCP CNAME value. An endpoint MAY
			have multiple CNAMEs, as the CNAME also identifies a particular
			synchronization context, i.e. all SSRC associated with a CNAME share
			a common reference clock, and if an endpoint have SSRCs associated
			with different reference clocks it will need to use multiple CNAMEs.
			This ought not be common, and if possible reference clocks ought to
			be mapped to each other and one chosen to be used with RTP and RTCP.
	The RTP specification [RFC3550] includes guidelines for choosing a		The RTP specification [RFC3550] includes guidelines for choosing a
	unique RTP CNAME, but these are not sufficient in the presence of NAT		unique RTP CNAME, but these are not sufficient in the presence of NAT
	devices. In addition, long-term persistent identifiers can be		devices. In addition, long-term persistent identifiers can be
	problematic from a privacy viewpoint. Accordingly, support for		problematic from a privacy viewpoint. Accordingly, support for
	generating a short-term persistent RTCP CNAMEs following [RFC7022] is		generating a short-term persistent RTCP CNAMEs following [RFC7022] is
	RECOMMENDED.		RECOMMENDED.
	An WebRTC end-point MUST support reception of any CNAME that matches		An WebRTC end-point MUST support reception of any CNAME that matches
	the syntax limitations specified by the RTP specification [RFC3550]		the syntax limitations specified by the RTP specification [RFC3550]
	skipping to change at page 16, line 17		skipping to change at page 16, line 42
	these extra bits needs to be considered, and the aggregate bit-rate		these extra bits needs to be considered, and the aggregate bit-rate
	MUST be rate controlled to avoid causing network congestion (see		MUST 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-
	sections can be used to improve tolerance to packet loss.		sections can be used to improve tolerance to packet loss.
	6.1. Negative Acknowledgements and RTP Retransmission		6.1. Negative Acknowledgements and RTP Retransmission
	As a consequence of supporting the RTP/SAVPF profile, implementations		As a consequence of supporting the RTP/SAVPF profile, implementations
	will support negative acknowledgements (NACKs) for RTP data packets		can support negative acknowledgements (NACKs) for RTP data packets
	[RFC4585]. This feedback can be used to inform a sender of the loss		[RFC4585]. This feedback can be used to inform a sender of the loss
	of particular RTP packets, subject to the capacity limitations of the		of particular RTP packets, subject to the capacity limitations of the
	RTCP feedback channel. A sender can use this information to optimise		RTCP feedback channel. A sender can use this information to optimise
	the user experience by adapting the media encoding to compensate for		the user experience by adapting the media encoding to compensate for
	known lost packets, for example.		known lost packets, for example.
	Senders are REQUIRED to understand the Generic NACK message defined		Senders are REQUIRED to understand the Generic NACK message defined
	in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback		in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback
	(following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for		(following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for
	missing RTP packets; [RFC4585] provides some guidelines on when to		missing RTP packets; [RFC4585] provides some guidelines on when to
	skipping to change at page 17, line 10		skipping to change at page 17, line 32
	appropriate to blindly retransmit RTP packets in response to a NACK.		appropriate to blindly retransmit RTP packets in response to a NACK.
	The importance of lost packets and the likelihood of them arriving in		The importance of lost packets and the likelihood of them arriving in
	time to be useful needs to be considered before RTP retransmission is		time to be useful needs to be considered before RTP retransmission is
	used.		used.
	Receivers are REQUIRED to implement support for RTP retransmission		Receivers are REQUIRED to implement support for RTP retransmission
	packets [RFC4588]. Senders MAY send RTP retransmission packets in		packets [RFC4588]. Senders MAY send RTP retransmission packets in
	response to NACKs if the RTP retransmission payload format has been		response to NACKs if the RTP retransmission payload format has been
	negotiated for the session, and if the sender believes it is useful		negotiated for the session, and if the sender believes it is useful
	to send a retransmission of the packet(s) referenced in the NACK. An		to send a retransmission of the packet(s) referenced in the NACK. An
	RTP sender is not expected to retransmit every NACKed packet.		RTP sender does not need to retransmit every NACKed packet.
	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
	skipping to change at page 17, line 48		skipping to change at page 18, line 24
	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 media		mixtures. Individual end-points can send one or more RTP media
	streams to each participant in a WebRTC conference, and there can be		streams to each participant in a WebRTC conference, and there can be
	several participants. Each of these RTP media streams can contain		several participants. Each of these RTP media streams can contain
	different types of media, and the type of media, bit rate, and number		different types of media, and the type of media, bit rate, and number
	of flows can be highly asymmetric. Non-RTP traffic can share the		of flows can be highly asymmetric. Non-RTP traffic can share the
	network paths RTP flows. Since the network environment is not		network paths with RTP flows. Since the network environment is not
	predictable or stable, WebRTC endpoints MUST ensure that the RTP		predictable or stable, WebRTC endpoints MUST ensure that the RTP
	traffic they generate can adapt to match changes in the available		traffic they generate can adapt to match changes in the available
	network capacity.		network capacity.
	The quality of experience for users of WebRTC implementation is very		The quality of experience for users of WebRTC implementation is very
	dependent on effective adaptation of the media to the limitations of		dependent on effective adaptation of the media to the limitations of
	the network. End-points have to be designed so they do not transmit		the network. End-points have to be designed so they do not transmit
	significantly more data than the network path can support, except for		significantly more data than the network path can support, except for
	very short time periods, otherwise high levels of network packet loss		very short time periods, otherwise high levels of network packet loss
	or delay spikes will occur, causing media quality degradation. The		or delay spikes will occur, causing media quality degradation. The
	skipping to change at page 18, line 29		skipping to change at page 19, line 4
	be used for interactive media applications such as WebRTC flows.		be used for interactive media applications such as WebRTC flows.
	Some requirements for congestion control algorithms for WebRTC		Some requirements for congestion control algorithms for WebRTC
	sessions are discussed in [I-D.jesup-rtp-congestion-reqs], and it is		sessions are discussed in [I-D.jesup-rtp-congestion-reqs], and it is
	expected that a future version of this memo will mandate the use of a		expected that a future version of this memo will mandate the use of a
	congestion control algorithm that satisfies these requirements.		congestion control algorithm that satisfies these requirements.
	7.1. Boundary Conditions and Circuit Breakers		7.1. Boundary Conditions and Circuit Breakers
	In the absence of a concrete congestion control algorithm, all WebRTC		In the absence of a concrete congestion control algorithm, all WebRTC
	implementations MUST implement the RTP circuit breaker algorithm that		implementations MUST implement the RTP circuit breaker algorithm that
	is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The circuit		is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP
	breaker defines a conservative boundary condition for safe operation,		circuit breaker is designed to enable applications to recognise and
	chosen such that applications that trigger the circuit breaker will		react to situations of extreme network congestion. However, since
	almost certainly be causing severe network congestion. Any future		the RTP circuit breaker might not be triggered until congestion
	RTP congestion control algorithms are expected to operate within the		becomes extreme, it cannot be considered a substitute for congestion
			control, and applications MUST also implement congestion control to
			allow them to adapt to changes in network capacity. Any future RTP
			congestion control algorithms are expected to operate within the
	envelope allowed by the circuit breaker.		envelope allowed by the circuit breaker.
	The session establishment signalling will also necessarily establish		The session establishment signalling will also necessarily establish
	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 packetization choices that exist. In addition, the signalling		the packetization choices that exist. In addition, the signalling
	channel can establish maximum media bit-rate boundaries using the SDP		channel can establish maximum media bit-rate boundaries using the SDP
	"b=AS:" or "b=CT:" lines, and the RTP/AVPF Temporary Maximum Media		"b=AS:" or "b=CT:" lines, and the RTP/AVPF Temporary Maximum Media
	Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo).		Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo).
	skipping to change at page 26, line 8		skipping to change at page 26, line 42
	discussed further in Section 12.1.3.		discussed further in Section 12.1.3.
	To separate media with different purposes: An end-point might want		To separate media with different purposes: An end-point might want
	to send media streams that have different purposes on different		to send media streams that have different purposes on different
	RTP sessions, to make it easy for the peer device to distinguish		RTP sessions, to make it easy for the peer device to distinguish
	them. For example, some centralised multiparty conferencing		them. For example, some centralised multiparty conferencing
	systems display the active speaker in high resolution, but show		systems display the active speaker in high resolution, but show
	low resolution "thumbnails" of other participants. Such systems		low resolution "thumbnails" of other participants. Such systems
	might configure the end-points to send simulcast high- and low-		might configure the end-points to send simulcast high- and low-
	resolution versions of their video using separate RTP sessions, to		resolution versions of their video using separate RTP sessions, to
	simplify the operation of the central mixer In the WebRTC context		simplify the operation of the central mixer. In the WebRTC
	this appears to be most easily accomplished by establishing		context this appears to be most easily accomplished by
	multiple PeerConnection all being feed the same set of WebRTC		establishing multiple PeerConnection all being feed the same set
	MediaStreams. Each PeerConnection is then configured to deliver a		of WebRTC MediaStreams. Each PeerConnection is then configured to
	particular media quality and thus media bit-rate, and will produce		deliver a particular media quality and thus media bit-rate, and
	an independently encoded version with the codec parameters agreed		will produce an independently encoded version with the codec
	specifically in the context of that PeerConnection. The central		parameters agreed specifically in the context of that
	mixer can always distinguish packets corresponding to the low- and		PeerConnection. The central mixer can always distinguish packets
	high-resolution streams by inspecting their SSRC, RTP payload		corresponding to the low- and high-resolution streams by
	type, or some other information contained in RTP header extensions		inspecting their SSRC, RTP payload type, or some other information
	or RTCP packets, but it can be easier to distinguish the flows if		contained in RTP header extensions or RTCP packets, but it can be
	they arrive on separate RTP sessions on separate UDP ports.		easier to distinguish the flows if they arrive on separate RTP
			sessions on separate UDP ports.
	To directly connect with multiple peers: A multi-party conference		To directly connect with multiple peers: A multi-party conference
	does not need to use a central mixer. Rather, a multi-unicast		does not need to use a central mixer. Rather, a multi-unicast
	mesh can be created, comprising several distinct RTP sessions,		mesh can be created, comprising several distinct RTP sessions,
	with each participant sending RTP traffic over a separate RTP		with each participant sending RTP traffic over a separate RTP
	session (that is, using an independent an PeerConnection object)		session (that is, using an independent PeerConnection object) to
	to every other participant, as shown in Figure 1. This topology		every other participant, as shown in Figure 1. This topology has
	has the benefit of not requiring a central mixer node that is		the benefit of not requiring a central mixer node that is trusted
	trusted to access and manipulate the media data. The downside is		to access and manipulate the media data. The downside is that it
	that it increases the used bandwidth at each sender by requiring		increases the used bandwidth at each sender by requiring one copy
	one copy of the RTP media streams for each participant that are		of the RTP media streams for each participant that are part of the
	part of the same session beyond the sender itself.		same session beyond the sender itself.
			+---+ +---+
			| A |<--->| B |
			+---+ +---+
			^ ^
			\ /
			\ /
			v v
			+---+
			| C |
			+---+
			Figure 1: Multi-unicast using several RTP sessions
	The multi-unicast topology could also be implemented as a single		The multi-unicast topology could also be implemented as a single
	RTP session, spanning multiple peer-to-peer transport layer		RTP session, spanning multiple peer-to-peer transport layer
	connections, or as several pairwise RTP sessions, one between each		connections, or as several pairwise RTP sessions, one between each
	pair of peers. To maintain a coherent mapping between the		pair of peers. To maintain a coherent mapping between the
	relation between RTP sessions and PeerConnection objects we		relation between RTP sessions and PeerConnection objects we
	recommend that this is implemented as several individual RTP		recommend that this is implemented as several individual RTP
	sessions. The only downside is that end-point A will not learn of		sessions. The only downside is that end-point A will not learn of
	the quality of any transmission happening between B and C, since		the quality of any transmission happening between B and C, since
	it will not see RTCP reports for the RTP session between B and C,		it will not see RTCP reports for the RTP session between B and C,
	skipping to change at page 27, line 18		skipping to change at page 28, line 19
	To indirectly connect with multiple peers: A common scenario in		To indirectly connect with multiple peers: A common scenario in
	multi-party conferencing is to create indirect connections to		multi-party conferencing is to create indirect connections to
	multiple peers, using an RTP mixer, translator, or some other type		multiple peers, using an RTP mixer, translator, or some other type
	of RTP middlebox. Figure 2 outlines a simple topology that might		of RTP middlebox. Figure 2 outlines a simple topology that might
	be used in a four-person centralised conference. The middlebox		be used in a four-person centralised conference. The middlebox
	acts to optimise the transmission of RTP media streams from		acts to optimise the transmission of RTP media streams from
	certain perspectives, either by only sending some of the received		certain perspectives, either by only sending some of the received
	RTP media stream to any given receiver, or by providing a combined		RTP media stream to any given receiver, or by providing a combined
	RTP media stream out of a set of contributing streams.		RTP media stream out of a set of contributing streams.
			+---+ +-------------+ +---+
			| A |<---->| |<---->| B |
			+---+ | RTP mixer, | +---+
			| translator, |
			| or other |
			+---+ | middlebox | +---+
			| C |<---->| |<---->| D |
			+---+ +-------------+ +---+
			Figure 2: RTP mixer with only unicast paths
	There are various methods of implementation for the middlebox. If		There are various methods of implementation for the middlebox. If
	implemented as a standard RTP mixer or translator, a single RTP		implemented as a standard RTP mixer or translator, a single RTP
	session will extend across the middlebox and encompass all the		session will extend across the middlebox and encompass all the
	end-points in one multi-party session. Other types of middlebox		end-points in one multi-party session. Other types of middlebox
	might use separate RTP sessions between each end-point and the		might use separate RTP sessions between each end-point and the
	middlebox. A common aspect is that these central nodes can use a		middlebox. A common aspect is that these central nodes can use a
	number of tools to control the media encoding provided by a WebRTC		number of tools to control the media encoding provided by a WebRTC
	end-point. This includes functions like requesting breaking the		end-point. This includes functions like requesting breaking the
	encoding chain and have the encoder produce a so called Intra		encoding chain and have the encoder produce a so called Intra
	frame. Another is limiting the bit-rate of a given stream to		frame. Another is limiting the bit-rate of a given stream to
	skipping to change at page 29, line 32		skipping to change at page 31, line 7
	resource on the transcoding. The media transcoding does result in		resource on the transcoding. The media transcoding does result in
	a separation of the two different legs removing almost all		a separation of the two different legs removing almost all
	dependencies, and allowing the forwarding end-point to optimize		dependencies, and allowing the forwarding end-point to optimize
	its media transcoding operation. It also allows forwarding		its media transcoding operation. It also allows forwarding
	without the original sender being aware of the forwarding. The		without the original sender being aware of the forwarding. The
	cost is greatly increased computational complexity on the		cost is greatly increased computational complexity on the
	forwarding node.		forwarding node.
	(tbd: ought media forwarding be allowed?)		(tbd: ought media forwarding be allowed?)
	+---+ +---+
	| A |<--->| B |
	+---+ +---+
	^ ^
	\ /
	\ /
	v v
	+---+
	| C |
	+---+
	Figure 1: Multi-unicast using several RTP sessions
	+---+ +-------------+ +---+
	| A |<---->| |<---->| B |
	+---+ | RTP mixer, | +---+
	| translator, |
	| or other |
	+---+ | middlebox | +---+
	| C |<---->| |<---->| D |
	+---+ +-------------+ +---+
	Figure 2: RTP mixer with only unicast paths
	12.1.3. Differentiated Treatment of Flows		12.1.3. Differentiated Treatment of Flows
	There are use cases for differentiated treatment of RTP media		There are use cases for differentiated treatment of RTP media
	streams. Such differentiation can happen at several places in the		streams. Such differentiation can happen at several places in the
	system. First of all is the prioritization within the end-point		system. First of all is the prioritization within the end-point
	sending the media, which controls, both which RTP media streams that		sending the media, which controls, both which RTP media streams that
	will be sent, and their allocation of bit-rate out of the current		will be sent, and their allocation of bit-rate out of the current
	available aggregate as determined by the congestion control.		available aggregate as determined by the congestion control.
	It is expected that the WebRTC API will allow the application to		It is expected that the WebRTC API will allow the application to
	skipping to change at page 31, line 24		skipping to change at page 32, line 16
	prioritization of audio and video if desired by application.		prioritization of audio and video if desired by application.
	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		two requirements arise in the WebRTC context: 1) The WebRTC
	application or browser has to know which DSCP to use and that it can		application or browser has to know which DSCP to use and that it can
	use them on some set of RTP media streams. 2) The information needs		use them on some set of RTP media streams. 2) The information needs
	to be propagated to the operating system when transmitting the		to be propagated to the operating system when transmitting the
	packet. These issues are discussed in DSCP and other packet markings		packet. These issues are discussed in DSCP and other packet markings
	for RTCWeb QoS [I-D.ietf-rtcweb-qos].		for RTCWeb QoS [I-D.dhesikan-tsvwg-rtcweb-qos].
	For packet based marking schemes it would be possible in the context		For packet based marking schemes it would be possible in the context
	to mark individual RTP packets differently based on the relative		to mark individual RTP packets differently based on the relative
	priority of the RTP payload. For example video codecs that has I,P		priority of the RTP payload. For example video codecs that has I,P
	and B pictures could prioritise any payloads carrying only B frames		and B pictures could prioritise any payloads carrying only B frames
	less, as these are less damaging to loose. But as default policy all		less, as these are less damaging to loose. But as default policy all
	RTP packets related to a media stream ought to be provided with the		RTP packets related to a media stream ought to be provided with the
	same prioritization.		same prioritization.
	It is also important to consider how RTCP packets associated with a		It is also important to consider how RTCP packets associated with a
	skipping to change at page 34, line 30		skipping to change at page 35, line 24
	The security considerations of the RTP specification, the RTP/SAVPF		The security considerations of the RTP specification, the RTP/SAVPF
	profile, and the various RTP/RTCP extensions and RTP payload formats		profile, and the various RTP/RTCP extensions and RTP payload formats
	that form the complete protocol suite described in this memo apply.		that form the complete protocol suite described in this memo apply.
	We do not believe there are any new security considerations resulting		We do not believe there are any new security considerations resulting
	from the combination of these various protocol extensions.		from the combination of these various protocol extensions.
	The Extended Secure RTP Profile for Real-time Transport Control		The Extended Secure RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides		Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides
	handling of fundamental issues by offering confidentiality, integrity		handling of fundamental issues by offering confidentiality, integrity
	and partial source authentication. A mandatory to implement media		and partial source authentication. A mandatory to implement media
	security solution is (tbd).		security solution is created by combing this secured RTP profile and
			DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of
			[I-D.ietf-rtcweb-security-arch].
	RTCP packets convey a Canonical Name (CNAME) identifier that is used		RTCP packets convey a Canonical Name (CNAME) identifier that is used
	to associate media flows that need to be synchronised across related		to associate media flows that need to be synchronised across related
	RTP sessions. Inappropriate choice of CNAME values can be a privacy		RTP sessions. Inappropriate choice of CNAME values can be a privacy
	concern, since long-term persistent CNAME identifiers can be used to		concern, since long-term persistent CNAME identifiers can be used to
	track users across multiple WebRTC calls. Section 4.9 of this memo		track users across multiple WebRTC calls. Section 4.9 of this memo
	provides guidelines for generation of untraceable CNAME values that		provides guidelines for generation of untraceable CNAME values that
	alleviate this risk.		alleviate this risk.
	The guidelines in [RFC6562] apply when using variable bit rate (VBR)		The guidelines in [RFC6562] apply when using variable bit rate (VBR)
	skipping to change at page 35, line 6		skipping to change at page 36, line 4
	extensions (Section 5.2.3).		extensions (Section 5.2.3).
	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. Open Issues		15. Open Issues
	This section contains a summary of the open issues or to be done		This section contains a summary of the open issues or to be done
	things noted in the document:		things noted in the document:
	1. tbd: The API mapping to RTP level concepts has to be agreed and		1. tbd: The API mapping to RTP level concepts has to be agreed and
	documented in Section 11.		documented in Section 11. This include both SSRC to API
			constructs, but also how different SSRC are related in this
			context.
	2. tbd: An open question if any requirements are needed to agree and		2. tbd: An open question if any requirements are needed to agree and
	limit the number of simultaneously used media sources (SSRCs)		limit the number of simultaneously used media sources (SSRCs)
	within an RTP session. See Section 4.1.		within an RTP session. See Section 4.1.
	3. tbd: The method for achieving simulcast of a media source has to		3. tbd: The method for achieving simulcast of a media source has to
	be decided.		be decided.
	4. tbd: Possible documentation of what support for differentiated		4. tbd: Possible documentation of what support for differentiated
	treatment that are needed on RTP level as the API and the network		treatment that are needed on RTP level as the API and the network
	level specification matures as discussed in Section 12.1.3.		level specification matures as discussed in Section 12.1.3.
			5. tbd: There are various reasons for having multiple SSRCs of the
			same media type in the PeerConnections RTP session(s)
			(Section 12.1.1). The signalling separating these cases needs
			clarifications, preferably just by pointing to relevant
			signalling section taking care of it. Related to Open Issue 1.
			6. tbd: The section on usage of multiple RTP sessions
			(Section 12.1.2) raised the question: ought media forwarding be
			allowed?
	16. Acknowledgements		16. Acknowledgements
	The authors would like to thank Harald Alvestrand, Cary Bran, Charles		The authors would like to thank Harald Alvestrand, Cary Bran, Charles
	Eckel, Cullen Jennings, Bernard Aboba, and the other members of the		Eckel, Cullen Jennings, Bernard Aboba, and the other members of the
	IETF RTCWEB working group for their valuable feedback.		IETF RTCWEB working group for their valuable feedback.
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	skipping to change at page 35, line 47		skipping to change at page 37, line 8
	ietf-avtcore-multi-media-rtp-session-03 (work in		ietf-avtcore-multi-media-rtp-session-03 (work in
	progress), July 2013.		progress), July 2013.
	[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-03 (work in progress), July		avtcore-rtp-circuit-breakers-03 (work in progress), July
	2013.		2013.
	[I-D.ietf-avtcore-rtp-multi-stream-optimisation]		[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
	Lennox, J., Westerlund, M., Wu, Q., 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:
	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-01 (work in progress),		draft-ietf-avtcore-rtp-multi-stream-01 (work in progress),
	July 2013.		July 2013.
	[I-D.ietf-avtext-multiple-clock-rates]		[I-D.ietf-avtext-multiple-clock-rates]
	Petit-Huguenin, M. and G. Zorn, "Support for Multiple		Petit-Huguenin, M. and G. Zorn, "Support for Multiple
	Clock Rates in an RTP Session", draft-ietf-avtext-		Clock Rates in an RTP Session", draft-ietf-avtext-
	multiple-clock-rates-09 (work in progress), April 2013.		multiple-clock-rates-10 (work in progress), September
			2013.
	[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,
	"Multiplexing Negotiation Using Session Description		"Multiplexing Negotiation Using Session Description
	Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-		Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
	bundle-negotiation-04 (work in progress), June 2013.		bundle-negotiation-05 (work in progress), October 2013.
	[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-07 (work in progress), July 2013.		rtcweb-security-arch-07 (work in progress), July 2013.
	[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-05 (work in progress), July 2013.		ietf-rtcweb-security-05 (work in progress), July 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 38, line 25		skipping to change at page 39, line 37
	"Guidelines for Choosing RTP Control Protocol (RTCP)		"Guidelines for Choosing RTP Control Protocol (RTCP)
	Canonical Names (CNAMEs)", RFC 7022, September 2013.		Canonical Names (CNAMEs)", RFC 7022, September 2013.
	17.2. Informative References		17.2. Informative References
	[I-D.alvestrand-rtcweb-msid]		[I-D.alvestrand-rtcweb-msid]
	Alvestrand, H., "Cross Session Stream Identification in		Alvestrand, H., "Cross Session Stream Identification in
	the Session Description Protocol", draft-alvestrand-		the Session Description Protocol", draft-alvestrand-
	rtcweb-msid-02 (work in progress), May 2012.		rtcweb-msid-02 (work in progress), May 2012.
	[I-D.ietf-avt-srtp-ekt]		[I-D.dhesikan-tsvwg-rtcweb-qos]
	Wing, D., McGrew, D., and K. Fischer, "Encrypted Key		Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
	Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03		other packet markings for RTCWeb QoS", draft-dhesikan-
	(work in progress), October 2011.		tsvwg-rtcweb-qos-02 (work in progress), July 2013.
			[I-D.ietf-avtcore-multiplex-guidelines]
			Westerlund, M., Perkins, C., and H. Alvestrand,
			"Guidelines for using the Multiplexing Features of RTP to
			Support Multiple Media Streams", draft-ietf-avtcore-
			multiplex-guidelines-01 (work in progress), July 2013.
	[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-00 (work in progress),		ietf-avtcore-rtp-topologies-update-00 (work in progress),
	April 2013.		April 2013.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for Brower-		Alvestrand, H., "Overview: Real Time Protocols for Brower-
	based Applications", draft-ietf-rtcweb-overview-08 (work		based Applications", draft-ietf-rtcweb-overview-08 (work
	in progress), September 2013.		in progress), September 2013.
	[I-D.ietf-rtcweb-qos]
	Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
	other packet markings for RTCWeb QoS", draft-ietf-rtcweb-
	qos-00 (work in progress), October 2012.
	[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-11 (work in		ietf-rtcweb-use-cases-and-requirements-12 (work in
	progress), June 2013.		progress), October 2013.
	[I-D.jesup-rtp-congestion-reqs]		[I-D.jesup-rtp-congestion-reqs]
	Jesup, R. and H. Alvestrand, "Congestion Control		Jesup, R. and H. Alvestrand, "Congestion Control
	Requirements For Real Time Media", draft-jesup-rtp-		Requirements For Real Time Media", draft-jesup-rtp-
	congestion-reqs-00 (work in progress), March 2012.		congestion-reqs-00 (work in progress), March 2012.
	[I-D.westerlund-avtcore-multiplex-architecture]
	Westerlund, M., Perkins, C., and H. Alvestrand,
	"Guidelines for using the Multiplexing Features of RTP",
	draft-westerlund-avtcore-multiplex-architecture-03 (work
	in progress), February 2013.
	[I-D.westerlund-avtcore-transport-multiplexing]		[I-D.westerlund-avtcore-transport-multiplexing]
	Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a		Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a
	Single Lower-Layer Transport", draft-westerlund-avtcore-		Single Lower-Layer Transport", draft-westerlund-avtcore-
	transport-multiplexing-06 (work in progress), August 2013.		transport-multiplexing-06 (work in progress), August 2013.
	[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.
	[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion		[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
	skipping to change at page 40, line 21		skipping to change at page 41, line 28
	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
	Email: csp@csperkins.org		Email: csp@csperkins.org
			URI: http://csperkins.org/
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
	Farogatan 6		Farogatan 6
	SE-164 80 Kista		SE-164 80 Kista
	Sweden		Sweden
	Phone: +46 10 714 82 87		Phone: +46 10 714 82 87
	Email: magnus.westerlund@ericsson.com		Email: magnus.westerlund@ericsson.com
End of changes. 45 change blocks.
	117 lines changed or deleted		136 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/