Diff: rfc8853v3.txt - rfc8853.txt

	rfc8853v3.txt	rfc8853.txt

	Internet Engineering Task Force (IETF) B. Burman	Internet Engineering Task Force (IETF) B. Burman
	Request for Comments: 8853 M. Westerlund	Request for Comments: 8853 M. Westerlund
	Category: Standards Track Ericsson	Category: Standards Track Ericsson
	ISSN: 2070-1721 S. Nandakumar	ISSN: 2070-1721 S. Nandakumar
	M. Zanaty	M. Zanaty
	Cisco	Cisco

	May 2020	January 2021

	Using Simulcast in Session Description Protocol (SDP) and RTP Sessions	Using Simulcast in Session Description Protocol (SDP) and RTP Sessions

	Abstract	Abstract

	In some application scenarios, it may be desirable to send multiple	In some application scenarios, it may be desirable to send multiple
	differently encoded versions of the same media source in different	differently encoded versions of the same media source in different
	RTP streams. This is called simulcast. This document describes how	RTP streams. This is called simulcast. This document describes how
	to accomplish simulcast in RTP and how to signal it in the Session	to accomplish simulcast in RTP and how to signal it in the Session
	Description Protocol (SDP). The described solution uses an RTP/RTCP	Description Protocol (SDP). The described solution uses an RTP/RTCP

	skipping to change at line 41 ¶	skipping to change at line 41 ¶
	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/rfc8853.	https://www.rfc-editor.org/info/rfc8853.

	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 1166 ¶	skipping to change at line 1166 ¶
	those agreed between the SFM and the receiver, and no MID values from	those agreed between the SFM and the receiver, and no MID values from
	the originating side of the SFM are to be forwarded.	the originating side of the SFM are to be forwarded.

	An SFM could expose corresponding RTP streams for all the media	An SFM could expose corresponding RTP streams for all the media
	sources and their simulcast streams and then, for any media source	sources and their simulcast streams and then, for any media source
	that is to be provided, forward one selected simulcast stream.	that is to be provided, forward one selected simulcast stream.
	However, this is not recommended, as it would unnecessarily increase	However, this is not recommended, as it would unnecessarily increase
	the number of RTP streams and require the receiver to timely detect	the number of RTP streams and require the receiver to timely detect
	switching between simulcast streams. The above usage requires the	switching between simulcast streams. The above usage requires the
	same SFM functionality for switching, while avoiding the	same SFM functionality for switching, while avoiding the

	uncertainties of timely detecting that a RTP stream ends. The	uncertainties of timely detecting that an RTP stream ends. The
	benefit would be that the received simulcast stream would be	benefit would be that the received simulcast stream would be
	implicitly provided by which RTP stream would be active for a media	implicitly provided by which RTP stream would be active for a media
	source. However, using RtpStreamId to make this explicit also	source. However, using RtpStreamId to make this explicit also
	exposes which alternative format is used. The conclusion is that	exposes which alternative format is used. The conclusion is that
	using one RTP stream per simulcast stream is unnecessary. The issue	using one RTP stream per simulcast stream is unnecessary. The issue
	with timely detecting end of streams, independent of whether they are	with timely detecting end of streams, independent of whether they are
	stopped temporarily or long term, is that there is no explicit	stopped temporarily or long term, is that there is no explicit
	indication that the transmission has intentionally been stopped. The	indication that the transmission has intentionally been stopped. The
	RTCP-based pause and resume mechanism [RFC7728] includes a PAUSED	RTCP-based pause and resume mechanism [RFC7728] includes a PAUSED
	indication that provides the last RTP sequence number transmitted	indication that provides the last RTP sequence number transmitted

	skipping to change at line 1216 ¶	skipping to change at line 1216 ¶
	they are. The RTP-stream-to-MID and -RtpStreamId associations should	they are. The RTP-stream-to-MID and -RtpStreamId associations should
	here be long-term stable.	here be long-term stable.

	7. Network Aspects	7. Network Aspects

	Simulcast is in this memo defined as the act of sending multiple	Simulcast is in this memo defined as the act of sending multiple
	alternative encoded streams of the same underlying media source.	alternative encoded streams of the same underlying media source.
	Transmitting multiple independent streams that originate from the	Transmitting multiple independent streams that originate from the
	same source could potentially be done in several different ways using	same source could potentially be done in several different ways using
	RTP. A general discussion on considerations for use of the different	RTP. A general discussion on considerations for use of the different

	RTP multiplexing alternatives can be found in "Guidelines for using	RTP multiplexing alternatives can be found in "Guidelines for Using
	the Multiplexing Features of RTP to Support Multiple Media Streams"	the Multiplexing Features of RTP to Support Multiple Media Streams"

	[MULTIPLEX]. Discussion and clarification on how to handle multiple	[RFC8872]. Discussion and clarification on how to handle multiple
	streams in an RTP session can be found in [RFC8108].	streams in an RTP session can be found in [RFC8108].

	The network aspects that are relevant for simulcast are:	The network aspects that are relevant for simulcast are:

	Quality of Service (QoS): When using simulcast, it might be of	Quality of Service (QoS): When using simulcast, it might be of
	interest to prioritize a particular simulcast stream, rather than	interest to prioritize a particular simulcast stream, rather than
	applying equal treatment to all streams. For example, lower-	applying equal treatment to all streams. For example, lower-
	bitrate streams may be prioritized over higher-bitrate streams to	bitrate streams may be prioritized over higher-bitrate streams to
	minimize congestion or packet losses in the low-bitrate streams.	minimize congestion or packet losses in the low-bitrate streams.
	Thus, there is a benefit to using a simulcast solution with good	Thus, there is a benefit to using a simulcast solution with good

	skipping to change at line 1371 ¶	skipping to change at line 1371 ¶
	Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728,	Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728,
	February 2016, <https://www.rfc-editor.org/info/rfc7728>.	February 2016, <https://www.rfc-editor.org/info/rfc7728>.

	[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, April 2020,	DOI 10.17487/RFC8843, January 2021,
	<https://www.rfc-editor.org/info/rfc8843>.	<https://www.rfc-editor.org/info/rfc8843>.

	[RFC8851] Roach, A.B., Ed., "RTP Payload Format Restrictions",	[RFC8851] Roach, A.B., Ed., "RTP Payload Format Restrictions",

	DOI 10.17487/RFC8851, RFC 8851, April 2020,	RFC 8851, DOI 10.17487/RFC8851, January 2021,
	<https://www.rfc-editor.org/info/rfc8851>.	<https://www.rfc-editor.org/info/rfc8851>.

	[RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream	[RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream

	Identifier Source Description (SDES)",	Identifier Source Description (SDES)", RFC 8852,
	DOI 10.17487/RFC8852, RFC 8852, April 2020,	DOI 10.17487/RFC8852, January 2021,
	<https://www.rfc-editor.org/info/rfc8852>.	<https://www.rfc-editor.org/info/rfc8852>.


	[RFC8859] Nandakumar, S., "A Framework for SDP Attributes when	[RFC8859] Nandakumar, S., "A Framework for Session Description
	Multiplexing", RFC 8859, DOI 10.17487/RFC8859, April 2020,	Protocol (SDP) Attributes When Multiplexing", RFC 8859,
		DOI 10.17487/RFC8859, January 2021,
	<https://www.rfc-editor.org/info/rfc8859>.	<https://www.rfc-editor.org/info/rfc8859>.

	11.2. Informative References	11.2. Informative References


	[MULTIPLEX]
	Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
	and R. Even, "Guidelines for using the Multiplexing
	Features of RTP to Support Multiple Media Streams", Work
	in Progress, Internet-Draft, draft-ietf-avtcore-multiplex-
	guidelines-12, 16 June 2020, <https://tools.ietf.org/html/
	draft-ietf-avtcore-multiplex-guidelines-12>.

	[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,	[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
	Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-	Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-
	Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,	Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
	DOI 10.17487/RFC2198, September 1997,	DOI 10.17487/RFC2198, September 1997,
	<https://www.rfc-editor.org/info/rfc2198>.	<https://www.rfc-editor.org/info/rfc2198>.

	[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for	[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
	Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,	Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
	September 2002, <https://www.rfc-editor.org/info/rfc3389>.	September 2002, <https://www.rfc-editor.org/info/rfc3389>.


	skipping to change at line 1487 ¶	skipping to change at line 1480 ¶
	[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,	[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	"Sending Multiple RTP Streams in a Single RTP Session",	"Sending Multiple RTP Streams in a Single RTP Session",
	RFC 8108, DOI 10.17487/RFC8108, March 2017,	RFC 8108, DOI 10.17487/RFC8108, March 2017,
	<https://www.rfc-editor.org/info/rfc8108>.	<https://www.rfc-editor.org/info/rfc8108>.

	[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP	[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
	Payload Format for Flexible Forward Error Correction	Payload Format for Flexible Forward Error Correction
	(FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019,	(FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019,
	<https://www.rfc-editor.org/info/rfc8627>.	<https://www.rfc-editor.org/info/rfc8627>.


		[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
		and R. Even, "Guidelines for Using the Multiplexing
		Features of RTP to Support Multiple Media Streams",
		RFC 8872, DOI 10.17487/RFC8872, January 2021,
		<https://www.rfc-editor.org/info/rfc8872>.

	Appendix A. Requirements	Appendix A. Requirements

	The following requirements are met by the defined solution to support	The following requirements are met by the defined solution to support
	the use cases (Section 3):	the use cases (Section 3):

	REQ-1: Identification:	REQ-1: Identification:

	REQ-1.1: It must be possible to identify a set of simulcasted RTP	REQ-1.1: It must be possible to identify a set of simulcasted RTP
	streams as originating from the same media source in SDP	streams as originating from the same media source in SDP
	signaling.	signaling.

End of changes. 11 change blocks.
	19 lines changed or deleted	18 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/