rfc8872v3.txt   rfc8872.txt 
Internet Engineering Task Force (IETF) M. Westerlund Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 8872 B. Burman Request for Comments: 8872 B. Burman
Category: Informational Ericsson Category: Informational Ericsson
ISSN: 2070-1721 C. Perkins ISSN: 2070-1721 C. Perkins
University of Glasgow University of Glasgow
H. Alvestrand H. Alvestrand
Google Google
R. Even R. Even
September 2020 January 2021
Guidelines for Using the Multiplexing Features of RTP to Support Guidelines for Using the Multiplexing Features of RTP to Support
Multiple Media Streams Multiple Media Streams
Abstract Abstract
The Real-time Transport Protocol (RTP) is a flexible protocol that The Real-time Transport Protocol (RTP) is a flexible protocol that
can be used in a wide range of applications, networks, and system can be used in a wide range of applications, networks, and system
topologies. That flexibility makes for wide applicability but can topologies. That flexibility makes for wide applicability but can
complicate the application design process. One particular design complicate the application design process. One particular design
skipping to change at line 44 skipping to change at line 44
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841. Standard; see 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/rfc8872. https://www.rfc-editor.org/info/rfc8872.
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 357 skipping to change at line 357
media descriptions to be used so that RTP Session Groups can be media descriptions to be used so that RTP Session Groups can be
created. Through the use of "Negotiating Media Multiplexing Using created. Through the use of "Negotiating Media Multiplexing Using
the Session Description Protocol (SDP)" [RFC8843], multiple media the Session Description Protocol (SDP)" [RFC8843], multiple media
descriptions become part of a common RTP session where each media descriptions become part of a common RTP session where each media
description represents the RTP streams sent or received for a media description represents the RTP streams sent or received for a media
source. source.
RTP makes no normative statements about the relationship between RTP makes no normative statements about the relationship between
different RTP sessions; however, applications that use more than one different RTP sessions; however, applications that use more than one
RTP session need to understand how the different RTP sessions that RTP session need to understand how the different RTP sessions that
are created relate to one another. they create relate to one another.
3.2.2. Synchronization Source (SSRC) 3.2.2. Synchronization Source (SSRC)
An SSRC identifies a source of an RTP stream, or an RTP receiver when An SSRC identifies a source of an RTP stream, or an RTP receiver when
sending RTCP. Every endpoint has at least one SSRC identifier, even sending RTCP. Every endpoint has at least one SSRC identifier, even
if it does not send RTP packets. RTP endpoints that are only RTP if it does not send RTP packets. RTP endpoints that are only RTP
receivers still send RTCP and use their SSRC identifiers in the RTCP receivers still send RTCP and use their SSRC identifiers in the RTCP
packets they send. An endpoint can have multiple SSRC identifiers if packets they send. An endpoint can have multiple SSRC identifiers if
it sends multiple RTP streams. Endpoints that function as both RTP it sends multiple RTP streams. Endpoints that function as both RTP
sender and RTP receiver use the same SSRC(s) in both roles. sender and RTP receiver use the same SSRC(s) in both roles.
skipping to change at line 749 skipping to change at line 749
SSRC carrying the RTP retransmission payload, where that SSRC is from SSRC carrying the RTP retransmission payload, where that SSRC is from
the same CNAME. This limits a requester to having only one the same CNAME. This limits a requester to having only one
outstanding retransmission request on any new SSRCs per endpoint. outstanding retransmission request on any new SSRCs per endpoint.
"RTP Payload Format Restrictions" [RFC8851] provides an RTP/RTCP- "RTP Payload Format Restrictions" [RFC8851] provides an RTP/RTCP-
based mechanism to unambiguously identify the RTP streams within an based mechanism to unambiguously identify the RTP streams within an
RTP session and restrict the streams' payload format parameters in a RTP session and restrict the streams' payload format parameters in a
codec-agnostic way beyond what is provided with the regular payload codec-agnostic way beyond what is provided with the regular payload
types. The mapping is done by specifying an "a=rid" value in the SDP types. The mapping is done by specifying an "a=rid" value in the SDP
offer/answer signaling and having the corresponding RtpStreamId value offer/answer signaling and having the corresponding RtpStreamId value
as an SDES item and an RTP header extension. The RID solution also as an SDES item and an RTP header extension [RFC8852]. The RID
includes a solution for binding redundancy RTP streams to their solution also includes a solution for binding redundancy RTP streams
original source RTP streams, given that those streams use RID to their original source RTP streams, given that those streams use
identifiers. RID identifiers. The redundancy stream uses the RepairedRtpStreamId
SDES item and RTP header extension to declare the RtpStreamId value
of the source stream to create the binding.
Experience has shown that an explicit binding between the RTP Experience has shown that an explicit binding between the RTP
streams, agnostic of SSRC values, behaves well. That way, solutions streams, agnostic of SSRC values, behaves well. That way, solutions
using multiple RTP streams in a single RTP session and in multiple using multiple RTP streams in a single RTP session and in multiple
RTP sessions will use the same type of binding. RTP sessions will use the same type of binding.
3.4.4. Forward Error Correction 3.4.4. Forward Error Correction
There exist a number of FEC-based schemes designed to mitigate packet There exist a number of FEC-based schemes designed to mitigate packet
loss in the original streams. Most of the FEC schemes protect a loss in the original streams. Most of the FEC schemes protect a
skipping to change at line 1633 skipping to change at line 1635
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<https://www.rfc-editor.org/info/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015, DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>. <https://www.rfc-editor.org/info/rfc7667>.
[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, September 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",
RFC 8851, DOI 10.17487/RFC8851, September 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
Identifier Source Description (SDES)", RFC 8852,
DOI 10.17487/RFC8852, January 2021,
<https://www.rfc-editor.org/info/rfc8852>.
[RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending [RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", Multiple Types of Media in a Single RTP Session",
RFC 8860, DOI 10.17487/RFC8860, September 2020, RFC 8860, DOI 10.17487/RFC8860, January 2021,
<https://www.rfc-editor.org/info/rfc8860>. <https://www.rfc-editor.org/info/rfc8860>.
[RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. [RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
Andreasen, "Encrypted Key Transport for DTLS and Secure Andreasen, "Encrypted Key Transport for DTLS and Secure
RTP", RFC 8870, DOI 10.17487/RFC8870, September 2020, RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021,
<https://www.rfc-editor.org/info/rfc8870>. <https://www.rfc-editor.org/info/rfc8870>.
9.2. Informative References 9.2. Informative References
[JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, [JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan,
S., and J. Hildebrand, "XEP-0166: Jingle", September 2018, S., and J. Hildebrand, "XEP-0166: Jingle", September 2018,
<https://xmpp.org/extensions/xep-0166.html>. <https://xmpp.org/extensions/xep-0166.html>.
[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-
skipping to change at line 1787 skipping to change at line 1794
"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>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream
Identifier Source Description (SDES)", RFC 8852,
DOI 10.17487/RFC8852, September 2020,
<https://www.rfc-editor.org/info/rfc8852>.
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy-Enhanced RTP Framework for Private Media in Privacy-Enhanced RTP
Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
September 2020, <https://www.rfc-editor.org/info/rfc8871>. January 2021, <https://www.rfc-editor.org/info/rfc8871>.
Appendix A. Dismissing Payload Type Multiplexing Appendix A. Dismissing Payload Type Multiplexing
This section documents a number of reasons why using the payload type This section documents a number of reasons why using the payload type
as a multiplexing point is unsuitable for most issues related to as a multiplexing point is unsuitable for most issues related to
multiple RTP streams. Attempting to use payload type multiplexing multiple RTP streams. Attempting to use payload type multiplexing
beyond its defined usage has well-known negative effects on RTP, as beyond its defined usage has well-known negative effects on RTP, as
discussed below. To use the payload type as the single discriminator discussed below. To use the payload type as the single discriminator
for multiple streams implies that all the different RTP streams are for multiple streams implies that all the different RTP streams are
being sent with the same SSRC, thus using the same timestamp and being sent with the same SSRC, thus using the same timestamp and
skipping to change at line 2007 skipping to change at line 2009
the document. the document.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamnsgatan 23 Torshamnsgatan 23
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Bo Burman Bo Burman
Ericsson Ericsson
Gronlandsgatan 31 Gronlandsgatan 31
SE-164 60 Kista SE-164 60 Kista
Sweden Sweden
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
 End of changes. 12 change blocks. 
18 lines changed or deleted 19 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/