draft-ietf-avtcore-multiplex-guidelines-06.txt   draft-ietf-avtcore-multiplex-guidelines-07.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft B. Burman Internet-Draft B. Burman
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: January 3, 2019 C. Perkins Expires: June 10, 2019 C. Perkins
University of Glasgow University of Glasgow
H. Alvestrand H. Alvestrand
Google Google
R. Even R. Even
Huawei Huawei
July 2, 2018 December 07, 2018
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
draft-ietf-avtcore-multiplex-guidelines-06 draft-ietf-avtcore-multiplex-guidelines-07
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
question that has received much attention is how to support multiple question that has received much attention is how to support multiple
media streams in RTP. This memo discusses the available options and media streams in RTP. This memo discusses the available options and
design trade-offs, and provides guidelines on how to use the design trade-offs, and provides guidelines on how to use the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on June 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Subjects Out of Scope . . . . . . . . . . . . . . . . . . 5 2.2. Subjects Out of Scope . . . . . . . . . . . . . . . . . . 5
3. RTP Multiplexing Overview . . . . . . . . . . . . . . . . . . 5 3. RTP Multiplexing Overview . . . . . . . . . . . . . . . . . . 5
3.1. Reasons for Multiplexing and Grouping RTP Streams . . . . 5 3.1. Reasons for Multiplexing and Grouping RTP Streams . . . . 5
3.2. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6 3.2. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6
3.2.1. RTP Session . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. RTP Session . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Synchronisation Source (SSRC) . . . . . . . . . . . . 8 3.2.2. Synchronisation Source (SSRC) . . . . . . . . . . . . 8
3.2.3. Contributing Source (CSRC) . . . . . . . . . . . . . 10 3.2.3. Contributing Source (CSRC) . . . . . . . . . . . . . 9
3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 10 3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 10
3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11
3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 12 3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 12
3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 13 3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 12
3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 15 3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 14
3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 14
3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17 3.4.4. Forward Error Correction . . . . . . . . . . . . . . 16
4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17 4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17
4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 4.1. Interworking Considerations . . . . . . . . . . . . . . . 17
4.1.1. Application Interworking . . . . . . . . . . . . . . 18 4.1.1. Application Interworking . . . . . . . . . . . . . . 17
4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 17
4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 19 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18
4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 20 4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19
4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 4.2. Network Considerations . . . . . . . . . . . . . . . . . 20
4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20
4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 21 4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 20
4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 23 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Security and Key Management Considerations . . . . . . . 24 4.3. Security and Key Management Considerations . . . . . . . 23
4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24
4.3.2. Key Management for Multi-party sessions . . . . . . . 25 4.3.2. Key Management for Multi-party sessions . . . . . . . 24
4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25
5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26 5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 25
5.1. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 26 5.1. Multiple Media Types in one Session . . . . . . . . . . . 25
5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27 5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 26
5.3. Multiple Sessions for one Media type . . . . . . . . . . 28 5.3. Multiple Sessions for one Media type . . . . . . . . . . 28
5.4. Multiple Media Types in one Session . . . . . . . . . . . 30 5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 29
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 37
Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 38 Appendix B. Signalling Considerations . . . . . . . . . . . . . 39
Appendix B. Signalling Considerations . . . . . . . . . . . . . 40 B.1. Session Oriented Properties . . . . . . . . . . . . . . . 39
B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40 B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 40
B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 41 B.3. Signalling RTP stream Usage . . . . . . . . . . . . . . . 40
B.3. Signalling RTP stream Usage . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used
protocol for real-time media transport. It is a protocol that protocol for real-time media transport. It is a protocol that
provides great flexibility and can support a large set of different provides great flexibility and can support a large set of different
applications. RTP was from the beginning designed for multiple applications. RTP was from the beginning designed for multiple
participants in a communication session. It supports many topology participants in a communication session. It supports many topology
paradigms and usages, as defined in [RFC7667]. RTP has several paradigms and usages, as defined in [RFC7667]. RTP has several
multiplexing points designed for different purposes. These enable multiplexing points designed for different purposes. These enable
skipping to change at page 4, line 34 skipping to change at page 4, line 34
The definitions in Section 3 of [RFC3550] are referenced normatively. The definitions in Section 3 of [RFC3550] are referenced normatively.
The taxonomy defined in [RFC7656] is referenced normatively. The taxonomy defined in [RFC7656] is referenced normatively.
The following terms and abbreviations are used in this document: The following terms and abbreviations are used in this document:
Multiparty: A communication situation including multiple endpoints. Multiparty: A communication situation including multiple endpoints.
In this document, it will be used to refer to situations where In this document, it will be used to refer to situations where
more than two endpoints communicate. more than two endpoints communicate.
RTP Source: The originator or source of a particular RTP stream sent
from an endpoint. Identified using an SSRC in a particular RTP
session. An RTP source is the source of a single RTP stream, and
is associated with a single endpoint and a single media source.
An RTP Source is just called a Source in RFC 3550. An endpoint
can have multiple RTP sources.
RTP Sink: An endpoint that receives RTP streams. The RTP Sink is
identified using one or more SSRCs. The SSRCs used by an RTP sink
can be both RTP source ones, as well as used soley to represent
the RTP sink. There can be more than one RTP Sink for one RTP
source.
Multiplexing: The operation of taking multiple entities as input, Multiplexing: The operation of taking multiple entities as input,
aggregating them onto some common resource while keeping the aggregating them onto some common resource while keeping the
individual entities addressable such that they can later be fully individual entities addressable such that they can later be fully
and unambiguously separated (de-multiplexed) again. and unambiguously separated (de-multiplexed) again.
RTP Session Group: One or more RTP sessions that are used together RTP Session Group: One or more RTP sessions that are used together
to perform some function. Examples are multiple RTP sessions used to perform some function. Examples are multiple RTP sessions used
to carry different layers of a layered encoding. In an RTP to carry different layers of a layered encoding. In an RTP
Session Group, CNAMEs are assumed to be valid across all RTP Session Group, CNAMEs are assumed to be valid across all RTP
sessions, and designate synchronisation contexts that can cross sessions, and designate synchronisation contexts that can cross
skipping to change at page 7, line 23 skipping to change at page 6, line 37
Session | RTCP || +------> STUN (multiplexed using same port) Session | RTCP || +------> STUN (multiplexed using same port)
+-- || +-- ||
+-- || +-- ||
| (split by SSRC) | (split by SSRC)
| || || || | || || ||
| || || || | || || ||
RTP | +--+ +--+ +--+ RTP | +--+ +--+ +--+
Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, etc. Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, etc.
| +--+ +--+ +--+ | +--+ +--+ +--+
+-- | | | +-- | | |
(select decoder based on PT)
+-- | / | +-- | / |
| +----+ | | +----+ |
| / | | | / | |
Payload | +---+ +---+ +---+ Payload | +---+ +---+ +---+
Formats | |Dec| |Dec| |Dec| Decoders Formats | |Dec| |Dec| |Dec| Decoders
| +---+ +---+ +---+ | +---+ +---+ +---+
+-- +--
Figure 1: RTP Demultiplexing Process Figure 1: RTP Demultiplexing Process
skipping to change at page 8, line 11 skipping to change at page 7, line 32
the Session Description Protocol (SDP) [RFC4566] "a=ssrc:" attribute the Session Description Protocol (SDP) [RFC4566] "a=ssrc:" attribute
[RFC5576]). Thus, the scope of an RTP session is determined by the [RFC5576]). Thus, the scope of an RTP session is determined by the
participants' network interconnection topology, in combination with participants' network interconnection topology, in combination with
RTP and RTCP forwarding strategies deployed by the endpoints and any RTP and RTCP forwarding strategies deployed by the endpoints and any
middleboxes, and by the signalling. middleboxes, and by the signalling.
For RTP session separation within a single endpoint, RTP relies on For RTP session separation within a single endpoint, RTP relies on
the underlying transport layer, and on the signalling to identify RTP the underlying transport layer, and on the signalling to identify RTP
sessions in a manner that is meaningful to the application. A single sessions in a manner that is meaningful to the application. A single
endpoint can have one or more transport flows for the same RTP endpoint can have one or more transport flows for the same RTP
session. The signalling layer might give RTP sessions an explicit session, and a single RTP session can span multiple transport layer
flows. The signalling layer might give RTP sessions an explicit
identifier, or the identification might be implicit based on the identifier, or the identification might be implicit based on the
addresses and ports used. Accordingly, a single RTP session can have addresses and ports used. Accordingly, a single RTP session can have
multiple associated identifiers, explicit and implicit, belonging to multiple associated identifiers, explicit and implicit, belonging to
different contexts. For example, when running RTP on top of UDP/IP, different contexts. For example, when running RTP on top of UDP/IP,
an RTP endpoint can identify and delimit an RTP session from other an RTP endpoint can identify and delimit an RTP session from other
RTP sessions by receiving the multiple UDP flows used as identified RTP sessions by receiving the multiple UDP flows used as identified
based on their UDP source and destination IP addresses and UDP port based on their UDP source and destination IP addresses and UDP port
numbers. Another example is SDP media descriptions (the "m=" line numbers. Another example is SDP media descriptions (the "m=" line
and the following associated lines) signals the transport flow and and the following associated lines) signals the transport flow and
RTP session configuration for the endpoints part of the RTP session. RTP session configuration for the endpoints part of the RTP session.
skipping to change at page 8, line 36 skipping to change at page 8, line 9
multiple media descriptions where each represents the RTP streams multiple media descriptions where each represents the RTP streams
sent or received for a media source are part of a common RTP session. sent or received for a media source are part of a common RTP session.
The RTP protocol makes no normative statements about the relationship The RTP protocol makes no normative statements about the relationship
between different RTP sessions, however the applications that use between different RTP sessions, however the applications that use
more than one RTP session will have some higher layer understanding more than one RTP session will have some higher layer understanding
of the relationship between the sessions they create. of the relationship between the sessions they create.
3.2.2. Synchronisation Source (SSRC) 3.2.2. Synchronisation Source (SSRC)
A synchronisation source (SSRC) identifies an RTP source or an RTP A synchronisation source (SSRC) identifies an source of an RTP stream
sink. Every endpoint has at least one SSRC identifier, even if it or an RTP receiver when sending RTCP. Every endpoint has at least
does not send RTP packets. RTP endpoints that are only RTP sinks one SSRC identifier, even if it does not send RTP packets. RTP
still send RTCP and use their SSRC identifiers in the RTCP packets endpoints that are only RTP receivers still send RTCP and use their
they send. An endpoint can have multiple SSRC identifiers if it SSRC identifiers in the RTCP packets they send. An endpoint can have
contains multiple RTP sources (i.e., if it sends multiple RTP multiple SSRC identifiers if it sends multiple RTP streams.
streams). Endpoints that are both RTP sources and RTP sinks use the Endpoints that are both RTP streams sender and RTP receiver use the
same SSRC in both roles. At any given time, an RTP source has one same SSRC in both roles.
and only one SSRC - although that can change over the lifetime of the
RTP source or sink.
The SSRC is a 32-bit identifier. It is present in every RTP and RTCP The SSRC is a 32-bit identifier. It is present in every RTP and RTCP
packet header, and in the payload of some RTCP packet types. It can packet header, and in the payload of some RTCP packet types. It can
also be present in SDP signalling. Unless pre-signalled, e.g. using also be present in SDP signalling. Unless pre-signalled, e.g. using
the SDP "a=ssrc:" attribute [RFC5576], the SSRC is chosen at random. the SDP "a=ssrc:" attribute [RFC5576], the SSRC is chosen at random.
It is not dependent on the network address of the endpoint, and is It is not dependent on the network address of the endpoint, and is
intended to be unique within an RTP session. SSRC collisions can intended to be unique within an RTP session. SSRC collisions can
occur, and are handled as specified in [RFC3550] and [RFC5576], occur, and are handled as specified in [RFC3550] and [RFC5576],
resulting in the SSRC of the colliding RTP sources and/or sinks resulting in the SSRC of the colliding RTP streams or receivers
changing. An RTP source that changes its network transport address changing. An RTP sending endpoint that changes its network transport
during a session have to choose a new SSRC identifier to avoid being address during a session have to choose a new SSRC identifier to
interpreted as looped source, unless the transport layer mechansism, avoid being interpreted as looped source, unless the transport layer
e.g ICE [RFC5245], handle such changes mechanism, e.g ICE [RFC8445], handles such changes.
SSRC identifiers that belong to the same synchronisation context SSRC identifiers that belong to the same synchronisation context
(i.e., that represent RTP streams that can be synchronised using (i.e., that represent RTP streams that can be synchronised using
information in RTCP SR packets) use identical CNAME chunks in information in RTCP SR packets) use identical CNAME chunks in
corresponding RTCP SDES packets. SDP signalling can also be used to corresponding RTCP SDES packets. SDP signalling can also be used to
provide explicit SSRC grouping [RFC5576]. provide explicit SSRC grouping [RFC5576].
In some cases, the same SSRC identifier value is used to relate In some cases, the same SSRC identifier value is used to relate
streams in two different RTP sessions, such as in RTP retransmission streams in two different RTP sessions, such as in RTP retransmission
[RFC4588]. This is to be avoided since there is no guarantee that [RFC4588]. This is to be avoided since there is no guarantee that
SSRC values are unique across RTP sessions. For the RTP SSRC values are unique across RTP sessions. For the RTP
retransmission [RFC4588] case it is recommended to use explicit retransmission [RFC4588] case it is recommended to use explicit
binding of the source RTP stream and the redundancy stream, e.g. binding of the source RTP stream and the redundancy stream, e.g.
using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid].
Note that RTP sequence number and RTP timestamp are scoped by the Note that RTP sequence number and RTP timestamp are scoped by the
SSRC. Each RTP source will have a different SSRC, and the SSRC and thus specific per RTP stream.
corresponding RTP stream will have a separate RTP sequence number and
timestamp space.
An SSRC identifier is used by different type of sources as well as An SSRC identifier is used by different type of sources as well as
sinks: receivers:
Real Media Source: Connected to a "physical" media source, for Real Media Source: Connected to a "physical" media source, for
example a camera or microphone. example a camera or microphone.
Conceptual Media Source: A source with some attributed property Conceptual Media Source: A media source with some attributed
generated by some network node, for example a filtering function property generated by some network node, for example a filtering
in an RTP mixer that provides the most active speaker based on function in an RTP mixer that provides the most active speaker
some criteria, or a mix representing a set of other sources. based on some criteria, or a mix representing a set of other
sources.
RTP Sink: A source that does not generate any RTP stream in RTP receiver: A receiver that does not generate any RTP stream
itself (e.g. an endpoint or middlebox only receiving in an RTP themself (e.g. an endpoint or middlebox only receiving in an RTP
session). It still needs an SSRC for use as source in RTCP session). It still needs an SSRC for use as source in RTCP
reports. reports.
Note that an endpoint that generates more than one media type, e.g. a Note that an endpoint that generates more than one media type, e.g.
conference participant sending both audio and video, need not (and a conference participant sending both audio and video, need not (and
should not) use the same SSRC value across RTP sessions. RTCP should not) use the same SSRC value across RTP sessions. RTCP
Compound packets containing the CNAME SDES item is the designated Compound packets containing the CNAME SDES item is the designated
method to bind an SSRC to a CNAME, effectively cross-correlating method to bind an SSRC to a CNAME, effectively cross-correlating
SSRCs within and between RTP Sessions as coming from the same SSRCs within and between RTP Sessions as coming from the same
endpoint. The main property attributed to SSRCs associated with the endpoint. The main property attributed to SSRCs associated with the
same CNAME is that they are from a particular synchronisation context same CNAME is that they are from a particular synchronisation context
and can be synchronised at playback. and can be synchronised at playback.
An RTP receiver receiving a previously unseen SSRC value will An RTP receiver receiving a previously unseen SSRC value will
interpret it as a new source. It might in fact be a previously interpret it as a new source. It might in fact be a previously
skipping to change at page 11, line 10 skipping to change at page 10, line 28
be described by out-of-band signalling means. In SDP, the term be described by out-of-band signalling means. In SDP, the term
"format" includes media type, RTP timestamp sampling rate, codec, "format" includes media type, RTP timestamp sampling rate, codec,
codec configuration, payload format configurations, and various codec configuration, payload format configurations, and various
robustness mechanisms such as redundant encodings [RFC2198]. robustness mechanisms such as redundant encodings [RFC2198].
The RTP payload type is scoped by the sending endpoint within an RTP The RTP payload type is scoped by the sending endpoint within an RTP
session. PT has the same meaning across all RTP streams in an RTP session. PT has the same meaning across all RTP streams in an RTP
session. All SSRCs sent from a single endpoint share the same session. All SSRCs sent from a single endpoint share the same
payload type definitions. The RTP payload type is designed such that payload type definitions. The RTP payload type is designed such that
only a single payload type is valid at any time instant in the RTP only a single payload type is valid at any time instant in the RTP
source's RTP timestamp time line, effectively time-multiplexing stream's timestamp time line, effectively time-multiplexing different
different payload types if any change occurs. The payload type used payload types if any change occurs. The payload type used can change
can change on a per-packet basis for an SSRC, for example a speech on a per-packet basis for an SSRC, for example a speech codec making
codec making use of generic comfort noise [RFC3389]. If there is a use of generic comfort noise [RFC3389]. If there is a true need to
true need to send multiple payload types for the same SSRC that are send multiple payload types for the same SSRC that are valid for the
valid for the same instant, then redundant encodings [RFC2198] can be same instant, then redundant encodings [RFC2198] can be used.
used. Several additional constraints than the ones mentioned above Several additional constraints than the ones mentioned above need to
need to be met to enable this use, one of which is that the combined be met to enable this use, one of which is that the combined payload
payload sizes of the different payload types ought not exceed the sizes of the different payload types ought not exceed the transport
transport MTU. If it is acceptable to send multiple formats of the MTU. If it is acceptable to send multiple formats of the same media
same media source as separate RTP streams (with separate SSRC), source as separate RTP streams (with separate SSRC), simulcast
simulcast [I-D.ietf-mmusic-sdp-simulcast] can be used. [I-D.ietf-mmusic-sdp-simulcast] can be used.
Other aspects of RTP payload format use are described in How to Write Other aspects of RTP payload format use are described in How to Write
an RTP Payload Format [RFC8088]. an RTP Payload Format [RFC8088].
The payload type is not a multiplexing point at the RTP layer (see The payload type is not a multiplexing point at the RTP layer (see
Appendix A for a detailed discussion of why using the payload type as Appendix A for a detailed discussion of why using the payload type as
an RTP multiplexing point does not work). The RTP payload type is, an RTP multiplexing point does not work). The RTP payload type is,
however, used to determine how to consume and decode an RTP stream. however, used to determine how to consume and decode an RTP stream.
The RTP payload type number is sometimes used to associate an RTP The RTP payload type number is sometimes used to associate an RTP
stream with the signalling; this is not recommended since a specific stream with the signalling; this is not recommended since a specific
skipping to change at page 12, line 8 skipping to change at page 11, line 29
SSRCs per RTP session? SSRCs per RTP session?
o Do I need network differentiation in form of QoS? o Do I need network differentiation in form of QoS?
o Can the application more easily process and handle the media o Can the application more easily process and handle the media
streams if they are in different RTP sessions? streams if they are in different RTP sessions?
o Do I need to use additional RTP streams for RTP retransmission or o Do I need to use additional RTP streams for RTP retransmission or
FEC? FEC?
o etc.
For some point to multi-point topologies (e.g. Topo-ASM and Topo-SSM For some point to multi-point topologies (e.g. Topo-ASM and Topo-SSM
in [RFC7667]), multicast is used to interconnect the session in [RFC7667]), multicast is used to interconnect the session
participants. Special considerations (documented in Section 4.2.3) participants. Special considerations (documented in Section 4.2.3)
are then needed as multicast is a one-to-many distribution system. are then needed as multicast is a one-to-many distribution system.
Sometimes an RTP communication can end up in a situation when the Sometimes an RTP communication can end up in a situation when the
communicating peers are not compatible for various reasons: communicating peers are not compatible for various reasons:
o No common media codec for a media type thus requiring transcoding. o No common media codec for a media type thus requiring transcoding.
o Different support for multiple RTP sources and RTP sessions. o Different support for multiple RTP streams and RTP sessions.
o Usage of different media transport protocols, i.e RTP or other. o Usage of different media transport protocols, i.e., RTP or other.
o Usage of different transport protocols, e.g. UDP, DCCP, TCP. o Usage of different transport protocols, e.g., UDP, DCCP, or TCP.
o Different security solutions, e.g. IPsec, TLS, DTLS, SRTP with o Different security solutions, e.g., IPsec, TLS, DTLS, or SRTP with
different keying mechanisms. different keying mechanisms.
In many situations this is resolved by the inclusion of a translator In many situations this is resolved by the inclusion of a translator
between the two peers, as described by Topo-PtP-Translator in between the two peers, as described by Topo-PtP-Translator in
[RFC7667]. The translator's main purpose is to make the peers look [RFC7667]. The translator's main purpose is to make the peers look
compatible to each other. There can also be other reasons than compatible to each other. There can also be other reasons than
compatibility to insert a translator in the form of a middlebox or compatibility to insert a translator in the form of a middlebox or
gateway, for example a need to monitor the RTP streams. If the gateway, for example a need to monitor the RTP streams. If the
stream transport characteristics are changed by the translator, stream transport characteristics are changed by the translator,
appropriate media handling can require thorough understanding of the appropriate media handling can require thorough understanding of the
application logic, specifically any congestion control or media application logic, specifically any congestion control or media
adaptation. adaptation.
The point to point topology can contain one to many RTP sessions with The point to point topology can contain one to many RTP sessions with
one to many media sources per session, each having one or more RTP one to many media sources per session, each having one or more RTP
sources per media source. streams per media source.
3.4. Issues Related to RTP and RTCP Protocol 3.4. Issues Related to RTP and RTCP Protocol
Using multiple RTP streams is a well-supported feature of RTP. Using multiple RTP streams is a well-supported feature of RTP.
However, for most implementers or people writing RTP/RTCP However, for most implementers or people writing RTP/RTCP
applications or extensions attempting to apply multiple streams, it applications or extensions attempting to apply multiple streams, it
can be unclear when it is most appropriate to add an additional RTP can be unclear when it is most appropriate to add an additional RTP
stream in an existing RTP session and when it is better to use stream in an existing RTP session and when it is better to use
multiple RTP sessions. This section discusses the various multiple RTP sessions. This section discusses the various
considerations needed. considerations needed.
skipping to change at page 14, line 19 skipping to change at page 13, line 36
On the other hand, multiplexing multiple related sources of the same On the other hand, multiplexing multiple related sources of the same
medium in one RTP session using different SSRC values is the norm for medium in one RTP session using different SSRC values is the norm for
multicast sessions. The problems listed above don't apply: an RTP multicast sessions. The problems listed above don't apply: an RTP
mixer can combine multiple audio sources, for example, and the same mixer can combine multiple audio sources, for example, and the same
treatment is applicable for all of them. It might also be treatment is applicable for all of them. It might also be
appropriate to multiplex streams of the same medium using different appropriate to multiplex streams of the same medium using different
SSRC values in other scenarios where the last two problems do not SSRC values in other scenarios where the last two problems do not
apply." apply."
Let's consider one argument at a time. The first argument is for Let's consider one argument at a time. The first argument is for
using different SSRC for each individual RTP stream, which is very using different SSRC for each individual RTP stream, which is
basic. fundamental to RTP operation.
The second argument is advocating against demultiplexing RTP streams The second argument is advocating against demultiplexing RTP streams
within a session based on their RTP payload type numbers, which still within a session based on their RTP payload type numbers, which still
stands as can been seen by the extensive list of issues found in stands as can been seen by the extensive list of issues found in
Appendix A. Appendix A.
The third argument is yet another argument against payload type The third argument is yet another argument against payload type
multiplexing. multiplexing.
The fourth argument is against multiplexing RTP packets that require The fourth argument is against multiplexing RTP packets that require
skipping to change at page 15, line 18 skipping to change at page 14, line 36
designer. designer.
3.4.2. Multiple SSRCs in a Session 3.4.2. Multiple SSRCs in a Session
Using multiple SSRCs at one endpoint in an RTP session requires Using multiple SSRCs at one endpoint in an RTP session requires
resolving some unclear aspects of the RTP specification. These could resolving some unclear aspects of the RTP specification. These could
potentially lead to some interoperability issues as well as some potentially lead to some interoperability issues as well as some
potential significant inefficiencies, as further discussed in "RTP potential significant inefficiencies, as further discussed in "RTP
Considerations for Endpoints Sending Multiple Media Streams" Considerations for Endpoints Sending Multiple Media Streams"
[RFC8108]. An RTP application designer should consider these issues [RFC8108]. An RTP application designer should consider these issues
and the possible applicaiton impact from lack of appropriate RTP and the possible application impact from lack of appropriate RTP
handling or optimization in the peer endpoints. handling or optimization in the peer endpoints.
Using multiple RTP sessions can potentially mitigate application Using multiple RTP sessions can potentially mitigate application
issues caused by multiple SSRCs in an RTP session. issues caused by multiple SSRCs in an RTP session.
3.4.3. Binding Related Sources 3.4.3. Binding Related Sources
A common problem in a number of various RTP extensions has been how A common problem in a number of various RTP extensions has been how
to bind related RTP sources and their RTP streams together. This to bind related RTP streams together. This issue is common to both
issue is common to both using additional SSRCs and multiple RTP using additional SSRCs and multiple RTP sessions.
sessions.
The solutions can be divided into a few groups: The solutions can be divided into a few groups:
o RTP/RTCP based o RTP/RTCP based
o Signalling based (SDP) o Signalling based (SDP)
o grouping related RTP sessions o grouping related RTP sessions
o grouping SSRCs within an RTP session o grouping SSRCs within an RTP session
Most solutions are explicit, but some implicit methods have also been Most solutions are explicit, but some implicit methods have also been
applied to the problem. applied to the problem.
The SDP-based signalling solutions are: The SDP-based signalling solutions are:
skipping to change at page 16, line 9 skipping to change at page 15, line 25
SDP Media Description Grouping: The SDP Grouping Framework [RFC5888] SDP Media Description Grouping: The SDP Grouping Framework [RFC5888]
uses various semantics to group any number of media descriptions. uses various semantics to group any number of media descriptions.
These has previously been considered primarily as grouping RTP These has previously been considered primarily as grouping RTP
sessions, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple sessions, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple
media descriptions as a single RTP session. media descriptions as a single RTP session.
SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576] SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576]
includes a solution for grouping SSRCs the same way as the includes a solution for grouping SSRCs the same way as the
Grouping framework groups Media Descriptions. Grouping framework groups Media Descriptions.
SDP MSID grouping: Media Stream Identifiers [I-D.ietf-mmusic-msid]
specifies a Session Description Protocol (SDP) Grouping mechanism
for RTP streams that can be used to specify relations between RTP
streams. This mechanism is used to signal the association between
the SDP concept of "media description" and the WebRTC concept of
"MediaStream" / "MediaStreamTrack" (Corresponds to the [RFC7656]
term "Source Stream") using SDP signalling.
This supports a lot of use cases. All these solutions have This supports a lot of use cases. All these solutions have
shortcomings in cases where the session's dynamic properties are such shortcomings in cases where the session's dynamic properties are such
that it is difficult or resource consuming to keep the list of that it is difficult or resource consuming to keep the list of
related SSRCs up to date. related SSRCs up to date.
An RTP/RTCP-based solution is to use the RTCP SDES CNAME to bind the An RTP/RTCP-based solution is to use the RTCP SDES CNAME to bind the
RTP streams to an endpoint or synchronization context. For RTP streams to an endpoint or synchronization context. For
applications with a single RTP stream per type (Media, Source or applications with a single RTP stream per type (Media, Source or
Redundancy) this is sufficient independent if one or more RTP Redundancy) this is sufficient independent if one or more RTP
sessions are used. However, some applications choose not to use it sessions are used. However, some applications choose not to use it
skipping to change at page 16, line 43 skipping to change at page 16, line 4
force one to change SSRC in all RTP sessions and thus resynchronize force one to change SSRC in all RTP sessions and thus resynchronize
all of them instead of only the single media stream having the all of them instead of only the single media stream having the
collision. Therefore, it is not recommended to use identical SSRC collision. Therefore, it is not recommended to use identical SSRC
values to relate RTP streams. values to relate RTP streams.
Another solution to bind SSRCs is an implicit method used by RTP Another solution to bind SSRCs is an implicit method used by RTP
Retransmission [RFC4588] when doing retransmissions in the same RTP Retransmission [RFC4588] when doing retransmissions in the same RTP
session as the source RTP stream. The receiver missing a packet session as the source RTP stream. The receiver missing a packet
issues an RTP retransmission request, and then awaits a new SSRC issues an RTP retransmission request, and then awaits a new SSRC
carrying the RTP retransmission payload and where that SSRC is from carrying the RTP retransmission payload and where that SSRC is from
the same CNAME. This limits a requestor to having only one the same CNAME. This limits a requester to having only one
outstanding request on any new source SSRCs per endpoint. outstanding request on any new source SSRCs per endpoint.
RTP Payload Format Restrictions [I-D.ietf-mmusic-rid] provides an RTP Payload Format Restrictions [I-D.ietf-mmusic-rid] provides an
RTP/RTCP based mechanism to unambiguously identify the RTP streams RTP/RTCP based mechanism to unambiguously identify the RTP streams
within an RTP session and restrict the streams' payload format within an RTP session and restrict the streams' payload format
parameters in a codec-agnostic way beyond what is provided with the parameters in a codec-agnostic way beyond what is provided with the
regular Payload Types. The mapping is done by specifying an "a=rid" regular Payload Types. The mapping is done by specifying an "a=rid"
value in the SDP offer/answer signalling and having the corresponding value in the SDP offer/answer signalling and having the corresponding
"rtp-stream-id" value as an SDES item and an RTP header extension. "rtp-stream-id" value as an SDES item and an RTP header extension.
The RID solution also includes a solution for binding redundancy RTP The RID solution also includes a solution for binding redundancy RTP
streams to their original source RTP streams, given that those use streams to their original source RTP streams, given that those use
RID identifiers. RID identifiers.
It can be noted that Section 8.3 of the RTP Specification [RFC3550] It can be noted that Section 8.3 of the RTP Specification [RFC3550]
recommends using a single SSRC space across all RTP sessions for recommends using a single SSRC space across all RTP sessions for
layered coding. Based on the experience so far however, we recommend layered coding. Based on the experience so far however, we recommend
to use a solution doing explicit binding between the RTP streams so to use a solution doing explicit binding between the RTP streams so
what the used SSRC values are do not matter. That way solutions what the used SSRC values are do not matter. That way solutions
using multiple RTP streams in a single RTP session and multiple RTP using multiple RTP streams in a single RTP session and multiple RTP
skipping to change at page 18, line 19 skipping to change at page 17, line 29
It is not uncommon that applications or services of similar but not It is not uncommon that applications or services of similar but not
identical usage, especially the ones intended for interactive identical usage, especially the ones intended for interactive
communication, encounter a situation where one want to interconnect communication, encounter a situation where one want to interconnect
two or more of these applications. two or more of these applications.
In these cases, one ends up in a situation where one might use a In these cases, one ends up in a situation where one might use a
gateway to interconnect applications. This gateway must then either gateway to interconnect applications. This gateway must then either
change the multiplexing structure or adhere to the respective change the multiplexing structure or adhere to the respective
limitations in each application. limitations in each application.
There are two fundamental approaches to gatewaying: RTP Translator There are two fundamental approaches to building a gateway: using an
interworking (RTP bridging), where the gateway acts as an RTP RTP Translator interworking (RTP bridging), where the gateway acts as
Translator, with the two applications being members of the same RTP an RTP Translator, with the two applications being members of the
session, and Gateway Interworking (with RTP termination), where there same RTP session; or Gateway Interworking with RTP termination, where
are independent RTP sessions running from each interconnected there are independent RTP sessions running from each interconnected
application to the gateway. application to the gateway.
4.1.2. RTP Translator Interworking 4.1.2. RTP Translator Interworking
From an RTP perspective the RTP Translator approach could work if all From an RTP perspective the RTP Translator approach could work if all
the applications are using the same codecs with the same payload the applications are using the same codecs with the same payload
types, have made the same multiplexing choices, and have the same types, have made the same multiplexing choices, and have the same
capabilities in number of simultaneous RTP streams combined with the capabilities in number of simultaneous RTP streams combined with the
same set of RTP/RTCP extensions being supported. Unfortunately, this same set of RTP/RTCP extensions being supported. Unfortunately, this
might not always be true. might not always be true.
When one is gatewaying via an RTP Translator, an important When a gateway is implemented via an RTP Translator, an important
consideration is if the two applications being interconnected need to consideration is if the two applications being interconnected need to
use the same approach to multiplexing. If one side is using RTP use the same approach to multiplexing. If one side is using RTP
session multiplexing and the other is using SSRC multiplexing with session multiplexing and the other is using SSRC multiplexing with
bundle, the mapping of SDP "m=" lines between both sides requires bundle, the mapping of SDP "m=" lines between both sides requires
that the order in bundled and not bundled sides will be the same to that the order in bundled and not bundled sides will be the same to
allow routing without mapping, it is possible for the RTP translator allow routing without mapping, it is possible for the RTP translator
to map the RTP streams between both sides. There are also challenges to map the RTP streams between both sides. There are also challenges
with SSRC collision handling since there may be a collision on the with SSRC collision handling since there may be a collision on the
SSRC multiplexing side but the RTP session multiplexing side will not SSRC multiplexing side but the RTP session multiplexing side will not
be aware of any collision unless SSRC translation is applied on the be aware of any collision unless SSRC translation is applied on the
skipping to change at page 19, line 22 skipping to change at page 18, line 32
o Generating appropriate RTCP reports for all RTP streams (possibly o Generating appropriate RTCP reports for all RTP streams (possibly
based on incoming RTCP reports), originating from SSRCs controlled based on incoming RTCP reports), originating from SSRCs controlled
by the gateway. by the gateway.
o Handling SSRC collision resolution in each application's RTP o Handling SSRC collision resolution in each application's RTP
sessions. sessions.
o Signalling, choosing and policing appropriate bit-rates for each o Signalling, choosing and policing appropriate bit-rates for each
session. session.
For applications that uses any security mechanism, e.g. in the form For applications that uses any security mechanism, e.g., in the form
of SRTP, the gateway needs to be able to decrypt incoming packets and of SRTP, the gateway needs to be able to decrypt incoming packets and
re-encrypt them in the other application's security context. This is re-encrypt them in the other application's security context. This is
necessary even if all that's needed is a simple remapping of SSRC necessary even if all that's needed is a simple remapping of SSRC
numbers. If this is done, the gateway also needs to be a member of numbers. If this is done, the gateway also needs to be a member of
the security contexts of both sides, of course. the security contexts of both sides, of course.
Other tasks a gateway might need to apply include transcoding (for Other tasks a gateway might need to apply include transcoding (for
incompatible codec types), media-level adaptations that cannot be incompatible codec types), media-level adaptations that cannot be
solved through media negotiation (such as rescaling for incompatible solved through media negotiation (such as rescaling for incompatible
video size requirements), suppression of content that is known not to video size requirements), suppression of content that is known not to
skipping to change at page 20, line 12 skipping to change at page 19, line 24
in form of the decrypt-encrypt cycles needed for each forwarded in form of the decrypt-encrypt cycles needed for each forwarded
packet. SRTP, due to its keying structure, also requires that each packet. SRTP, due to its keying structure, also requires that each
RTP session needs different master keys, as use of the same key in RTP session needs different master keys, as use of the same key in
two RTP sessions can for some ciphers result in two-time pads that two RTP sessions can for some ciphers result in two-time pads that
completely breaks the confidentiality of the packets. completely breaks the confidentiality of the packets.
4.1.4. Multiple SSRC Legacy Considerations 4.1.4. Multiple SSRC Legacy Considerations
Historically, the most common RTP use cases have been point to point Historically, the most common RTP use cases have been point to point
Voice over IP (VoIP) or streaming applications, commonly with no more Voice over IP (VoIP) or streaming applications, commonly with no more
than one media source per endpoint and media type (typically audio than one media source per endpoint and media type (typically audio or
and video). Even in conferencing applications, especially voice- video). Even in conferencing applications, especially voice-only,
only, the conference focus or bridge has provided a single stream the conference focus or bridge has provided a single stream with a
with a mix of the other participants to each participant. It is also mix of the other participants to each participant. It is also common
common to have individual RTP sessions between each endpoint and the to have individual RTP sessions between each endpoint and the RTP
RTP mixer, meaning that the mixer functions as an RTP-terminating mixer, meaning that the mixer functions as an RTP-terminating
gateway. gateway.
When establishing RTP sessions that can contain endpoints that aren't When establishing RTP sessions that can contain endpoints that aren't
updated to handle multiple streams following these recommendations, a updated to handle multiple streams following these recommendations, a
particular application can have issues with multiple SSRCs within a particular application can have issues with multiple SSRCs within a
single session. These issues include: single session. These issues include:
1. Need to handle more than one stream simultaneously rather than 1. Need to handle more than one stream simultaneously rather than
replacing an already existing stream with a new one. replacing an already existing stream with a new one.
skipping to change at page 24, line 9 skipping to change at page 23, line 20
depend on how the actual application is realized what is the most depend on how the actual application is realized what is the most
appropriate choice. With sender side congestion control there might appropriate choice. With sender side congestion control there might
not exist any benefit with using multiple RTP session. not exist any benefit with using multiple RTP session.
The properties of a broadcast application using RTP multicast: The properties of a broadcast application using RTP multicast:
1. Uses a group of RTP sessions, not one. Each endpoint will need 1. Uses a group of RTP sessions, not one. Each endpoint will need
to be a member of a number of RTP sessions in order to perform to be a member of a number of RTP sessions in order to perform
well. well.
2. Within each RTP session, the number of RTP sinks is likely to be 2. Within each RTP session, the number of RTP receivers is likely to
much larger than the number of RTP sources. be much larger than the number of RTP senders.
3. The applications need signalling functions to identify the 3. The applications need signalling functions to identify the
relationships between RTP sessions. relationships between RTP sessions.
4. The applications need signalling or RTP/RTCP functions to 4. The applications need signalling or RTP/RTCP functions to
identify the relationships between SSRCs in different RTP identify the relationships between SSRCs in different RTP
sessions when needs beyond CNAME exists. sessions when needs beyond CNAME exists.
Both broadcast and many to many multicast applications do share a Both broadcast and many to many multicast applications do share a
signalling requirement; all of the participants will need to have the signalling requirement; all of the participants will need to have the
skipping to change at page 26, line 19 skipping to change at page 25, line 32
the SSRC value implies a decryption using the old SSRC and its the SSRC value implies a decryption using the old SSRC and its
security context, followed by an encryption using the new one. security context, followed by an encryption using the new one.
5. RTP Multiplexing Design Choices 5. RTP Multiplexing Design Choices
This section discusses how some RTP multiplexing design choices can This section discusses how some RTP multiplexing design choices can
be used in applications to achieve certain goals, and a summary of be used in applications to achieve certain goals, and a summary of
the implications of such choices. For each design there is the implications of such choices. For each design there is
discussion of benefits and downsides. discussion of benefits and downsides.
5.1. Single SSRC per Endpoint 5.1. Multiple Media Types in one Session
In this design each endpoint in a point-to-point session has only a This design uses a single RTP session for multiple different media
single SSRC, thus the RTP session contains only two SSRCs, one local types, like audio and video, and possibly also transport robustness
and one remote. This session can be used both unidirectional, i.e. mechanisms like FEC or Retransmission. An endpoint can have zero,
only a single RTP stream or bi-directional, i.e. both endpoints have one or more media sources per media type. Resulting in a number of
one RTP stream each. If the application needs additional media flows RTP streams of various media types and both source and redundancy
between the endpoints, they will have to establish additional RTP type.
sessions.
The Pros: The Pros:
1. This design has great legacy interoperability potential as it 1. Single RTP session which implies:
will not tax any RTP stack implementations.
2. The signalling has good possibilities to negotiate and describe * Minimal NAT/FW state.
the exact formats and bit-rates for each RTP stream, especially
using today's tools in SDP.
3. It is possible to control security association per RTP stream * Minimal NAT/FW Traversal Cost.
with current key-management, since each RTP stream is directly
related to an RTP session, and the most used keying mechanisms
operates on a per-session basis.
The Cons: * Fate-sharing for all media flows.
a. The number of RTP sessions grows directly in proportion with the 2. Can handle dynamic allocations of RTP streams well on an RTP
number of RTP streams, which has the implications: level. Depends on the application's needs for explicit
indication of the stream usage and how timely that can be
signalled.
* Linear growth of the amount of NAT/FW state with number of RTP 3. Minimal overhead for security association establishment.
streams.
* Increased delay and resource consumption from NAT/FW The Cons:
traversal.
* Likely larger signalling message and signalling processing a. Less suitable for interworking with other applications that uses
requirement due to the amount of session related information. individual RTP sessions per media type or multiple sessions for a
single media type, due to the potential need of SSRC translation.
* Higher potential for a single RTP stream to fail during b. Negotiation of bandwidth for the different media types is
transport between the endpoints. currently only possible using RID [I-D.ietf-mmusic-rid] in SDP.
b. When the number of RTP sessions grows, the amount of explicit c. Not suitable for Split Component Terminal (see Section 3.10 of
state for relating RTP stream also grows, linearly, depending on [RFC7667]).
how the application needs to relate RTP streams.
c. The port consumption might become a problem for centralised d. Flow-based QoS cannot provide separate treatment of RTP streams
services, where the central node's port consumption grows rapidly compared to others in the single RTP session.
with the number of sessions.
d. For applications where the RTP stream usage is highly dynamic, e. If there is significant asymmetry between the RTP streams' RTCP
i.e. entering and leaving, the amount of signalling can grow reporting needs, there are some challenges in configuration and
high. Issues can also arise from the timely establishment of usage to avoid wasting RTCP reporting on the RTP stream that does
additional RTP sessions. not need that frequent reporting.
e. If, against the recommendation, the same SSRC value is reused in f. Not suitable for applications where some receivers like to
multiple RTP sessions rather than being randomly chosen, receive only a subset of the RTP streams, especially if multicast
interworking with applications that use a different multiplexing or transport translator is being used.
structure will require SSRC translation.
RTP applications that need to interwork with legacy RTP applications g. Additional concern with legacy implementations that do not
can potentially benefit from this structure. However, a large number support the RTP specification fully when it comes to handling
of media descriptions in SDP can also run into issues with existing multiple SSRC per endpoint, as also multiple simultaneous media
implementations. For any application needing a larger number of types needs to be handled.
media flows, the overhead can become very significant. This
structure is also not suitable for multi-party sessions, as any given h. If the applications need finer control over which session
RTP stream from each participant, although having same usage in the participants that are included in different sets of security
application, needs its own RTP session. In addition, the dynamic associations, most key-management will have difficulties
behaviour that can arise in multi-party applications can tax the establishing such a session.
signalling system and make timely media establishment more difficult.
5.2. Multiple SSRCs of the Same Media Type 5.2. Multiple SSRCs of the Same Media Type
In this design, each RTP session serves only a single media type. In this design, each RTP session serves only a single media type.
The RTP session can contain multiple RTP streams, either from a The RTP session can contain multiple RTP streams, either from a
single endpoint or from multiple endpoints. This commonly creates a single endpoint or from multiple endpoints. This commonly creates a
low number of RTP sessions, typically only one for audio and one for low number of RTP sessions, typically only one for audio and one for
video, with a corresponding need for two listening ports when using video, with a corresponding need for two listening ports when using
RTP/RTCP multiplexing. RTP/RTCP multiplexing.
The Pros: The Pros:
1. Low number of RTP sessions needed compared to Single SSRC per 1. Works well with Split Component Terminal (see Section 3.10 of
Endpoint case. This implies:
* Reduced NAT/FW state
* Lower NAT/FW Traversal Cost in both processing and delay.
2. Works well with Split Component Terminal (see Section 3.10 of
[RFC7667]) where the split is per media type. [RFC7667]) where the split is per media type.
3. Enables Flow-based QoS with different prioritisation between 2. Enables Flow-based QoS with different prioritisation between
media types. media types.
4. For applications with dynamic usage of RTP streams, i.e. 3. For applications with dynamic usage of RTP streams, i.e.
frequently added and removed, having much of the state associated frequently added and removed, having much of the state associated
with the RTP session rather than per individual SSRC can avoid with the RTP session rather than per individual SSRC can avoid
the need for in-session signalling of meta-information about each the need for in-session signalling of meta-information about each
SSRC. SSRC.
5. Low overhead for security association establishment. 4. Low overhead for security association establishment.
The Cons: The Cons:
a. Some potential for concern with legacy implementations that don't a. Slightly higher number of RTP sessions needed compared to
Multiple Media Types in one Session Section 5.1. This implies:
* More NAT/FW state
* Increased NAT/FW Traversal Cost in both processing and delay.
b. Some potential for concern with legacy implementations that don't
support the RTP specification fully when it comes to handling support the RTP specification fully when it comes to handling
multiple SSRC per endpoint. multiple SSRC per endpoint.
b. Not possible to control security association for sets of RTP c. Not possible to control security association for sets of RTP
streams within the same media type with today's key- management streams within the same media type with today's key- management
mechanisms, unless these are split into different RTP sessions. mechanisms, unless these are split into different RTP sessions.
For RTP applications where all RTP streams of the same media type For RTP applications where all RTP streams of the same media type
share same usage, this structure provides efficiency gains in amount share same usage, this structure provides efficiency gains in amount
of network state used and provides more fate sharing with other media of network state used and provides more fate sharing with other media
flows of the same type. At the same time, it is still maintaining flows of the same type. At the same time, it is still maintaining
almost all functionalities when it comes to negotiation in the almost all functionalities when it comes to negotiation in the
signalling of the properties for the individual media type, and also signalling of the properties for the individual media type, and also
enables flow based QoS prioritisation between media types. It enables flow based QoS prioritisation between media types. It
skipping to change at page 30, line 6 skipping to change at page 29, line 14
e. Higher overhead for security association establishment due to the e. Higher overhead for security association establishment due to the
increased number of RTP sessions. increased number of RTP sessions.
f. If the applications need finer control than on RTP session level f. If the applications need finer control than on RTP session level
over which participants that are included in different sets of over which participants that are included in different sets of
security associations, most of today's key-management will have security associations, most of today's key-management will have
difficulties establishing such a session. difficulties establishing such a session.
For more complex RTP applications that have several different usages For more complex RTP applications that have several different usages
for RTP streams of the same media type and / or uses scalability or for RTP streams of the same media type, or uses scalability or
simulcast, this solution can enable those functions at the cost of simulcast, this solution can enable those functions at the cost of
increased overhead associated with the additional sessions. This increased overhead associated with the additional sessions. This
type of structure is suitable for more advanced applications as well type of structure is suitable for more advanced applications as well
as multicast-based applications requiring differentiation to as multicast-based applications requiring differentiation to
different participants. different participants.
5.4. Multiple Media Types in one Session 5.4. Single SSRC per Endpoint
This design uses a single RTP session for multiple different media In this design each endpoint in a point-to-point session has only a
types, like audio and video, and possibly also transport robustness single SSRC, thus the RTP session contains only two SSRCs, one local
mechanisms like FEC or Retransmission. An endpoint can have zero, and one remote. This session can be used both unidirectional, i.e.
one or more media sources per media type. Resulting in a number of only a single RTP stream or bi-directional, i.e. both endpoints have
RTP streams of various media types and both source and redundancy one RTP stream each. If the application needs additional media flows
type. between the endpoints, they will have to establish additional RTP
sessions.
The Pros: The Pros:
1. Single RTP session which implies: 1. This design has great legacy interoperability potential as it
will not tax any RTP stack implementations.
* Minimal NAT/FW state.
* Minimal NAT/FW Traversal Cost. 2. The signalling has good possibilities to negotiate and describe
the exact formats and bit-rates for each RTP stream, especially
using today's tools in SDP.
* Fate-sharing for all media flows. 3. It is possible to control security association per RTP stream
with current key-management, since each RTP stream is directly
related to an RTP session, and the most used keying mechanisms
operates on a per-session basis.
2. Can handle dynamic allocations of RTP streams well on an RTP The Cons:
level. Depends on the application's needs for explicit
indication of the stream usage and how timely that can be
signalled.
3. Minimal overhead for security association establishment. a. The number of RTP sessions grows directly in proportion with the
number of RTP streams, which has the implications:
The Cons: * Linear growth of the amount of NAT/FW state with number of RTP
streams.
a. Less suitable for interworking with other applications that uses * Increased delay and resource consumption from NAT/FW
individual RTP sessions per media type or multiple sessions for a traversal.
single media type, due to the potential need of SSRC translation.
b. Negotiation of bandwidth for the different media types is * Likely larger signalling message and signalling processing
currently only possible using RID [I-D.ietf-mmusic-rid] in SDP. requirement due to the amount of session related information.
c. Not suitable for Split Component Terminal (see Section 3.10 of * Higher potential for a single RTP stream to fail during
[RFC7667]). transport between the endpoints.
d. Flow-based QoS cannot provide separate treatment of RTP streams b. When the number of RTP sessions grows, the amount of explicit
compared to others in the single RTP session. state for relating RTP stream also grows, depending on how the
application needs to relate RTP streams.
e. If there is significant asymmetry between the RTP streams' RTCP c. The port consumption might become a problem for centralised
reporting needs, there are some challenges in configuration and services, where the central node's port or 5-tuple filter
usage to avoid wasting RTCP reporting on the RTP stream that does consumption grows rapidly with the number of sessions.
not need that frequent reporting.
f. Not suitable for applications where some receivers like to d. For applications where the RTP stream usage is highly dynamic,
receive only a subset of the RTP streams, especially if multicast i.e. entering and leaving, the amount of signalling can grow
or transport translator is being used. high. Issues can also arise from the timely establishment of
additional RTP sessions.
g. Additional concern with legacy implementations that do not e. If, against the recommendation, the same SSRC value is reused in
support the RTP specification fully when it comes to handling multiple RTP sessions rather than being randomly chosen,
multiple SSRC per endpoint, as also multiple simultaneous media interworking with applications that use a different multiplexing
types needs to be handled. structure will require SSRC translation.
h. If the applications need finer control over which session RTP applications that need to interwork with legacy RTP applications
participants that are included in different sets of security can potentially benefit from this structure. However, a large number
associations, most key-management will have difficulties of media descriptions in SDP can also run into issues with existing
establishing such a session. implementations. For any application needing a larger number of
media flows, the overhead can become very significant. This
structure is also not suitable for multi-party sessions, as any given
RTP stream from each participant, although having same usage in the
application, needs its own RTP session. In addition, the dynamic
behaviour that can arise in multi-party applications can tax the
signalling system and make timely media establishment more difficult.
5.5. Summary 5.5. Summary
There are some clear similarities between these designs. Both the There are some clear similarities between these designs. Both the
"Single SSRC per Endpoint" and the "Multiple Media Types in one "Single SSRC per Endpoint" and the "Multiple Media Types in one
Session" are cases that require full explicit signalling of the media Session" are cases that require full explicit signalling of the media
stream relations. However, they operate on two different levels stream relations. However, they operate on two different levels
where the first primarily enables session level binding, and the where the first primarily enables session level binding, and the
second needs SSRC level binding. From another perspective, the two second needs SSRC level binding. From another perspective, the two
solutions are the two extreme points when it comes to number of RTP solutions are the two extreme points when it comes to number of RTP
skipping to change at page 32, line 5 skipping to change at page 31, line 22
amount of RTP sessions established, i.e. representing an attempt to amount of RTP sessions established, i.e. representing an attempt to
balance the amount of RTP sessions with the functionality the balance the amount of RTP sessions with the functionality the
communication session provides both on network level and on communication session provides both on network level and on
signalling level. signalling level.
6. Guidelines 6. Guidelines
This section contains a number of multi-stream guidelines for This section contains a number of multi-stream guidelines for
implementers or specification writers. implementers or specification writers.
Do not use the same SSRC across RTP sessions: As discussed in Do not require us of the same SSRC value across RTP sessions: As dis
Section 3.4.3 there exist drawbacks in using the same SSRC in cussed in Section 3.4.3 there exist drawbacks in using the same
multiple RTP sessions as a mechanism to bind related RTP streams SSRC in multiple RTP sessions as a mechanism to bind related RTP
together. It is instead recommended to use a mechanism to streams together. It is instead recommended to use a mechanism to
explicitly signal the relation, either in RTP/RTCP or in the explicitly signal the relation, either in RTP/RTCP or in the
signalling mechanism used to establish the RTP session(s). signalling mechanism used to establish the RTP session(s).
Use additional RTP streams for additional media sources: In the Use additional RTP streams for additional media sources: In the
cases where an RTP endpoint needs to transmit additional RTP cases where an RTP endpoint needs to transmit additional RTP
streams of the same media type in the application, with the same streams of the same media type in the application, with the same
processing requirements at the network and RTP layers, it is processing requirements at the network and RTP layers, it is
suggested to send them in the same RTP session. For example a suggested to send them in the same RTP session. For example a
telepresence room where there are three cameras, and each camera telepresence room where there are three cameras, and each camera
captures 2 persons sitting at the table, sending each camera as captures 2 persons sitting at the table, sending each camera as
its own RTP stream within a single RTP session is suggested. its own RTP stream within a single RTP session is suggested.
Use additional RTP sessions for streams with different requirements: Use additional RTP sessions for streams with different requirements:
When RTP streams have different processing requirements from the When RTP streams have different processing requirements from the
network or the RTP layer at the endpoints, it is suggested that network or the RTP layer at the endpoints, it is suggested that
the different types of streams are put in different RTP sessions. the different types of streams are put in different RTP sessions.
This includes the case where different participants want different This includes the case where different participants want different
subsets of the set of RTP streams. subsets of the set of RTP streams.
When using multiple RTP Sessions use grouping: When using Multiple When using multiple RTP Sessions, use grouping: When using Multiple
RTP session solutions, it is suggested to explicitly group the RTP session solutions, it is suggested to explicitly group the
involved RTP sessions when needed using a signalling mechanism, involved RTP sessions when needed using a signalling mechanism,
for example The Session Description Protocol (SDP) Grouping for example The Session Description Protocol (SDP) Grouping
Framework [RFC5888], using some appropriate grouping semantics. Framework [RFC5888], using some appropriate grouping semantics.
RTP/RTCP Extensions Support Multiple RTP Streams as well as Multiple RTP/RTCP Extensions Support Multiple RTP Streams as well as Multiple
RTP sessions: RTP sessions:
When defining an RTP or RTCP extension, the creator needs to When defining an RTP or RTCP extension, the creator needs to
consider if this extension is applicable to use with additional consider if this extension is applicable to use with additional
SSRCs and multiple RTP sessions. Any extension intended to be SSRCs and multiple RTP sessions. Any extension intended to be
skipping to change at page 33, line 5 skipping to change at page 32, line 22
served by defining a single solution or providing both options. served by defining a single solution or providing both options.
Transport Support Extensions: When defining new RTP/RTCP extensions Transport Support Extensions: When defining new RTP/RTCP extensions
intended for transport support, like the retransmission or FEC intended for transport support, like the retransmission or FEC
mechanisms, they must include support for both multiple RTP mechanisms, they must include support for both multiple RTP
streams in the same RTP sessions and multiple RTP sessions, such streams in the same RTP sessions and multiple RTP sessions, such
that application developers can choose freely from the set of that application developers can choose freely from the set of
mechanisms without concerning themselves with which of the mechanisms without concerning themselves with which of the
multiplexing choices a particular solution supports. multiplexing choices a particular solution supports.
7. Open Issues 7. IANA Considerations
There are currently some issues that needs to be resolved before this
document is ready to be published:
1. Does the MSID text need to be updated and clarified based on the
evolution of MSID since previous version. Section 3.4.3.
2. Changed definitions needs review and consideration.
8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section can be removed on publication as an Note to RFC Editor: this section can be removed on publication as an
RFC. RFC.
9. Security Considerations 8. Security Considerations
The security considerations of the RTP specification [RFC3550] and The security considerations of the RTP specification [RFC3550] and
any applicable RTP profile [RFC3551],[RFC4585],[RFC3711], the any applicable RTP profile [RFC3551],[RFC4585],[RFC3711], the
extensions for sending multiple media types in a single RTP session extensions for sending multiple media types in a single RTP session
[I-D.ietf-avtcore-multi-media-rtp-session], MSID [I-D.ietf-avtcore-multi-media-rtp-session], RID
[I-D.ietf-mmusic-msid], RID [I-D.ietf-mmusic-rid], BUNDLE [I-D.ietf-mmusic-rid], BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation], [RFC5760], [RFC5761], apply [I-D.ietf-mmusic-sdp-bundle-negotiation], [RFC5760], [RFC5761], apply
if selected and thus needs to be considered in the evaluation. if selected and thus needs to be considered in the evaluation.
There is discussion of the security implications of choosing multiple There is discussion of the security implications of choosing multiple
SSRC vs multiple RTP sessions in Section 4.3. SSRC vs multiple RTP sessions in Section 4.3.
10. Contributors 9. Contributors
Hui Zheng (Marvin) from Huawei contributed to WG draft versions -04 Hui Zheng (Marvin) from Huawei contributed to WG draft versions -04
and -05 of the document. and -05 of the document.
11. References 10. References
10.1. Normative References
11.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
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>.
11.2. Informative References 10.2. Informative References
[ALF] Clark, D. and D. Tennenhouse, "Architectural [ALF] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of Protocols", SIGCOMM Considerations for a New Generation of Protocols", SIGCOMM
Symposium on Communications Architectures and Symposium on Communications Architectures and
Protocols (Philadelphia, Pennsylvania), pp. 200--208, IEEE Protocols (Philadelphia, Pennsylvania), pp. 200--208, IEEE
Computer Communications Review, Vol. 20(4), September Computer Communications Review, Vol. 20(4), September
1990. 1990.
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-13 (work in ietf-avtcore-multi-media-rtp-session-13 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-avtext-rid] [I-D.ietf-avtext-rid]
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
Identifier Source Description (SDES)", draft-ietf-avtext- Identifier Source Description (SDES)", draft-ietf-avtext-
rid-09 (work in progress), October 2016. rid-09 (work in progress), October 2016.
[I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-16
(work in progress), February 2017.
[I-D.ietf-mmusic-rid] [I-D.ietf-mmusic-rid]
Roach, A., "RTP Payload Format Restrictions", draft-ietf- Roach, A., "RTP Payload Format Restrictions", draft-ietf-
mmusic-rid-15 (work in progress), May 2018. mmusic-rid-15 (work in progress), May 2018.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-52 (work in progress), May 2018. negotiation-53 (work in progress), September 2018.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-13 (work in progress), June 2018. mmusic-sdp-simulcast-13 (work in progress), June 2018.
[I-D.ietf-perc-srtp-ekt-diet] [I-D.ietf-perc-srtp-ekt-diet]
Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. 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", draft-ietf-perc-srtp-ekt-diet-07 (work in progress), RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress),
March 2018. October 2018.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., 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>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
skipping to change at page 37, line 5 skipping to change at page 36, line 5
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <https://www.rfc-editor.org/info/rfc5109>. 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, Sessions with Unicast Feedback", RFC 5760,
DOI 10.17487/RFC5760, February 2010, DOI 10.17487/RFC5760, February 2010,
<https://www.rfc-editor.org/info/rfc5760>. <https://www.rfc-editor.org/info/rfc5760>.
skipping to change at page 38, line 23 skipping to change at page 37, line 19
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", [RFC8088] Westerlund, M., "How to Write an RTP Payload Format",
RFC 8088, DOI 10.17487/RFC8088, May 2017, RFC 8088, DOI 10.17487/RFC8088, May 2017,
<https://www.rfc-editor.org/info/rfc8088>. <https://www.rfc-editor.org/info/rfc8088>.
[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>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
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 things related to as a multiplexing point is unsuitable for most things related to
multiple RTP streams. If one attempts to use Payload type multiple RTP streams. If one attempts to use Payload type
multiplexing beyond its defined usage, that has well known negative multiplexing beyond its defined usage, that has well known negative
effects on RTP. To use payload type as the single discriminator for effects on RTP. To use payload type as the single discriminator for
multiple streams implies that all the different RTP streams are being multiple streams implies that all the different RTP streams are being
sent with the same SSRC, thus using the same timestamp and sequence sent with the same SSRC, thus using the same timestamp and sequence
number space. This has many effects: number space. This has many effects:
 End of changes. 94 change blocks. 
274 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/