rfc8834v5.txt		rfc8834.txt
	Internet Engineering Task Force (IETF) C. Perkins		Internet Engineering Task Force (IETF) C. Perkins
	Request for Comments: 8834 University of Glasgow		Request for Comments: 8834 University of Glasgow
	Category: Standards Track M. Westerlund		Category: Standards Track M. Westerlund
	ISSN: 2070-1721 Ericsson		ISSN: 2070-1721 Ericsson
	J. Ott		J. Ott
	Aalto University		Technical University Munich
	December 2020		January 2021
	Media Transport and Use of RTP in WebRTC		Media Transport and Use of RTP in WebRTC
	Abstract		Abstract
	The framework for Web Real-Time Communication (WebRTC) provides		The framework for Web Real-Time Communication (WebRTC) provides
	support for direct interactive rich communication using audio, video,		support for direct interactive rich communication using audio, video,
	text, collaboration, games, etc. between two peers' web browsers.		text, collaboration, games, etc. between two peers' web browsers.
	This memo describes the media transport aspects of the WebRTC		This memo describes the media transport aspects of the WebRTC
	framework. It specifies how the Real-time Transport Protocol (RTP)		framework. It specifies how the Real-time Transport Protocol (RTP)
	skipping to change at line 38 ¶		skipping to change at line 38 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc8834.		https://www.rfc-editor.org/info/rfc8834.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at line 187 ¶		skipping to change at line 187 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here. Lower- or mixed-case uses of these key		capitals, as shown here. Lower- or mixed-case uses of these key
	words are not to be interpreted as carrying special significance in		words are not to be interpreted as carrying special significance in
	this memo.		this memo.
	We define the following additional terms:		We define the following additional terms:
	WebRTC MediaStream: The MediaStream concept defined by the W3C in		WebRTC MediaStream: The MediaStream concept defined by the W3C in
	the WebRTC API [W3C-MEDIA-CAPTURE]. A MediaStream consists of		the WebRTC API [W3C.WD-mediacapture-streams]. A MediaStream
	zero or more MediaStreamTracks.		consists of zero or more MediaStreamTracks.
	MediaStreamTrack: Part of the MediaStream concept defined by the W3C		MediaStreamTrack: Part of the MediaStream concept defined by the W3C
	in the WebRTC API [W3C-MEDIA-CAPTURE]. A MediaStreamTrack is an		in the WebRTC API [W3C.WD-mediacapture-streams]. A
	individual stream of media from any type of media source such as a		MediaStreamTrack is an individual stream of media from any type of
	microphone or a camera, but conceptual sources such as an audio		media source such as a microphone or a camera, but conceptual
	mix or a video composition are also possible.		sources such as an audio mix or a video composition are also
			possible.
	Transport-layer flow: A unidirectional flow of transport packets		Transport-layer flow: A unidirectional flow of transport packets
	that are identified by a particular 5-tuple of source IP address,		that are identified by a particular 5-tuple of source IP address,
	source port, destination IP address, destination port, and		source port, destination IP address, destination port, and
	transport protocol.		transport protocol.
	Bidirectional transport-layer flow: A bidirectional transport-layer		Bidirectional transport-layer flow: A bidirectional transport-layer
	flow is a transport-layer flow that is symmetric. That is, the		flow is a transport-layer flow that is symmetric. That is, the
	transport-layer flow in the reverse direction has a 5-tuple where		transport-layer flow in the reverse direction has a 5-tuple where
	the source and destination address and ports are swapped compared		the source and destination address and ports are swapped compared
	skipping to change at line 264 ¶		skipping to change at line 265 ¶
	of a single synchronization context, using a single RTCP CNAME for		of a single synchronization context, using a single RTCP CNAME for
	all streams and allowing receivers to play the streams out in a		all streams and allowing receivers to play the streams out in a
	synchronized manner. For compatibility with potential future		synchronized manner. For compatibility with potential future
	versions of this specification, or for interoperability with non-		versions of this specification, or for interoperability with non-
	WebRTC devices through a gateway, receivers MUST support multiple		WebRTC devices through a gateway, receivers MUST support multiple
	synchronization contexts, indicated by the use of multiple RTCP		synchronization contexts, indicated by the use of multiple RTCP
	CNAMEs in an RTP session. This specification mandates the usage		CNAMEs in an RTP session. This specification mandates the usage
	of a single CNAME when sending RTP streams in some circumstances;		of a single CNAME when sending RTP streams in some circumstances;
	see Section 4.9.		see Section 4.9.
	* Support for sending and receiving RTCP SR, RR, Source Description		* Support for sending and receiving RTCP Sender Report (SR),
	(SDES), and BYE packet types. Note that support for other RTCP		Receiver Report (RR), Source Description (SDES), and BYE packet
	packet types is OPTIONAL unless mandated by other parts of this		types. Note that support for other RTCP packet types is OPTIONAL
	specification. Note that additional RTCP packet types are used by		unless mandated by other parts of this specification. Note that
	the RTP/SAVPF profile (Section 4.2) and the other RTCP extensions		additional RTCP packet types are used by the RTP/SAVPF profile
	(Section 5). WebRTC endpoints that implement the Session		(Section 4.2) and the other RTCP extensions (Section 5). WebRTC
	Description Protocol (SDP) bundle negotiation extension will use		endpoints that implement the Session Description Protocol (SDP)
	the SDP Grouping Framework "mid" attribute to identify media		bundle negotiation extension will use the SDP Grouping Framework
	streams. Such endpoints MUST implement the RTCP SDES media		"mid" attribute to identify media streams. Such endpoints MUST
	identification (MID) item described in [RFC8843].		implement the RTCP SDES media identification (MID) item described
			in [RFC8843].
	* Support for multiple endpoints in a single RTP session, and for		* Support for multiple endpoints 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 randomized RTCP		participants in the session; support for randomized RTCP
	transmission intervals to avoid synchronization of RTCP reports;		transmission intervals to avoid synchronization of RTCP reports;
	support for RTCP timer reconsideration (Section 6.3.6 of		support for RTCP timer reconsideration (Section 6.3.6 of
	[RFC3550]) and reverse reconsideration (Section 6.3.4 of		[RFC3550]) and reverse reconsideration (Section 6.3.4 of
	[RFC3550]).		[RFC3550]).
	* Support for configuring the RTCP bandwidth as a fraction of the		* Support for configuring the RTCP bandwidth as a fraction of the
	skipping to change at line 357 ¶		skipping to change at line 359 ¶
	| interworking with RTP/(S)AVP endpoints via a gateway is to set		| interworking with RTP/(S)AVP endpoints via a gateway is to set
	| the "trr-int" parameter to a value representing 4 seconds; see		| the "trr-int" parameter to a value representing 4 seconds; see
	| Section 7.1.3 of [RFC8108].		| Section 7.1.3 of [RFC8108].
	The secure RTP (SRTP) profile extensions [RFC3711] are needed to		The secure RTP (SRTP) profile extensions [RFC3711] are needed to
	provide media encryption, integrity protection, replay protection,		provide media encryption, integrity protection, replay protection,
	and a limited form of source authentication. WebRTC endpoints MUST		and a limited form of source authentication. WebRTC endpoints MUST
	NOT send packets using the basic RTP/AVP profile or the RTP/AVPF		NOT send packets using the basic RTP/AVP profile or the RTP/AVPF
	profile; they MUST employ the full RTP/SAVPF profile to protect all		profile; they MUST employ the full RTP/SAVPF profile to protect all
	RTP and RTCP packets that are generated. In other words,		RTP and RTCP packets that are generated. In other words,
	implementations MUST use SRTP and SRTCP. The RTP/SAVPF profile MUST		implementations MUST use SRTP and Secure RTCP (SRTCP). The RTP/SAVPF
	be configured using the cipher suites, DTLS-SRTP protection profiles,		profile MUST be configured using the cipher suites, DTLS-SRTP
	keying mechanisms, and other parameters described in [RFC8827].		protection profiles, keying mechanisms, and other parameters
			described in [RFC8827].
	4.3. Choice of RTP Payload Formats		4.3. Choice of RTP Payload Formats
	Mandatory-to-implement audio codecs and RTP payload formats for		Mandatory-to-implement audio codecs and RTP payload formats for
	WebRTC endpoints are defined in [RFC7874]. Mandatory-to-implement		WebRTC endpoints are defined in [RFC7874]. Mandatory-to-implement
	video codecs and RTP payload formats for WebRTC endpoints are defined		video codecs and RTP payload formats for WebRTC endpoints are defined
	in [RFC7742]. WebRTC endpoints MAY additionally implement any other		in [RFC7742]. WebRTC endpoints MAY additionally implement any other
	codec for which an RTP payload format and associated signaling has		codec for which an RTP payload format and associated signaling has
	been defined.		been defined.
	skipping to change at line 490 ¶		skipping to change at line 493 ¶
	defined in [RFC8858].		defined in [RFC8858].
	Note that the use of RTP and RTCP multiplexed onto a single		Note that the use of RTP and RTCP multiplexed onto a single
	transport-layer flow ensures that there is occasional traffic sent on		transport-layer flow ensures that there is occasional traffic sent on
	that port, even if there is no active media traffic. This can be		that port, even if there is no active media traffic. This can be
	useful to keep NAT bindings alive [RFC6263].		useful to keep NAT bindings alive [RFC6263].
	4.6. Reduced Size RTCP		4.6. Reduced Size RTCP
	RTCP packets are usually sent as compound RTCP packets, and [RFC3550]		RTCP packets are usually sent as compound RTCP packets, and [RFC3550]
	requires that those compound packets start with a Sender Report (SR)		requires that those compound packets start with an SR or RR packet.
	or Receiver Report (RR) packet. When using frequent RTCP feedback		When using frequent RTCP feedback messages under the RTP/AVPF profile
	messages under the RTP/AVPF profile [RFC4585], these statistics are		[RFC4585], these statistics are not needed in every packet, and they
	not needed in every packet, and they unnecessarily increase the mean		unnecessarily increase the mean RTCP packet size. This can limit the
	RTCP packet size. This can limit the frequency at which RTCP packets		frequency at which RTCP packets can be sent within the RTCP bandwidth
	can be sent within the RTCP bandwidth share.		share.
	To avoid this problem, [RFC5506] specifies how to reduce the mean		To avoid this problem, [RFC5506] specifies how to reduce the mean
	RTCP message size and allow for more frequent feedback. Frequent		RTCP message size and allow for more frequent feedback. Frequent
	feedback, in turn, is essential to make real-time applications		feedback, in turn, is essential to make real-time applications
	quickly aware of changing network conditions and to allow them to		quickly aware of changing network conditions and to allow them to
	adapt their transmission and encoding behavior. Implementations MUST		adapt their transmission and encoding behavior. Implementations MUST
	support sending and receiving noncompound RTCP feedback packets		support sending and receiving noncompound RTCP feedback packets
	[RFC5506]. Use of noncompound RTCP packets MUST be negotiated using		[RFC5506]. Use of noncompound RTCP packets MUST be negotiated using
	the signaling channel. If SDP is used for signaling, this		the signaling channel. If SDP is used for signaling, this
	negotiation MUST use the attributes defined in [RFC5506]. For		negotiation MUST use the attributes defined in [RFC5506]. For
	skipping to change at line 1042 ¶		skipping to change at line 1045 ¶
	effective congestion control is negotiated for media flowing in both		effective congestion control is negotiated for media flowing in both
	directions. If the IETF were to standardize both sender- and		directions. If the IETF were to standardize both sender- and
	receiver-based congestion control algorithms for WebRTC traffic in		receiver-based congestion control algorithms for WebRTC traffic in
	the future, the issues of interoperability, control, and ensuring		the future, the issues of interoperability, control, and ensuring
	that both directions of media flow are congestion controlled would		that both directions of media flow are congestion controlled would
	also need to be considered.		also need to be considered.
	8. WebRTC Use of RTP: Performance Monitoring		8. WebRTC Use of RTP: Performance Monitoring
	As described in Section 4.1, implementations are REQUIRED to generate		As described in Section 4.1, implementations are REQUIRED to generate
	RTCP Sender Report (SR) and Reception Report (RR) packets relating to		RTCP Sender Report (SR) and Receiver Report (RR) packets relating to
	the RTP packet streams they send and receive. These RTCP reports can		the RTP packet streams they send and receive. These RTCP reports can
	be used for performance monitoring purposes, since they include basic		be used for performance monitoring purposes, since they include basic
	packet-loss and jitter statistics.		packet-loss and jitter statistics.
	A large number of additional performance metrics are supported by the		A large number of additional performance metrics are supported by the
	RTCP Extended Reports (XR) framework; see [RFC3611] and [RFC6792].		RTCP Extended Reports (XR) framework; see [RFC3611] and [RFC6792].
	At the time of this writing, it is not clear what extended metrics		At the time of this writing, it is not clear what extended metrics
	are suitable for use in WebRTC, so there is no requirement that		are suitable for use in WebRTC, so there is no requirement that
	implementations generate RTCP XR packets. However, implementations		implementations generate RTCP XR packets. However, implementations
	that can use detailed performance monitoring data MAY generate RTCP		that can use detailed performance monitoring data MAY generate RTCP
	skipping to change at line 1144 ¶		skipping to change at line 1147 ¶
	an offer/answer exchange. RTP does not depend on SDP or the offer/		an offer/answer exchange. RTP does not depend on SDP or the offer/
	answer model but does require all the necessary parameters to be		answer model but does require all the necessary parameters to be
	agreed upon and provided to the RTP implementation. Note that in		agreed upon and provided to the RTP implementation. Note that in
	WebRTC, it will depend on the signaling model and API how these		WebRTC, it will depend on the signaling model and API how these
	parameters need to be configured, but they will need to either be set		parameters need to be configured, but they will need to either be set
	in the API or explicitly signaled between the peers.		in the API or explicitly signaled between the peers.
	11. WebRTC API Considerations		11. WebRTC API Considerations
	The WebRTC API [W3C.WebRTC] and the Media Capture and Streams API		The WebRTC API [W3C.WebRTC] and the Media Capture and Streams API
	[W3C-MEDIA-CAPTURE] define and use the concept of a MediaStream that		[W3C.WD-mediacapture-streams] define and use the concept of a
	consists of zero or more MediaStreamTracks. A MediaStreamTrack is an		MediaStream that consists of zero or more MediaStreamTracks. A
	individual stream of media from any type of media source, such as a		MediaStreamTrack is an individual stream of media from any type of
	microphone or a camera, but conceptual sources, like an audio mix or		media source, such as a microphone or a camera, but conceptual
	a video composition, are also possible. The MediaStreamTracks within		sources, like an audio mix or a video composition, are also possible.
	a MediaStream might need to be synchronized during playback.		The MediaStreamTracks within a MediaStream might need to be
			synchronized during playback.
	A MediaStreamTrack's realization in RTP, in the context of an		A MediaStreamTrack's realization in RTP, in the context of an
	RTCPeerConnection, consists of a source packet stream, identified by		RTCPeerConnection, consists of a source packet stream, identified by
	an SSRC, sent within an RTP session that is part of the		an SSRC, sent within an RTP session that is part of the
	RTCPeerConnection. The MediaStreamTrack can also result in		RTCPeerConnection. The MediaStreamTrack can also result in
	additional packet streams, and thus SSRCs, in the same RTP session.		additional packet streams, and thus SSRCs, in the same RTP session.
	These can be dependent packet streams from scalable encoding of the		These can be dependent packet streams from scalable encoding of the
	source stream associated with the MediaStreamTrack, if such a media		source stream associated with the MediaStreamTrack, if such a media
	encoder is used. They can also be redundancy packet streams; these		encoder is used. They can also be redundancy packet streams; these
	are created when applying Forward Error Correction (Section 6.2) or		are created when applying Forward Error Correction (Section 6.2) or
	skipping to change at line 1179 ¶		skipping to change at line 1183 ¶
	configuration will be identical between different MediaStreamTracks		configuration will be identical between different MediaStreamTracks
	sharing the same media source. If the encoding parameters and		sharing the same media source. If the encoding parameters and
	constraints are the same, an implementation could choose to use only		constraints are the same, an implementation could choose to use only
	one encoded stream to create the different RTP packet streams. Note		one encoded stream to create the different RTP packet streams. Note
	that such optimizations would need to take into account that the		that such optimizations would need to take into account that the
	constraints for one of the MediaStreamTracks can change at any		constraints for one of the MediaStreamTracks can change at any
	moment, meaning that the encoding configurations might no longer be		moment, meaning that the encoding configurations might no longer be
	identical, and two different encoder instances would then be needed.		identical, and two different encoder instances would then be needed.
	The same MediaStreamTrack can also be included in multiple		The same MediaStreamTrack can also be included in multiple
	MediaStreams, thus multiple sets of MediaStreams can implicitly need		MediaStreams; thus, multiple sets of MediaStreams can implicitly need
	to use the same synchronization base. To ensure that this works in		to use the same synchronization base. To ensure that this works in
	all cases and does not force an endpoint to disrupt the media by		all cases and does not force an endpoint to disrupt the media by
	changing synchronization base and CNAME during delivery of any		changing synchronization base and CNAME during delivery of any
	ongoing packet streams, all MediaStreamTracks and their associated		ongoing packet streams, all MediaStreamTracks and their associated
	SSRCs originating from the same endpoint need to be sent using the		SSRCs originating from the same endpoint need to be sent using the
	same CNAME within one RTCPeerConnection. This is motivating the use		same CNAME within one RTCPeerConnection. This is motivating the use
	of a single CNAME in Section 4.9.		of a single CNAME in Section 4.9.
	| The requirement to use the same CNAME for all SSRCs that		| The requirement to use the same CNAME for all SSRCs that
	| originate from the same endpoint does not require a middlebox		| originate from the same endpoint does not require a middlebox
	skipping to change at line 1316 ¶		skipping to change at line 1320 ¶
	An endpoint might send an RTP packet stream that is somehow		An endpoint might send an RTP packet stream that is somehow
	associated with another stream. For example, it might send an RTP		associated with another stream. For example, it might send an RTP
	packet stream that contains FEC or retransmission data relating to		packet stream that contains FEC or retransmission data relating to
	another stream. Some RTP payload formats send this sort of		another stream. Some RTP payload formats send this sort of
	associated repair data as part of the source packet stream, while		associated repair data as part of the source packet stream, while
	others send it as a separate packet stream.		others send it as a separate packet stream.
	* Layered or multiple-description coding:		* Layered or multiple-description coding:
	Within a single RTP session, an endpoint can use a layered media		Within a single RTP session, an endpoint can use a layered media
	codec -- for example, H.264 SVC -- or a multiple-description codec		codec -- for example, H.264 Scalable Video Coding (SVC) -- or a
	that generates multiple RTP packet streams, each with a distinct		multiple-description codec that generates multiple RTP packet
	RTP SSRC.		streams, each with a distinct RTP SSRC.
	* RTP mixers, translators, and other middleboxes:		* RTP mixers, translators, and other middleboxes:
	An RTP session, in the WebRTC context, is a point-to-point		An RTP session, in the WebRTC context, is a point-to-point
	association between an endpoint and some other peer device, where		association between an endpoint and some other peer device, where
	those devices share a common SSRC space. The peer device might be		those devices share a common SSRC space. The peer device might be
	another WebRTC endpoint, or it might be an RTP mixer, translator,		another WebRTC endpoint, or it might be an RTP mixer, translator,
	or some other form of media-processing middlebox. In the latter		or some other form of media-processing middlebox. In the latter
	cases, the middlebox might send mixed or relayed RTP streams from		cases, the middlebox might send mixed or relayed RTP streams from
	several participants, which the WebRTC endpoint will need to		several participants, which the WebRTC endpoint will need to
	skipping to change at line 2011 ¶		skipping to change at line 2015 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General		[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
	Mechanism for RTP Header Extensions", RFC 8285,		Mechanism for RTP Header Extensions", RFC 8285,
	DOI 10.17487/RFC8285, October 2017,		DOI 10.17487/RFC8285, October 2017,
	<https://www.rfc-editor.org/info/rfc8285>.		<https://www.rfc-editor.org/info/rfc8285>.
	[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for		[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
	Browser-Based Applications", RFC 8825,		Browser-Based Applications", RFC 8825,
	DOI 10.17487/RFC8825, December 2020,		DOI 10.17487/RFC8825, January 2021,
	<https://www.rfc-editor.org/info/rfc8825>.		<https://www.rfc-editor.org/info/rfc8825>.
	[RFC8826] Rescorla, E., "Security Considerations for WebRTC",		[RFC8826] Rescorla, E., "Security Considerations for WebRTC",
	RFC 8826, DOI 10.17487/RFC8826, December 2020,		RFC 8826, DOI 10.17487/RFC8826, January 2021,
	<https://www.rfc-editor.org/info/rfc8826>.		<https://www.rfc-editor.org/info/rfc8826>.
	[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,		[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
	DOI 10.17487/RFC8827, December 2020,		DOI 10.17487/RFC8827, January 2021,
	<https://www.rfc-editor.org/info/rfc8827>.		<https://www.rfc-editor.org/info/rfc8827>.
	[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,		[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
	"Negotiating Media Multiplexing Using the Session		"Negotiating Media Multiplexing Using the Session
	Description Protocol (SDP)", RFC 8843,		Description Protocol (SDP)", RFC 8843,
	DOI 10.17487/RFC8843, December 2020,		DOI 10.17487/RFC8843, January 2021,
	<https://www.rfc-editor.org/info/rfc8843>.		<https://www.rfc-editor.org/info/rfc8843>.
	[RFC8854] Uberti, J., "WebRTC Forward Error Correction		[RFC8854] Uberti, J., "WebRTC Forward Error Correction
	Requirements", RFC 8854, DOI 10.17487/RFC8854, December		Requirements", RFC 8854, DOI 10.17487/RFC8854, January
	2020, <https://www.rfc-editor.org/info/rfc8854>.		2021, <https://www.rfc-editor.org/info/rfc8854>.
	[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP		[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP
	Control Protocol (RTCP) Multiplexing Using the Session		Control Protocol (RTCP) Multiplexing Using the Session
	Description Protocol (SDP)", RFC 8858,		Description Protocol (SDP)", RFC 8858,
	DOI 10.17487/RFC8858, December 2020,		DOI 10.17487/RFC8858, January 2021,
	<https://www.rfc-editor.org/info/rfc8858>.		<https://www.rfc-editor.org/info/rfc8858>.
	[RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending		[RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending
	Multiple Types of Media in a Single RTP Session",		Multiple Types of Media in a Single RTP Session",
	RFC 8860, DOI 10.17487/RFC8860, December 2020,		RFC 8860, DOI 10.17487/RFC8860, January 2021,
	<https://www.rfc-editor.org/info/rfc8860>.		<https://www.rfc-editor.org/info/rfc8860>.
	[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,		[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	"Sending Multiple RTP Streams in a Single RTP Session:		"Sending Multiple RTP Streams in a Single RTP Session:
	Grouping RTP Control Protocol (RTCP) Reception Statistics		Grouping RTP Control Protocol (RTCP) Reception Statistics
	and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,		and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
	December 2020, <https://www.rfc-editor.org/info/rfc8861>.		January 2021, <https://www.rfc-editor.org/info/rfc8861>.
	[W3C-MEDIA-CAPTURE]		[W3C.WD-mediacapture-streams]
	Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A.,		Jennings, C., Aboba, B., Bruaroey, J-I., and H. Boström,
	Aboba, B., Bruaroey, J-I., and H. Boström, "Media Capture		"Media Capture and Streams", W3C Candidate Recommendation,
	and Streams", W3C Candidate Recommendation, 2 July 2019,		<https://www.w3.org/TR/mediacapture-streams/>.
	<https://www.w3.org/TR/2019/CR-mediacapture-streams-
	20190702/>.
	[W3C.WebRTC]		[W3C.WebRTC]
	Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:		Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
	Real-time Communication Between Browsers", W3C Candidate		Real-time Communication Between Browsers", W3C Proposed
	Recommendation, <https://www.w3.org/TR/webrtc/>.		Recommendation, <https://www.w3.org/TR/webrtc/>.
	15.2. Informative References		15.2. Informative References
	[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,		[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
	"RTP Control Protocol Extended Reports (RTCP XR)",		"RTP Control Protocol Extended Reports (RTCP XR)",
	RFC 3611, DOI 10.17487/RFC3611, November 2003,		RFC 3611, DOI 10.17487/RFC3611, November 2003,
	<https://www.rfc-editor.org/info/rfc3611>.		<https://www.rfc-editor.org/info/rfc3611>.
	[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient		[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
	skipping to change at line 2126 ¶		skipping to change at line 2128 ¶
	<https://www.rfc-editor.org/info/rfc8088>.		<https://www.rfc-editor.org/info/rfc8088>.
	[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive		[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network		Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", RFC 8445,		Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC8445, July 2018,		DOI 10.17487/RFC8445, July 2018,
	<https://www.rfc-editor.org/info/rfc8445>.		<https://www.rfc-editor.org/info/rfc8445>.
	[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,		[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
	"JavaScript Session Establishment Protocol (JSEP)",		"JavaScript Session Establishment Protocol (JSEP)",
	RFC 8829, DOI 10.17487/RFC8829, December 2020,		RFC 8829, DOI 10.17487/RFC8829, January 2021,
	<https://www.rfc-editor.org/info/rfc8829>.		<https://www.rfc-editor.org/info/rfc8829>.
	[RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the		[RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the
	Session Description Protocol", RFC 8830,		Session Description Protocol", RFC 8830,
	DOI 10.17487/RFC8830, December 2020,		DOI 10.17487/RFC8830, January 2021,
	<https://www.rfc-editor.org/info/rfc8830>.		<https://www.rfc-editor.org/info/rfc8830>.
	[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control		[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
	Requirements for Interactive Real-Time Media", RFC 8836,		Requirements for Interactive Real-Time Media", RFC 8836,
	DOI 10.17487/RFC8836, December 2020,		DOI 10.17487/RFC8836, January 2021,
	<https://www.rfc-editor.org/info/rfc8836>.		<https://www.rfc-editor.org/info/rfc8836>.
	[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta,		[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
	"Differentiated Services Code Point (DSCP) Packet Markings		"Differentiated Services Code Point (DSCP) Packet Markings
	for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, December		for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
	2020, <https://www.rfc-editor.org/info/rfc8837>.		2021, <https://www.rfc-editor.org/info/rfc8837>.
	[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,		[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
	and R. Even, "Guidelines for Using the Multiplexing		and R. Even, "Guidelines for Using the Multiplexing
	Features of RTP to Support Multiple Media Streams",		Features of RTP to Support Multiple Media Streams",
	RFC 8872, DOI 10.17487/RFC8872, December 2020,		RFC 8872, DOI 10.17487/RFC8872, January 2021,
	<https://www.rfc-editor.org/info/rfc8872>.		<https://www.rfc-editor.org/info/rfc8872>.
	Acknowledgements		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, Alissa Cooper, Spencer Dawkins, Charles		Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles
	Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen		Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen
	Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim		Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim
	Spring, Martin Thomson, and the other members of the IETF RTCWEB		Spring, Martin Thomson, and the other members of the IETF RTCWEB
	working group for their valuable feedback.		working group for their valuable feedback.
	skipping to change at line 2173 ¶		skipping to change at line 2175 ¶
	School of Computing Science		School of Computing Science
	Glasgow		Glasgow
	G12 8QQ		G12 8QQ
	United Kingdom		United Kingdom
	Email: csp@csperkins.org		Email: csp@csperkins.org
	URI: https://csperkins.org/		URI: https://csperkins.org/
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
	Torshamsgatan 23		Torshamnsgatan 23
	SE-164 80 Kista		SE-164 80 Kista
	Sweden		Sweden
	Email: magnus.westerlund@ericsson.com		Email: magnus.westerlund@ericsson.com
	Jörg Ott		Jörg Ott
	Aalto University		Technical University Munich
	School of Electrical Engineering		Department of Informatics
	FI-02150 Espoo		Chair of Connected Mobility
	Finland		Boltzmannstrasse 3
			85748 Garching
			Germany
	Email: jorg.ott@aalto.fi		Email: ott@in.tum.de
End of changes. 29 change blocks.
	66 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/