draft-ietf-rtcweb-rtp-usage-25.txt		draft-ietf-rtcweb-rtp-usage-26.txt
	RTCWEB Working Group C. 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: December 14, 2015 Ericsson		Expires: September 18, 2016 Ericsson
	J. Ott		J. Ott
	Aalto University		Aalto University
	June 12, 2015		March 17, 2016
	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-25		draft-ietf-rtcweb-rtp-usage-26
	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 December 14, 2015.		This Internet-Draft will expire on September 18, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	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 page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21		7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21
	7.2. Congestion Control Interoperability and Legacy Systems . 22		7.2. Congestion Control Interoperability and Legacy Systems . 22
	8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22		8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22
	9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23		9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23
	10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23		10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23
	11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25		11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25
	12. RTP Implementation Considerations . . . . . . . . . . . . . . 27		12. RTP Implementation Considerations . . . . . . . . . . . . . . 27
	12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27		12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27
	12.1.1. Use of Multiple Media Sources Within an RTP Session 27		12.1.1. Use of Multiple Media Sources Within an RTP Session 27
	12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28		12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28
	12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33		12.1.3. Differentiated Treatment of RTP Streams . . . . . . 33
	12.2. Media Source, RTP Packet Streams, and Participant		12.2. Media Source, RTP Streams, and Participant
	Identification . . . . . . . . . . . . . . . . . . . . . 35		Identification . . . . . . . . . . . . . . . . . . . . . 35
	12.2.1. Media Source Identification . . . . . . . . . . . . 35		12.2.1. Media Source Identification . . . . . . . . . . . . 35
	12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36		12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36
	12.2.3. Media Synchronisation Context . . . . . . . . . . . 37		12.2.3. Media Synchronisation Context . . . . . . . . . . . 37
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 37		13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	16.1. Normative References . . . . . . . . . . . . . . . . . . 39		16.1. Normative References . . . . . . . . . . . . . . . . . . 39
	16.2. Informative References . . . . . . . . . . . . . . . . . 43		16.2. Informative References . . . . . . . . . . . . . . . . . 44
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
	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 5, line 31 ¶		skipping to change at page 5, line 31 ¶
	layer flow is a transport-layer flow that is symmetric. That is,		layer flow is a transport-layer flow that is symmetric. That is,
	the transport-layer flow in the reverse direction has a 5-tuple		the transport-layer flow in the reverse direction has a 5-tuple
	where the source and destination address and ports are swapped		where the source and destination address and ports are swapped
	compared to the forward path transport-layer flow, and the		compared to the forward path transport-layer flow, and the
	transport protocol is the same.		transport protocol is the same.
	This document uses the terminology from		This document uses the terminology from
	[I-D.ietf-avtext-rtp-grouping-taxonomy] and		[I-D.ietf-avtext-rtp-grouping-taxonomy] and
	[I-D.ietf-rtcweb-overview]. Other terms are used according to their		[I-D.ietf-rtcweb-overview]. Other terms are used according to their
	definitions from the RTP Specification [RFC3550]. Especially note		definitions from the RTP Specification [RFC3550]. Especially note
	the following frequently used terms: RTP Packet Stream, RTP Session,		the following frequently used terms: RTP Stream, RTP Session, and
	and Endpoint.		Endpoint.
	4. WebRTC Use of RTP: Core Protocols		4. WebRTC Use of RTP: Core Protocols
	The following sections describe the core features of RTP and RTCP		The following sections describe the core features of RTP and RTCP
	that need to be implemented, along with the mandated RTP profiles.		that need to be implemented, along with the mandated RTP profiles.
	Also described are the core extensions providing essential features		Also described are the core extensions providing essential features
	that all WebRTC Endpoints need to implement to function effectively		that all WebRTC Endpoints need to implement to function effectively
	on today's networks.		on today's networks.
	4.1. RTP and RTCP		4.1. RTP and RTCP
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 33 ¶
	o Support for multiple synchronisation contexts. Participants that		o Support for multiple synchronisation contexts. Participants that
	send multiple simultaneous RTP packet streams SHOULD do so as part		send multiple simultaneous RTP packet streams SHOULD do so as part
	of a single synchronisation context, using a single RTCP CNAME for		of a single synchronisation 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
	synchronised manner. For compatibility with potential future		synchronised 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
	synchronisation contexts, indicated by the use of multiple RTCP		synchronisation contexts, indicated by the use of multiple RTCP
	CNAMEs in an RTP session. This specification mandates the usage		CNAMEs in an RTP session. This specification mandates the usage
	of a single CNAME when sending RTP Packet Streams in some		of a single CNAME when sending RTP Streams in some circumstances,
	circumstances, see Section 4.9.		see Section 4.9.
	o Support for sending and receiving RTCP SR, RR, SDES, and BYE		o Support for sending and receiving RTCP SR, RR, SDES, and BYE
	packet types. Note that support for other RTCP packet types is		packet types. Note that support for other RTCP packet types is
	OPTIONAL, unless mandated by other parts of this specification.		OPTIONAL, unless mandated by other parts of this specification.
	Note that additional RTCP Packet types are used by the RTP/SAVPF		Note that additional RTCP Packet types are used by the RTP/SAVPF
	Profile (Section 4.2) and the other RTCP extensions (Section 5).		Profile (Section 4.2) and the other RTCP extensions (Section 5).
	WebRTC endpoints that implement the SDP bundle negotiation		WebRTC endpoints that implement the SDP bundle negotiation
	extension will use the SDP grouping framework 'mid' attribute to		extension will use the SDP grouping framework 'mid' attribute to
	identify media streams. Such endpoints MUST implement the RTCP		identify media streams. Such endpoints MUST implement the RTCP
	SDES MID item described in		SDES MID item described in
	skipping to change at page 11, line 8 ¶		skipping to change at page 11, line 8 ¶
	flows (e.g., two UDP ports for each RTP session, one port for RTP and		flows (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/Port		one port for RTCP). With the increased use of Network Address/Port
	Translation (NAT/NAPT) this has become problematic, since maintaining		Translation (NAT/NAPT) this has become problematic, since maintaining
	multiple NAT bindings can be costly. It also complicates firewall		multiple NAT bindings can be costly. It also complicates firewall
	administration, since multiple ports need to be opened to allow RTP		administration, since multiple ports need to be opened to allow RTP
	traffic. To reduce these costs and session set-up times,		traffic. To reduce these costs and session set-up times,
	implementations are REQUIRED to support multiplexing RTP data packets		implementations are REQUIRED to support multiplexing RTP data packets
	and RTCP control packets on a single transport-layer flow [RFC5761].		and RTCP control packets on a single transport-layer flow [RFC5761].
	Such RTP and RTCP multiplexing MUST be negotiated in the signalling		Such RTP and RTCP multiplexing MUST be negotiated in the signalling
	channel before it is used. If SDP is used for signalling, this		channel before it is used. If SDP is used for signalling, this
	negotiation MUST use the attributes defined in [RFC5761]. For		negotiation MUST use the mechanism defined in [RFC5761].
	backwards compatibility, implementations are also REQUIRED to support		Implementations can also support sending RTP and RTCP on separate
	RTP and RTCP sent on separate transport-layer flows.		transport-layer flows, but this is OPTIONAL to implement. If an
			implementation does not support RTP and RTCP sent on separate
			transport-layer flows, it MUST indicate that using the mechanism
			defined in [I-D.ietf-mmusic-mux-exclusive].
	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 an Sender Report (SR)		requires that those compound packets start with an Sender Report (SR)
	skipping to change at page 33, line 15 ¶		skipping to change at page 33, line 15 ¶
	transcoding does result in a separation of the two different legs		transcoding does result in a separation of the two different legs
	removing almost all dependencies, and allowing the forwarding		removing almost all dependencies, and allowing the forwarding
	endpoint to optimise its media transcoding operation. The cost is		endpoint to optimise its media transcoding operation. The cost is
	greatly increased computational complexity on the forwarding node.		greatly increased computational complexity on the forwarding node.
	Receivers of the forwarded stream will see the forwarding device		Receivers of the forwarded stream will see the forwarding device
	as the sender of the stream, and will not be able to tell from the		as the sender of the stream, and will not be able to tell from the
	RTP layer that they are receiving a forwarded stream rather than		RTP layer that they are receiving a forwarded stream rather than
	an entirely new RTP packet stream generated by the forwarding		an entirely new RTP packet stream generated by the forwarding
	device.		device.
	12.1.3. Differentiated Treatment of RTP Packet Streams		12.1.3. Differentiated Treatment of RTP Streams
	There are use cases for differentiated treatment of RTP packet		There are use cases for differentiated treatment of RTP packet
	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 endpoint		system. First of all is the prioritization within the endpoint
	sending the media, which controls, both which RTP packet streams that		sending the media, which controls, both which RTP packet 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 [W3C.WD-webrtc-20130910] will		It is expected that the WebRTC API [W3C.WD-webrtc-20130910] will
	allow the application to indicate relative priorities for different		allow the application to indicate relative priorities for different
	skipping to change at page 35, line 18 ¶		skipping to change at page 35, line 18 ¶
	particular RTP packet stream need to be marked. RTCP compound		particular RTP packet stream need to be marked. RTCP compound
	packets with Sender Reports (SR), ought to be marked with the same		packets with Sender Reports (SR), ought to be marked with the same
	priority as the RTP packet stream itself, so the RTCP-based round-		priority as the RTP packet stream itself, so the RTCP-based round-
	trip time (RTT) measurements are done using the same transport-layer		trip time (RTT) measurements are done using the same transport-layer
	flow priority as the RTP packet stream experiences. RTCP compound		flow priority as the RTP packet stream experiences. RTCP compound
	packets containing RR packet ought to be sent with the priority used		packets containing RR packet ought to be sent with the priority used
	by the majority of the RTP packet streams reported on. RTCP packets		by the majority of the RTP packet streams reported on. RTCP packets
	containing time-critical feedback packets can use higher priority to		containing time-critical feedback packets can use higher priority to
	improve the timeliness and likelihood of delivery of such feedback.		improve the timeliness and likelihood of delivery of such feedback.
	12.2. Media Source, RTP Packet Streams, and Participant Identification		12.2. Media Source, RTP Streams, and Participant Identification
	12.2.1. Media Source Identification		12.2.1. Media Source Identification
	Each RTP packet stream is identified by a unique synchronisation		Each RTP packet stream is identified by a unique synchronisation
	source (SSRC) identifier. The SSRC identifier is carried in each of		source (SSRC) identifier. The SSRC identifier is carried in each of
	the RTP packets comprising a RTP packet stream, and is also used to		the RTP packets comprising a RTP packet stream, and is also used to
	identify that stream in the corresponding RTCP reports. The SSRC is		identify that stream in the corresponding RTCP reports. The SSRC is
	chosen as discussed in Section 4.8. The first stage in		chosen as discussed in Section 4.8. The first stage in
	demultiplexing RTP and RTCP packets received on a single transport		demultiplexing RTP and RTCP packets received on a single transport
	layer flow at a WebRTC Endpoint is to separate the RTP packet streams		layer flow at a WebRTC Endpoint is to separate the RTP packet streams
	skipping to change at page 39, line 51 ¶		skipping to change at page 39, line 51 ¶
	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.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[I-D.ietf-avtcore-multi-media-rtp-session]		[I-D.ietf-avtcore-multi-media-rtp-session]
	Westerlund, M., Perkins, C., and J. Lennox, "Sending		Westerlund, M., Perkins, C., and J. Lennox, "Sending
	Multiple Types of Media in a Single RTP Session", draft-		Multiple Types of Media in a Single RTP Session", draft-
	ietf-avtcore-multi-media-rtp-session-07 (work in		ietf-avtcore-multi-media-rtp-session-13 (work in
	progress), March 2015.		progress), December 2015.
	[I-D.ietf-avtcore-rtp-circuit-breakers]		[I-D.ietf-avtcore-rtp-circuit-breakers]
	Perkins, C. and V. Singh, "Multimedia Congestion Control:		Perkins, C. and V. Varun, "Multimedia Congestion Control:
	Circuit Breakers for Unicast RTP Sessions", draft-ietf-		Circuit Breakers for Unicast RTP Sessions", draft-ietf-
	avtcore-rtp-circuit-breakers-10 (work in progress), March		avtcore-rtp-circuit-breakers-13 (work in progress),
	2015.		February 2016.
	[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, Q., and C. Perkins,
	"Sending Multiple Media Streams in a Single RTP Session",		"Sending Multiple RTP Streams in a Single RTP Session",
	draft-ietf-avtcore-rtp-multi-stream-07 (work in progress),		draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
	March 2015.		December 2015.
	[I-D.ietf-avtcore-rtp-multi-stream-optimisation]		[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
	Lennox, J., Westerlund, M., Wu, W., and C. Perkins,		Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	"Sending Multiple Media Streams in a Single RTP Session:		"Sending Multiple RTP 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-05 (work		draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work
	in progress), February 2015.		in progress), March 2016.
	[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-07 (work in progress),		ietf-avtcore-rtp-topologies-update-10 (work in progress),
	April 2015.		July 2015.
			[I-D.ietf-mmusic-mux-exclusive]
			Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
			Multiplexing using SDP", draft-ietf-mmusic-mux-
			exclusive-03 (work in progress), February 2016.
	[I-D.ietf-mmusic-sdp-bundle-negotiation]		[I-D.ietf-mmusic-sdp-bundle-negotiation]
	Holmberg, C., Alvestrand, H., and C. Jennings,		Holmberg, C., Alvestrand, H., and C. Jennings,
	"Negotiating Media Multiplexing Using the Session		"Negotiating Media Multiplexing Using the Session
	Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-		Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
	negotiation-19 (work in progress), March 2015.		negotiation-27 (work in progress), February 2016.
	[I-D.ietf-rtcweb-audio]		[I-D.ietf-rtcweb-audio]
	Valin, J. and C. Bran, "WebRTC Audio Codec and Processing		Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
	Requirements", draft-ietf-rtcweb-audio-08 (work in		Requirements", draft-ietf-rtcweb-audio-10 (work in
	progress), April 2015.		progress), February 2016.
	[I-D.ietf-rtcweb-fec]		[I-D.ietf-rtcweb-fec]
	Uberti, J., "WebRTC Forward Error Correction		Uberti, J., "WebRTC Forward Error Correction
	Requirements", draft-ietf-rtcweb-fec-01 (work in		Requirements", draft-ietf-rtcweb-fec-02 (work in
	progress), March 2015.		progress), October 2015.
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-13		Browser-based Applications", draft-ietf-rtcweb-overview-15
	(work in progress), November 2014.		(work in progress), January 2016.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-08 (work in progress), February 2015.		ietf-rtcweb-security-08 (work in progress), February 2015.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-11 (work in progress), March 2015.		rtcweb-security-arch-11 (work in progress), March 2015.
	[I-D.ietf-rtcweb-video]		[I-D.ietf-rtcweb-video]
	Roach, A., "WebRTC Video Processing and Codec		Roach, A., "WebRTC Video Processing and Codec
	Requirements", draft-ietf-rtcweb-video-05 (work in		Requirements", draft-ietf-rtcweb-video-06 (work in
	progress), March 2015.		progress), June 2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP		[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
	Payload Format Specifications", BCP 36, RFC 2736, December		Payload Format Specifications", BCP 36, RFC 2736,
	1999.		DOI 10.17487/RFC2736, December 1999,
			<http://www.rfc-editor.org/info/rfc2736>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
			July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and		[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
	Video Conferences with Minimal Control", STD 65, RFC 3551,		Video Conferences with Minimal Control", STD 65, RFC 3551,
	July 2003.		DOI 10.17487/RFC3551, July 2003,
			<http://www.rfc-editor.org/info/rfc3551>.
	[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth		[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
	Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC		Modifiers for RTP Control Protocol (RTCP) Bandwidth",
	3556, July 2003.		RFC 3556, DOI 10.17487/RFC3556, July 2003,
			<http://www.rfc-editor.org/info/rfc3556>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.		RFC 3711, DOI 10.17487/RFC3711, March 2004,
			<http://www.rfc-editor.org/info/rfc3711>.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
			July 2006, <http://www.rfc-editor.org/info/rfc4566>.
	[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
	2006.		DOI 10.17487/RFC4585, July 2006,
			<http://www.rfc-editor.org/info/rfc4585>.
	[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.		[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
	Hakenberg, "RTP Retransmission Payload Format", RFC 4588,		Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
	July 2006.		DOI 10.17487/RFC4588, July 2006,
			<http://www.rfc-editor.org/info/rfc4588>.
	[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",		[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
	BCP 131, RFC 4961, July 2007.		BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
			<http://www.rfc-editor.org/info/rfc4961>.
	[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,		[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
	"Codec Control Messages in the RTP Audio-Visual Profile		"Codec Control Messages in the RTP Audio-Visual Profile
	with Feedback (AVPF)", RFC 5104, February 2008.		with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
			February 2008, <http://www.rfc-editor.org/info/rfc5104>.
	[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for		[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
	Real-time Transport Control Protocol (RTCP)-Based Feedback		Real-time Transport Control Protocol (RTCP)-Based Feedback
	(RTP/SAVPF)", RFC 5124, February 2008.		(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
			2008, <http://www.rfc-editor.org/info/rfc5124>.
	[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP		[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
	Header Extensions", RFC 5285, July 2008.		Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
			2008, <http://www.rfc-editor.org/info/rfc5285>.
	[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size		[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
	Real-Time Transport Control Protocol (RTCP): Opportunities		Real-Time Transport Control Protocol (RTCP): Opportunities
	and Consequences", RFC 5506, April 2009.		and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
			2009, <http://www.rfc-editor.org/info/rfc5506>.
	[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and		[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
	Control Packets on a Single Port", RFC 5761, April 2010.		Control Packets on a Single Port", RFC 5761,
			DOI 10.17487/RFC5761, April 2010,
			<http://www.rfc-editor.org/info/rfc5761>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764,
			DOI 10.17487/RFC5764, May 2010,
			<http://www.rfc-editor.org/info/rfc5764>.
	[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP		[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
	Flows", RFC 6051, November 2010.		Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
			<http://www.rfc-editor.org/info/rfc6051>.
	[RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time		[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
	Transport Protocol (RTP) Header Extension for Client-to-		Transport Protocol (RTP) Header Extension for Client-to-
	Mixer Audio Level Indication", RFC 6464, December 2011.		Mixer Audio Level Indication", RFC 6464,
			DOI 10.17487/RFC6464, December 2011,
			<http://www.rfc-editor.org/info/rfc6464>.
	[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time		[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
	Transport Protocol (RTP) Header Extension for Mixer-to-		time Transport Protocol (RTP) Header Extension for Mixer-
	Client Audio Level Indication", RFC 6465, December 2011.		to-Client Audio Level Indication", RFC 6465,
			DOI 10.17487/RFC6465, December 2011,
			<http://www.rfc-editor.org/info/rfc6465>.
	[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of		[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
	Variable Bit Rate Audio with Secure RTP", RFC 6562, March		Variable Bit Rate Audio with Secure RTP", RFC 6562,
	2012.		DOI 10.17487/RFC6562, March 2012,
			<http://www.rfc-editor.org/info/rfc6562>.
	[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure		[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
	Real-time Transport Protocol (SRTP)", RFC 6904, April		Real-time Transport Protocol (SRTP)", RFC 6904,
	2013.		DOI 10.17487/RFC6904, April 2013,
			<http://www.rfc-editor.org/info/rfc6904>.
	[RFC7007] Terriberry, T., "Update to Remove DVI4 from the		[RFC7007] Terriberry, T., "Update to Remove DVI4 from the
	Recommended Codecs for the RTP Profile for Audio and Video		Recommended Codecs for the RTP Profile for Audio and Video
	Conferences with Minimal Control (RTP/AVP)", RFC 7007,		Conferences with Minimal Control (RTP/AVP)", RFC 7007,
	August 2013.		DOI 10.17487/RFC7007, August 2013,
			<http://www.rfc-editor.org/info/rfc7007>.
	[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,		[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
	"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, DOI 10.17487/RFC7022,
			September 2013, <http://www.rfc-editor.org/info/rfc7022>.
	[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple		[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
	Clock Rates in an RTP Session", RFC 7160, April 2014.		Clock Rates in an RTP Session", RFC 7160,
			DOI 10.17487/RFC7160, April 2014,
			<http://www.rfc-editor.org/info/rfc7160>.
	[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC		[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
	7164, March 2014.		RFC 7164, DOI 10.17487/RFC7164, March 2014,
			<http://www.rfc-editor.org/info/rfc7164>.
	[W3C.WD-mediacapture-streams-20130903]		[W3C.WD-mediacapture-streams-20130903]
	Burnett, D., Bergkvist, A., Jennings, C., and A.		Burnett, D., Bergkvist, A., Jennings, C., and A.
	Narayanan, "Media Capture and Streams", World Wide Web		Narayanan, "Media Capture and Streams", World Wide Web
	Consortium WD WD-mediacapture-streams-20130903, September		Consortium WD WD-mediacapture-streams-20130903, September
	2013, <http://www.w3.org/TR/2013/		2013, <http://www.w3.org/TR/2013/
	WD-mediacapture-streams-20130903>.		WD-mediacapture-streams-20130903>.
	[W3C.WD-webrtc-20130910]		[W3C.WD-webrtc-20130910]
	Bergkvist, A., Burnett, D., Jennings, C., and A.		Bergkvist, A., Burnett, D., Jennings, C., and A.
	skipping to change at page 43, line 39 ¶		skipping to change at page 44, line 29 ¶
	16.2. Informative References		16.2. Informative References
	[I-D.ietf-avtcore-multiplex-guidelines]		[I-D.ietf-avtcore-multiplex-guidelines]
	Westerlund, M., Perkins, C., and H. Alvestrand,		Westerlund, M., Perkins, C., and H. Alvestrand,
	"Guidelines for using the Multiplexing Features of RTP to		"Guidelines for using the Multiplexing Features of RTP to
	Support Multiple Media Streams", draft-ietf-avtcore-		Support Multiple Media Streams", draft-ietf-avtcore-
	multiplex-guidelines-03 (work in progress), October 2014.		multiplex-guidelines-03 (work in progress), October 2014.
	[I-D.ietf-avtext-rtp-grouping-taxonomy]		[I-D.ietf-avtext-rtp-grouping-taxonomy]
	Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and		Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
	B. Burman, "A Taxonomy of Grouping Semantics and		B. Burman, "A Taxonomy of Semantics and Mechanisms for
	Mechanisms for Real-Time Transport Protocol (RTP)		Real-Time Transport Protocol (RTP) Sources", draft-ietf-
	Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work		avtext-rtp-grouping-taxonomy-08 (work in progress), July
	in progress), March 2015.		2015.
	[I-D.ietf-dart-dscp-rtp]		[I-D.ietf-dart-dscp-rtp]
	Black, D. and P. Jones, "Differentiated Services		Black, D. and P. Jones, "Differentiated Services
	(DiffServ) and Real-time Communication", draft-ietf-dart-		(DiffServ) and Real-time Communication", draft-ietf-dart-
	dscp-rtp-10 (work in progress), November 2014.		dscp-rtp-10 (work in progress), November 2014.
	[I-D.ietf-mmusic-msid]		[I-D.ietf-mmusic-msid]
	Alvestrand, H., "WebRTC MediaStream Identification in the		Alvestrand, H., "WebRTC MediaStream Identification in the
	Session Description Protocol", draft-ietf-mmusic-msid-10		Session Description Protocol", draft-ietf-mmusic-msid-11
	(work in progress), April 2015.		(work in progress), October 2015.
	[I-D.ietf-payload-rtp-howto]		[I-D.ietf-payload-rtp-howto]
	Westerlund, M., "How to Write an RTP Payload Format",		Westerlund, M., "How to Write an RTP Payload Format",
	draft-ietf-payload-rtp-howto-14 (work in progress), May		draft-ietf-payload-rtp-howto-14 (work in progress), May
	2015.		2015.
	[I-D.ietf-rmcat-cc-requirements]		[I-D.ietf-rmcat-cc-requirements]
	Jesup, R. and Z. Sarker, "Congestion Control Requirements		Jesup, R. and Z. Sarker, "Congestion Control Requirements
	for Interactive Real-Time Media", draft-ietf-rmcat-cc-		for Interactive Real-Time Media", draft-ietf-rmcat-cc-
	requirements-09 (work in progress), December 2014.		requirements-09 (work in progress), December 2014.
	[I-D.ietf-rtcweb-jsep]		[I-D.ietf-rtcweb-jsep]
	Uberti, J., Jennings, C., and E. Rescorla, "Javascript		Uberti, J., Jennings, C., and E. Rescorla, "Javascript
	Session Establishment Protocol", draft-ietf-rtcweb-jsep-09		Session Establishment Protocol", draft-ietf-rtcweb-jsep-13
	(work in progress), March 2015.		(work in progress), March 2016.
	[I-D.ietf-tsvwg-rtcweb-qos]		[I-D.ietf-tsvwg-rtcweb-qos]
	Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.		Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
	Polk, "DSCP and other packet markings for RTCWeb QoS",		and other packet markings for WebRTC QoS", draft-ietf-
	draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),		tsvwg-rtcweb-qos-14 (work in progress), March 2016.
	November 2014.
	[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control		[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
	Protocol Extended Reports (RTCP XR)", RFC 3611, November		"RTP Control Protocol Extended Reports (RTCP XR)",
	2003.		RFC 3611, DOI 10.17487/RFC3611, November 2003,
			<http://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
	Stream Loss-Tolerant Authentication (TESLA) in the Secure		Stream Loss-Tolerant Authentication (TESLA) in the Secure
	Real-time Transport Protocol (SRTP)", RFC 4383, February		Real-time Transport Protocol (SRTP)", RFC 4383,
	2006.		DOI 10.17487/RFC4383, February 2006,
			<http://www.rfc-editor.org/info/rfc4383>.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245,
	2010.		DOI 10.17487/RFC5245, April 2010,
			<http://www.rfc-editor.org/info/rfc5245>.
	[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific		[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
	Media Attributes in the Session Description Protocol		Media Attributes in the Session Description Protocol
	(SDP)", RFC 5576, June 2009.		(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
			<http://www.rfc-editor.org/info/rfc5576>.
	[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP		[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
	Control Protocol (RTCP)", RFC 5968, September 2010.		Control Protocol (RTCP)", RFC 5968, DOI 10.17487/RFC5968,
			September 2010, <http://www.rfc-editor.org/info/rfc5968>.
	[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for		[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
	Keeping Alive the NAT Mappings Associated with RTP / RTP		Keeping Alive the NAT Mappings Associated with RTP / RTP
	Control Protocol (RTCP) Flows", RFC 6263, June 2011.		Control Protocol (RTCP) Flows", RFC 6263,
			DOI 10.17487/RFC6263, June 2011,
			<http://www.rfc-editor.org/info/rfc6263>.
	[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the		[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
	RTP Monitoring Framework", RFC 6792, November 2012.		of the RTP Monitoring Framework", RFC 6792,
			DOI 10.17487/RFC6792, November 2012,
			<http://www.rfc-editor.org/info/rfc6792>.
	[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use Cases and Requirements", RFC 7478,		Time Communication Use Cases and Requirements", RFC 7478,
	March 2015.		DOI 10.17487/RFC7478, March 2015,
			<http://www.rfc-editor.org/info/rfc7478>.
	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
End of changes. 62 change blocks.
	102 lines changed or deleted		150 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/