draft-ietf-avtcore-multiplex-guidelines-09.txt   draft-ietf-avtcore-multiplex-guidelines-10.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 23, 2020 C. Perkins Expires: August 17, 2020 C. Perkins
University of Glasgow University of Glasgow
H. Alvestrand H. Alvestrand
Google Google
R. Even R. Even
Huawei Huawei
July 22, 2019 February 14, 2020
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-09 draft-ietf-avtcore-multiplex-guidelines-10
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 23, 2020. This Internet-Draft will expire on August 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 page 2, line 37 skipping to change at page 2, line 37
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) . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . 13
3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 14 3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 14
3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 14 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15
3.4.4. Forward Error Correction . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . 17 4.1.1. Application Interworking . . . . . . . . . . . . . . 17
4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 17 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18
4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18
4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 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 . . . . . . . . . . . . . 20 4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 21
4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Security and Key Management Considerations . . . . . . . 23 4.3. Security and Key Management Considerations . . . . . . . 24
4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24
4.3.2. Key Management for Multi-party Sessions . . . . . . . 24 4.3.2. Key Management for Multi-party Sessions . . . . . . . 25
4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25
5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 25 5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26
5.1. Multiple Media Types in One Session . . . . . . . . . . . 25 5.1. Multiple Media Types in One Session . . . . . . . . . . . 26
5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27 5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27
5.3. Multiple Sessions for One Media Type . . . . . . . . . . 28 5.3. Multiple Sessions for One Media Type . . . . . . . . . . 28
5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 29 5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 30
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 38 Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 38
Appendix B. Signalling Considerations . . . . . . . . . . . . . 40 Appendix B. Signalling Considerations . . . . . . . . . . . . . 40
B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40 B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40
B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 41 B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 41
B.3. Signalling RTP Stream Usage . . . . . . . . . . . . . . . 41 B.3. Signalling RTP Stream Usage . . . . . . . . . . . . . . . 41
skipping to change at page 5, line 40 skipping to change at page 5, line 40
3.1. Reasons for Multiplexing and Grouping RTP Streams 3.1. Reasons for Multiplexing and Grouping RTP Streams
There are several reasons why an endpoint might choose to send There are several reasons why an endpoint might choose to send
multiple media streams. In the below discussion, please keep in mind multiple media streams. In the below discussion, please keep in mind
that the reasons for having multiple RTP streams vary and include but that the reasons for having multiple RTP streams vary and include but
are not limited to the following: are not limited to the following:
o Multiple media sources o Multiple media sources
o Multiple RTP streams might be needed to represent one media source o Multiple RTP streams might be needed to represent one media source
(for instance when using layered encodings) (for instance when using simulcast or scalable video coding)
o A retransmission stream might repeat some parts of the content of o A retransmission stream might repeat some parts of the content of
another RTP stream another RTP stream
o A Forward Error Correction (FEC) stream might provide material o A Forward Error Correction (FEC) stream might provide material
that can be used to repair another RTP stream that can be used to repair another RTP stream
o Alternative encodings, for instance using different codecs for the o Alternative encodings during simulcast, for instance using
same audio stream different codecs for the same audio stream
o Alternative formats, for instance multiple resolutions of the same o Alternative formats during simulcast, for instance multiple
video stream resolutions of the same video stream
For each of these reasons, it is necessary to decide if each For each of these reasons, it is necessary to decide if each
additional RTP stream is sent within the same RTP session as the additional RTP stream is sent within the same RTP session as the
other RTP streams, or if it is necessary to use additional RTP other RTP streams, or if it is necessary to use additional RTP
sessions to group the RTP streams. The choice suitable for one sessions to group the RTP streams. The choice suitable for one
reason, might not be the choice suitable for another reason. The reason, might not be the choice suitable for another reason. The
clearest understanding is associated with multiplexing multiple media clearest understanding is associated with multiplexing multiple media
sources of the same media type. However, all reasons warrant sources of the same media type. However, all reasons warrant
discussion and clarification on how to deal with them. As the discussion and clarification on how to deal with them. As the
discussion below will show, in reality we cannot choose a single one discussion below will show, in reality we cannot choose a single one
skipping to change at page 6, line 32 skipping to change at page 6, line 32
3.2. RTP Multiplexing Points 3.2. RTP Multiplexing Points
This section describes the multiplexing points present in the RTP This section describes the multiplexing points present in the RTP
protocol that can be used to distinguish RTP streams and groups of protocol that can be used to distinguish RTP streams and groups of
RTP streams. Figure 1 outlines the process of demultiplexing RTP streams. Figure 1 outlines the process of demultiplexing
incoming RTP streams starting already at the socket representing incoming RTP streams starting already at the socket representing
reception of one or transport flows, e.g. an UDP destination port. reception of one or transport flows, e.g. an UDP destination port.
It also demultiplexes RTP/RTCP from any other protocols, such as STUN It also demultiplexes RTP/RTCP from any other protocols, such as STUN
[RFC5389] and DTLS-SRTP [RFC5764] on the same transport as described [RFC5389] and DTLS-SRTP [RFC5764] on the same transport as described
in [RFC7983]. in [RFC7983]. The Processing and Buffering (PB) step of Figure 1
terminates the RTP/RTCP protocol and prepares the RTP payload for
input to the decoder.
| |
| packets | packets
+-- v +-- v
| +------------+ | +------------+
| | Socket | Transport Protocol Demultiplexing | | Socket | Transport Protocol Demultiplexing
| +------------+ | +------------+
| || || | || ||
RTP | RTP/ || |+-----> DTLS (SRTP Keying, SCTP, etc) RTP | RTP/ || |+-----> DTLS (SRTP Keying, SCTP, etc)
Session | RTCP || +------> STUN (multiplexed using same port) Session | RTCP || +------> STUN (multiplexed using same port)
+-- || +-- ||
+-- || +-- ||
| (split by SSRC) | (split by MID/RID and/or SSRC)
| || || || | || || || ||
| || || || | || || || ||
RTP | +--+ +--+ +--+ RTP | +--+ +--+ +--+ +--+ Jitter buffer,
Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, etc. Streams | |PB| |PB| |PB| |PB| process RTCP, etc.
| +--+ +--+ +--+ | +--+ +--+ +--+ +--+
+-- | | | +-- | | | |
(select decoder based on PT) (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
3.2.1. RTP Session 3.2.1. RTP Session
skipping to change at page 9, line 15 skipping to change at page 9, line 15
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 streams or receivers resulting in the SSRC of the colliding RTP streams or receivers
changing. An endpoint that changes its network transport address changing. An endpoint that changes its network transport address
during a session has to choose a new SSRC identifier to avoid being during a session has to choose a new SSRC identifier to avoid being
interpreted as looped source, unless the transport layer mechanism, interpreted as looped source, unless a mechanism providing a virtual
e.g ICE [RFC8445], handles such changes. transport (such as ICE [RFC8445]) abstracts the 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
skipping to change at page 10, line 15 skipping to change at page 10, line 15
RTCP compound packets containing the CNAME SDES item is the RTCP compound packets containing the CNAME SDES item is the
designated method to bind an SSRC to a CNAME, effectively cross- designated method to bind an SSRC to a CNAME, effectively cross-
correlating SSRCs within and between RTP Sessions as coming from the correlating SSRCs within and between RTP Sessions as coming from the
same endpoint. The main property attributed to SSRCs associated with same endpoint. The main property attributed to SSRCs associated with
the same CNAME is that they are from a particular synchronisation the same CNAME is that they are from a particular synchronisation
context and can be synchronised at playback. context 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
existing source that had to change SSRC number due to an SSRC existing source that had to change SSRC number due to an SSRC
conflict. However, the originator of the previous SSRC ought to have conflict. Use of the MID extension
ended the conflicting source by sending an RTCP BYE for it prior to [I-D.ietf-mmusic-sdp-bundle-negotiation] helps to identify which
starting to send with the new SSRC, making the new SSRC a new source. media source the apparently new source belongs to and use of the RID
extension [I-D.ietf-mmusic-rid] helps to identify what encoding or
redundancy stream it represents, even though the SSRC changed.
However, the originator of the previous SSRC ought to have ended the
conflicting source by sending an RTCP BYE for it prior to starting to
send with the new SSRC, making the new SSRC a new source.
3.2.3. Contributing Source (CSRC) 3.2.3. Contributing Source (CSRC)
The Contributing Source (CSRC) is not a separate identifier. Rather The Contributing Source (CSRC) is not a separate identifier. Rather
an SSRC identifier is listed as a CSRC in the RTP header of a packet an SSRC identifier is listed as a CSRC in the RTP header of a packet
generated by an RTP mixer, if the corresponding SSRC was in the generated by an RTP mixer or video MCU/switch, if the corresponding
header of one of the packets that contributed to the mix. SSRC was in the header of one of the packets that contributed to the
output.
It is not possible, in general, to extract media represented by an It is not possible, in general, to extract media represented by an
individual CSRC since it is typically the result of a media mixing individual CSRC since it is typically the result of a media merge
(merge) operation by an RTP mixer on the individual media streams (e.g. mix) operation on the individual media streams corresponding to
corresponding to the CSRC identifiers. The exception is the case the CSRC identifiers. The exception is the case when only a single
when only a single CSRC is indicated as this represent forwarding of CSRC is indicated as this represent forwarding of an RTP stream,
an RTP stream, possibly modified. The RTP header extension for possibly modified. The RTP header extension for Mixer-to-Client
Mixer-to-Client Audio Level Indication [RFC6465] expands on the Audio Level Indication [RFC6465] expands on the receiver's
receiver's information about a packet with a CSRC list. Due to these information about a packet with a CSRC list. Due to these
restrictions, CSRC will not be considered a fully qualified restrictions, CSRC will not be considered a fully qualified
multiplexing point and will be disregarded in the rest of this multiplexing point and will be disregarded in the rest of this
document. document.
3.2.4. RTP Payload Type 3.2.4. RTP Payload Type
Each RTP stream utilises one or more RTP payload formats. An RTP Each RTP stream utilises one or more RTP payload formats. An RTP
payload format describes how the output of a particular media codec payload format describes how the output of a particular media codec
is framed and encoded into RTP packets. The payload format is is framed and encoded into RTP packets. The payload format is
identified by the payload type (PT) field in the RTP packet header. identified by the payload type (PT) field in the RTP packet header.
skipping to change at page 11, line 19 skipping to change at page 11, line 25
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
stream's timestamp time line, effectively time-multiplexing different stream's timestamp time line, effectively time-multiplexing different
payload types if any change occurs. The payload type can change on a payload types if any change occurs. The payload type can change on a
per-packet basis for an SSRC, for example a speech codec making use per-packet basis for an SSRC, for example a speech codec making use
of generic comfort noise [RFC3389]. If there is a true need to send of generic comfort noise [RFC3389]. If there is a true need to send
multiple payload types for the same SSRC that are valid for the same multiple payload types for the same SSRC that are valid for the same
instant, then redundant encodings [RFC2198] can be used. Several instant, then redundant encodings [RFC2198] can be used. Several
additional constraints than the ones mentioned above need to be met additional constraints than the ones mentioned above need to be met
to enable this use, one of which is that the combined payload sizes to enable this use, one of which is that the combined payload sizes
of the different payload types ought not exceed the transport MTU. of the different payload types ought not exceed the transport MTU.
If it is acceptable to send multiple formats of the same media source
as separate RTP streams (with separate SSRC), simulcast
[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, which in general requires that unique RTP
payload type value can be used in multiple bundled "m=" sections payload type numbers are used in each context. Use of MID, e.g. when
[I-D.ietf-mmusic-sdp-bundle-negotiation]. This association is only bundling "m=" sections [I-D.ietf-mmusic-sdp-bundle-negotiation], can
possible if unique RTP payload type numbers are used in each context. replace the payload type as signalling association and unique RTP
payload types are then no longer required for that purpose.
3.3. Issues Related to RTP Topologies 3.3. Issues Related to RTP Topologies
The impact of how RTP multiplexing is performed will in general vary The impact of how RTP multiplexing is performed will in general vary
with how the RTP session participants are interconnected, described with how the RTP session participants are interconnected, described
by RTP Topology [RFC7667]. by RTP Topology [RFC7667].
Even the most basic use case, denoted Topo-Point-to-Point in Even the most basic use case, denoted Topo-Point-to-Point in
[RFC7667], raises a number of considerations that are discussed in [RFC7667], raises a number of considerations that are discussed in
detail in following sections. They range over such aspects as: detail in following sections. They range over such aspects as:
o Does my communication peer support RTP as defined with multiple o Does my communication peer support RTP as defined with multiple
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 ( Section 4.2.1)?
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?
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)
skipping to change at page 15, line 20 skipping to change at page 15, line 28
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:
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.
This has previously been considered primarily as grouping RTP This has primarily been grouping RTP sessions, but in combination
sessions, but [I-D.ietf-mmusic-sdp-bundle-negotiation] groups with [I-D.ietf-mmusic-sdp-bundle-negotiation] it can also group
multiple media descriptions as a single RTP session. multiple media descriptions within a single RTP session.
SDP Media Multiplexing: Negotiating Media Multiplexing Using the
Session Description Protocol (SDP)
[I-D.ietf-mmusic-sdp-bundle-negotiation]
uses both SDP and RTCP information to associate RTP streams to SDP
media descriptions. This allows both to group RTP streams
belonging to an SDP media description, and to group multiple SDP
media descriptions into 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.
The above grouping constructs support many use cases. Those The above grouping constructs support many use cases. Those
solutions have shortcomings in cases where the session's dynamic solutions have shortcomings in cases where the session's dynamic
properties are such that it is difficult or a drain on resources to properties are such that it is difficult or a drain on resources to
keep the list of related SSRCs up to date. keep the list of related SSRCs up to date.
skipping to change at page 27, line 26 skipping to change at page 27, line 48
1. It works well with Split Component Terminal (see Section 3.10 of 1. It 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.
2. It enables flow-based QoS with different prioritisation between 2. It enables flow-based QoS with different prioritisation between
media types. media types.
3. 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. In the simple cases this allows for unsignalled RTP
streams where session level information and RTCP SDES item (e.g.
CNAME) are suffient. In the more complex cases where more
source-specific metadata needs to be signalled the SSRC can be
associated with an intermediate identifier, e.g. the MID conveyed
as an SDES item as defined in Section 15 of
[I-D.ietf-mmusic-sdp-bundle-negotiation].
4. There is low overhead for security association establishment. 4. There is low overhead for security association establishment.
The Disadvantages The Disadvantages
a. There are a slightly higher number of RTP sessions needed a. There are a slightly higher number of RTP sessions needed
compared to Multiple Media Types in one Session Section 5.1. compared to Multiple Media Types in one Session Section 5.1.
This implies: This implies:
* More NAT/FW state is needed. * More NAT/FW state is needed.
skipping to change at page 33, line 36 skipping to change at page 34, line 11
[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-54 (work in progress), December 2018. negotiation-54 (work in progress), December 2018.
[I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-14 (work in progress), March 2019.
[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-10 (work in progress), RTP", draft-ietf-perc-srtp-ekt-diet-11 (work in progress),
July 2019. January 2020.
[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>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
skipping to change at page 35, line 7 skipping to change at page 35, line 22
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>.
[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>.
11.2. Informative References 11.2. Informative References
[ALF] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of Protocols", SIGCOMM
Symposium on Communications Architectures and
Protocols (Philadelphia, Pennsylvania), pp. 200--208, IEEE
Computer Communications Review, Vol. 20(4), September
1990.
[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-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution 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)", draft-ietf-perc-private-media- Conferencing (PERC)", draft-ietf-perc-private-media-
framework-12 (work in progress), June 2019. framework-12 (work in progress), June 2019.
 End of changes. 30 change blocks. 
72 lines changed or deleted 80 lines changed or added

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