draft-ietf-avtcore-multiplex-guidelines-11.txt   draft-ietf-avtcore-multiplex-guidelines-12.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: August 21, 2020 C. Perkins Expires: December 18, 2020 C. Perkins
University of Glasgow University of Glasgow
H. Alvestrand H. Alvestrand
Google Google
R. Even R. Even
Huawei June 16, 2020
February 18, 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-11 draft-ietf-avtcore-multiplex-guidelines-12
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 43
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 August 21, 2020. This Internet-Draft will expire on December 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 32 skipping to change at page 2, line 27
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) . . . . . . . . . . . . . 10
3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 10 3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 11
3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 12
3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 13 3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 13
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 . . . . . . . . . . . . . 15
3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15
3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17 3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . 18 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18
4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 19
4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 20
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 . . . . . . . . . . . . . 21
4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Security and Key Management Considerations . . . . . . . 24 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 . . . . . . . 25 4.3.2. Key Management for Multi-party Sessions . . . . . . . 25
4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 26
5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26 5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26
5.1. Multiple Media Types in One Session . . . . . . . . . . . 26 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 . . . . . . . . . . 28
5.3. Multiple Sessions for One Media Type . . . . . . . . . . 28 5.3. Multiple Sessions for One Media Type . . . . . . . . . . 29
5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 30 5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 30
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 38 Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 39
Appendix B. Signalling Considerations . . . . . . . . . . . . . 40 Appendix B. Signalling Considerations . . . . . . . . . . . . . 40
B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40 B.1. Session Oriented Properties . . . . . . . . . . . . . . . 41
B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 41 B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 42
B.3. Signalling RTP Stream Usage . . . . . . . . . . . . . . . 41 B.3. Signalling RTP Stream Usage . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 3, line 49 skipping to change at page 3, line 43
needs to understand how to best use the RTP session, the RTP stream needs to understand how to best use the RTP session, the RTP stream
identifier (SSRC), and the RTP payload type to meet the application's identifier (SSRC), and the RTP payload type to meet the application's
needs. needs.
There have been increased interest in more advanced usage of RTP. There have been increased interest in more advanced usage of RTP.
For example, multiple RTP streams can be used when a single endpoint For example, multiple RTP streams can be used when a single endpoint
has multiple media sources (like multiple cameras or microphones) has multiple media sources (like multiple cameras or microphones)
that need to be sent simultaneously. Consequently, questions are that need to be sent simultaneously. Consequently, questions are
raised regarding the most appropriate RTP usage. The limitations in raised regarding the most appropriate RTP usage. The limitations in
some implementations, RTP/RTCP extensions, and signalling have also some implementations, RTP/RTCP extensions, and signalling have also
been exposed. The authors hope that clarification on the usefulness been exposed. This document aims to clarify the usefulness of some
of some functionalities in RTP will result in more complete functionalities in RTP which will hopefully result in more complete
implementations in the future. implementations in the future.
The purpose of this document is to provide clear information about The purpose of this document is to provide clear information about
the possibilities of RTP when it comes to multiplexing. The RTP the possibilities of RTP when it comes to multiplexing. The RTP
application designer needs to understand the implications arising application designer needs to understand the implications arising
from a particular usage of the RTP multiplexing points. The document from a particular usage of the RTP multiplexing points. The document
will provide some guidelines and recommend against some usages as will provide some guidelines and recommend against some usages as
being unsuitable, in general or for particular purposes. being unsuitable, in general or for particular purposes.
The document starts with some definitions and then goes into the The document starts with some definitions and then goes into the
skipping to change at page 5, line 4 skipping to change at page 4, line 47
RTP Sender: An Endpoint sending one or more RTP streams, but also RTP Sender: An Endpoint sending one or more RTP streams, but also
sending RTCP messages. sending RTCP messages.
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
RTP sessions; i.e. SSRCs that map to a common CNAME can be assumed RTP sessions; i.e. SSRCs that map to a common CNAME can be assumed
to have RTCP SR timing information derived from a common clock to have RTCP Sender Report (SR) timing information derived from a
such that they can be synchronised for playout. common clock such that they can be synchronised for playout.
Signalling: The process of configuring endpoints to participate in Signalling: The process of configuring endpoints to participate in
one or more RTP sessions. one or more RTP sessions.
Note: The above definitions of RTP Receiver and RTP Sender are Note: The above definitions of RTP Receiver and RTP Sender are
consistent with the usage in [RFC3550]. consistent with the usage in [RFC3550].
2.2. Subjects Out of Scope 2.2. Subjects Out of Scope
This document is focused on issues that affect RTP. Thus, issues This document is focused on issues that affect RTP. Thus, issues
skipping to change at page 5, line 40 skipping to change at page 5, line 35
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 simulcast or scalable video coding) for instance:
* To carry different layers of an scalable encoding of a media
source
* Alternative encodings during simulcast, for instance using
different codecs for the same audio stream
* Alternative formats during simulcast, for instance multiple
resolutions of the same video stream
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 during simulcast, for instance using
different codecs for the same audio stream
o Alternative formats during simulcast, for instance multiple
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 situation, might not be the choice suitable in another situation or
clearest understanding is associated with multiplexing multiple media combination of reasons. The clearest understanding is associated
sources of the same media type. However, all reasons warrant with multiplexing multiple media sources of the same media type.
discussion and clarification on how to deal with them. As the However, all reasons warrant discussion and clarification on how to
discussion below will show, in reality we cannot choose a single one deal with them. As the discussion below will show, in reality we
of SSRC or RTP session multiplexing solutions for all purposes. To cannot choose a single one of SSRC or RTP session multiplexing
utilise RTP well and as efficiently as possible, both are needed. solutions for all purposes. To utilise RTP well and as efficiently
The real issue is finding the right guidance on when to create as possible, both are needed. The real issue is finding the right
additional RTP sessions and when additional RTP streams in the same guidance on when to create additional RTP sessions and when
RTP session is the right choice. additional RTP streams in the same RTP session is the right choice.
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 more transport flows, e.g. based on the UDP
It also demultiplexes RTP/RTCP from any other protocols, such as STUN destination port. It also demultiplexes RTP/RTCP from any other
[RFC5389] and DTLS-SRTP [RFC5764] on the same transport as described protocols, such as STUN [RFC5389] and DTLS-SRTP [RFC5764] on the same
in [RFC7983]. The Processing and Buffering (PB) step of Figure 1 transport as described in [RFC7983]. The Processing and Buffering
terminates the RTP/RTCP protocol and prepares the RTP payload for (PB) step of Figure 1 terminates the RTP/RTCP protocol and prepares
input to the decoder. the RTP payload for input to the decoder.
| | | |
| packets | | | packets
+-- v +-- v v v
| +------------+ | +------------+
| | Socket | Transport Protocol Demultiplexing | | Socket(s) | 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) +---> Identify SSRC collision | ++(split by SSRC)-++---> Identify SSRC collision
| || || || || | || || || ||
| (associate with signalling by MID/RID) | (associate with signalling by MID/RID)
| || || || || | vv vv vv vv
RTP | +--+ +--+ +--+ +--+ Jitter buffer, RTP | +--+ +--+ +--+ +--+ Jitter buffer,
Streams | |PB| |PB| |PB| |PB| process RTCP, etc. Streams | |PB| |PB| |PB| |PB| process RTCP, etc.
| +--+ +--+ +--+ +--+ | +--+ +--+ +--+ +--+
+-- | | | | +-- | | | |
(select decoder based on PT) (select decoder based on PT)
+-- | / | / +-- | / | /
| +----+ | / | +-----+ | /
| / | | | / | |/
Payload | +---+ +---+ +---+ Payload | v v v
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
An RTP session is the highest semantic layer in the RTP protocol, and An RTP session is the highest semantic layer in the RTP protocol, and
represents an association between a group of communicating endpoints. represents an association between a group of communicating endpoints.
RTP does not contain a session identifier, yet different RTP sessions RTP does not contain a session identifier, yet different RTP sessions
must be possible to identify both across different endpoints and must be possible to identify both across a set of different endpoints
within a single endpoint. and from the perspective of a single endpoint.
For RTP session separation across endpoints, the set of participants For RTP session separation across endpoints, the set of participants
that form an RTP session is defined as those that share a single that form an RTP session is defined as those that share a single
synchronisation source space [RFC3550]. That is, if a group of synchronisation source space [RFC3550]. That is, if a group of
participants are each aware of the synchronisation source identifiers participants are each aware of the synchronisation source identifiers
belonging to the other participants, then those participants are in a belonging to the other participants, then those participants are in a
single RTP session. A participant can become aware of a single RTP session. A participant can become aware of a
synchronisation source identifier by receiving an RTP packet synchronisation source identifier by receiving an RTP packet
containing it in the SSRC field or CSRC list, by receiving an RTCP containing it in the SSRC field or CSRC list, by receiving an RTCP
packet mentioning it in an SSRC field, or through signalling (e.g., packet mentioning it in an SSRC field, or through signalling (e.g.,
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
the underlying transport layer, and on the signalling to identify RTP 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, and a single RTP session can therefore span multiple session, and a single RTP session can span multiple transport layer
transport layer flows even if all endpoints use a single transport flows even if all endpoints use a single transport layer flow per
layer flow per endpoint for that RTP session. The signalling layer endpoint for that RTP session. The signalling layer might give RTP
might give RTP sessions an explicit identifier, or the identification sessions an explicit identifier, or the identification might be
might be implicit based on the addresses and ports used. implicit based on the addresses and ports used. Accordingly, a
Accordingly, a single RTP session can have multiple associated single RTP session can have multiple associated identifiers, explicit
identifiers, explicit and implicit, belonging to different contexts. and implicit, belonging to different contexts. For example, when
For example, when running RTP on top of UDP/IP, an endpoint can running RTP on top of UDP/IP, an endpoint can identify and delimit an
identify and delimit an RTP session from other RTP sessions by their RTP session from other RTP sessions by their UDP source and
UDP source and destination IP addresses and UDP port numbers. destination IP addresses and UDP port numbers. A single RTP session
Independently if an endpoint has one or more IP addresses, a single can be using multiple IP/UDP flows for receiving and/or sending RTP
RTP session can be using multiple IP/UDP flows for receiving and/or packets to other endpoints or middleboxes, even if the endpoint does
sending RTP packets to other endpoints or middleboxes. Another not have multiple IP addresses. Using multiple IP addresses only
makes it more likely to require multiple IP/UDP flows. Another
example is SDP media descriptions (the "m=" line and the following example is SDP media descriptions (the "m=" line and the following
associated lines) that signals the transport flow and RTP session associated lines) that signal the transport flow and RTP session
configuration for the endpoint's part of the RTP session. The SDP configuration for the endpoint's part of the RTP session. The SDP
grouping framework [RFC5888] allows labeling of the media grouping framework [RFC5888] allows labeling of the media
descriptions to be used so that RTP Session Groups can be created. descriptions to be used so that RTP Session Groups can be created.
Through use of Negotiating Media Multiplexing Using the Session Through use of Negotiating Media Multiplexing Using the Session
Description Protocol (SDP) [I-D.ietf-mmusic-sdp-bundle-negotiation], Description Protocol (SDP) [I-D.ietf-mmusic-sdp-bundle-negotiation],
multiple media descriptions become part of a common RTP session where multiple media descriptions become part of a common RTP session where
each media description represents the RTP streams sent or received each media description represents the RTP streams sent or received
for a media source. for a media source.
The RTP protocol makes no normative statements about the relationship The RTP protocol makes no normative statements about the relationship
skipping to change at page 9, line 4 skipping to change at page 9, line 5
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 a source of an RTP stream, A synchronisation source (SSRC) identifies a source of an RTP stream,
or an RTP receiver when sending RTCP. Every endpoint has at least or an RTP receiver when sending RTCP. Every endpoint has at least
one SSRC identifier, even if it does not send RTP packets. RTP one SSRC identifier, even if it does not send RTP packets. RTP
endpoints that are only RTP receivers still send RTCP and use their endpoints that are only RTP receivers still send RTCP and use their
SSRC identifiers in the RTCP packets they send. An endpoint can have SSRC identifiers in the RTCP packets they send. An endpoint can have
multiple SSRC identifiers if it sends multiple RTP streams. multiple SSRC identifiers if it sends multiple RTP streams.
Endpoints that are both RTP sender and RTP receiver use the same
Endpoints that are both RTP sender and RTP receiver use the same SSRC SSRC(s) in both roles.
in both roles.
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
skipping to change at page 9, line 34 skipping to change at page 9, line 34
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].
The RepairedRtpStreamId is a rather recent mechanism, so one cannot
expect older applications to follow this recommendation.
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 and thus specific per RTP stream. SSRC and thus specific per RTP stream.
Different types of entities use an SSRC to identify themselves, as Different types of entities use an SSRC to identify themselves, as
follows: follows:
A real media source: Uses the SSRC to identify a "physical" media A real media source: Uses the SSRC to identify a "physical" media
source. source.
skipping to change at page 12, line 41 skipping to change at page 12, line 51
o Different security solutions, e.g., IPsec, TLS, DTLS, or 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. Beware that gateway, for example a need to monitor the RTP streams. Beware that
changing the stream transport characteristics in the translator, can changing the stream transport characteristics in the translator can
require thorough understanding of the application logic, specifically require thorough understanding of aspects from congestion control and
any congestion control or media adaptation to ensure appropriate media adaptation to application-layer semantics.
media handling.
Within the uses enabled by the RTP standard the point to point Within the uses enabled by the RTP standard, the point to point
topology can contain one to many RTP sessions with one to many media topology can contain one or more RTP sessions with one or more media
sources per session, each having one or more RTP streams per media sources per session, each having one or more RTP streams per media
source. 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
skipping to change at page 14, line 33 skipping to change at page 14, line 43
Section 4.2. It also goes into aspects of implementation, like Split Section 4.2. It also goes into aspects of implementation, like Split
Component Terminal (see Section 3.10 of [RFC7667]) endpoints where Component Terminal (see Section 3.10 of [RFC7667]) endpoints where
different processes or inter-connected devices handle different different processes or inter-connected devices handle different
aspects of the whole multi-media session. aspects of the whole multi-media session.
A summary of RFC 3550's view on multiplexing is to use unique SSRCs A summary of RFC 3550's view on multiplexing is to use unique SSRCs
for anything that is its own media/packet stream, and to use for anything that is its own media/packet stream, and to use
different RTP sessions for media streams that don't share a media different RTP sessions for media streams that don't share a media
type. This document supports the first point; it is very valid. The type. This document supports the first point; it is very valid. The
latter needs further discussion, as imposing a single solution on all latter needs further discussion, as imposing a single solution on all
usages of RTP is inappropriate. Multiple Media Types in an RTP usages of RTP is inappropriate. "Multiple Media Types in an RTP
Session specification [I-D.ietf-avtcore-multi-media-rtp-session] Session specification" [I-D.ietf-avtcore-multi-media-rtp-session]
provides a detailed analysis of the potential issues in having updates RFC 3550 to allow multiple media types in a RTP session. It
multiple media types in the same RTP session. This document provides also provides a detailed analysis of the potential benefits and
a wider scope for an RTP session and considers multiple media types issues in having multiple media types in the same RTP session. Thus,
in one RTP session as a possible choice for the RTP application that document provides a wider scope for an RTP session and considers
designer. multiple media types in one RTP session as a possible choice for the
RTP application 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 application impact from lack of appropriate RTP and the possible application impact from lack of appropriate RTP
skipping to change at page 15, line 18 skipping to change at page 15, line 29
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 streams together. This issue is common to both to bind related RTP streams together. This issue is common to both
using additional SSRCs and multiple RTP sessions. using additional SSRCs and multiple RTP 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, e.g. 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 16, line 18
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.
An RTP/RTCP-based grouping solution is to use the RTCP SDES CNAME to An RTP/RTCP-based grouping solution is to use the RTCP SDES CNAME to
bind related RTP streams to an endpoint or to a synchronization bind related RTP streams to an endpoint or to a synchronization
context. For applications with a single RTP stream per type (media, context. For applications with a single RTP stream per type (media,
source or redundancy stream), CNAME is sufficient for that purpose source or redundancy stream), CNAME is sufficient for that purpose
independent if one or more RTP sessions are used. However, some independently of whether one or more RTP sessions are used. However,
applications choose not to use CNAME because of perceived complexity some applications choose not to use CNAME because of perceived
or a desire not to implement RTCP and instead use the same SSRC value complexity or a desire not to implement RTCP and instead use the same
to bind related RTP streams across multiple RTP sessions. RTP SSRC value to bind related RTP streams across multiple RTP sessions.
Retransmission [RFC4588] in multiple RTP session mode and Generic FEC RTP Retransmission [RFC4588] in multiple RTP session mode and Generic
[RFC5109] both use the CNAME method to relate the RTP streams, which FEC [RFC5109] both use the CNAME method to relate the RTP streams,
may work but might have some downsides in RTP sessions with many which may work but might have some downsides in RTP sessions with
participating SSRCs. It is not recommended to use identical SSRC many participating SSRCs. It is not recommended to use identical
values across RTP sessions to relate RTP streams; When an SSRC SSRC values across RTP sessions to relate RTP streams; When an SSRC
collision occurs, this will force change of that SSRC in all RTP collision occurs, this will force change of that SSRC in all RTP
sessions and thus resynchronize all of them instead of only the sessions and thus resynchronize all of them instead of only the
single media stream having the collision. single media stream having the collision.
Another method to implicitly bind SSRCs is used by RTP Retransmission Another method to implicitly bind SSRCs is used by RTP Retransmission
[RFC4588] when using the same RTP session as the source RTP stream [RFC4588] when using the same RTP session as the source RTP stream
for retransmissions. The receiver missing a packet issues an RTP for retransmissions. The receiver missing a packet issues an RTP
retransmission request, and then awaits a new SSRC carrying the RTP retransmission request, and then awaits a new SSRC carrying the RTP
retransmission payload and where that SSRC is from the same CNAME. retransmission payload and where that SSRC is from the same CNAME.
This limits a requester to having only one outstanding retransmission This limits a requester to having only one outstanding retransmission
skipping to change at page 16, line 41 skipping to change at page 16, line 50
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
RtpStreamId value as an SDES item and an RTP header extension. The RtpStreamId value as an SDES item and an RTP header extension. The
RID solution also includes a solution for binding redundancy RTP 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.
Section 8.3 of the RTP Specification [RFC3550] recommends using a Experience has found that an explicit binding between the RTP
single SSRC space across all RTP sessions for layered coding. Based streams, agnostic of SSRC values, behaves well. That way, solutions
on the experience so far however, we recommend to use a solution with using multiple RTP streams in a single RTP session and in multiple
explicit binding between the RTP streams that is agnostic to the used RTP sessions will use the same type of binding.
SSRC values. That way, solutions using multiple RTP streams in a
single RTP session and in multiple RTP sessions will use the same
type of binding.
3.4.4. Forward Error Correction 3.4.4. Forward Error Correction
There exist a number of Forward Error Correction (FEC) based schemes There exist a number of Forward Error Correction (FEC) based schemes
for how to reduce the packet loss of the original streams. Most of for how to mitigate packet loss in the original streams. Most of the
the FEC schemes protects a single source flow. The protection is FEC schemes protect a single source flow. The protection is achieved
achieved by transmitting a certain amount of redundant information by transmitting a certain amount of redundant information that is
that is encoded such that it can repair one or more packet losses encoded such that it can repair one or more packet losses over the
over the set of packets the redundant information protects. This set of packets the redundant information protects. This sequence of
sequence of redundant information needs to be transmitted as its own redundant information needs to be transmitted as its own media
media stream, or in some cases, instead of the original media stream. stream, or in some cases, instead of the original media stream.
Thus, many of these schemes create a need for binding related flows Thus, many of these schemes create a need for binding related flows
as discussed above. Looking at the history of these schemes, there as discussed above. Looking at the history of these schemes, there
are schemes using multiple SSRCs and schemes using multiple RTP are schemes using multiple SSRCs and schemes using multiple RTP
sessions, and some schemes that support both modes of operation. sessions, and some schemes that support both modes of operation.
Using multiple RTP sessions supports the case where some set of Using multiple RTP sessions supports the case where some set of
receivers might not be able to utilise the FEC information. By receivers might not be able to utilise the FEC information. By
placing it in a separate RTP session and if separating RTP sessions placing it in a separate RTP session and if separating RTP sessions
on transport level, FEC can easily be ignored already on transport on transport level, FEC can easily be ignored already on the
level, without considering any RTP layer information. transport level, without considering any RTP layer information.
In usages involving multicast, having the FEC information on its own In usages involving multicast, having the FEC information on its own
multicast group allows for similar flexibility. This is especially multicast group allows for similar flexibility. This is especially
useful when receivers see heterogeneous packet loss rates. A useful when receivers see heterogeneous packet loss rates. A
receiver can based on measurment of experienced packet loss decide to receiver can decide, based on measurement of experienced packet loss
join a multicast group with the suitable FEC data repair rates, whether to join a multicast group with the suitable FEC data
capabilities. repair capabilities.
4. Considerations for RTP Multiplexing 4. Considerations for RTP Multiplexing
4.1. Interworking Considerations 4.1. Interworking Considerations
There are several different kinds of interworking, and this section There are several different kinds of interworking, and this section
discusses two; interworking directly between different applications, discusses two; interworking directly between different applications,
and interworking of applications through an RTP Translator. The and interworking of applications through an RTP Translator. The
discussion includes the implications of potentially different RTP discussion includes the implications of potentially different RTP
multiplexing point choices and limitations that have to be considered multiplexing point choices and limitations that have to be considered
skipping to change at page 18, line 14 skipping to change at page 18, line 17
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 building a gateway: using RTP There are two fundamental approaches to building a gateway: using RTP
Translator interworking (RTP bridging), where the gateway acts as an Translator interworking (RTP bridging), where the gateway acts as an
RTP Translator with the two interconnected applications being members RTP Translator with the two interconnected applications being members
of the same RTP session; or using Gateway Interworking with RTP of the same RTP session; or using Gateway Interworking with RTP
termination, where there are independent RTP sessions between each termination, where there are independent RTP sessions between each
interconnected application and the gateway. interconnected application and the gateway.
For interworking to be feasible, any security solution in use needs
to be compatible and capable of exchanging keys with either the peer
or the gateway under the used trust model. Secondly, the
applications need to use media streams in a way that makes sense in
both applications.
4.1.2. RTP Translator Interworking 4.1.2. RTP Translator Interworking
From an RTP perspective, the RTP Translator approach could work if From an RTP perspective, the RTP Translator approach could work if
all the applications are using the same codecs with the same payload all 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 a gateway is implemented 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 [I-D.ietf-mmusic-sdp-bundle-negotiation], it is possible for BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], it may be possible
the RTP translator to map the RTP streams between both sides using for the RTP translator to map the RTP streams between both sides
some method, e.g. if the number and order of SDP "m=" lines between using some method, e.g. based on the number and order of SDP "m="
both sides are the same. There are also challenges with SSRC lines from each side. There are also challenges with SSRC collision
collision handling since, unless SSRC translation is applied on the handling since, unless SSRC translation is applied on the RTP
RTP translator, there may be a collision on the SSRC multiplexing translator, there may be a collision on the SSRC multiplexing side
side that the RTP session multiplexing side will not be aware of. that the RTP session multiplexing side will not be aware of.
Furthermore, if one of the applications is capable of working in Furthermore, if one of the applications is capable of working in
several modes (such as being able to use additional RTP streams in several modes (such as being able to use additional RTP streams in
one RTP session or multiple RTP sessions at will), and the other one one RTP session or multiple RTP sessions at will), and the other one
is not, successful interconnection depends on locking the more is not, successful interconnection depends on locking the more
flexible application into the operating mode where interconnection flexible application into the operating mode where interconnection
can be successful, even if none of the participants are using the can be successful, even if none of the participants are using the
less flexible application when the RTP sessions are being created. less flexible application when the RTP sessions are being created.
4.1.3. Gateway Interworking 4.1.3. Gateway Interworking
When one terminates RTP sessions at the gateway, there are certain When one terminates RTP sessions at the gateway, there are certain
tasks that the gateway has to carry out: tasks that the gateway has to carry out:
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 use any security mechanism, e.g., in the form For applications that use any security mechanism, e.g., in the form
of SRTP, the gateway needs to be able to decrypt and verify source of SRTP, the gateway needs to be able to decrypt and verify source
integrity of the incoming packets, and re-encrypt, integrity protect, integrity of the incoming packets, and re-encrypt, integrity protect,
and sign the packets as peer in the other application's security and sign the packets as the peer in the other application's security
context. This is necessary even if all that's needed is a simple context. This is necessary even if all that's needed is a simple
remapping of SSRC numbers. If this is done, the gateway also needs remapping of SSRC numbers. If this is done, the gateway also needs
to be a member of the security contexts of both sides, of course. to be a member of the security contexts of both sides, and thus a
trusted entity.
The gateway might also need to apply transcoding (for incompatible The gateway might also need to apply transcoding (for incompatible
codec types), media-level adaptations that cannot be solved through codec types), media-level adaptations that cannot be solved through
media negotiation (such as rescaling for incompatible video size media negotiation (such as rescaling for incompatible video size
requirements), suppression of content that is known not to be handled requirements), suppression of content that is known not to be handled
in the destination application, or the addition or removal of in the destination application, or the addition or removal of
redundancy coding or scalability layers to fit the needs of the redundancy coding or scalability layers to fit the needs of the
destination domain. destination domain.
From the above, we can see that the gateway needs to have an intimate From the above, we can see that the gateway needs to have an intimate
knowledge of the application requirements; a gateway is by its nature knowledge of the application requirements; a gateway is by its nature
application specific, not a commodity product. application specific, not a commodity product.
These gateways might therefore potentially block application These gateways might therefore potentially block application
evolution by blocking RTP and RTCP extensions that the applications evolution by blocking RTP and RTCP extensions that the applications
have been extended with but that are unknown to the gateway. have been extended with but that are unknown to the gateway.
If one uses security functions, like SRTP, and as can be seen from If one uses security mechanism, like SRTP, the gateway and the
above, they incur both additional risk due to the requirement to have necessary trust in it by the peers is an additional risk to the
the gateway in the security association between the endpoints (unless communication security. The gateway also incur additional
the gateway is on the transport level), and additional complexities complexities in form of the decrypt-encrypt cycles needed for each
in form of the decrypt-encrypt cycles needed for each forwarded forwarded packet. SRTP, due to its keying structure, also requires
packet. SRTP, due to its keying structure, also requires that each that each RTP session needs different master keys, as use of the same
RTP session needs different master keys, as use of the same key in key in two RTP sessions can for some ciphers result in a reuse of a
two RTP sessions can for some ciphers result in two-time pads that one-time pad that completely breaks the confidentiality of the
completely breaks the confidentiality of the packets. 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 or than one media source per endpoint and media type (typically audio or
video). Even in conferencing applications, especially voice-only, video). Even in conferencing applications, especially voice-only,
the conference focus or bridge has provided a single stream to each the conference focus or bridge has provided a single stream to each
participant containing a mix of the other participants. It is also participant containing a mix of the other participants. It is also
common to have individual RTP sessions between each endpoint and the common to have individual RTP sessions between each endpoint and the
RTP mixer, meaning that the mixer functions as an RTP-terminating RTP mixer, meaning that the mixer functions as an RTP-terminating
gateway. gateway.
Endpoints that aren't updated to handle multiple streams following Applications and systems that aren't updated to handle multiple
these recommendations can have issues with participating in RTP streams following these recommendations can have issues with
sessions containing multiple SSRCs within a single session, such as: participating in RTP sessions containing multiple SSRCs within a
single session, such as:
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.
2. Be capable of decoding multiple streams simultaneously. 2. Be capable of decoding multiple streams simultaneously.
3. Be capable of rendering multiple streams simultaneously. 3. Be capable of rendering multiple streams simultaneously.
This indicates that gateways attempting to interconnect to this class This indicates that gateways attempting to interconnect to this class
of devices have to make sure that only one RTP stream of each media of devices have to make sure that only one RTP stream of each media
skipping to change at page 20, line 45 skipping to change at page 21, line 10
Diff-Serv [RFC2474] is an example of a packet marking based one. Diff-Serv [RFC2474] is an example of a packet marking based one.
For a flow based scheme, additional SSRC will receive the same QoS as For a flow based scheme, additional SSRC will receive the same QoS as
all other RTP streams being part of the same 5-tuple (protocol, all other RTP streams being part of the same 5-tuple (protocol,
source address, destination address, source port, destination port), source address, destination address, source port, destination port),
which is the most common selector for flow based QoS. which is the most common selector for flow based QoS.
For a packet marking based scheme, the method of multiplexing will For a packet marking based scheme, the method of multiplexing will
not affect the possibility to use QoS. Different Differentiated not affect the possibility to use QoS. Different Differentiated
Services Code Points (DSCP) can be assigned to different packets Services Code Points (DSCP) can be assigned to different packets
within a flow as well as within an RTP stream. However, care must be within a transport flow (5-Tuple) as well as within an RTP stream,
taken when considering which forwarding behaviours that are applied assuming usage of UDP or other transport protocol that do not have
on path due to these DSCPs. In some cases the forwarding behaviour issues with packet reordering within the transport flow (5-tuple).
can result in packet reordering. For more discussion of this see To avoid packet reording issues, packets belonging to the same RTP
[RFC7657]. flow should limits its use of DSCP to those whose corresponding Per
Hop Behavior (PHB) that do not enable reordering. If the transport
protocol used assumes in order delivery of packet, such as TCP and
SCTP, then a single DSCP should be used. For more discussion of this
see [RFC7657].
The method for assigning marking to packets can impact what number of The method for assigning marking to packets can impact what number of
RTP sessions to choose. If this marking is done using a network RTP sessions to choose. If this marking is done using a network
ingress function, it can have issues discriminating the different RTP ingress function, it can have issues discriminating the different RTP
streams. The network API on the endpoint also needs to be capable of streams. The network API on the endpoint also needs to be capable of
setting the marking on a per-packet basis to reach the full setting the marking on a per-packet basis to reach the full
functionality. functionality.
4.2.2. NAT and Firewall Traversal 4.2.2. NAT and Firewall Traversal
skipping to change at page 22, line 17 skipping to change at page 22, line 34
case scenario for additional NAT/FW traversal time after finding case scenario for additional NAT/FW traversal time after finding
the first valid candidate pair following the specified ICE the first valid candidate pair following the specified ICE
procedures is 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the procedures is 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the
pacing timer. That assumes a message in one direction, pacing timer. That assumes a message in one direction,
immediately followed by a check back. The reason it isn't more, immediately followed by a check back. The reason it isn't more,
is that ICE first finds one candidate pair that works prior to is that ICE first finds one candidate pair that works prior to
attempting to establish multiple flows. Thus, there is no extra attempting to establish multiple flows. Thus, there is no extra
time until one has found a working candidate pair. Based on that time until one has found a working candidate pair. Based on that
working pair, the extra time is needed to in parallel establish working pair, the extra time is needed to in parallel establish
the, in most cases 2-3, additional flows. However, packet loss the, in most cases 2-3, additional flows. However, packet loss
causes extra delays, at least 100 ms, which is the minimal causes extra delays, at least 500 ms, which is the minimal
retransmission timer for ICE. retransmission timer for ICE.
NAT Traversal Failure Rate: Due to the need to establish more than a NAT Traversal Failure Rate: Due to the need to establish more than a
single flow through the NAT, there is some risk that establishing single flow through the NAT, there is some risk that establishing
the first flow succeeds but that one or more of the additional the first flow succeeds but that one or more of the additional
flows fail. The risk that this happens is hard to quantify, but flows fail. The risk that this happens is hard to quantify, but
ought to be fairly low as one flow from the same interfaces has ought to be fairly low as one flow from the same interfaces has
just been successfully established. Thus only rare events such as just been successfully established. Thus only rare events such as
NAT resource overload, or selecting particular port numbers that NAT resource overload, or selecting particular port numbers that
are filtered etc., ought to be reasons for failure. are filtered etc., ought to be reasons for failure.
Deep Packet Inspection and Multiple Streams: Firewalls differ in how Deep Packet Inspection and Multiple Streams: Firewalls differ in how
deeply they inspect packets. There exist some risk that deeply deeply they inspect packets. Due to all previous issues with
inspecting firewalls will have similar legacy issues with multiple firewall and Session Boarder Gateways (SBG) with RTP transport
SSRCs as some RTP stack implementations. media e.g. in Voice over IP (VoIP) systems, there exists a
significant risk that deeply inspecting firewalls will have
similar legacy issues with multiple SSRCs as some RTP stack
implementations.
Using additional RTP streams in the same RTP session and transport Using additional RTP streams in the same RTP session and transport
flow does not introduce any additional NAT traversal complexities per flow does not introduce any additional NAT traversal complexities per
RTP stream. This can be compared with normally one or two additional RTP stream. This can be compared with normally one or two additional
transport flows per RTP session when using multiple RTP sessions. transport flows per RTP session when using multiple RTP sessions.
Additional lower layer transport flows will be needed, unless an Additional lower layer transport flows will be needed, unless an
explicit de-multiplexing layer is added between RTP and the transport explicit de-multiplexing layer is added between RTP and the transport
protocol. At time of writing no such mechanism was defined. protocol. At time of writing no such mechanism was defined.
4.2.3. Multicast 4.2.3. Multicast
skipping to change at page 24, line 50 skipping to change at page 25, line 20
create issues in a few cases. create issues in a few cases.
The first case is when someone leaves a multi-party session and one The first case is when someone leaves a multi-party session and one
wants to ensure that the party that left can no longer access the RTP wants to ensure that the party that left can no longer access the RTP
streams. This requires that everyone re-keys without disclosing the streams. This requires that everyone re-keys without disclosing the
new keys to the excluded party. new keys to the excluded party.
A second case is when using security as an enforcing mechanism for A second case is when using security as an enforcing mechanism for
stream access differentiation between different receivers. Take for stream access differentiation between different receivers. Take for
example a scalable layer or a high quality simulcast version that example a scalable layer or a high quality simulcast version that
only premium users are allowed to access. The mechanism preventing a only users paying a premium are allowed to access. The mechanism
receiver from getting the high quality stream can be based on the preventing a receiver from getting the high quality stream can be
stream being encrypted with a key that user can't access without based on the stream being encrypted with a key that user can't access
paying premium, using the key-management to limit access to the key. without paying premium, using the key-management to limit access to
the key.
SRTP [RFC3711] has no special functions for dealing with different SRTP [RFC3711] as specified uses per SSRC unique keys, however the
sets of master keys for different SSRCs. The key-management original assumption was a single session master key from which SSRC
functions have different capabilities to establish different sets of specific RTP and RTCP keys where derived. However, that assumption
keys, normally on a per-endpoint basis. For example, DTLS-SRTP was proven incorrect, as the application usage and the developed key-
[RFC5764] and Security Descriptions [RFC4568] establish different mamangement mechanisms have chosen many different methods for
keys for outgoing and incoming traffic from an endpoint. This key ensuring SSRC unique keys. The key-management functions have
usage has to be written into the cryptographic context, possibly different capabilities to establish different sets of keys, normally
associated with different SSRCs. on a per-endpoint basis. For example, DTLS-SRTP [RFC5764] and
Security Descriptions [RFC4568] establish different keys for outgoing
and incoming traffic from an endpoint. This key usage has to be
written into the cryptographic context, possibly associated with
different SSRCs. Thus, limitations do exist depending on chosen key-
management method and due to integration of particular
implementations of the key-management and SRTP.
4.3.2. Key Management for Multi-party Sessions 4.3.2. Key Management for Multi-party Sessions
The capabilities of the key-management combined with the RTP The capabilities of the key-management combined with the RTP
multiplexing choices affects the resulting security properties, multiplexing choices affects the resulting security properties,
control over the secured media, and who have access to it. control over the secured media, and who have access to it.
Multi-party sessions contain at least one RTP stream from each active Multi-party sessions contain at least one RTP stream from each active
participant. Depending on the multi-party topology [RFC7667], each participant. Depending on the multi-party topology [RFC7667], each
participant can both send and receive multiple RTP streams. participant can both send and receive multiple RTP streams.
Transport translator-based sessions and multicast sessions, can Transport translator-based sessions (Topo-Trn-Translator) and
neither use Security Description [RFC4568] nor DTLS-SRTP [RFC5764] multicast sessions (Topo-ASM), can neither use Security Description
without an extension as each endpoint provides its set of keys. In
centralised conferences, the signalling counterpart is a conference [RFC4568] nor DTLS-SRTP [RFC5764] without an extension as each
server, and the transport translator is the media plane unicast endpoint provides its set of keys. In centralised conferences, the
counterpart (to which DTLS messages would be sent). Thus, an signalling counterpart is a conference server, and the transport
extension like Encrypted Key Transport [I-D.ietf-perc-srtp-ekt-diet] translator is the media plane unicast counterpart (to which DTLS
or a MIKEY [RFC3830] based solution that allows for keying all messages would be sent). Thus, an extension like Encrypted Key
session participants with the same master key is needed. Transport [I-D.ietf-perc-srtp-ekt-diet] or a MIKEY [RFC3830] based
solution that allows for keying all session participants with the
same master key is needed.
Privacy Enchanced RTP Conferencing (PERC) also enables a different Privacy Enchanced RTP Conferencing (PERC) also enables a different
trust model with semi-trusted media switching RTP middleboxes trust model with semi-trusted media switching RTP middleboxes
[I-D.ietf-perc-private-media-framework]. [I-D.ietf-perc-private-media-framework].
4.3.3. Complexity Implications 4.3.3. Complexity Implications
The usage of security functions can surface complexity implications The usage of security functions can surface complexity implications
from the choice of multiplexing and topology. This becomes from the choice of multiplexing and topology. This becomes
especially evident in RTP topologies having any type of middlebox especially evident in RTP topologies having any type of middlebox
skipping to change at page 27, line 26 skipping to change at page 27, line 50
f. It is not suitable for applications where some receivers like to f. It is not suitable for applications where some receivers like to
receive only a subset of the RTP streams, especially if multicast receive only a subset of the RTP streams, especially if multicast
or transport translator is being used. or transport translator is being used.
g. There is some additional concern with legacy implementations that g. There is some additional concern with legacy implementations that
do not support the RTP specification fully when it comes to do not support the RTP specification fully when it comes to
handling multiple SSRC per endpoint, as multiple simultaneous handling multiple SSRC per endpoint, as multiple simultaneous
media types are sent as separate SSRC in the same RTP session. media types are sent as separate SSRC in the same RTP session.
h. If the applications need finer control over which session h. If the applications need finer control over which session
participants that are included in different sets of security participants are included in different sets of security
associations, most key-management will have difficulties associations, most key-management mechanisms will have
establishing such a session. difficulties establishing such a session.
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 [RFC5761]. RTP/RTCP multiplexing [RFC5761].
skipping to change at page 29, line 12 skipping to change at page 29, line 35
prioritisation, or the need for fine-grained signalling using RTP prioritisation, or the need for fine-grained signalling using RTP
session-focused signalling tools. session-focused signalling tools.
The Advantages: The Advantages:
1. This is more suitable for multicast usage where receivers can 1. This is more suitable for multicast usage where receivers can
individually select which RTP sessions they want to participate individually select which RTP sessions they want to participate
in, assuming each RTP session has its own multicast group. in, assuming each RTP session has its own multicast group.
2. The application can indicate its usage of the RTP streams on RTP 2. The application can indicate its usage of the RTP streams on RTP
session level, in case multiple different usages exist. session level, when multiple different usages exist.
3. There is less need for SSRC-specific explicit signalling for each 3. There is less need for SSRC-specific explicit signalling for each
media stream and thus reduced need for explicit and timely media stream and thus reduced need for explicit and timely
signalling when RTP streams are added or removed. signalling when RTP streams are added or removed.
4. It enables detailed QoS prioritisation for flow-based mechanisms. 4. It enables detailed QoS prioritisation for flow-based mechanisms.
5. It works well with Split Component Terminal (see Section 3.10 of 5. It works well with Split Component Terminal (see Section 3.10 of
[RFC7667]). [RFC7667]).
skipping to change at page 32, line 8 skipping to change at page 32, line 32
need for real-time signalling in sessions with dynamically changing need for real-time signalling in sessions with dynamically changing
number of RTP streams. They also represent points in-between the number of RTP streams. They also represent points in-between the
first two designs when it comes to amount of RTP sessions first two designs when it comes to amount of RTP sessions
established, i.e. representing an attempt to balance the amount of established, i.e. representing an attempt to balance the amount of
RTP sessions with the functionality the communication session RTP sessions with the functionality the communication session
provides both on network level and on signalling level. provides both on network level and on 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, system designers, or specification writers.
Do not require use of the same SSRC value across RTP sessions: Do not require use of the same SSRC value across RTP sessions:
As discussed in Section 3.4.3 there exist drawbacks in using the As discussed in Section 3.4.3 there exist drawbacks in using the
same SSRC in multiple RTP sessions as a mechanism to bind related same SSRC in multiple RTP sessions as a mechanism to bind related
RTP streams together. It is instead recommended to use a RTP streams together. It is instead recommended to use a
mechanism to explicitly signal the relation, either in RTP/RTCP or mechanism to explicitly signal the relation, either in RTP/RTCP or
in the signalling mechanism used to establish the RTP session(s). in the 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
skipping to change at page 32, line 49 skipping to change at page 33, line 26
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
generic must support both. Extensions that are not as generally generic must support both. Extensions that are not as generally
applicable will have to consider if interoperability is better applicable will have to consider if interoperability is better
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 Extensions for Transport Support: When defining new RTP/RTCP
intended for transport support, like the retransmission or FEC extensions intended for transport support, like the retransmission
mechanisms, they must include support for both multiple RTP or FEC mechanisms, they must include support for both multiple RTP
streams in the same RTP session and multiple RTP sessions, such streams in the same RTP session 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. IANA Considerations 7. 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
skipping to change at page 33, line 36 skipping to change at page 34, line 13
SSRC vs multiple RTP sessions in Section 4.3. SSRC vs multiple RTP sessions in Section 4.3.
9. Contributors 9. Contributors
Hui Zheng (Marvin) contributed to WG draft versions -04 and -05 of Hui Zheng (Marvin) contributed to WG draft versions -04 and -05 of
the document. the document.
10. Acknowledgments 10. Acknowledgments
The Authors like to acknowledge and thank Cullen Jennings, Dale R The Authors like to acknowledge and thank Cullen Jennings, Dale R
Worley, Huang Yihong (Rachel), and Vijay Gurbani for review and Worley, Huang Yihong (Rachel), Benjamin Kaduk, Mirja Kuehlewind, and
comments. Vijay Gurbani for review and comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
skipping to change at page 34, line 32 skipping to change at page 35, line 10
[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>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
DOI 10.17487/RFC3830, August 2004,
<https://www.rfc-editor.org/info/rfc3830>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[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>.
skipping to change at page 36, line 24 skipping to change at page 37, line 5
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
September 2002, <https://www.rfc-editor.org/info/rfc3389>. September 2002, <https://www.rfc-editor.org/info/rfc3389>.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
DOI 10.17487/RFC3830, August 2004,
<https://www.rfc-editor.org/info/rfc3830>.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>. <https://www.rfc-editor.org/info/rfc4103>.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, Real-time Transport Protocol (SRTP)", RFC 4383,
DOI 10.17487/RFC4383, February 2006, DOI 10.17487/RFC4383, February 2006,
<https://www.rfc-editor.org/info/rfc4383>. <https://www.rfc-editor.org/info/rfc4383>.
skipping to change at page 39, line 4 skipping to change at page 39, line 38
transmitted in sequence and without interruptions within the transmitted in sequence and without interruptions within the
object. This can relatively simple be solved on the sender side object. This can relatively simple be solved on the sender side
by ensuring that the fragments of each RTP stream are sent in by ensuring that the fragments of each RTP stream are sent in
sequence. sequence.
3. Some media formats require uninterrupted sequence number space 3. Some media formats require uninterrupted sequence number space
between media parts. These are media formats where any missing between media parts. These are media formats where any missing
RTP sequence number will result in decoding failure or invoking RTP sequence number will result in decoding failure or invoking
a repair mechanism within a single media context. The text/ a repair mechanism within a single media context. The text/
T140 payload format [RFC4103] is an example of such a format. T140 payload format [RFC4103] is an example of such a format.
These formats will need a sequence numbering abstraction These formats will need a sequence numbering abstraction
function between RTP and the individual RTP stream before being function between RTP and the individual RTP stream before being
used with payload type multiplexing. used with payload type multiplexing.
4. Sending multiple streams in the same sequence number space makes 4. Sending multiple media streams in the same sequence number space
it impossible to determine which payload type, which stream a makes it impossible to determine which media stream lost a
packet loss relates to, and thus to which stream to potentially packet. This as the payload type that is used for demultiplex
apply packet loss concealment or other stream-specific loss the media stream is not received. Thus, causing the receiver
mitigation mechanisms. difficulties in determining which stream to apply packet loss
concealment or other stream-specific loss mitigation mechanisms.
5. If RTP Retransmission [RFC4588] is used and there is a loss, it 5. If RTP Retransmission [RFC4588] is used and there is a loss, it
is possible to ask for the missing packet(s) by SSRC and is possible to ask for the missing packet(s) by SSRC and
sequence number, not by payload type. If only some of the sequence number, not by payload type. If only some of the
payload type multiplexed streams are of interest, there is no payload type multiplexed streams are of interest, there is no
way of telling which missing packet(s) belong to the interesting way of telling which missing packet(s) belong to the interesting
stream(s) and all lost packets need be requested, wasting stream(s) and all lost packets need be requested, wasting
bandwidth. bandwidth.
6. The current RTCP feedback mechanisms are built around providing 6. The current RTCP feedback mechanisms are built around providing
skipping to change at page 40, line 35 skipping to change at page 41, line 20
also dependent on the signalling protocols carrying the SDP. RTSP also dependent on the signalling protocols carrying the SDP. RTSP
[RFC7826] and SAP [RFC2974] both use SDP in a declarative fashion, [RFC7826] and SAP [RFC2974] both use SDP in a declarative fashion,
while SIP [RFC3261] uses SDP with the additional definition of Offer/ while SIP [RFC3261] uses SDP with the additional definition of Offer/
Answer [RFC3264]. The impact on signalling and especially SDP needs Answer [RFC3264]. The impact on signalling and especially SDP needs
to be considered as it can greatly affect how to deploy a certain to be considered as it can greatly affect how to deploy a certain
multiplexing point choice. multiplexing point choice.
B.1. Session Oriented Properties B.1. Session Oriented Properties
One aspect of the existing signalling is that it is focused on RTP One aspect of the existing signalling is that it is focused on RTP
sessions, or at least in the case of SDP the media description. sessions, or in the case of SDP, the media description concept.
There are a number of things that are signalled on media description There are a number of things that are signalled on media description
level but those are not necessarily strictly bound to an RTP session level but those are not necessarily strictly bound to an RTP session
and could be of interest to signal specifically for a particular RTP and could be of interest to signal specifically for a particular RTP
stream (SSRC) within the session. The following properties have been stream (SSRC) within the session. The following properties have been
identified as being potentially useful to signal not only on RTP identified as being potentially useful to signal not only on RTP
session level: session level:
o Bitrate/Bandwidth exist today only at aggregate or as a common o Bitrate/Bandwidth exist today only at aggregate or as a common
"any RTP stream" limit, unless either codec-specific bandwidth "any RTP stream" limit, unless either codec-specific bandwidth
limiting or RTCP signalling using TMMBR is used. limiting or RTCP signalling using TMMBR [RFC5104] is used.
o Which SSRC that will use which RTP payload type (this will be o Which SSRC that will use which RTP payload type (this will be
visible from the first media packet, but is sometimes useful to visible from the first media packet, but is sometimes useful to
know before packet arrival). know before packet arrival).
Some of these issues are clearly SDP's problem rather than RTP Some of these issues are clearly SDP's problem rather than RTP
limitations. However, if the aim is to deploy an solution using limitations. However, if the aim is to deploy an solution using
additional SSRCs that contains several sets of RTP streams with additional SSRCs that contains several sets of RTP streams with
different properties (encoding/packetization parameter, bit-rate, different properties (encoding/packetization parameter, bit-rate,
etc.), putting each set in a different RTP session would directly etc.), putting each set in a different RTP session would directly
skipping to change at page 41, line 34 skipping to change at page 42, line 22
to be loosened in order to use SDP to describe RTP sessions to be loosened in order to use SDP to describe RTP sessions
containing multiple MIME top level types. containing multiple MIME top level types.
[I-D.ietf-mmusic-sdp-bundle-negotiation] describes how to let [I-D.ietf-mmusic-sdp-bundle-negotiation] describes how to let
multiple SDP media descriptions use a single underlying transport in multiple SDP media descriptions use a single underlying transport in
SDP, which allows to define one RTP session with media types having SDP, which allows to define one RTP session with media types having
different MIME top level types. different MIME top level types.
B.3. Signalling RTP Stream Usage B.3. Signalling RTP Stream Usage
RTP streams being transported in RTP has some particular usage in an RTP streams being transported in RTP have some particular usage in an
RTP application. This usage of the RTP stream is in many RTP application. This usage of the RTP stream is in many
applications so far implicitly signalled. For example, an applications so far implicitly signalled. For example, an
application might choose to take all incoming audio RTP streams, mix application might choose to take all incoming audio RTP streams, mix
them and play them out. However, in more advanced applications that them and play them out. However, in more advanced applications that
use multiple RTP streams there will be more than a single usage or use multiple RTP streams there will be more than a single usage or
purpose among the set of RTP streams being sent or received. RTP purpose among the set of RTP streams being sent or received. RTP
applications will need to signal this usage somehow. The signalling applications will need to signal this usage somehow. The signalling
used will have to identify the RTP streams affected by their RTP- used will have to identify the RTP streams affected by their RTP-
level identifiers, which means that they have to be identified either level identifiers, which means that they have to be identified either
by their session or by their SSRC + session. by their session or by their SSRC + session.
skipping to change at page 43, line 4 skipping to change at page 43, line 39
Email: csp@csperkins.org Email: csp@csperkins.org
Harald Tveit Alvestrand Harald Tveit Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
Stockholm 11122 Stockholm 11122
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
Roni Even Roni Even
Huawei
Email: roni.even@huawei.com Email: ron.even.tlv@gmail.com
 End of changes. 69 change blocks. 
204 lines changed or deleted 229 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/