rfc8849v4.txt		rfc8849.txt
	Internet Engineering Task Force (IETF) R. Even		Internet Engineering Task Force (IETF) R. Even
	Request for Comments: 8849		Request for Comments: 8849
	Category: Standards Track J. Lennox		Category: Standards Track J. Lennox
	ISSN: 2070-1721 8x8 / Jitsi		ISSN: 2070-1721 8x8 / Jitsi
	November 2020		January 2021
	Mapping RTP Streams to Controlling Multiple Streams for Telepresence		Mapping RTP Streams to Controlling Multiple Streams for Telepresence
	(CLUE) Media Captures		(CLUE) Media Captures
	Abstract		Abstract
	This document describes how the Real-time Transport Protocol (RTP) is		This document describes how the Real-time Transport Protocol (RTP) is
	used in the context of the Controlling Multiple Streams for		used in the context of the Controlling Multiple Streams for
	Telepresence (CLUE) protocol. It also describes the mechanisms and		Telepresence (CLUE) protocol. It also describes the mechanisms and
	recommended practice for mapping RTP media streams, as defined in the		recommended practice for mapping RTP media streams, as defined in the
	skipping to change at line 36 ¶		skipping to change at line 36 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc8849.		https://www.rfc-editor.org/info/rfc8849.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at line 133 ¶		skipping to change at line 133 ¶
	In the Point-to-Point topology, one peer communicates directly with a		In the Point-to-Point topology, one peer communicates directly with a
	single peer over unicast. There can be one or more RTP sessions,		single peer over unicast. There can be one or more RTP sessions,
	each sent on a separate 5-tuple, that have a separate SSRC space,		each sent on a separate 5-tuple, that have a separate SSRC space,
	with each RTP session carrying multiple RTP streams identified by		with each RTP session carrying multiple RTP streams identified by
	their SSRC. All SSRCs are recognized by the peers based on the		their SSRC. All SSRCs are recognized by the peers based on the
	information in the RTCP Source description (SDES) report that		information in the RTCP Source description (SDES) report that
	includes the Canonical Name (CNAME) and SSRC of the sent RTP streams.		includes the Canonical Name (CNAME) and SSRC of the sent RTP streams.
	There are different Point-to-Point use cases as specified in the CLUE		There are different Point-to-Point use cases as specified in the CLUE
	use case [RFC7205]. In some cases, a CLUE session that, at a high		use case [RFC7205]. In some cases, a CLUE session that, at a high
	level, is point-to-point may nonetheless have an RTP stream that is		level, is Point-to-Point may nonetheless have an RTP stream that is
	best described by one of the mixer topologies. For example, a CLUE		best described by one of the mixer topologies. For example, a CLUE
	endpoint can produce composite or switched captures for use by a		endpoint can produce composite or switched captures for use by a
	receiving system with fewer displays than the sender has cameras.		receiving system with fewer displays than the sender has cameras.
	The Media Capture may be described using an MCC.		The Media Capture may be described using an MCC.
	For the media mixer topology [RFC7667], the peers communicate only		For the media mixer topology [RFC7667], the peers communicate only
	with the mixer. The mixer provides mixed or composited media		with the mixer. The mixer provides mixed or composited media
	streams, using its own SSRC for the sent streams. If needed by the		streams, using its own SSRC for the sent streams. If needed by the
	CLUE endpoint, the conference roster information including conference		CLUE endpoint, the conference roster information including conference
	participants, endpoints, media, and media-id (SSRC) can be determined		participants, endpoints, media, and media-id (SSRC) can be determined
	skipping to change at line 162 ¶		skipping to change at line 162 ¶
	distribution models and RTP stream multiplexing points.		distribution models and RTP stream multiplexing points.
	Most video conferencing systems today can separate multiple RTP		Most video conferencing systems today can separate multiple RTP
	sources by placing them into RTP sessions using the SDP description;		sources by placing them into RTP sessions using the SDP description;
	the video conferencing application can also have some knowledge about		the video conferencing application can also have some knowledge about
	the purpose of each RTP session. For example, video conferencing		the purpose of each RTP session. For example, video conferencing
	applications that have a primary video source and a slides video		applications that have a primary video source and a slides video
	source can send each media source in a separate RTP session with a		source can send each media source in a separate RTP session with a
	content attribute [RFC4796], enabling different application behavior		content attribute [RFC4796], enabling different application behavior
	for each received RTP media source. Demultiplexing is		for each received RTP media source. Demultiplexing is
	straightforward because each media capture is sent as a single RTP		straightforward because each Media Capture is sent as a single RTP
	stream, with each RTP stream being sent in a separate RTP session, on		stream, with each RTP stream being sent in a separate RTP session, on
	a distinct UDP 5-tuple. This will also be true for mapping the RTP		a distinct UDP 5-tuple. This will also be true for mapping the RTP
	streams to Capture Encodings, if each Capture Encoding uses a		streams to Capture Encodings, if each Capture Encoding uses a
	separate RTP session and the consumer can identify it based on the		separate RTP session and the consumer can identify it based on the
	receiving RTP port. In this case, SDP only needs to label the RTP		receiving RTP port. In this case, SDP only needs to label the RTP
	session with an identifier that can be used to identify the Media		session with an identifier that can be used to identify the Media
	Capture in the CLUE description. The SDP label attribute serves as		Capture in the CLUE description. The SDP label attribute serves as
	this identifier.		this identifier.
	Each Capture Encoding MUST be sent as a separate RTP stream. CLUE		Each Capture Encoding MUST be sent as a separate RTP stream. CLUE
	skipping to change at line 208 ¶		skipping to change at line 208 ¶
	allowing the consumer to use the MC's original source attributes like		allowing the consumer to use the MC's original source attributes like
	the spatial information.		the spatial information.
	This mapping temporarily associates the SSRC of the RTP stream		This mapping temporarily associates the SSRC of the RTP stream
	conveying a particular MCC with the captureID of the single original		conveying a particular MCC with the captureID of the single original
	MC that is currently switched into the MCC. This mapping cannot be		MC that is currently switched into the MCC. This mapping cannot be
	used for a composed case where more than one original MC is composed		used for a composed case where more than one original MC is composed
	into the MCC simultaneously.		into the MCC simultaneously.
	If there is only one MC in the MCC, then the media provider MUST send		If there is only one MC in the MCC, then the media provider MUST send
	the captureID of the current constituent MC in the RTP Header		the captureID of the current constituent MC in the RTP header
	Extension and as an RTCP CaptureID SDES item. When the media		extension and as an RTCP CaptureID SDES item. When the media
	provider switches the MC it sends within an MCC, it MUST send the		provider switches the MC it sends within an MCC, it MUST send the
	captureID value for the MC that just switched into the MCC in an RTP		captureID value for the MC that just switched into the MCC in an RTP
	Header Extension and as an RTCP CaptureID SDES item as specified in		header extension and as an RTCP CaptureID SDES item as specified in
	[RFC7941].		[RFC7941].
	If there is more than one MC composed into the MCC, then the media		If there is more than one MC composed into the MCC, then the media
	provider MUST NOT send any of the MCs' captureIDs using this		provider MUST NOT send any of the MCs' captureIDs using this
	mechanism. However, if an MCC is sending Contributing Source (CSRC)		mechanism. However, if an MCC is sending Contributing Source (CSRC)
	information in the RTP header for a composed capture, it MAY send the		information in the RTP header for a composed capture, it MAY send the
	captureID values in the RTCP SDES packets giving source information		captureID values in the RTCP SDES packets giving source information
	for the SSRC values sent as CSRCs.		for the SSRC values sent as CSRCs.
	If the media provider sends the captureID of a single MC switched		If the media provider sends the captureID of a single MC switched
	into an MCC, then later sends one composed stream of multiple MCs in		into an MCC, then later sends one composed stream of multiple MCs in
	the same MCC, it MUST send the special value "-", a single-dash		the same MCC, it MUST send the special value "-", a single-dash
	character, as the captureID RTP Header Extension and RTCP CaptureID		character, as the captureID RTP header extension and RTCP CaptureID
	SDES item. The single-dash character indicates there is no		SDES item. The single-dash character indicates there is no
	applicable value for the MCC constituent CaptureID. The media		applicable value for the MCC constituent CaptureID. The media
	consumer interprets this as meaning that any previous CaptureID value		consumer interprets this as meaning that any previous CaptureID value
	associated with this SSRC no longer applies. As [RFC8846] defines		associated with this SSRC no longer applies. As [RFC8846] defines
	the captureID syntax as "xs:ID", the single-dash character is not a		the captureID syntax as "xs:ID", the single-dash character is not a
	legal captureID value, so there is no possibility of confusing it		legal captureID value, so there is no possibility of confusing it
	with an actual captureID.		with an actual captureID.
	5.1. RTCP CaptureID SDES Item		5.1. RTCP CaptureID SDES Item
	skipping to change at line 263 ¶		skipping to change at line 263 ¶
	SDES packet in a noncompound RTCP packet.		SDES packet in a noncompound RTCP packet.
	5.2. RTP Header Extension		5.2. RTP Header Extension
	The CaptureID is also carried in an RTP header extension [RFC8285],		The CaptureID is also carried in an RTP header extension [RFC8285],
	using the mechanism defined in [RFC7941].		using the mechanism defined in [RFC7941].
	Support is negotiated within SDP using the URN "urn:ietf:params:rtp-		Support is negotiated within SDP using the URN "urn:ietf:params:rtp-
	hdrext:sdes:CaptureID".		hdrext:sdes:CaptureID".
	The CaptureID is sent in an RTP Header Extension because for switched		The CaptureID is sent in an RTP header extension because for switched
	captures, receivers need to know which original MC corresponds to the		captures, receivers need to know which original MC corresponds to the
	media being sent for an MCC, in order to correctly apply geometric		media being sent for an MCC, in order to correctly apply geometric
	adjustments to the received media.		adjustments to the received media.
	As discussed in [RFC7941], there is no need to send the CaptId Header		As discussed in [RFC7941], there is no need to send the CaptId Header
	Extension with all RTP packets. Senders MAY choose to send it only		Extension with all RTP packets. Senders MAY choose to send it only
	when a new MC is sent. If such a mode is being used, the header		when a new MC is sent. If such a mode is being used, the header
	extension SHOULD be sent in the first few RTP packets to reduce the		extension SHOULD be sent in the first few RTP packets to reduce the
	risk of losing it due to packet loss. See [RFC7941] for further		risk of losing it due to packet loss. See [RFC7941] for further
	discussion.		discussion.
	6. Examples		6. Examples
	In this partial advertisement, the Media Provider advertises a		In this partial advertisement, the media provider advertises a
	composed capture VC7 made of a big picture representing the current		composed capture VC7 made of a big picture representing the current
	speaker (VC3) and two picture-in-picture boxes representing the		speaker (VC3) and two picture-in-picture boxes representing the
	previous speakers (the previous one -- VC5 -- and the oldest one --		previous speakers (the previous one -- VC5 -- and the oldest one --
	VC6).		VC6).
	<ns2:mediaCapture		<ns2:mediaCapture
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:type="ns2:videoCaptureType" captureID="VC7"		xsi:type="ns2:videoCaptureType" captureID="VC7"
	mediaType="video">		mediaType="video">
	<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>		<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
	skipping to change at line 512 ¶		skipping to change at line 512 ¶
	Source Description Items", RFC 7941, DOI 10.17487/RFC7941,		Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
	August 2016, <https://www.rfc-editor.org/info/rfc7941>.		August 2016, <https://www.rfc-editor.org/info/rfc7941>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,		[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
	"Negotiating Media Multiplexing Using the Session		"Negotiating Media Multiplexing Using the Session
	Description Protocol (SDP)", RFC 8843,		Description Protocol (SDP)", RFC 8843,
	DOI 10.17487/RFC8843, November 2020,		DOI 10.17487/RFC8843, January 2021,
	<https://www.rfc-editor.org/info/rfc8843>.		<https://www.rfc-editor.org/info/rfc8843>.
	[RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger,		[RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger,
	"Framework for Telepresence Multi-Streams", RFC 8845,		"Framework for Telepresence Multi-Streams", RFC 8845,
	DOI 10.17487/RFC8845, November 2020,		DOI 10.17487/RFC8845, January 2021,
	<https://www.rfc-editor.org/info/rfc8845>.		<https://www.rfc-editor.org/info/rfc8845>.
	[RFC8846] Presta, R. and S P. Romano, "An XML Schema for the		[RFC8846] Presta, R. and S P. Romano, "An XML Schema for the
	Controlling Multiple Streams for Telepresence (CLUE) Data		Controlling Multiple Streams for Telepresence (CLUE) Data
	Model", RFC 8846, DOI 10.17487/RFC8846, November 2020,		Model", RFC 8846, DOI 10.17487/RFC8846, January 2021,
	<http://www.rfc-editor.org/info/rfc8846>.		<http://www.rfc-editor.org/info/rfc8846>.
	10.2. Informative References		10.2. Informative References
	[FIPS186] National Institute of Standards and Technology (NIST),		[FIPS186] National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS)", FIPS, PUB 186-4,		"Digital Signature Standard (DSS)", FIPS, PUB 186-4,
	DOI 10.6028/NIST.FIPS.186-4, July 2013,		DOI 10.6028/NIST.FIPS.186-4, July 2013,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/		<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.186-4.pdf>.		NIST.FIPS.186-4.pdf>.
	skipping to change at line 619 ¶		skipping to change at line 619 ¶
	<https://www.rfc-editor.org/info/rfc8108>.		<https://www.rfc-editor.org/info/rfc8108>.
	[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General		[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
	Mechanism for RTP Header Extensions", RFC 8285,		Mechanism for RTP Header Extensions", RFC 8285,
	DOI 10.17487/RFC8285, October 2017,		DOI 10.17487/RFC8285, October 2017,
	<https://www.rfc-editor.org/info/rfc8285>.		<https://www.rfc-editor.org/info/rfc8285>.
	[RFC8848] Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session		[RFC8848] Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session
	Signaling for Controlling Multiple Streams for		Signaling for Controlling Multiple Streams for
	Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848,		Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848,
	November 2020, <https://www.rfc-editor.org/info/rfc8848>.		January 2021, <https://www.rfc-editor.org/info/rfc8848>.
	Acknowledgments		Acknowledgments
	The authors would like to thank Allyn Romanow and Paul Witty for		The authors would like to thank Allyn Romanow and Paul Witty for
	contributing text to this work. Magnus Westerlund helped draft the		contributing text to this work. Magnus Westerlund helped draft the
	security section.		security section.
	Authors' Addresses		Authors' Addresses
	Roni Even		Roni Even
End of changes. 13 change blocks.
	14 lines changed or deleted		14 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/