Diff: rfc8861xml2.original.xml

	rfc8861xml2.original.xml	rfc8861.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc toc="yes" ?>
	<?rfc strict="yes" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
	<?rfc compact="yes" ?>
	<?rfc sortrefs="yes" ?>
	<?rfc symrefs="yes" ?>
	<rfc category="std"
	docName="draft-ietf-avtcore-rtp-multi-stream-optimisation-12"	docName="draft-ietf-avtcore-rtp-multi-stream-optimisation-12"

	ipr="trust200902" updates="">	number="8861" ipr="trust200902" updates="" obsoletes=""
		submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" sort
		Refs="true" symRefs="true" version="3">
		<!-- xml2rfc v2v3 conversion 2.35.0 -->
	<front>	<front>
	<title abbrev="Grouping RTCP Reception Statistics">Sending Multiple RTP	<title abbrev="Grouping RTCP Reception Statistics">Sending Multiple RTP

	Streams in a Single RTP Session: Grouping RTCP Reception Statistics and	Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Recept ion Statistics and
	Other Feedback</title>	Other Feedback</title>


	<author fullname="Jonathan Lennox" initials="J." surname="Lennox">	<seriesInfo name="RFC" value="8861"/>
	<organization abbrev="Vidyo">Vidyo, Inc.</organization>


		<author fullname="Jonathan Lennox" initials="J." surname="Lennox">
		<organization abbrev="8x8 / Jitsi">8x8, Inc. / Jitsi</organization>
	<address>	<address>
	<postal>	<postal>

	<street>433 Hackensack Avenue</street>	<city>Jersey City</city>

	<street>Seventh Floor</street>

	<city>Hackensack</city>

	<region>NJ</region>	<region>NJ</region>

		<code>07302</code>
	<code>07601</code>	<country>United States of America</country>

	<country>US</country>
	</postal>	</postal>

		<email>jonathan.lennox@8x8.com</email>
	<email>jonathan@vidyo.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">	<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
	<organization>Ericsson</organization>	<organization>Ericsson</organization>


	<address>	<address>
	<postal>	<postal>

	<street>Farogatan 2</street>	<street>Torshamnsgatan 23</street>
		<city>Kista</city>
	<city>SE-164 80 Kista</city>	<code>164 80</code>

	<country>Sweden</country>	<country>Sweden</country>
	</postal>	</postal>


	<phone>+46 10 714 82 87</phone>

	<email>magnus.westerlund@ericsson.com</email>	<email>magnus.westerlund@ericsson.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Qin Wu" initials="Q." surname="Wu">	<author fullname="Qin Wu" initials="Q." surname="Wu">
	<organization>Huawei</organization>	<organization>Huawei</organization>


	<address>	<address>
	<postal>	<postal>
	<street>101 Software Avenue, Yuhua District</street>	<street>101 Software Avenue, Yuhua District</street>


	<city>Nanjing, Jiangsu 210012</city>	<city>Nanjing, Jiangsu 210012</city>


	<country>China</country>	<country>China</country>
	</postal>	</postal>


	<email>bill.wu@huawei.com</email>	<email>bill.wu@huawei.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Colin Perkins" initials="C. " surname="Perkins">	<author fullname="Colin Perkins" initials="C. " surname="Perkins">
	<organization>University of Glasgow</organization>	<organization>University of Glasgow</organization>


	<address>	<address>
	<postal>	<postal>
	<street>School of Computing Science</street>	<street>School of Computing Science</street>


	<city>Glasgow</city>	<city>Glasgow</city>


	<code>G12 8QQ</code>	<code>G12 8QQ</code>


	<country>United Kingdom</country>	<country>United Kingdom</country>
	</postal>	</postal>


	<email>csp@csperkins.org</email>	<email>csp@csperkins.org</email>
	</address>	</address>
	</author>	</author>

		<date month="January" year="2021"/>


	<date/>	<keyword>RGRP</keyword>
		<keyword>SDES</keyword>
	<workgroup>AVTCORE WG</workgroup>	<keyword>XR</keyword>
		<keyword>Reporting</keyword>
		<keyword>Group</keyword>

	<abstract>	<abstract>

	<t>RTP allows multiple RTP streams to be sent in a single session, but	<t>RTP allows multiple RTP streams to be sent in a single session but
	requires each Synchronisation Source (SSRC) to send RTCP reception	requires each Synchronization Source (SSRC) to send RTP Control Protocol
	quality reports for every other SSRC visible in the session. This causes	(RTCP)
		reception quality reports for every other SSRC visible in the session. Thi
		s causes
	the number of RTCP reception reports to grow with the number of SSRCs,	the number of RTCP reception reports to grow with the number of SSRCs,

	rather than the number of endpoints. In many cases most of these RTCP	rather than the number of endpoints. In many cases, most of these RTCP
	reception reports are unnecessary, since all SSRCs of an endpoint are	reception reports are unnecessary, since all SSRCs of an endpoint are
	normally co-located and see the same reception quality. This memo	normally co-located and see the same reception quality. This memo
	defines a Reporting Group extension to RTCP to reduce the reporting	defines a Reporting Group extension to RTCP to reduce the reporting
	overhead in such scenarios.</t>	overhead in such scenarios.</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section anchor="introduction" title="Introduction">	<section anchor="introduction" numbered="true" toc="default">
	<t>The Real-time Transport Protocol (RTP) <xref target="RFC3550"/> is a	<name>Introduction</name>
		<t>The Real-time Transport Protocol (RTP) <xref target="RFC3550" format="d
		efault"/> is a
	protocol for group communication, supporting multiparty multimedia	protocol for group communication, supporting multiparty multimedia
	sessions. A single RTP session can support multiple participants sending	sessions. A single RTP session can support multiple participants sending

	at once, and can also support participants sending multiple simultaneous	data at once and can also support participants sending multiple simultaneo us
	RTP streams. Examples of the latter might include a participant with	RTP streams. Examples of the latter might include a participant with
	multiple cameras who chooses to send multiple views of a scene, or a	multiple cameras who chooses to send multiple views of a scene, or a
	participant that sends audio and video flows multiplexed in a single RTP	participant that sends audio and video flows multiplexed in a single RTP
	session. Rules for handling RTP sessions containing multiple RTP streams	session. Rules for handling RTP sessions containing multiple RTP streams

	are described in <xref target="RFC3550"/> with some clarifications in	are described in <xref target="RFC3550" format="default"/>, with some clar
	<xref target="I-D.ietf-avtcore-rtp-multi-stream"/>.</t>	ifications in
		<xref target="RFC8108" format="default"/>.</t>
	<t>An RTP endpoint will have one or more synchronisation sources	<t>An RTP endpoint will have one or more Synchronization Sources
	(SSRCs). It will have at least one RTP Stream, and thus SSRC, for each	(SSRCs). It will have at least one RTP stream, and thus at least one SSRC,
	media source it sends, and might use multiple SSRCs per media source	for each
	when using <xref target="RFC6190">media scalability features</xref>,	media source it sends, and it might use multiple SSRCs per media source
	forward error correction, <xref target="RFC4588">RTP	when using <xref target="RFC6190" format="default">media scalability featu
		res</xref>,
		forward error correction, <xref target="RFC4588" format="default">RTP
	retransmission</xref>, or similar mechanisms. An endpoint that is not	retransmission</xref>, or similar mechanisms. An endpoint that is not

	sending any RTP stream, will have at least one SSRC to use for reporting	sending any RTP streams will have at least one SSRC to use for reporting
	and any feedback messages. Each SSRC has to send RTCP sender reports	and any feedback messages. Each SSRC has to send RTP Control Protocol
	corresponding to the RTP packets it sends, and receiver reports for	(RTCP) Sender Reports (SRs) corresponding to the RTP packets it sends
	traffic it receives. That is, every SSRC will send RTCP packets to	and Receiver Reports (RRs) for traffic it receives. (SRs and RRs are
	report on every other SSRC. This rule is simple, but can be quite	described in <xref target="RFC3550"/>.) That is, every SSRC will send RTCP
		packets to
		report on every other SSRC. This rule is simple, but it can be quite
	inefficient for endpoints that send large numbers of RTP streams in a	inefficient for endpoints that send large numbers of RTP streams in a
	single RTP session. Consider a session comprising ten participants, each	single RTP session. Consider a session comprising ten participants, each

	sending three media sources, each with their own RTP stream. There will	sending three media sources, each media source associated with its own RTP stream. There will
	be 30 SSRCs in such an RTP session, and each of those 30 SSRCs will send	be 30 SSRCs in such an RTP session, and each of those 30 SSRCs will send

	an RTCP Sender Report/Receiver Report packet (containing several report	an RTCP SR/RR packet (containing several report
	blocks) per reporting interval as each SSRC reports on all the others.	blocks) per reporting interval as each SSRC reports on all the others.
	However, the three SSRCs comprising each participant are commonly	However, the three SSRCs comprising each participant are commonly
	co-located such that they see identical reception quality. If there was	co-located such that they see identical reception quality. If there was

	a way to indicate that several SSRCs are co-located, and see the same	a way to indicate that several SSRCs are co-located and see the same
	reception quality, then two-thirds of those RTCP reports could be	reception quality, then two-thirds of those RTCP reports could be
	suppressed. This would allow the remaining RTCP reports to be sent more	suppressed. This would allow the remaining RTCP reports to be sent more
	often, while keeping within the same RTCP bandwidth fraction.</t>	often, while keeping within the same RTCP bandwidth fraction.</t>

		<t>This memo defines such an RTCP extension: RTCP Reporting Groups. This
	<t>This memo defines such an RTCP extension, RTCP Reporting Groups. This
	extension is used to indicate the SSRCs that originate from the same	extension is used to indicate the SSRCs that originate from the same

	endpoint, and therefore have identical reception quality, hence allowing	endpoint and therefore have identical reception quality, hence allowing
	the endpoints to suppress unnecessary RTCP reception quality	the endpoints to suppress unnecessary RTCP reception quality
	reports.</t>	reports.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Terminology">	<name>Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	document are to be interpreted as described in <xref	"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	target="RFC2119"/>.</t>	"<bcp14>SHOULD NOT</bcp14>",
		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
		to be interpreted as described in BCP 14 <xref target="RFC2119"/>
		<xref target="RFC8174"/> when, and only when, they appear in all
		capitals, as shown here.</t>
	</section>	</section>

		<section anchor="reportgroups" numbered="true" toc="default">
	<section anchor="reportgroups" title="RTCP Reporting Groups">	<name>RTCP Reporting Groups</name>
	<t>An RTCP Reporting Group is a set of synchronization sources (SSRCs)	<t>An RTCP Reporting Group is a set of SSRCs that are co&nbhy;located at a
	that are co-located at a single endpoint (which could be an end host or	single endpoint (which could be an end host or
	a middlebox) in an RTP session. Since they are co-located, every SSRC in	a middlebox) in an RTP session. Since they are co-located, every SSRC in

	the RTCP reporting group will have an identical view of the network	the RTCP Reporting Group will have an identical view of the network
	conditions, and see the same lost packets, jitter, etc. This allows a	conditions and will see the same lost packets, jitter, etc. This allows a
	single representative to send RTCP reception quality reports on behalf	single representative to send RTCP reception quality reports on behalf

	of the rest of the reporting group, reducing the number of RTCP packets	of the rest of the Reporting Group, reducing the number of RTCP packets
	that need to be sent without loss of information.</t>	that need to be sent without loss of information.</t>

		<section numbered="true" toc="default">
	<section title="Semantics and Behaviour of RTCP Reporting Groups">	<name>Semantics and Behavior of RTCP Reporting Groups</name>
	<t>A group of co-located SSRCs that see identical network conditions	<t>A group of co-located SSRCs that see identical network conditions

	can form an RTCP reporting group. If reporting groups are in use, an	can form an RTCP Reporting Group. If Reporting Groups are in use, an
	RTP endpoint with multiple SSRCs MAY put those SSRCs into a reporting	RTP endpoint with multiple SSRCs <bcp14>MAY</bcp14> put those SSRCs into
	group if their view of the network is identical; i.e., if they report	a Reporting
		Group if their view of the network is identical, i.e., if they report
	on traffic received at the same interface of an RTP endpoint. SSRCs	on traffic received at the same interface of an RTP endpoint. SSRCs

	with different views of the network MUST NOT be put into the same	with different views of the network <bcp14>MUST NOT</bcp14> be put into
	reporting group.</t>	the same
		Reporting Group.</t>
	<t>An endpoint that has combined its SSRCs into an RTCP reporting	<t>An endpoint that has combined its SSRCs into an RTCP Reporting
	group will choose one (or a subset) of those SSRCs to act as	Group will choose one (or a subset) of those SSRCs to act as
	"reporting source(s)" for that RTCP reporting group. A reporting	"reporting source(s)" for that RTCP Reporting Group. A reporting
	source will send RTCP SR/RR reception quality reports on behalf of the	source will send RTCP SR/RR reception quality reports on behalf of the

	other members of the RTCP reporting group. A reporting source MUST	other members of the RTCP Reporting Group. A reporting source <bcp14>MUS T</bcp14>
	suppress the RTCP SR/RR reports that relate to other members of the	suppress the RTCP SR/RR reports that relate to other members of the

	reporting group, and only report on remote SSRCs. The other members	Reporting Group and only report on remote SSRCs. The other members
	(non reporting sources) of the RTCP reporting group will suppress	(non-reporting sources) of the RTCP Reporting Group will suppress
	their RTCP reception quality reports, and instead send an RTCP RGRS	their RTCP reception quality reports and will instead send an
	packet (see <xref target="sec-rgrs"/>) to indicate that they are part	RTCP Reporting Group Reporting Sources (RGRS)
	of an RTCP reporting group and give the SSRCs of the reporting	packet (see <xref target="sec-rgrs" format="default"/>) to indicate that
		they are part
		of an RTCP Reporting Group and give the SSRCs of the reporting
	sources.</t>	sources.</t>


	<t>If there are large numbers of remote SSRCs in the RTP session, then	<t>If there are large numbers of remote SSRCs in the RTP session, then
	the reception quality reports generated by the reporting source might	the reception quality reports generated by the reporting source might
	grow too large to fit into a single compound RTCP packet, forcing the	grow too large to fit into a single compound RTCP packet, forcing the
	reporting source to use a round-robin policy to determine what remote	reporting source to use a round-robin policy to determine what remote
	SSRCs it includes in each compound RTCP packet, and so reducing the	SSRCs it includes in each compound RTCP packet, and so reducing the
	frequency of reports on each SSRC. To avoid this, in sessions with	frequency of reports on each SSRC. To avoid this, in sessions with

	large numbers of remote SSRCs, an RTCP reporting group MAY use more	large numbers of remote SSRCs, an RTCP Reporting Group <bcp14>MAY</bcp14 > use more
	than one reporting source. If several SSRCs are acting as reporting	than one reporting source. If several SSRCs are acting as reporting

	sources for an RTCP reporting group, then each reporting source MUST	sources for an RTCP Reporting Group, then each reporting source <bcp14>M UST</bcp14>
	have non-overlapping sets of remote SSRCs it reports on.</t>	have non-overlapping sets of remote SSRCs it reports on.</t>

		<t>An endpoint <bcp14>MUST NOT</bcp14> create an RTCP Reporting Group th
	<t>An endpoint MUST NOT create an RTCP reporting group that comprises	at comprises
	only a single local SSRC (i.e., an RTCP reporting group where the	only a single local SSRC (i.e., an RTCP Reporting Group where the
	reporting source is the only member of the group), unless it is	reporting source is the only member of the group), unless it is
	anticipated that the group might have additional SSRCs added to it in	anticipated that the group might have additional SSRCs added to it in
	the future.</t>	the future.</t>

		<t>If a reporting source leaves the RTP session (i.e., if it sends an
	<t>If a reporting source leaves the RTP session (i.e., if it sends a	RTCP BYE packet or it leaves the session without sending a BYE
	RTCP BYE packet, or leaves the session without sending BYE under the	according to the
	rules of <xref target="RFC3550"/> section 6.3.7), the remaining	rules of <xref target="RFC3550" sectionFormat="comma" section="6.3.7"/>)
	members of the RTCP reporting group MUST either (a) have another	, the remaining
	reporting source, if one exists, report on the remote SSRCs the	members of the RTCP Reporting Group <bcp14>MUST</bcp14> (a) have an
	leaving SSRC reported on, (b) choose a new reporting source, or (c)	other
	disband the RTCP reporting group and begin sending reception quality	reporting source -- if one exists -- report on the remote SSRCs that
	reports following <xref target="RFC3550"/> and <xref	the leaving SSRC had reported on, (b) choose a new reporting source
	target="I-D.ietf-avtcore-rtp-multi-stream"/>.</t>	, or (c) disband the RTCP Reporting Group and begin sending reception quali
		ty
		reports per <xref target="RFC3550" format="default"/> and <xref target="
		RFC8108" format="default"/>.</t>
	<t>The RTCP timing rules assign different bandwidth fractions to	<t>The RTCP timing rules assign different bandwidth fractions to
	senders and receivers. This lets senders transmit RTCP reception	senders and receivers. This lets senders transmit RTCP reception
	quality reports more often than receivers. If a reporting source in an	quality reports more often than receivers. If a reporting source in an

	RTCP reporting group is a receiver, but one or more non-reporting	RTCP Reporting Group is a receiver but one or more non-reporting
	SSRCs in the RTCP reporting group are senders, then the endpoint MAY	SSRCs in the RTCP Reporting Group are senders, then the endpoint <bcp14>
		MAY</bcp14>
	treat the reporting source as a sender for the purpose of RTCP	treat the reporting source as a sender for the purpose of RTCP
	bandwidth allocation, increasing its RTCP bandwidth allocation,	bandwidth allocation, increasing its RTCP bandwidth allocation,
	provided it also treats one of the senders as if it were a receiver	provided it also treats one of the senders as if it were a receiver
	and makes the corresponding reduction in RTCP bandwidth for that SSRC.	and makes the corresponding reduction in RTCP bandwidth for that SSRC.
	However, the application needs to consider the impact on the frequency	However, the application needs to consider the impact on the frequency

	of transmitting of the synchronization information included in RTCP	of transmitting of the synchronization information included in RTCP SRs.
	Sender Reports.</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Identifying Members of an RTCP Reporting Group">	<name>Identifying Members of an RTCP Reporting Group</name>
	<t>When RTCP Reporting Groups are in use, the other SSRCs in the RTP	<t>When RTCP Reporting Groups are in use, the other SSRCs in the RTP
	session need to be able to identify which SSRCs are members of an RTCP	session need to be able to identify which SSRCs are members of an RTCP

	reporting group. Two RTCP extensions are defined to support this: the	Reporting Group. Two RTCP extensions are defined to support this: the
	RTCP RGRP SDES item is used by the reporting source(s) to identify an	RTCP Reporting Group (RGRP) Source Description (SDES) item is used by th
	RTCP reporting group, and the RTCP RGRS packet is used by other	e reporting source(s) to identify an
	members of an RTCP reporting group to identify the reporting	RTCP Reporting Group, and the RTCP RGRS packet is used by other
		members of an RTCP Reporting Group to identify the reporting
	source(s).</t>	source(s).</t>

		<section anchor="sec-rgrp" numbered="true" toc="default">
	<section anchor="sec-rgrp"	<name>Definition and Use of the RTCP RGRP SDES Item</name>
	title="Definition and Use of the RTCP RGRP SDES Item">	<t>This document defines a new RTCP RGRP SDES item to identify an RTCP
	<t>This document defines a new RTCP SDES item to identify an RTCP	Reporting Group. The motivation for giving a Reporting Group an
	reporting group. The motivation for giving a reporting group an	identifier is to ensure that (1) the RTCP Reporting Group and its
	identify is to ensure that the RTCP reporting group and its member	member
	SSRCs can be correctly associated when there are multiple reporting	SSRCs can be correctly associated when there are multiple reporting

	sources, and to ensure that a reporting SSRC can be associated with	sources and (2) a reporting SSRC can be associated with
	the correct reporting group if an SSRC collision occurs.</t>	the correct Reporting Group if an SSRC collision occurs.</t>
		<t>This document defines the RTCP RGRP SDES item.
	<t>This document defines the RTCP Source Description (SDES) RGRP	The RTCP RGRP SDES item <bcp14>MUST</bcp14> be sent by the reporting sources
	item. The RTCP SDES RGRP item MUST be sent by the reporting sources	in a Reporting Group and <bcp14>MUST NOT</bcp14> be sent by other memb
	in a reporting group, and MUST NOT be sent by other members of the	ers of the
	reporting group or by SSRCs that are not members of any RTCP	Reporting Group or by SSRCs that are not members of any RTCP
	reporting group. Specifically, every reporting source in an RTCP	Reporting Group. Specifically, every reporting source in an RTCP
	reporting group MUST include an RTCP SDES packet containing an RGRP	Reporting Group <bcp14>MUST</bcp14> include an RTCP SDES packet contai
		ning an RGRP
	item in every compound RTCP packet in which it sends an RR or SR	item in every compound RTCP packet in which it sends an RR or SR

	packet (i.e., in every RTCP packet it sends, unless <xref	packet (i.e., in every RTCP packet it sends, unless <xref target="RFC5
	target="RFC5506">Reduced-Size RTCP</xref> is in use).</t>	506" format="default">Reduced-Size RTCP</xref> is in use).</t>


	<t>Syntactically, the format of the RTCP SDES RGRP item is identical	<t>Syntactically, the format of the RTCP RGRP SDES item is identical
	to that of the <xref target="RFC7022">RTCP SDES CNAME item</xref>,	to that of the <xref target="RFC7022" format="default">RTCP SDES CNAME
	except that the SDES item type field MUST have value RGRP=(TBA)	item</xref>,
	instead of CNAME=1. The value of the RTCP SDES RGRP item MUST be	except that the SDES item type field <bcp14>MUST</bcp14> have value RG
		RP=11
		instead of CNAME=1. The value of the RTCP RGRP SDES item <bcp14>MUST</
		bcp14> be
	chosen with the same concerns about global uniqueness and the same	chosen with the same concerns about global uniqueness and the same
	privacy considerations as the RTCP SDES CNAME. The value of the RTCP	privacy considerations as the RTCP SDES CNAME. The value of the RTCP

	SDES RGRP item MUST be stable throughout the lifetime of the	RGRP SDES item <bcp14>MUST</bcp14> be stable throughout the lifetime o
	reporting group, even if some or all of the reporting sources change	f the
	their SSRC due to collisions, or if the set of reporting sources	Reporting Group, even if some or all of the reporting sources change
		their SSRC due to collisions or if the set of reporting sources
	changes.</t>	changes.</t>


	<t><list style="empty">
	<t>Note to RFC Editor: please replace (TBA) in the above
	paragraph with the RTCP SDES item type number assigned to the
	RGRP item, then delete this note.</t>
	</list></t>

	<t>An RTP mixer or translator that forwards RTCP SR or RR packets	<t>An RTP mixer or translator that forwards RTCP SR or RR packets

	from members of a reporting group MUST forward the corresponding	from members of a Reporting Group <bcp14>MUST</bcp14> forward the corr
	RTCP SDES RGRP items as well, even if it otherwise strips SDES items	esponding
		RTCP RGRP SDES items as well, even if it otherwise strips SDES items
	other than the CNAME item.</t>	other than the CNAME item.</t>
	</section>	</section>

		<section anchor="sec-rgrs" numbered="true" toc="default">
	<section anchor="sec-rgrs"	<name>Definition and Use of the RTCP RGRS Packet</name>
	title="Definition and Use of the RTCP RGRS Packet">
	<t>A new RTCP packet type is defined to allow the members of an RTCP	<t>A new RTCP packet type is defined to allow the members of an RTCP

	reporting group to identify the reporting sources for that group.	Reporting Group to identify the reporting sources for that group.
	This allows participants in an RTP session to distinguish an SSRC	This allows participants in an RTP session to distinguish an SSRC
	that is sending empty RTCP reception reports because it is a member	that is sending empty RTCP reception reports because it is a member

	of an RTCP reporting group, from an SSRC that is sending empty RTCP	of an RTCP Reporting Group from an SSRC that is sending empty RTCP
	reception reports because it is not receiving any traffic. It also	reception reports because it is not receiving any traffic. It also
	explicitly identifies the reporting sources, allowing other members	explicitly identifies the reporting sources, allowing other members

	of the RTP session to know which SSRCs are acting as the reporting	of the RTP session to (1) know which SSRCs are acting as the repo
	sources for an RTCP reporting group, and allowing them to detect if	rting
		sources for an RTCP Reporting Group and (2) detect if
	RTCP packets from any of the reporting sources are being lost.</t>	RTCP packets from any of the reporting sources are being lost.</t>


	<t>The format of the RTCP RGRS packet is defined below. It comprises	<t>The format of the RTCP RGRS packet is defined below. It comprises
	the fixed RTCP header that indicates the packet type and length, the	the fixed RTCP header that indicates the packet type and length, the
	SSRC of the packet sender, and a list of reporting sources for the	SSRC of the packet sender, and a list of reporting sources for the

	RTCP reporting group of which the packet sender is a member.</t>	RTCP Reporting Group of which the packet sender is a member.</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure>
	<artwork><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\|V=2\|P\| SC \| PT=RGRS(TBA) \| length \|	\|V=2\|P\| SC \| PT=RGRS(212) \| length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SSRC of packet sender \|	\| SSRC of packet sender \|
	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
	: List of SSRC(s) for the Reporting Source(s) :	: List of SSRC(s) for the Reporting Source(s) :
	: ... :	: ... :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

	</figure>	<t>The fields in the RTCP RGRS packet have the following definitions:
		</t>
	<t>The fields in the RTCP RGRS packet have the following definition:	<dl newline="false" spacing="normal">
	<list style="hanging">	<dt>version (V):</dt>
	<t hangText="version (V):">2 bits unsigned integer. This field	<dd>2-bit unsigned integer. This field
	identifies the RTP version. The current RTP version is 2.</t>	identifies the RTP version. The current RTP version is 2.</dd>
		<dt>padding (P):</dt>
	<t hangText="padding (P):">1 bit. If set, the padding bit	<dd>1 bit. If set, the padding bit
	indicates that the RTCP packet contains additional padding	indicates that the RTCP packet contains additional padding
	octets at the end that are not part of the control information	octets at the end that are not part of the control information

	but are included in the length field. See <xref	but are included in the length field. See <xref target="RFC3550" f
	target="RFC3550"/>.</t>	ormat="default"/>.</dd>
		<dt>Source Count (SC):</dt>
	<t hangText="Source Count (SC):">5 bits unsigned integer.	<dd>5-bit unsigned integer.
	Indicates the number of reporting source SSRCs that are included	Indicates the number of reporting source SSRCs that are included

	in this RTCP packet. As the RTCP RGRS packet MUST NOT be not	in this RTCP packet. As the RTCP RGRS packet <bcp14>MUST NOT</bcp1
	sent by reporting sources, all the SSRCs in the list of	4> be sent by reporting sources, all the SSRCs in the list of
	reporting sources will be different from the SSRC of the packet	reporting sources will be different from the SSRC of the packet

	sender. Every RTCP RGRS packet MUST contain at least one	sender. Every RTCP RGRS packet <bcp14>MUST</bcp14> contain at leas
	reporting source SSRC.</t>	t one
		reporting source SSRC.</dd>
	<t hangText="Payload type (PT):">8 bits unsigned integer. The	<dt>Payload type (PT):</dt>
		<dd>
		<t>8-bit unsigned integer. The
	RTCP packet type number that identifies the packet as being an	RTCP packet type number that identifies the packet as being an

	RTCP RGRS packet. The RGRS RTCP packet has the value [TBA].	RTCP RGRS packet. The RGRS RTCP packet has the value 212.
	<list style="empty">	</t>
	<t>Note to RFC Editor: please replace [TBA] here, and in the	</dd>
	packet format diagram above, with the RTCP packet type that	<dt>Length:</dt>
	IANA assigns to the RTCP RGRS packet.</t>	<dd>16-bit unsigned integer. The length of
	</list></t>

	<t hangText="Length:">16 bits unsigned integer. The length of
	this packet in 32-bit words minus one, including the header and	this packet in 32-bit words minus one, including the header and
	any padding. This is in line with the definition of the length	any padding. This is in line with the definition of the length

	field used in RTCP sender and receiver reports <xref	field used in RTCP SRs and RRs <xref target="RFC3550" format="defa
	target="RFC3550"/>. Since all RTCP RGRS packets include at least	ult"/>. Since all RTCP RGRS packets include at least
	one reporting source SSRC, the length will always be 2 or	one reporting source SSRC, the length will always be 2 or

	greater.</t>	greater.</dd>
		<dt>SSRC of packet sender:</dt>
	<t hangText="SSRC of packet sender:">32 bits. The SSRC of the	<dd>32 bits. The SSRC of the
	sender of this packet.</t>	sender of this packet.</dd>
		<dt>List of SSRCs for the Reporting Source(s):</dt>
	<t hangText="List of SSRCs for the Reporting Source(s):">A	<dd>A variable number (as indicated by the SC header field) of
	variable length size (as indicated by SC header field) of the 32	32&nbhy;bit SSRC values of the reporting sources for the
	bit SSRC values of the reporting sources for the RTCP Reporting	RTCP Reporting Group of which the packet sender is a member.</dd>
	Group of which the packet sender is a member.</t>	</dl>
	</list></t>	<t>Every source that belongs to an RTCP Reporting Group but is not a
		reporting source <bcp14>MUST</bcp14> include an RTCP RGRS packet in ev
	<t>Every source that belongs to an RTCP reporting group but is not a	ery compound
	reporting source MUST include an RTCP RGRS packet in every compound
	RTCP packet in which it sends an RR or SR packet (i.e., in every	RTCP packet in which it sends an RR or SR packet (i.e., in every

	RTCP packet it sends, unless <xref target="RFC5506"> Reduced-Size	RTCP packet it sends, unless <xref target="RFC5506" format="default">
	RTCP</xref> is in use). Each RTCP RGRS packet MUST contain the SSRC	Reduced-Size
		RTCP</xref> is in use). Each RTCP RGRS packet <bcp14>MUST</bcp14> cont
		ain the SSRC
	identifier of at least one reporting source. If there are more	identifier of at least one reporting source. If there are more

	reporting sources in an RTCP reporting group than can fit into an	reporting sources in an RTCP Reporting Group than can fit into an
	RTCP RGRS packet, the members of that reporting group MUST send the	RTCP RGRS packet, the members of that Reporting Group <bcp14>MUST</bcp
		14> send the
	SSRCs of the reporting sources in a round-robin fashion in	SSRCs of the reporting sources in a round-robin fashion in
	consecutive RTCP RGRS packets, such that all the SSRCs of the	consecutive RTCP RGRS packets, such that all the SSRCs of the
	reporting sources are included over the course of several RTCP	reporting sources are included over the course of several RTCP
	reporting intervals.</t>	reporting intervals.</t>


	<t>An RTP mixer or translator that forwards RTCP SR or RR packets	<t>An RTP mixer or translator that forwards RTCP SR or RR packets

	from members of a reporting group MUST also forward the	from members of a Reporting Group <bcp14>MUST</bcp14> also forward the
	corresponding RGRS RTCP packets. If the RTP mixer or translator	corresponding RGRS RTCP packets. If the RTP mixer or translator

	rewrites SSRC values of the packets it forwards, it MUST make the	rewrites SSRC values of the packets it forwards, it <bcp14>MUST</bcp14 > make the
	corresponding changes to the RTCP RGRS packets.</t>	corresponding changes to the RTCP RGRS packets.</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Interactions with the RTP/AVPF Feedback Profile">	<name>Interactions with the RTP/AVPF Feedback Profile</name>
	<t>Use of the RTP/AVPF Feedback Profile <xref target="RFC4585"/>	<t>The use of the RTP/AVPF Feedback Profile <xref target="RFC4585" forma
		t="default"/>
	allows SSRCs to send rapid RTCP feedback requests and codec control	allows SSRCs to send rapid RTCP feedback requests and codec control

	messages. If use of the RTP/AVPF profile has been negotiated in an RTP	messages. If the use of the RTP/AVPF profile has been negotiated in an R
	session, members of an RTCP reporting group can send rapid RTCP	TP
	feedback and codec control messages following <xref target="RFC4585"/>	session, members of an RTCP Reporting Group can send rapid RTCP
	and <xref target="RFC5104"/>, as updated by Section 5.4 of <xref	feedback and codec control messages per <xref target="RFC5104"
	target="I-D.ietf-avtcore-rtp-multi-stream"/>, and by the following	format="default"/>, per <xref target="RFC4585" format="default"/>
	considerations.</t>	as updated by <xref target="RFC8108" sectionFormat="of"
		section="5.4"/>, and by the following considerations.</t>
	<t>The members of an RTCP reporting group will all see identical	<t>The members of an RTCP Reporting Group will all see identical
	network conditions. Accordingly, one might therefore think that it	network conditions. Accordingly, one might therefore think that it

	doesn't matter which SSRC in the reporting group sends the RTP/AVPF	doesn't matter which SSRC in the Reporting Group sends the RTP/AVPF
	feedback or codec control messages. There might be, however, cases	feedback or codec control messages. There might be, however, cases
	where the sender of the feedback/codec control message has semantic	where the sender of the feedback/codec control message has semantic

	importance, or when only a subset of the members of an RTCP reporting	importance, or when only a subset of the members of an RTCP Reporting
	group might want to send RTP/AVPF feedback or a codec control message	Group might want to send RTP/AVPF feedback or a codec control message
	in response to a particular event. For example, an RTP video sender	in response to a particular event. For example, an RTP video sender
	might choose to treat packet loss feedback received from SSRCs known	might choose to treat packet loss feedback received from SSRCs known
	to be audio receivers with less urgency than feedback that it receives	to be audio receivers with less urgency than feedback that it receives
	from video receivers when deciding what packets to retransmit, and a	from video receivers when deciding what packets to retransmit, and a

	multimedia receiver using reporting groups might want to choose the	multimedia receiver using Reporting Groups might want to choose the
	outgoing SSRC for feedback packets to reflect this.</t>	outgoing SSRC for feedback packets to reflect this.</t>

		<t>Each member of an RTCP Reporting Group <bcp14>SHOULD</bcp14> therefor
	<t>Each member of an RTCP reporting group SHOULD therefore send	e send
	RTP/AVPF feedback/codec control messages independently of the other	RTP/AVPF feedback/codec control messages independently of the other

	members of the reporting group, to respect the semantic meaning of the	members of the Reporting Group, to respect the semantic meaning of the
	message sender. The suppression rules of <xref target="RFC4585"/> will	message sender. The suppression rules of <xref target="RFC4585" format="
		default"/> will
	ensure that only a single copy of each feedback packet is (typically)	ensure that only a single copy of each feedback packet is (typically)

	generated, even if several members of a reporting group send the same	generated, even if several members of a Reporting Group send the same
	feedback. When an endpoint knows that several members of its RTCP	feedback. When an endpoint knows that several members of its RTCP

	reporting group will be sending identical feedback, and that the	Reporting Group will be sending identical feedback and that the
	sender of the feedback is not semantically important, then that	sender of the feedback is not semantically important, that
	endpoint MAY choose to send all its feedback from the reporting source	endpoint <bcp14>MAY</bcp14> choose to send all its feedback from the rep
		orting source
	and deterministically suppress feedback packets generated by the other	and deterministically suppress feedback packets generated by the other

	sources in the reporting group.</t>	sources in the Reporting Group.</t>

	<t>It is important to note that the RTP/AVPF timing rules operate on a	<t>It is important to note that the RTP/AVPF timing rules operate on a
	per-SSRC basis. Using a single reporting source to send all feedback	per-SSRC basis. Using a single reporting source to send all feedback

	for a reporting group will hence limit the amount of feedback that can	for a Reporting Group will hence limit the amount of feedback that can
	be sent to that which can be sent by one SSRC. If this limit is a	be sent to that which can be sent by one SSRC. If this limit is a

	problem, then the reporting group can allow each of its members to	problem, then the Reporting Group can allow each of its members to
	send its own feedback, using its own SSRC.</t>	send its own feedback, using its own SSRC.</t>


	<t>If the RTP/AVPF feedback messages or codec control requests are	<t>If the RTP/AVPF feedback messages or codec control requests are

	sent as compound RTCP packets, then those compound RTCP packets MUST	sent as compound RTCP packets, then those compound RTCP packets <bcp14>M
	include either an RTCP RGRS packet or an RTCP SDES RGRP item,	UST</bcp14>
		include either an RTCP RGRS packet or an RTCP RGRP SDES item,
	depending on whether they are sent by the reporting source or a	depending on whether they are sent by the reporting source or a

	non-reporting source in the RTCP reporting group respectively. The	non&nbhy;reporting source in the RTCP Reporting Group, respectively. The
	contents of non-compound RTCP feedback or codec control messages are	contents of noncompound RTCP feedback or codec control messages are
	not affected by the use of RTCP reporting groups.</t>	not affected by the use of RTCP Reporting Groups.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Interactions with RTCP Extended Report (XR) Packets">	<name>Interactions with RTCP Extended Report (XR) Packets</name>
	<t>When using RTCP Extended Reports (XR) <xref target="RFC3611"/> with	<t>When using RTCP Extended Report (XR) packets <xref target="RFC3611" f
	RTCP reporting groups, it is RECOMMENDED that the reporting source is	ormat="default"/> with
		RTCP Reporting Groups, it is <bcp14>RECOMMENDED</bcp14> that the reporti
		ng source be
	used to send the RTCP XR packets. If multiple reporting sources are in	used to send the RTCP XR packets. If multiple reporting sources are in
	use, the reporting source that sends the SR/RR packets that relate to	use, the reporting source that sends the SR/RR packets that relate to

	a particular remote SSRC SHOULD send the RTCP XR reports about that	a particular remote SSRC <bcp14>SHOULD</bcp14> send the RTCP XR reports about that
	SSRC. This is motivated as one commonly combine the RTCP XR metrics	SSRC. This is motivated as one commonly combine the RTCP XR metrics
	with the regular report block to more fully understand the situation.	with the regular report block to more fully understand the situation.
	Receiving these blocks in different compound packets reduces their	Receiving these blocks in different compound packets reduces their

	value as the measuring intervals are not synchronized in those	value, as the measuring intervals are not synchronized in those
	cases.</t>	cases.</t>


	<t>Some RTCP XR report blocks are specific to particular types of	<t>Some RTCP XR report blocks are specific to particular types of

	media, and might be relevant to only some members of a reporting	media and might be relevant to only some members of a Reporting
	group. For example, it would make no sense for an SSRC that is	Group. For example, it would make no sense for an SSRC that is
	receiving video to send a VoIP metric RTCP XR report block. Such media	receiving video to send a Voice over IP (VoIP) metric RTCP XR report blo
	specific RTCP XR report blocks MUST be sent by the SSRC to which they	ck. Such
	are relevant, and MUST NOT be included in the common report sent by	media-specific RTCP XR report blocks <bcp14>MUST</bcp14> be sent by the
		SSRC to which they
		are relevant and <bcp14>MUST NOT</bcp14> be included in the common repor
		t sent by
	the reporting source. This might mean that some SSRCs send RTCP XR	the reporting source. This might mean that some SSRCs send RTCP XR
	packets in compound RTCP packets that contain an empty RTCP SR/RR	packets in compound RTCP packets that contain an empty RTCP SR/RR

	packet, and that the time period covered by the RTCP XR packet is	packet and that the time period covered by the RTCP XR packet is
	different to that covered by the RTCP SR/RR packet. If it is important	different from that covered by the RTCP SR/RR packet. If it is important
	that the RTCP XR packet and RTCP SR/RR packet cover the same time	that the RTCP XR packet and RTCP SR/RR packet cover the same time

	period, then that source SHOULD be removed from the RTCP reporting	period, then that source <bcp14>SHOULD</bcp14> be removed from the RTCP
	group, and send standard RTCP packets instead.</t>	Reporting
		Group, and standard RTCP packets be sent instead.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Middlebox Considerations">	<name>Middlebox Considerations</name>
	<t>Many different types of middlebox are used with RTP. RTCP reporting	<t>Many different types of middleboxes are used with RTP. RTCP Reporting
	groups are potentially relevant to those types of RTP middlebox that	Groups are potentially relevant to those types of RTP middleboxes that
	have their own SSRCs and generate RTCP reports for the traffic they	have their own SSRCs and generate RTCP reports for the traffic they

	receive. RTP middleboxes that do not have their own SSRC, and that	receive. RTP middleboxes that do not have their own SSRC and that do not
	don't send RTCP reports on the traffic they receive, cannot use the	send RTCP reports on the traffic they receive cannot use the
	RTCP reporting groups extension, since they generate no RTCP reports	RTCP Reporting Group extension, since they generate no RTCP reports
	to group.</t>	to that group.</t>

	<t>An RTP middlebox that has several SSRCs of its own can use the RTCP	<t>An RTP middlebox that has several SSRCs of its own can use the RTCP

	reporting groups extension to group the RTCP reports it generates.	Reporting Group extension to group the RTCP reports it generates.
	This can occur, for example, if a middlebox is acting as an RTP mixer	This can occur, for example, if a middlebox is acting as an RTP mixer
	for both audio and video flows that are multiplexed onto a single RTP	for both audio and video flows that are multiplexed onto a single RTP
	session, where the middlebox has one SSRC for the audio mixer and one	session, where the middlebox has one SSRC for the audio mixer and one

	for the video mixer part, and when the middlebox wants to avoid cross	for the video mixer part, and when the middlebox wants to avoid
	reporting between audio and video.</t>	cross-reporting between audio and video.</t>
		<t>A middlebox cannot use the RTCP Reporting Group extension to group
	<t>A middlebox cannot use the RTCP reporting groups extension to group
	RTCP packets from the SSRCs that it is forwarding. It can, however,	RTCP packets from the SSRCs that it is forwarding. It can, however,
	group the RTCP packets from the SSRCs it is forwarding into compound	group the RTCP packets from the SSRCs it is forwarding into compound

	RTCP packets following the rules in Section 6.1 of <xref	RTCP packets, following the rules in <xref target="RFC3550" sectionForma
	target="RFC3550"/> and Section 5.3 of <xref	t="of" section="6.1"/> and <xref target="RFC8108" sectionFormat="of" section="5.
	target="I-D.ietf-avtcore-rtp-multi-stream"/>. If the middlebox is	3"/>. If the middlebox is
	using RTCP reporting groups for its own SSRCs, it MAY include RTCP	using RTCP Reporting Groups for its own SSRCs, it <bcp14>MAY</bcp14> inc
		lude RTCP
	packets from the SSRCs that it is forwarding as part of the compound	packets from the SSRCs that it is forwarding as part of the compound
	RTCP packets its reporting source generates.</t>	RTCP packets its reporting source generates.</t>


	<t>A middlebox that forwards RTCP SR or RR packets sent by members of	<t>A middlebox that forwards RTCP SR or RR packets sent by members of

	a reporting group MUST forward the corresponding RTCP SDES RGRP items,	a Reporting Group <bcp14>MUST</bcp14> forward the corresponding RTCP
	as described in <xref target="sec-rgrp"/>. A middlebox that forwards	RGRP SDES items,
	RTCP SR or RR packets sent by member of a reporting group MUST also	as described in <xref target="sec-rgrp" format="default"/>. A middlebox
	forward the corresponding RTCP RGRS packets, as described in <xref	that forwards
	target="sec-rgrs"/>. Failure to forward these packets can cause	RTCP SR or RR packets sent by members of a Reporting Group <bcp14>MUST</
	compatibility problems, as described in <xref target="compat"/>.</t>	bcp14> also
		forward the corresponding RTCP RGRS packets, as described in <xref targe
		t="sec-rgrs" format="default"/>. Failure to forward these packets can cause
		compatibility problems, as described in <xref target="compat" format="de
		fault"/>.</t>
	<t>If a middlebox rewrites SSRC values in the RTP and RTCP packets	<t>If a middlebox rewrites SSRC values in the RTP and RTCP packets

	that it is forwarding, then it MUST make the corresponding changes in	that it is forwarding, then it <bcp14>MUST</bcp14> make the correspondin g changes in
	RTCP SDES packets containing RGRP items and in RTCP RGRS packets, to	RTCP SDES packets containing RGRP items and in RTCP RGRS packets, to
	allow them to be associated with the rewritten SSRCs.</t>	allow them to be associated with the rewritten SSRCs.</t>
	</section>	</section>

		<section anchor="sdp" numbered="true" toc="default">
	<section anchor="sdp" title="SDP Signalling for Reporting Groups">	<name>SDP Signaling for Reporting Groups</name>
	<t>This document defines the "a=rtcp-rgrp" <xref	<t>This document defines the "a=rtcp-rgrp" <xref target="RFC4566" format
	target="RFC4566">Session Description Protocol (SDP)</xref> attribute	="default">Session Description Protocol (SDP)</xref> attribute
	to indicate if the session participant is capable of supporting RTCP	to indicate if the session participant is capable of supporting RTCP
	Reporting Groups for applications that use SDP for configuration of	Reporting Groups for applications that use SDP for configuration of

	RTP sessions. It is a property attribute, and hence takes no value.	RTP sessions. It is a property attribute and hence takes no value.
	The <xref target="I-D.ietf-mmusic-sdp-mux-attributes">multiplexing	The <xref target="RFC8859" format="default">multiplexing
	category</xref> is IDENTICAL, as the functionality applies on RTP	category</xref> is IDENTICAL, as the functionality applies at the RTP
	session level. A participant that proposes the use of RTCP Reporting	session level. A participant that proposes the use of RTCP Reporting

	Groups SHALL itself support the reception of RTCP Reporting Groups.	Groups <bcp14>SHALL</bcp14> itself support the reception of RTCP Reporti
	The formal definition of this attribute is:</t>	ng Groups.
		The formal definition of this attribute is as follows:</t>


	<figure>	<ul empty="true"><li>
	<artwork><![CDATA[	<dl spacing="compact">
	Name: rtcp-rgrp	<dt>Name:</dt><dd>rtcp-rgrp</dd>
	Value:	<dt>Value:</dt><dd>None</dd>
	Usage Level: session, media	<dt>Usage Level:</dt><dd>session, media</dd>
	Charset Dependent: no	<dt>Charset Dependent:</dt><dd>no</dd>
	Example:	<dt>Example:</dt><dd>a=rtcp-rgrp</dd>
	a=rtcp-rgrp	</dl>
	]]></artwork>	</li>
	</figure>	</ul>


	<t>When using SDP Offer/Answer <xref target="RFC3264"/>, the following	<t>When using SDP Offer/Answer <xref target="RFC3264" format="default"/>
	procedures are to be used: <list style="symbols">	, the following
	<t>Generating the initial SDP offer: If the offerer supports the	procedures are to be used: </t>
	RTCP reporting group extensions, and is willing to accept RTCP	<dl newline="true" spacing="normal">
	packets containing those extensions, then it MUST include an	<dt>Generating the initial SDP offer:</dt>
		<dd>If the offerer supports the
		RTCP Reporting Group extensions and is willing to accept RTCP
		packets containing those extensions, then it <bcp14>MUST</bcp14> inc
		lude an
	"a=rtcp-rgrp" attribute in the initial offer. If the offerer does	"a=rtcp-rgrp" attribute in the initial offer. If the offerer does

	not support RTCP reporting groups extensions, or is not willing to	not support RTCP Reporting Group extensions or is not willing to
	accept RTCP packets containing those extensions, then it MUST NOT	accept RTCP packets containing those extensions, then it <bcp14>MUST
	include the "a=rtcp-rgrp" attribute in the offer.</t>	NOT</bcp14>
		include the "a=rtcp-rgrp" attribute in the offer.</dd>
	<t>Generating the SDP answer: If the SDP offer contains an	<dt>Generating the SDP answer:</dt>
	"a=rtcp-rgrp" attribute, and if the answerer supports RTCP	<dd>If the SDP offer contains an
	reporting groups and is willing to receive RTCP packets using the	"a=rtcp&nbhy;rgrp" attribute, and if the answerer supports RTCP
	RTCP reporting groups extensions, then the answerer MAY include an	Reporting Groups and is willing to receive RTCP packets using the
	"a=rtcp-rgrp" attribute in the answer and MAY send RTCP packets	RTCP Reporting Group extensions, then the answerer <bcp14>MAY</bcp14
	containing the RTCP reporting groups extensions. If the offer does	> include an
		"a=rtcp-rgrp" attribute in the answer and <bcp14>MAY</bcp14> send RT
		CP packets
		containing the RTCP Reporting Group extensions. If the offer does
	not contain an "a=rtcp-rgrp" attribute, or if the offer does	not contain an "a=rtcp-rgrp" attribute, or if the offer does
	contain such an attribute but the answerer does not wish to accept	contain such an attribute but the answerer does not wish to accept

	RTCP packets using the RTCP reporting groups extensions, then the	RTCP packets using the RTCP Reporting Group extensions, then the
	answer MUST NOT include an "a=rtcp-rgrp" attribute.</t>	answer <bcp14>MUST NOT</bcp14> include an "a=rtcp-rgrp" attribute.</
		dd>
	<t>Offerer Processing of the SDP Answer: If the SDP answer	<dt>Offerer processing of the SDP answer:</dt>
	contains an "a=rtcp-rgrp" attribute, and the corresponding offer	<dd>If the SDP answer
	also contained an "a=rtcp-rgrp" attribute, then the offerer MUST	contains an "a=rtcp-rgrp" attribute and the corresponding offer
		also contained an "a=rtcp-rgrp" attribute, then the offerer <bcp14>M
		UST</bcp14>
	be prepared to accept and process RTCP packets that contain the	be prepared to accept and process RTCP packets that contain the

	reporting groups extension, and MAY send RTCP packets that contain	Reporting Group extensions and <bcp14>MAY</bcp14> send RTCP packets
	the reporting groups extension. If the SDP answer contains an	that contain
	"a=rtcp-rgrp" attribute, but the corresponding offer did not	the Reporting Group extensions. If the SDP answer contains an
	contain the "a=rtcp-rgrp" attribute, then the offerer MUST reject	"a=rtcp-rgrp" attribute but the corresponding offer did not
		contain the "a=rtcp&nbhy;rgrp" attribute, then the offerer <bcp14>MU
		ST</bcp14> reject
	the call. If the SDP answer does not contain an "a=rtcp-rgrp"	the call. If the SDP answer does not contain an "a=rtcp-rgrp"

	attribute, then the offerer MUST NOT send packets containing the	attribute, then the offerer <bcp14>MUST NOT</bcp14> send packets con
	RTCP reporting groups extensions, and does not need to process	taining the
	packet containing the RTCP reporting groups extensions.</t>	RTCP Reporting Group extensions and does not need to process
	</list></t>	packets containing the RTCP Reporting Group extensions.</dd>
		</dl>
	<t>In declarative usage of SDP, such as the <xref	<t>In declarative usage of SDP, such as the <xref target="RFC7826" forma
	target="RFC2326">Real Time Streaming Protocol (RTSP)</xref> and the	t="default">Real-Time Streaming Protocol (RTSP)</xref> and the
	<xref target="RFC2974">Session Announcement Protocol (SAP)</xref>, the	<xref target="RFC2974" format="default">Session Announcement Protocol (S
	presence of the attribute indicates that the session participant MAY	AP)</xref>, the
		presence of the attribute indicates that the session participant <bcp14>
		MAY</bcp14>
	use RTCP Reporting Groups in its RTCP transmissions. An implementation	use RTCP Reporting Groups in its RTCP transmissions. An implementation

	that doesn't explicitly support RTCP Reporting Groups MAY join a RTP	that doesn't explicitly support RTCP Reporting Groups <bcp14>MAY</bcp14> join an RTP
	session as long as it has been verified that the implementation	session as long as it has been verified that the implementation

	doesn't suffer from the problems discussed in <xref	doesn't suffer from the problems discussed in <xref target="compat" form
	target="compat"/>.</t>	at="default"/>.</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Properties of RTCP Reporting Groups">	<name>Properties of RTCP Reporting Groups</name>
	<t>This section provides additional information on what the resulting	<t>This section provides additional information on what the resulting

	properties are with the design specified in <xref	properties are (i.e., resulting effects or impacts) as related to the desi
	target="reportgroups"/>. The content of this section is	gn specified in <xref target="reportgroups"
		format="default"/>. The content of this section is
	non-normative.</t>	non-normative.</t>

		<section anchor="reportgroups-bw" numbered="true" toc="default">
	<section anchor="reportgroups-bw"	<name>Bandwidth Benefits of RTCP Reporting Groups</name>
	title="Bandwidth Benefits of RTCP Reporting Groups">	<t>To understand the benefits of RTCP Reporting Groups, consider a
	<t>To understand the benefits of RTCP reporting groups, consider a
	scenario in which the two endpoints in a session each have a hundred	scenario in which the two endpoints in a session each have a hundred
	sources, of which eight each are sending within any given reporting	sources, of which eight each are sending within any given reporting
	interval.</t>	interval.</t>


	<t>For ease of analysis, we can make the simplifying approximation	<t>For ease of analysis, we can make the simplifying approximation
	that the duration of the RTCP reporting interval is equal to the total	that the duration of the RTCP reporting interval is equal to the total
	size of the RTCP packets sent during an RTCP interval, divided by the	size of the RTCP packets sent during an RTCP interval, divided by the
	RTCP bandwidth. (This will be approximately true in scenarios where	RTCP bandwidth. (This will be approximately true in scenarios where
	the bandwidth is not so high that the minimum RTCP interval is	the bandwidth is not so high that the minimum RTCP interval is

	reached.) For further simplification, we can assume RTCP senders are	reached.) To further simplify, we can assume that RTCP senders are
	following the recommendations regarding Compound RTCP Packets in <xref	following the recommendations regarding compound RTCP packets in <xref t
	target="I-D.ietf-avtcore-rtp-multi-stream"/>; thus, the per-packet	arget="RFC8108" format="default"/>; thus, the per-packet
	transport-layer overhead will be small relative to the RTCP data.	transport-layer overhead will be small relative to the RTCP data.
	Thus, only the actual RTCP data itself need be considered.</t>	Thus, only the actual RTCP data itself need be considered.</t>


	<t>In a report interval in this scenario, there will, as a baseline,	<t>In a report interval in this scenario, there will, as a baseline,
	be 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts	be 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts

	to approximately 6.5 kB of RTCP per report interval, assuming 16-byte	to approximately 6.5 KB of RTCP packets per report interval, assuming 16 -byte
	CNAMEs and no other SDES information.</t>	CNAMEs and no other SDES information.</t>

		<t>Using the original "everyone reports on every sender" feedback rules
	<t>Using the original <xref target="RFC3550"/>	<xref target="RFC3550" format="default"/>, each of the 184
	everyone-reports-on-every-sender feedback rules, each of the 184
	receivers will send 16 report blocks, and each of the 16 senders will	receivers will send 16 report blocks, and each of the 16 senders will

	send 15. This amounts to approximately 76 kB of report block traffic	send 15. This amounts to approximately 76 KB of report block traffic
	per interval; 92% of RTCP traffic consists of report blocks.</t>	per interval; 92% of RTCP traffic consists of report blocks.</t>

		<t>If Reporting Groups are used, however, there is only 0.4 KB of
	<t>If reporting groups are used, however, there is only 0.4 kB of
	reports per interval, with no loss of useful information.	reports per interval, with no loss of useful information.

	Additionally, there will be (assuming 16-byte RGRPs, and a single	Additionally, there will be (assuming 16-byte RGRPs and a single
	reporting source per reporting group) an additional 2.4 kB per cycle	reporting source per Reporting Group) an additional 2.4 KB per cycle
	of RGRP SDES items and RGRS packets. Put another way, the unmodified	of RTCP RGRP SDES items and RGRS packets. Put another way, the unmodifie
	<xref target="RFC3550"/> reporting interval is approximately 9 times	d
	longer than if reporting groups are in use.</t>	reporting interval per <xref target="RFC3550" format="default"/> is appr
		oximately 9 times
		longer than if Reporting Groups are in use.</t>
	</section>	</section>

		<section anchor="compat" numbered="true" toc="default">
	<section anchor="compat" title="Compatibility of RTCP Reporting Groups">	<name>Compatibility of RTCP Reporting Groups</name>
	<t>The RTCP traffic generated by receivers using RTCP Reporting Groups	<t>The RTCP traffic generated by receivers using RTCP Reporting Groups
	might appear, to observers unaware of these semantics, to be generated	might appear, to observers unaware of these semantics, to be generated
	by receivers who are experiencing a network disconnection, as the	by receivers who are experiencing a network disconnection, as the
	non-reporting sources appear not to be receiving a given sender at	non-reporting sources appear not to be receiving a given sender at
	all.</t>	all.</t>


	<t>This could be a potentially critical problem for such a sender	<t>This could be a potentially critical problem for such a sender
	using RTCP for congestion control, as such a sender might think that	using RTCP for congestion control, as such a sender might think that
	it is sending so much traffic that it is causing complete congestion	it is sending so much traffic that it is causing complete congestion
	collapse.</t>	collapse.</t>


	<t>However, such an interpretation of the session statistics would	<t>However, such an interpretation of the session statistics would
	require a fairly sophisticated RTCP analysis. Any receiver of RTCP	require a fairly sophisticated RTCP analysis. Any receiver of RTCP

	statistics which is just interested in information about itself needs	statistics that is just interested in information about itself needs
	to be prepared that any given reception report might not contain	to be prepared for the possibility that any given reception report might
		not contain
	information about a specific media source, because reception reports	information about a specific media source, because reception reports
	in large conferences can be round-robined.</t>	in large conferences can be round-robined.</t>

		<t>Thus, the extent to which such backward-compatibility
	<t>Thus, it is unclear to what extent such backward compatibility	issues would actually cause trouble in practice is unclear.</t>
	issues would actually cause trouble in practice.</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Security Considerations">	<name>Security Considerations</name>
	<t>The security considerations of <xref target="RFC3550"/> and <xref	<t>The security considerations of <xref target="RFC3550" format="default"/
	target="I-D.ietf-avtcore-rtp-multi-stream"/> apply. If the RTP/AVPF	> and <xref target="RFC8108" format="default"/> apply. If the RTP/AVPF
	profile is in use, then the security considerations of <xref	profile is in use, then the security considerations of <xref target="RFC45
	target="RFC4585"/> (and <xref target="RFC5104"/>, if used) also apply.	85" format="default"/> (and <xref target="RFC5104" format="default"/>, if used)
	If RTCP XR is used, the security consideration of <xref	also apply.
	target="RFC3611"/> and any XR report blocks used also apply.</t>	If RTCP XR is used, the security considerations of <xref
		target="RFC3611" format="default"/>, including security considerations reg
	<t>The RTCP SDES RGRP item is vulnerable to malicious modifications	arding any XR report blocks used, also apply.</t>
	unless integrity protected is used. A modification of this item's length	<t>The RTCP RGRP SDES item is vulnerable to malicious modifications
	field cause the parsing of the RTCP packet in which it is contained to	unless integrity protection is used. A modification of this item's length
		field causes the parsing of the RTCP packet in which it is contained to
	fail. Depending on the implementation, parsing of the full compound RTCP	fail. Depending on the implementation, parsing of the full compound RTCP

	packet can also fail causing the whole packet to be discarded. A	packet can also fail, causing the whole packet to be discarded. A
	modification to the value of this SDES item would make the receiver of	modification of the value of this SDES item would make the receiver of
	the report think that the sender of the report was a member of a	the report think that the sender of the report was a member of a

	different RTCP reporting group. This will potentially create an	different RTCP Reporting Group. This will potentially create an
	inconsistency, when the RGRS reports the source as being in the same	inconsistency, when the RGRS reports the source as being in the same

	reporting group as another source with another reporting group	Reporting Group as another source with another Reporting Group
	identifier. What impact on a receiver implementation such	identifier. The impacts on a receiver implementation that such
	inconsistencies would have are difficult to fully predict. One case is	inconsistencies could cause are difficult to fully predict. One case is
	when congestion control or other adaptation mechanisms are used, an	that when congestion control or other adaptation mechanisms are used, an
	inconsistent report can result in a media sender to reduce its bit-rate.	inconsistent report can result in a media sender reducing its bitrate.
	However, a direct modification of the receiver report or a feedback	However, a direct modification of the RR or a feedback
	message itself would be a more efficient attack, and equally costly to	message itself would be a more efficient attack and would be equally costl
		y to
	perform.</t>	perform.</t>

		<t>The new RGRS RTCP packet type is very simple. The common RTCP packet
	<t>The new RGRS RTCP Packet type is very simple. The common RTCP packet	type header shares the same security risks as those that affect previous R
	type header shares the security risks with previous RTCP packet types.	TCP packet types.
	Errors or modification of the length field can cause the full compound	Errors or modification of the length field can cause the full compound

	packet to fail header validation (see Appendix A.2 in <xref	packet to fail header validation (see <xref target="RFC3550" sectionFormat
	target="RFC3550"/>) resulting in the whole compound RTCP packet being	="of" section="A.2"/>), resulting in the whole compound RTCP packet being
	discarded. Modification of the SC or P fields would cause inconsistency	discarded. Modification of the SC field or the P field would cause an inco
	when processing the RTCP packet, likely resulting it being classified as	nsistency
	invalid. A modification of the PT field would cause the packet being	when processing the RTCP packet, likely resulting in the packet being clas
	interpreted under some other packet type's rules. In such case the	sified as
	result might be more or less predictable but packet type specific.	invalid. A modification of the PT field would cause the packet to be
	Modification of the SSRC of packet sender would attribute this packet to	interpreted according to some other packet type's rules. In such a case, t
	another sender. Resulting in a receiver believing the reporting group	he
	applies also for this SSRC, if it exists. If it doesn't exist, unless	result might be more or less predictable but would be specific to the pack
	also corresponding modifications are done on a SR/RR packet and a SDES	et type.
	packet the RTCP packet SHOULD be discarded. If consistent changes are	Modification of the "SSRC of packet sender" field would attribute this pac
	done, that could be part of a resource exhaustion attack on a receiver	ket to
		another sender, resulting in a receiver believing that the Reporting
		Group also applies for this SSRC, if it exists. If it doesn't exist, unles
		s
		corresponding modifications are also done on an SR/RR packet and an SDES
		packet, the RTCP packet <bcp14>SHOULD</bcp14> be discarded. If consistent
		changes are
		done, such a scenario could be part of a resource exhaustion attack on a r
		eceiver
	implementation. Modification of the "List of SSRCs for the Reporting	implementation. Modification of the "List of SSRCs for the Reporting

	Source(s)" would change the SSRC the receiver expect to report on behalf	Source(s)" field would change the SSRC the receiver expects to report on b
	of this SSRC. If that SSRC exist, that could potentially change the	ehalf
	report group used for this SSRC. A change to another reporting group	of this SSRC. If that SSRC exists, this situation could potentially change
	belonging to another endpoint is likely detectable as there would be a	the
		Reporting Group used for this SSRC. A change to another Reporting Group
		belonging to another endpoint is likely detectable, as there would be a
	mismatch between the SSRC of the packet sender's endpoint information,	mismatch between the SSRC of the packet sender's endpoint information,

	transport addresses, SDES CNAME etc and the corresponding information	transport addresses, SDES CNAME, etc., and the corresponding information
	from the reporting group indicated.</t>	from the Reporting Group indicated.</t>
		<t>In general, the Reporting Group is providing limited-impact attacks
	<t>In general the reporting group is providing limited impacts attacks.	on the endpoints. The most significant result from a deliberate attack wo
	The most significant result from an deliberate attack would be to cause	uld be to cause
	the information to be discarded or be inconsistent, including discard of	the information to be discarded or be inconsistent, including the
		discarding of
	all RTCP packets that are modified. This causes a lack of information at	all RTCP packets that are modified. This causes a lack of information at

	any receiver entity, possibly disregarding the endpoints participation	any receiver entity, possibly disregarding the endpoint's participation
	in the session.</t>	in the session.</t>

		<t>To protect against such attacks from external non-trusted
	<t>To protect against this type of attacks from external non trusted	entities, integrity and source authentication <bcp14>SHOULD</bcp14> be app
	entities, integrity and source authentication SHOULD be applied. This	lied. This
	can be done, for example, by using <xref target="RFC3711">SRTP</xref>	can be done, for example, by using <xref target="RFC3711"
	with appropriate key-management, other options exist as discussed in	format="default">the Secure Real-time Transport Protocol (SRTP)</xref>
	<xref target="RFC7201">RTP Security Options</xref>.</t>	with appropriate key management; other options exist, as discussed in
		<xref target="RFC7201" format="default">"Options for Securing RTP Sessions
	<t>The Report Group Identifier has a potential privacy impacting	"</xref>.</t>
	properties. If this would be generated by an implementation in such a	<t>The Reporting Group Identifier has properties that could potentially
	way that is long term stable or predictable, it could be used for	impact privacy. If this identifier were to be generated by an implementati
	tracking a particular end-point. Therefore it is RECOMMENDED that it be	on in a
		way that makes it long-term stable or predictable, it could be used for
		tracking a particular endpoint. Therefore, it is <bcp14>RECOMMENDED</bcp14
		> that it be
	generated as a short-term persistent RGRP, following the rules for	generated as a short-term persistent RGRP, following the rules for

	short-term persistent CNAMEs in <xref target="RFC7022"/>. The rest of	short-term persistent CNAMEs in <xref target="RFC7022" format="default"/>.
	the information revealed, i.e. the SSRCs, the size of reporting group	The rest of
	and the number of reporting sources in a reporting group is of less	the information revealed, i.e., the SSRCs, the size of the Reporting Group
		,
		and the number of reporting sources in a Reporting Group, is of a less
	sensitive nature, considering that the SSRCs and the communication would	sensitive nature, considering that the SSRCs and the communication would

	anyway be revealed without this extension. By encrypting the report	be revealed without this extension anyway. By encrypting the Reporting
	group extensions the SSRC values would preserved confidential, but can	Group extensions, the confidentiality of the SSRC values would be preserve
	still be revealed if <xref target="RFC3711">SRTP</xref> is used. The	d, but
	size of the reporting groups and number of reporting sources are likely	the values can
	determinable from analysis of the packet pattern and sizes. However,	still be revealed if <xref target="RFC3711" format="default">SRTP</xref>
		is used. The
		size of the Reporting Groups and the number of reporting sources are
		likely determinable from analysis of the packet pattern and sizes. However
		,
	this information appears to have limited value.</t>	this information appears to have limited value.</t>
	</section>	</section>

		<section numbered="true" toc="default">


	<section title="IANA Considerations">	<name>IANA Considerations</name>
	<t>(Note to the RFC-Editor: in the following, please replace "TBA" with	<t>IANA has registered a new RTCP RGRP SDES item in the
	the IANA-assigned value, and "XXXX" with the number of this document,	"RTP SDES Item Types" registry, as follows:</t>
	then delete this note)</t>

	<t>The IANA is requested to register one new RTCP SDES items in the
	"RTCP SDES Item Types" registry, as follows:</t>

	<figure>
	<artwork><![CDATA[
	Value Abbrev Name Reference
	TBA RGRP Reporting Group Identifier [RFCXXXX]
	]]></artwork>
	</figure>

	<t>The definition of the RTCP SDES RGRP item is given in <xref
	target="sec-rgrp"/> of this memo.</t>


	<t>The IANA is also requested to register one new RTCP packet type in	<table anchor="new-RTCP-SDES-item">
	the "RTCP Control Packet Types (PT)" Registry as follows:</t>	<name>New RTCP RGRP SDES Item: Reporting Group Identifier</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Abbrev</th>
		<th>Name</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>11</td>
		<td>RGRP</td>
		<td>Reporting Group Identifier</td>
		<td>RFC 8861</td>
		</tr>
		</tbody>
		</table>


	<figure>	<t>The definition of the RTCP RGRP SDES item is given in <xref
	<artwork><![CDATA[	target="sec-rgrp" format="default"/> of this memo.</t>
	Value Abbrev Name Reference
	TBA RGRS Reporting Group Reporting Sources [RFCXXXX]
	]]></artwork>
	</figure>


	<t>The definition of the RTCP RGRS packet type is given in <xref	<t>IANA has registered a new RTCP packet type in
	target="sec-rgrs"/> of this memo.</t>	the "RTCP Control Packet Types (PT)" registry, as follows:</t>


	<t>The IANA is also requested to register one new SDP attribute:</t>	<table anchor="new-RTCP-packet-type">
		<name>New RTCP Packet Type: Reporting Group Reporting Sources</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Abbrev</th>
		<th>Name</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>212</td>
		<td>RGRS</td>
		<td>Reporting Group Reporting Sources</td>
		<td>RFC 8861</td>
		</tr>
		</tbody>
		</table>


	<figure>	<t>The definition of the RTCP RGRS packet type is given in <xref target="s
	<artwork><![CDATA[	ec-rgrs" format="default"/> of this memo.</t>
	SDP Attribute ("att-field"):	<t>IANA has also registered a new SDP attribute.</t>
	Attribute name: rtcp-rgrp	<t>SDP Attribute ("att-field"):</t>
	Long form: RTCP Reporting Groups	<ul empty="true" spacing="normal"><li>
	Type of name: att-field	<dl indent="22" spacing="normal">
	Type of attribute: Media or session level	<dt>Contact Name:</dt><dd>IESG</dd>
	Subject to charset: No	<dt>Contact Email:</dt><dd>iesg@ietf.org</dd>
	Purpose: Negotiate or configure the use of the RTCP	<dt>Attribute name:</dt><dd>rtcp-rgrp</dd>
	Reporting Group Extension.	<dt>Long form:</dt><dd>RTCP Reporting Groups</dd>
	Reference: [RFCXXXX]	<dt>Type of name:</dt><dd>att-field</dd>
	Values: None	<dt>Type of attribute:</dt><dd>Media or session level</dd>
	]]></artwork>	<dt>Subject to charset:</dt><dd>No</dd>
	</figure>	<dt>Purpose:</dt><dd>To negotiate or configure the use of the RTCP Reporti
		ng Group extension</dd>
		<dt>Reference:</dt><dd>RFC 8861</dd>
		<dt>Value:</dt><dd>None</dd>
		<dt>Mux Category:</dt><dd>IDENTICAL</dd>
		</dl>
		</li>
		</ul>


	<t>The definition of the "a=rtcp-rgrp" SDES attribute is given in <xref	<t>The definition of the "a=rtcp-rgrp" SDES attribute is given in <xref ta
	target="sdp"/> of this memo.</t>	rget="sdp" format="default"/> of this memo.</t>
	</section>	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<references>
	<?rfc include="reference.RFC.2119"?>	<name>References</name>
		<references>
	<?rfc include='reference.RFC.3264'?>	<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.3550'?>	FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.4566'?>	FC.3264.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.7022'?>	FC.3550.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include="reference.I-D.ietf-avtcore-rtp-multi-stream"?>	FC.4566.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.I-D.ietf-mmusic-sdp-mux-attributes'?>	FC.7022.xml"/>
	</references>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
	<references title="Informative References">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.2326'?>	FC.8108.xml"/>

	<?rfc include='reference.RFC.2974'?>

	<?rfc include='reference.RFC.3611'?>

	<?rfc include='reference.RFC.3711'?>

	<?rfc include='reference.RFC.4585'?>

	<?rfc include='reference.RFC.4588'?>

	<?rfc include='reference.RFC.5104'?>

	<?rfc include='reference.RFC.5506'?>

	<?rfc include='reference.RFC.6190'?>


	<?rfc include='reference.RFC.7201'?>	<!-- draft-ietf-mmusic-sdp-mux-attributes (RFC 8859) -->
		<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
		<front>
		<title>A Framework for Session Description Protocol (SDP) Attributes When Mu
		ltiplexing</title>
		<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
		<organization/>
		</author>
		<date month="January" year="2021"/>
		</front>
		<seriesInfo name="RFC" value="8859"/>
		<seriesInfo name="DOI" value="10.17487/RFC8859"/>
		</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2974.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3611.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3711.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4585.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4588.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5104.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5506.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6190.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7201.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7826.xml"/>
		</references>
	</references>	</references>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 161 change blocks.
	539 lines changed or deleted	614 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/