draft-ietf-avtcore-multiplex-guidelines-08.txt | draft-ietf-avtcore-multiplex-guidelines-09.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: June 17, 2019 C. Perkins | Expires: January 23, 2020 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
H. Alvestrand | H. Alvestrand | |||
R. Even | R. Even | |||
Huawei | Huawei | |||
December 14, 2018 | July 22, 2019 | |||
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-08 | draft-ietf-avtcore-multiplex-guidelines-09 | |||
Abstract | Abstract | |||
The Real-time Transport Protocol (RTP) is a flexible protocol that | The Real-time Transport Protocol (RTP) is a flexible protocol that | |||
can be used in a wide range of applications, networks, and system | can be used in a wide range of applications, networks, and system | |||
topologies. That flexibility makes for wide applicability, but can | topologies. That flexibility makes for wide applicability, but can | |||
complicate the application design process. One particular design | complicate the application design process. One particular design | |||
question that has received much attention is how to support multiple | question that has received much attention is how to support multiple | |||
media streams in RTP. This memo discusses the available options and | media streams in RTP. This memo discusses the available options and | |||
design trade-offs, and provides guidelines on how to use the | design trade-offs, and provides guidelines on how to use the | |||
skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 17, 2019. | This Internet-Draft will expire on January 23, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 36 ¶ | skipping to change at page 2, line 36 ¶ | |||
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 . . . . . . . . . . . . . . . . . . 10 | |||
3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 | 3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 | |||
3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 12 | 3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 12 | |||
3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 13 | 3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 13 | |||
3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 15 | 3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 14 | |||
3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15 | 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 14 | |||
3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17 | 3.4.4. Forward Error Correction . . . . . . . . . . . . . . 16 | |||
4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17 | 4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17 | |||
4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 | 4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 | |||
4.1.1. Application Interworking . . . . . . . . . . . . . . 17 | 4.1.1. Application Interworking . . . . . . . . . . . . . . 17 | |||
4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18 | 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 17 | |||
4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 | 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 | |||
4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 | 4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 | |||
4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 | 4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 | |||
4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 | 4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 | |||
4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 21 | 4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 20 | |||
4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 | 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 | |||
4.3. Security and Key Management Considerations . . . . . . . 24 | 4.3. Security and Key Management Considerations . . . . . . . 23 | |||
4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 | 4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 | |||
4.3.2. Key Management for Multi-party sessions . . . . . . . 25 | 4.3.2. Key Management for Multi-party Sessions . . . . . . . 24 | |||
4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 | 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 | |||
5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26 | 5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 25 | |||
5.1. Multiple Media Types in one Session . . . . . . . . . . . 26 | 5.1. Multiple Media Types in One Session . . . . . . . . . . . 25 | |||
5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27 | 5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27 | |||
5.3. Multiple Sessions for one Media type . . . . . . . . . . 28 | 5.3. Multiple Sessions for One Media Type . . . . . . . . . . 28 | |||
5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 29 | 5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 29 | |||
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 33 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 | |||
Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 37 | 11.2. Informative References . . . . . . . . . . . . . . . . . 35 | |||
Appendix B. Signalling Considerations . . . . . . . . . . . . . 39 | Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 38 | |||
Appendix B. Signalling Considerations . . . . . . . . . . . . . 40 | ||||
B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40 | B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40 | |||
B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 40 | B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 41 | |||
B.3. Signalling RTP stream Usage . . . . . . . . . . . . . . . 41 | B.3. Signalling RTP Stream Usage . . . . . . . . . . . . . . . 41 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used | The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used | |||
protocol for real-time media transport. It is a protocol that | protocol for real-time media transport. It is a protocol that | |||
provides great flexibility and can support a large set of different | provides great flexibility and can support a large set of different | |||
applications. RTP was from the beginning designed for multiple | applications. RTP was from the beginning designed for multiple | |||
participants in a communication session. It supports many topology | participants in a communication session. It supports many topology | |||
paradigms and usages, as defined in [RFC7667]. RTP has several | paradigms and usages, as defined in [RFC7667]. RTP has several | |||
multiplexing points designed for different purposes. These enable | multiplexing points designed for different purposes. These enable | |||
support of multiple RTP streams and switching between different | support of multiple RTP streams and switching between different | |||
encoding or packetization of the media. By using multiple RTP | encoding or packetization of the media. By using multiple RTP | |||
sessions, sets of RTP streams can be structured for efficient | sessions, sets of RTP streams can be structured for efficient | |||
processing or identification. Thus, the question for any RTP | processing or identification. Thus, an RTP application designer | |||
application designer is how to best use the RTP session, the RTP | needs to understand how to best use the RTP session, the RTP stream | |||
stream identifier (SSRC), and the RTP payload type to meet the | identifier (SSRC), and the RTP payload type to meet the application's | |||
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 has also | some implementations, RTP/RTCP extensions, and signalling have also | |||
been exposed. The authors also hope that clarification on the | been exposed. The authors hope that clarification on the usefulness | |||
usefulness of some functionalities in RTP will result in more | of some functionalities in RTP will result in more complete | |||
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 that come | 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 recommend against some usages as being unsuitable, in general or | will provide some guidelines and recommend against some usages as | |||
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 | |||
existing RTP functionalities around multiplexing. Both the desired | existing RTP functionalities around multiplexing. Both the desired | |||
behaviour and the implications of a particular behaviour depend on | behaviour and the implications of a particular behaviour depend on | |||
which topologies are used, which requires some consideration. This | which topologies are used, which requires some consideration. This | |||
is followed by a discussion of some choices in multiplexing behaviour | is followed by a discussion of some choices in multiplexing behaviour | |||
and their impacts. Some designs of RTP usage are discussed. | and their impacts. Some designs of RTP usage are discussed. | |||
Finally, some guidelines and examples are provided. | Finally, some guidelines and examples are provided. | |||
2. Definitions | 2. Definitions | |||
skipping to change at page 4, line 41 ¶ | skipping to change at page 4, line 41 ¶ | |||
In this document, it will be used to refer to situations where | In this document, it will be used to refer to situations where | |||
more than two endpoints communicate. | more than two endpoints communicate. | |||
Multiplexing: The operation of taking multiple entities as input, | Multiplexing: The operation of taking multiple entities as input, | |||
aggregating them onto some common resource while keeping the | aggregating them onto some common resource while keeping the | |||
individual entities addressable such that they can later be fully | individual entities addressable such that they can later be fully | |||
and unambiguously separated (de-multiplexed) again. | and unambiguously separated (de-multiplexed) again. | |||
RTP Receiver: An Endpoint or Middlebox receiving RTP streams and | RTP Receiver: An Endpoint or Middlebox receiving RTP streams and | |||
RTCP messages. It uses at least one SSRC to send RTCP messages. | RTCP messages. It uses at least one SSRC to send RTCP messages. | |||
An RTP Receiver may also be an RTP sender. | An RTP Receiver may also be an RTP Sender. | |||
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 SR timing information derived from a common clock | |||
such that they can be synchronised for playout. | 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 | |||
intended to be 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 | |||
that involve signalling protocols, such as whether SIP, Jingle or | that involve signalling protocols, such as whether SIP [RFC3261], | |||
some other protocol is in use for session configuration, the | Jingle [JINGLE] or some other protocol is in use for session | |||
particular syntaxes used to define RTP session properties, or the | configuration, the particular syntaxes used to define RTP session | |||
constraints imposed by particular choices in the signalling | properties, or the constraints imposed by particular choices in the | |||
protocols, are mentioned only as examples in order to describe the | signalling protocols, are mentioned only as examples in order to | |||
RTP issues more precisely. | describe the RTP issues more precisely. | |||
This document assumes the applications will use RTCP. While there | This document assumes the applications will use RTCP. While there | |||
are applications that don't send RTCP, they do not conform to the RTP | are applications that don't send RTCP, they do not conform to the RTP | |||
specification, and thus can be regarded as reusing the RTP packet | specification, and thus can be regarded as reusing the RTP packet | |||
format but not implementing the RTP protocol. | format but not implementing the RTP protocol. | |||
3. RTP Multiplexing Overview | 3. RTP Multiplexing Overview | |||
3.1. Reasons for Multiplexing and Grouping RTP Streams | 3.1. Reasons for Multiplexing and Grouping RTP Streams | |||
skipping to change at page 5, line 45 ¶ | skipping to change at page 5, line 45 ¶ | |||
are not limited to the following: | are not limited to the following: | |||
o Multiple media sources | o Multiple media sources | |||
o Multiple RTP streams might be needed to represent one media source | o Multiple RTP streams might be needed to represent one media source | |||
(for instance when using layered encodings) | (for instance when using layered encodings) | |||
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 An FEC stream might provide material that can be used to repair | o A Forward Error Correction (FEC) stream might provide material | |||
another RTP stream | that can be used to repair another RTP stream | |||
o Alternative encodings, for instance using different codecs for the | o Alternative encodings, for instance using different codecs for the | |||
same audio stream | same audio stream | |||
o Alternative formats, for instance multiple resolutions of the same | o Alternative formats, for instance multiple resolutions of the same | |||
video stream | video stream | |||
For each of these reasons, it is necessary to decide if each | For each of these reasons, it is necessary to decide if each | |||
additional RTP stream is sent within the same RTP session as the | additional RTP stream is sent within the same RTP session as the | |||
other RTP streams, or if it is necessary to use additional RTP | other RTP streams, or if it is necessary to use additional RTP | |||
sessions to group the RTP streams. The choice suitable for one | sessions to group the RTP streams. The choice suitable for one | |||
reason, might not be the choice suitable for another reason. The | reason, might not be the choice suitable for another reason. The | |||
clearest understanding is associated with multiplexing multiple media | clearest understanding is associated with multiplexing multiple media | |||
sources of the same media type. However, all reasons warrant | sources of the same media type. However, all reasons warrant | |||
discussion and clarification on how to deal with them. As the | discussion and clarification on how to deal with them. As the | |||
discussion below will show, in reality we cannot choose a single one | discussion below will show, in reality we cannot choose a single one | |||
of SSRC or RTP session multiplexing solutions. To utilise RTP well | of SSRC or RTP session multiplexing solutions for all purposes. To | |||
and as efficiently as possible, both are needed. The real issue is | utilise RTP well and as efficiently as possible, both are needed. | |||
finding the right guidance on when to create additional RTP sessions | The real issue is finding the right guidance on when to create | |||
and when additional RTP streams in the same RTP session is the right | additional RTP sessions and when additional RTP streams in the same | |||
choice. | 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: | incoming RTP streams starting already at the socket representing | |||
reception of one or transport flows, e.g. an UDP destination port. | ||||
It also demultiplexes RTP/RTCP from any other protocols, such as STUN | ||||
[RFC5389] and DTLS-SRTP [RFC5764] on the same transport as described | ||||
in [RFC7983]. | ||||
| | | | |||
| packets | | packets | |||
+-- v | +-- v | |||
| +------------+ | | +------------+ | |||
| | Socket | Transport Protocol Demultiplexing | | | Socket | Transport Protocol Demultiplexing | |||
| +------------+ | | +------------+ | |||
| || || | | || || | |||
RTP | RTP/ || |+-----> SCTP ( ...and any other protocols) | RTP | RTP/ || |+-----> DTLS (SRTP Keying, SCTP, etc) | |||
Session | RTCP || +------> STUN (multiplexed using same port) | Session | RTCP || +------> STUN (multiplexed using same port) | |||
+-- || | +-- || | |||
+-- || | +-- || | |||
| (split by SSRC) | | (split by SSRC) | |||
| || || || | | || || || | |||
| || || || | | || || || | |||
RTP | +--+ +--+ +--+ | RTP | +--+ +--+ +--+ | |||
Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, etc. | Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, etc. | |||
| +--+ +--+ +--+ | | +--+ +--+ +--+ | |||
+-- | | | | +-- | | | | |||
skipping to change at page 7, line 36 ¶ | skipping to change at page 7, line 36 ¶ | |||
| / | | | | / | | | |||
Payload | +---+ +---+ +---+ | Payload | +---+ +---+ +---+ | |||
Formats | |Dec| |Dec| |Dec| Decoders | Formats | |Dec| |Dec| |Dec| Decoders | |||
| +---+ +---+ +---+ | | +---+ +---+ +---+ | |||
+-- | +-- | |||
Figure 1: RTP Demultiplexing Process | Figure 1: RTP Demultiplexing Process | |||
3.2.1. RTP Session | 3.2.1. RTP Session | |||
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 RTP sessions must be | RTP does not contain a session identifier, yet different RTP sessions | |||
possible to separate both across different endpoints and within a | must be possible to identify both across different endpoints and | |||
single endpoint. | within 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., | |||
skipping to change at page 8, line 14 ¶ | skipping to change at page 8, line 14 ¶ | |||
[RFC5576]). Thus, the scope of an RTP session is determined by the | [RFC5576]). Thus, the scope of an RTP session is determined by the | |||
participants' network interconnection topology, in combination with | participants' network interconnection topology, in combination with | |||
RTP and RTCP forwarding strategies deployed by the endpoints and any | RTP and RTCP forwarding strategies deployed by the endpoints and any | |||
middleboxes, and by the signalling. | middleboxes, and by the signalling. | |||
For RTP session separation within a single endpoint, RTP relies on | For RTP session separation within a single endpoint, RTP relies on | |||
the underlying transport layer, and on the signalling to identify RTP | the underlying transport layer, and on the signalling to identify RTP | |||
sessions in a manner that is meaningful to the application. A single | sessions in a manner that is meaningful to the application. A single | |||
endpoint can have one or more transport flows for the same RTP | endpoint can have one or more transport flows for the same RTP | |||
session, and a single RTP session can span multiple transport layer | session, and a single RTP session can therefore span multiple | |||
flows. The signalling layer might give RTP sessions an explicit | transport layer flows even if all endpoints use a single transport | |||
identifier, or the identification might be implicit based on the | layer flow per endpoint for that RTP session. The signalling layer | |||
addresses and ports used. Accordingly, a single RTP session can have | might give RTP sessions an explicit identifier, or the identification | |||
multiple associated identifiers, explicit and implicit, belonging to | might be implicit based on the addresses and ports used. | |||
different contexts. For example, when running RTP on top of UDP/IP, | Accordingly, a single RTP session can have multiple associated | |||
an endpoint can identify and delimit an RTP session from other RTP | identifiers, explicit and implicit, belonging to different contexts. | |||
sessions by receiving the multiple UDP flows used as identified based | For example, when running RTP on top of UDP/IP, an endpoint can | |||
on their UDP source and destination IP addresses and UDP port | identify and delimit an RTP session from other RTP sessions by their | |||
numbers. Another example is SDP media descriptions (the "m=" line | UDP source and destination IP addresses and UDP port numbers. | |||
and the following associated lines) signals the transport flow and | Independently if an endpoint has one or more IP addresses, a single | |||
RTP session configuration for the endpoints part of the RTP session. | RTP session can be using multiple IP/UDP flows for receiving and/or | |||
SDP grouping framework [RFC5888] allows labeling of the media | sending RTP packets to other endpoints or middleboxes. Another | |||
descriptions, for example used so that RTP Session Groups can be | example is SDP media descriptions (the "m=" line and the following | |||
created. With Negotiating Media Multiplexing Using the Session | associated lines) that signals the transport flow and RTP session | |||
Description Protocol (SDP)[I-D.ietf-mmusic-sdp-bundle-negotiation], | configuration for the endpoint's part of the RTP session. The SDP | |||
multiple media descriptions where each represents the RTP streams | grouping framework [RFC5888] allows labeling of the media | |||
sent or received for a media source are part of a common RTP session. | descriptions to be used so that RTP Session Groups can be created. | |||
Through use of Negotiating Media Multiplexing Using the Session | ||||
Description Protocol (SDP) [I-D.ietf-mmusic-sdp-bundle-negotiation], | ||||
multiple media descriptions become part of a common RTP session where | ||||
each media description represents the RTP streams sent or received | ||||
for a media source. | ||||
The RTP protocol makes no normative statements about the relationship | The RTP protocol makes no normative statements about the relationship | |||
between different RTP sessions, however the applications that use | between different RTP sessions, however the applications that use | |||
more than one RTP session will have some higher layer understanding | more than one RTP session will have some higher layer understanding | |||
of the relationship between the sessions they create. | of the relationship between the sessions they create. | |||
3.2.2. Synchronisation Source (SSRC) | 3.2.2. Synchronisation Source (SSRC) | |||
A synchronisation source (SSRC) identifies an 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 SSRC | Endpoints that are both RTP sender and RTP receiver use the same SSRC | |||
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 | |||
skipping to change at page 9, line 4 ¶ | skipping to change at page 9, line 9 ¶ | |||
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 SSRC | Endpoints that are both RTP sender and RTP receiver use the same SSRC | |||
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 | |||
during a session have to choose a new SSRC identifier to avoid being | during a session has to choose a new SSRC identifier to avoid being | |||
interpreted as looped source, unless the transport layer mechanism, | interpreted as looped source, unless the transport layer mechanism, | |||
e.g ICE [RFC8445], handles such changes. | e.g ICE [RFC8445], handles such changes. | |||
SSRC identifiers that belong to the same synchronisation context | SSRC identifiers that belong to the same synchronisation context | |||
(i.e., that represent RTP streams that can be synchronised using | (i.e., that represent RTP streams that can be synchronised using | |||
information in RTCP SR packets) use identical CNAME chunks in | information in RTCP SR packets) use identical CNAME chunks in | |||
corresponding RTCP SDES packets. SDP signalling can also be used to | corresponding RTCP SDES packets. SDP signalling can also be used to | |||
provide explicit SSRC grouping [RFC5576]. | provide explicit SSRC grouping [RFC5576]. | |||
In some cases, the same SSRC identifier value is used to relate | In some cases, the same SSRC identifier value is used to relate | |||
streams in two different RTP sessions, such as in RTP retransmission | streams in two different RTP sessions, such as in RTP retransmission | |||
[RFC4588]. This is to be avoided since there is no guarantee that | [RFC4588]. This is to be avoided since there is no guarantee that | |||
SSRC values are unique across RTP sessions. For the RTP | SSRC values are unique across RTP sessions. For the RTP | |||
retransmission [RFC4588] case it is recommended to use explicit | retransmission [RFC4588] case it is recommended to use explicit | |||
binding of the source RTP stream and the redundancy stream, e.g. | binding of the source RTP stream and the redundancy stream, e.g. | |||
using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. | using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. | |||
Note that RTP sequence number and RTP timestamp are scoped by the | Note that RTP sequence number and RTP timestamp are scoped by the | |||
SSRC and thus specific per RTP stream. | SSRC and thus specific per RTP stream. | |||
Different types of entities use a 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. | |||
A conceptual media source: Uses the SSRC to identify the result of | A conceptual media source: Uses the SSRC to identify the result of | |||
applying some filtering function in a network node, for example a | applying some filtering function in a network node, for example a | |||
filtering function in an RTP mixer that provides the most active | filtering function in an RTP mixer that provides the most active | |||
speaker based on some criteria, or a mix representing a set of | speaker based on some criteria, or a mix representing a set of | |||
other sources. | other sources. | |||
An RTP receiver: Uses the SSRC to identify itself as the source of | An RTP receiver: Uses the SSRC to identify itself as the source of | |||
its RTCP reports. | its RTCP reports. | |||
Note that an endpoint that generates more than one media type, e.g. | An endpoint that generates more than one media type, e.g. a | |||
a conference participant sending both audio and video, need not (and | conference participant sending both audio and video, need not (and, | |||
should not) use the same SSRC value across RTP sessions. RTCP | indeed, should not) use the same SSRC value across RTP sessions. | |||
compound packets containing the CNAME SDES item is the designated | ||||
method to bind an SSRC to a CNAME, effectively cross-correlating | RTCP compound packets containing the CNAME SDES item is the | |||
SSRCs within and between RTP Sessions as coming from the same | designated method to bind an SSRC to a CNAME, effectively cross- | |||
endpoint. The main property attributed to SSRCs associated with the | correlating SSRCs within and between RTP Sessions as coming from the | |||
same CNAME is that they are from a particular synchronisation context | same endpoint. The main property attributed to SSRCs associated with | |||
and can be synchronised at playback. | the same CNAME is that they are from a particular synchronisation | |||
context and can be synchronised at playback. | ||||
An RTP receiver receiving a previously unseen SSRC value will | An RTP receiver receiving a previously unseen SSRC value will | |||
interpret it as a new source. It might in fact be a previously | interpret it as a new source. It might in fact be a previously | |||
existing source that had to change SSRC number due to an SSRC | existing source that had to change SSRC number due to an SSRC | |||
conflict. However, the originator of the previous SSRC ought to have | conflict. However, the originator of the previous SSRC ought to have | |||
ended the conflicting source by sending an RTCP BYE for it prior to | ended the conflicting source by sending an RTCP BYE for it prior to | |||
starting to send with the new SSRC, so the new SSRC is anyway | starting to send with the new SSRC, making the new SSRC a new source. | |||
effectively a new source. | ||||
3.2.3. Contributing Source (CSRC) | 3.2.3. Contributing Source (CSRC) | |||
The Contributing Source (CSRC) is not a separate identifier. Rather | The Contributing Source (CSRC) is not a separate identifier. Rather | |||
an SSRC identifier is listed as a CSRC in the RTP header of a packet | an SSRC identifier is listed as a CSRC in the RTP header of a packet | |||
generated by an RTP mixer, if the corresponding SSRC was in the | generated by an RTP mixer, if the corresponding SSRC was in the | |||
header of one of the packets that contributed to the mix. | header of one of the packets that contributed to the mix. | |||
It is not possible, in general, to extract media represented by an | It is not possible, in general, to extract media represented by an | |||
individual CSRC since it is typically the result of a media mixing | individual CSRC since it is typically the result of a media mixing | |||
skipping to change at page 10, line 38 ¶ | skipping to change at page 10, line 42 ¶ | |||
Mixer-to-Client Audio Level Indication [RFC6465] expands on the | Mixer-to-Client Audio Level Indication [RFC6465] expands on the | |||
receiver's information about a packet with a CSRC list. Due to these | receiver's information about a packet with a CSRC list. Due to these | |||
restrictions, CSRC will not be considered a fully qualified | restrictions, CSRC will not be considered a fully qualified | |||
multiplexing point and will be disregarded in the rest of this | multiplexing point and will be disregarded in the rest of this | |||
document. | document. | |||
3.2.4. RTP Payload Type | 3.2.4. RTP Payload Type | |||
Each RTP stream utilises one or more RTP payload formats. An RTP | Each RTP stream utilises one or more RTP payload formats. An RTP | |||
payload format describes how the output of a particular media codec | payload format describes how the output of a particular media codec | |||
is framed and encoded into RTP packets. The payload format used is | is framed and encoded into RTP packets. The payload format is | |||
identified by the payload type (PT) field in the RTP packet header. | identified by the payload type (PT) field in the RTP packet header. | |||
The combination of SSRC and PT therefore identifies a specific RTP | The combination of SSRC and PT therefore identifies a specific RTP | |||
stream encoding format. The format definition can be taken from | stream in a specific encoding format. The format definition can be | |||
[RFC3551] for statically allocated payload types, but ought to be | taken from [RFC3551] for statically allocated payload types, but | |||
explicitly defined in signalling, such as SDP, both for static and | ought to be explicitly defined in signalling, such as SDP, both for | |||
dynamic payload types. The term "format" here includes whatever can | static and dynamic payload types. The term "format" here includes | |||
be described by out-of-band signalling means. In SDP, the term | those aspects described by out-of-band signalling means; in SDP, the | |||
"format" includes media type, RTP timestamp sampling rate, codec, | term "format" includes media type, RTP timestamp sampling rate, | |||
codec configuration, payload format configurations, and various | codec, codec configuration, payload format configurations, and | |||
robustness mechanisms such as redundant encodings [RFC2198]. | various robustness mechanisms such as redundant encodings [RFC2198]. | |||
The RTP payload type is scoped by the sending endpoint within an RTP | The RTP payload type is scoped by the sending endpoint within an RTP | |||
session. PT has the same meaning across all RTP streams in an RTP | session. PT has the same meaning across all RTP streams in an RTP | |||
session. All SSRCs sent from a single endpoint share the same | session. All SSRCs sent from a single endpoint share the same | |||
payload type definitions. The RTP payload type is designed such that | payload type definitions. The RTP payload type is designed such that | |||
only a single payload type is valid at any time instant in the RTP | only a single payload type is valid at any time instant in the RTP | |||
stream's timestamp time line, effectively time-multiplexing different | stream's timestamp time line, effectively time-multiplexing different | |||
payload types if any change occurs. The payload type used can change | payload types if any change occurs. The payload type can change on a | |||
on a per-packet basis for an SSRC, for example a speech codec making | per-packet basis for an SSRC, for example a speech codec making use | |||
use of generic comfort noise [RFC3389]. If there is a true need to | of generic comfort noise [RFC3389]. If there is a true need to send | |||
send multiple payload types for the same SSRC that are valid for the | multiple payload types for the same SSRC that are valid for the same | |||
same instant, then redundant encodings [RFC2198] can be used. | instant, then redundant encodings [RFC2198] can be used. Several | |||
Several additional constraints than the ones mentioned above need to | additional constraints than the ones mentioned above need to be met | |||
be met to enable this use, one of which is that the combined payload | to enable this use, one of which is that the combined payload sizes | |||
sizes of the different payload types ought not exceed the transport | of the different payload types ought not exceed the transport MTU. | |||
MTU. If it is acceptable to send multiple formats of the same media | If it is acceptable to send multiple formats of the same media source | |||
source as separate RTP streams (with separate SSRC), simulcast | as separate RTP streams (with separate SSRC), simulcast | |||
[I-D.ietf-mmusic-sdp-simulcast] can be used. | [I-D.ietf-mmusic-sdp-simulcast] can be used. | |||
Other aspects of RTP payload format use are described in How to Write | Other aspects of RTP payload format use are described in How to Write | |||
an RTP Payload Format [RFC8088]. | an RTP Payload Format [RFC8088]. | |||
The payload type is not a multiplexing point at the RTP layer (see | The payload type is not a multiplexing point at the RTP layer (see | |||
Appendix A for a detailed discussion of why using the payload type as | Appendix A for a detailed discussion of why using the payload type as | |||
an RTP multiplexing point does not work). The RTP payload type is, | an RTP multiplexing point does not work). The RTP payload type is, | |||
however, used to determine how to consume and decode an RTP stream. | however, used to determine how to consume and decode an RTP stream. | |||
The RTP payload type number is sometimes used to associate an RTP | The RTP payload type number is sometimes used to associate an RTP | |||
skipping to change at page 12, line 32 ¶ | skipping to change at page 12, line 32 ¶ | |||
o Usage of different transport protocols, e.g., UDP, DCCP, or TCP. | o Usage of different transport protocols, e.g., UDP, DCCP, or TCP. | |||
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. If the | gateway, for example a need to monitor the RTP streams. Beware that | |||
stream transport characteristics are changed by the translator, | changing the stream transport characteristics in the translator, can | |||
appropriate media handling can require thorough understanding of the | require thorough understanding of the application logic, specifically | |||
application logic, specifically any congestion control or media | any congestion control or media adaptation to ensure appropriate | |||
adaptation. | media handling. | |||
The point to point topology can contain one to many RTP sessions with | Within the uses enabled by the RTP standard the point to point | |||
one to many media sources per session, each having one or more RTP | topology can contain one to many RTP sessions with one to many media | |||
streams per media source. | sources per session, each having one or more RTP streams per media | |||
source. | ||||
3.4. Issues Related to RTP and RTCP Protocol | 3.4. Issues Related to RTP and RTCP Protocol | |||
Using multiple RTP streams is a well-supported feature of RTP. | Using multiple RTP streams is a well-supported feature of RTP. | |||
However, for most implementers or people writing RTP/RTCP | However, for most implementers or people writing RTP/RTCP | |||
applications or extensions attempting to apply multiple streams, it | applications or extensions attempting to apply multiple streams, it | |||
can be unclear when it is most appropriate to add an additional RTP | can be unclear when it is most appropriate to add an additional RTP | |||
stream in an existing RTP session and when it is better to use | stream in an existing RTP session and when it is better to use | |||
multiple RTP sessions. This section discusses the various | multiple RTP sessions. This section discusses the various | |||
considerations needed. | considerations needed. | |||
3.4.1. The RTP Specification | 3.4.1. The RTP Specification | |||
RFC 3550 contains some recommendations and a bullet list with 5 | RFC 3550 contains some recommendations and a bullet list with 5 | |||
arguments for different aspects of RTP multiplexing. Let's review | arguments for different aspects of RTP multiplexing. Please review | |||
Section 5.2 of [RFC3550], reproduced below: | Section 5.2 of [RFC3550]. Five important aspects are quoted below. | |||
"For efficient protocol processing, the number of multiplexing points | ||||
should be minimised, as described in the integrated layer processing | ||||
design principle [ALF]. In RTP, multiplexing is provided by the | ||||
destination transport address (network address and port number) which | ||||
is different for each RTP session. For example, in a teleconference | ||||
composed of audio and video media encoded separately, each medium | ||||
SHOULD be carried in a separate RTP session with its own destination | ||||
transport address. | ||||
Separate audio and video streams SHOULD NOT be carried in a single | ||||
RTP session and demultiplexed based on the payload type or SSRC | ||||
fields. Interleaving packets with different RTP media types but | ||||
using the same SSRC would introduce several problems: | ||||
1. If, say, two audio streams shared the same RTP session and the | ||||
same SSRC value, and one were to change encodings and thus | ||||
acquire a different RTP payload type, there would be no general | ||||
way of identifying which stream had changed encodings. | ||||
2. An SSRC is defined to identify a single timing and sequence | ||||
number space. Interleaving multiple payload types would require | ||||
different timing spaces if the media clock rates differ and would | ||||
require different sequence number spaces to tell which payload | ||||
type suffered packet loss. | ||||
3. The RTCP sender and receiver reports (see Section 6.4) can only | ||||
describe one timing and sequence number space per SSRC and do not | ||||
carry a payload type field. | ||||
4. An RTP mixer would not be able to combine interleaved streams of | ||||
incompatible media into one stream. | ||||
5. Carrying multiple media in one RTP session precludes: the use of | ||||
different network paths or network resource allocations if | ||||
appropriate; reception of a subset of the media if desired, for | ||||
example just audio if video would exceed the available bandwidth; | ||||
and receiver implementations that use separate processes for the | ||||
different media, whereas using separate RTP sessions permits | ||||
either single- or multiple-process implementations. | ||||
Using a different SSRC for each medium but sending them in the same | 1. If, say, two audio streams shared the same RTP session and the | |||
RTP session would avoid the first three problems but not the last | same SSRC value, and one were to change encodings and thus acquire | |||
two. | a different RTP payload type, there would be no general way of | |||
identifying which stream had changed encodings. | ||||
On the other hand, multiplexing multiple related sources of the same | The first argument is to use different SSRC for each individual RTP | |||
medium in one RTP session using different SSRC values is the norm for | stream, which is fundamental to RTP operation. | |||
multicast sessions. The problems listed above don't apply: an RTP | ||||
mixer can combine multiple audio sources, for example, and the same | ||||
treatment is applicable for all of them. It might also be | ||||
appropriate to multiplex streams of the same medium using different | ||||
SSRC values in other scenarios where the last two problems do not | ||||
apply." | ||||
Let's consider one argument at a time. The first argument is for | 2. An SSRC is defined to identify a single timing and sequence number | |||
using different SSRC for each individual RTP stream, which is | space. Interleaving multiple payload types would require | |||
fundamental to RTP operation. | different timing spaces if the media clock rates differ and would | |||
require different sequence number spaces to tell which payload | ||||
type suffered packet loss. | ||||
The second argument is advocating against demultiplexing RTP streams | The second argument is advocating against demultiplexing RTP streams | |||
within a session based on their RTP payload type numbers, which still | within a session based only on their RTP payload type numbers, which | |||
stands as can been seen by the extensive list of issues found in | still stands as can been seen by the extensive list of issues found | |||
Appendix A. | in Appendix A. | |||
3. The RTCP sender and receiver reports (see Section 6.4) can only | ||||
describe one timing and sequence number space per SSRC and do not | ||||
carry a payload type field. | ||||
The third argument is yet another argument against payload type | The third argument is yet another argument against payload type | |||
multiplexing. | multiplexing. | |||
4. An RTP mixer would not be able to combine interleaved streams of | ||||
incompatible media into one stream. | ||||
The fourth argument is against multiplexing RTP packets that require | The fourth argument is against multiplexing RTP packets that require | |||
different handling into the same session. As we saw in the | different handling into the same session. In most cases the RTP | |||
discussion of RTP mixers, the RTP mixer must embed application logic | mixer must embed application logic to handle streams; the separation | |||
to handle streams anyway; the separation of streams according to | of streams according to stream type is just another piece of | |||
stream type is just another piece of application logic, which might | application logic, which might or might not be appropriate for a | |||
or might not be appropriate for a particular application. One type | particular application. One type of application that can mix | |||
of application that can mix different media sources "blindly" is the | different media sources blindly is the audio-only telephone bridge, | |||
audio-only "telephone" bridge; most other types of applications need | although the ability to do that comes from the well-defined scenario | |||
application-specific logic to perform the mix correctly. | that is aided by use of a single media type, even though individual | |||
streams may use incompatible codec types; most other types of | ||||
applications need application-specific logic to perform the mix | ||||
correctly. | ||||
The fifth argument discusses network aspects that we will discuss | 5. Carrying multiple media in one RTP session precludes: the use of | |||
more below in Section 4.2. It also goes into aspects of | different network paths or network resource allocations if | |||
implementation, like Split Component Terminal (see Section 3.10 of | appropriate; reception of a subset of the media if desired, for | |||
[RFC7667]) endpoints where different processes or inter-connected | example just audio if video would exceed the available bandwidth; | |||
devices handle different aspects of the whole multi-media session. | and receiver implementations that use separate processes for the | |||
different media, whereas using separate RTP sessions permits | ||||
either single- or multiple-process implementations. | ||||
The fifth argument discusses network aspects that are described in | ||||
Section 4.2. It also goes into aspects of implementation, like Split | ||||
Component Terminal (see Section 3.10 of [RFC7667]) endpoints where | ||||
different processes or inter-connected devices handle different | ||||
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 | provides a detailed analysis of the potential issues in having | |||
multiple media types in the same RTP session. This document provides | multiple media types in the same RTP session. This document provides | |||
skipping to change at page 15, line 47 ¶ | skipping to change at page 15, line 20 ¶ | |||
o Grouping SSRCs within an RTP session | o Grouping SSRCs within an RTP session | |||
Most solutions are explicit, but some implicit methods have also been | Most solutions are explicit, but some implicit methods have also been | |||
applied to the problem. | applied to the problem. | |||
The SDP-based signalling solutions are: | The SDP-based signalling solutions are: | |||
SDP Media Description Grouping: The SDP Grouping Framework [RFC5888] | SDP Media Description Grouping: The SDP Grouping Framework [RFC5888] | |||
uses various semantics to group any number of media descriptions. | uses various semantics to group any number of media descriptions. | |||
These has previously been considered primarily as grouping RTP | This has previously been considered primarily as grouping RTP | |||
sessions, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple | sessions, but [I-D.ietf-mmusic-sdp-bundle-negotiation] groups | |||
media descriptions as a single RTP session. | multiple media descriptions as a single RTP session. | |||
SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576] | SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576] | |||
includes a solution for grouping SSRCs the same way as the | includes a solution for grouping SSRCs the same way as the | |||
Grouping framework groups Media Descriptions. | Grouping framework groups Media Descriptions. | |||
This supports a lot of use cases. All these solutions have | The above grouping constructs support many use cases. Those | |||
shortcomings in cases where the session's dynamic properties are such | solutions have shortcomings in cases where the session's dynamic | |||
that it is difficult or resource consuming to keep the list of | properties are such that it is difficult or a drain on resources to | |||
related SSRCs up to date. | keep the list of related SSRCs up to date. | |||
An RTP/RTCP-based solution is to use the RTCP SDES CNAME to bind the | An RTP/RTCP-based grouping solution is to use the RTCP SDES CNAME to | |||
RTP streams to an endpoint or synchronization context. For | bind related RTP streams to an endpoint or to a synchronization | |||
applications with a single RTP stream per type (Media, Source or | context. For applications with a single RTP stream per type (media, | |||
Redundancy) this is sufficient independent if one or more RTP | source or redundancy stream), CNAME is sufficient for that purpose | |||
sessions are used. However, some applications choose not to use it | independent if one or more RTP sessions are used. However, some | |||
because of perceived complexity or a desire not to implement RTCP and | applications choose not to use CNAME because of perceived complexity | |||
instead use the same SSRC value to bind related RTP streams across | or a desire not to implement RTCP and instead use the same SSRC value | |||
multiple RTP sessions. RTP Retransmission [RFC4588] in multiple RTP | to bind related RTP streams across multiple RTP sessions. RTP | |||
session mode and Generic FEC [RFC5109] both use this method. This | Retransmission [RFC4588] in multiple RTP session mode and Generic FEC | |||
method may work but might have some downsides in RTP sessions with | [RFC5109] both use the CNAME method to relate the RTP streams, which | |||
many participating SSRCs. When an SSRC collision occurs, this will | may work but might have some downsides in RTP sessions with many | |||
force one to change SSRC in all RTP sessions and thus resynchronize | participating SSRCs. It is not recommended to use identical SSRC | |||
all of them instead of only the single media stream having the | values across RTP sessions to relate RTP streams; When an SSRC | |||
collision. Therefore, it is not recommended to use identical SSRC | collision occurs, this will force change of that SSRC in all RTP | |||
values to relate RTP streams. | sessions and thus resynchronize all of them instead of only the | |||
single media stream having the collision. | ||||
Another solution to bind SSRCs is an implicit method used by RTP | Another method to implicitly bind SSRCs is used by RTP Retransmission | |||
Retransmission [RFC4588] when doing retransmissions in the same RTP | [RFC4588] when using the same RTP session as the source RTP stream | |||
session as the source RTP stream. The receiver missing a packet | for retransmissions. The receiver missing a packet issues an RTP | |||
issues an RTP retransmission request, and then awaits a new SSRC | retransmission request, and then awaits a new SSRC carrying the RTP | |||
carrying the RTP retransmission payload and where that SSRC is from | retransmission payload and where that SSRC is from the same CNAME. | |||
the same CNAME. This limits a requester to having only one | This limits a requester to having only one outstanding retransmission | |||
outstanding request on any new source SSRCs per endpoint. | request on any new source SSRCs per endpoint. | |||
RTP Payload Format Restrictions [I-D.ietf-mmusic-rid] provides an | RTP Payload Format Restrictions [I-D.ietf-mmusic-rid] provides an | |||
RTP/RTCP based mechanism to unambiguously identify the RTP streams | RTP/RTCP based mechanism to unambiguously identify the RTP streams | |||
within an RTP session and restrict the streams' payload format | within an RTP session and restrict the streams' payload format | |||
parameters in a codec-agnostic way beyond what is provided with the | parameters in a codec-agnostic way beyond what is provided with the | |||
regular Payload Types. The mapping is done by specifying an "a=rid" | regular payload types. The mapping is done by specifying an "a=rid" | |||
value in the SDP offer/answer signalling and having the corresponding | value in the SDP offer/answer signalling and having the corresponding | |||
"rtp-stream-id" value as an SDES item and an RTP header extension. | RtpStreamId value as an SDES item and an RTP header extension. The | |||
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. | |||
It can be noted that Section 8.3 of the RTP Specification [RFC3550] | Section 8.3 of the RTP Specification [RFC3550] recommends using a | |||
recommends using a single SSRC space across all RTP sessions for | single SSRC space across all RTP sessions for layered coding. Based | |||
layered coding. Based on the experience so far however, we recommend | on the experience so far however, we recommend to use a solution with | |||
to use a solution doing explicit binding between the RTP streams so | explicit binding between the RTP streams that is agnostic to the used | |||
what the used SSRC values are do not matter. That way solutions | SSRC values. That way, solutions using multiple RTP streams in a | |||
using multiple RTP streams in a single RTP session and multiple RTP | single RTP session and in multiple RTP sessions will use the same | |||
sessions uses the same solution. | 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 reduce the packet loss of the original streams. Most of | |||
the FEC schemes will protect a single source flow. The protection is | the FEC schemes protects a single source flow. The protection is | |||
achieved by transmitting a certain amount of redundant information | achieved by transmitting a certain amount of redundant information | |||
that is encoded such that it can repair one or more packet losses | that is encoded such that it can repair one or more packet losses | |||
over the set of packets the redundant information protects. This | over the set of packets the redundant information protects. This | |||
sequence of redundant information also needs to be transmitted as its | sequence of redundant information needs to be transmitted as its own | |||
own media stream, or in some cases, instead of the original media | media stream, or in some cases, instead of the original media stream. | |||
stream. Thus, many of these schemes create a need for binding | Thus, many of these schemes create a need for binding related flows | |||
related flows as discussed above. Looking at the history of these | as discussed above. Looking at the history of these schemes, there | |||
schemes, there are schemes using multiple SSRCs and schemes using | are schemes using multiple SSRCs and schemes using multiple RTP | |||
multiple RTP sessions, and some schemes that support both modes of | sessions, and some schemes that support both modes of operation. | |||
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 transport | |||
level. | 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 very heterogeneous packet loss rates. | useful when receivers see heterogeneous packet loss rates. A | |||
Those receivers that are not seeing packet loss don't need to join | receiver can based on measurment of experienced packet loss decide to | |||
the multicast group with the FEC data, and so avoid the overhead of | join a multicast group with the suitable FEC data repair | |||
receiving unnecessary FEC packets, for example. | 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 between different applications including | discusses two; interworking directly between different applications, | |||
the implications of potentially different RTP multiplexing point | and interworking of applications through an RTP Translator. The | |||
choices and limitations that have to be considered when working with | discussion includes the implications of potentially different RTP | |||
some legacy applications. | multiplexing point choices and limitations that have to be considered | |||
when working with some legacy applications. | ||||
4.1.1. Application Interworking | 4.1.1. Application Interworking | |||
It is not uncommon that applications or services of similar but not | It is not uncommon that applications or services of similar but not | |||
identical usage, especially the ones intended for interactive | identical usage, especially the ones intended for interactive | |||
communication, encounter a situation where one want to interconnect | communication, encounter a situation where one want to interconnect | |||
two or more of these applications. | two or more of these applications. | |||
In these cases, one ends up in a situation where one might use a | In these cases, one ends up in a situation where one might use a | |||
gateway to interconnect applications. This gateway must then either | gateway to interconnect applications. This gateway must then either | |||
change the multiplexing structure or adhere to the respective | change the multiplexing structure or adhere to the respective | |||
limitations in each application. | limitations in each application. | |||
There are two fundamental approaches to building a gateway: using an | There are two fundamental approaches to building a gateway: using RTP | |||
RTP Translator interworking (RTP bridging), where the gateway acts as | Translator interworking (RTP bridging), where the gateway acts as an | |||
an RTP Translator, with the two applications being members of the | RTP Translator with the two interconnected applications being members | |||
same RTP session; or Gateway Interworking with RTP termination, where | of the same RTP session; or using Gateway Interworking with RTP | |||
there are independent RTP sessions running from each interconnected | termination, where there are independent RTP sessions between each | |||
application to the gateway. | interconnected application and the gateway. | |||
4.1.2. RTP Translator Interworking | 4.1.2. RTP Translator Interworking | |||
From an RTP perspective, the RTP Translator approach could work if | 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, it is possible for the RTP translator to map the RTP streams | BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], it is possible for | |||
between both sides if the order of SDP "m=" lines between both sides | the RTP translator to map the RTP streams between both sides using | |||
are the same. There are also challenges with SSRC collision handling | some method, e.g. if the number and order of SDP "m=" lines between | |||
since there may be a collision on the SSRC multiplexing side but the | both sides are the same. There are also challenges with SSRC | |||
RTP session multiplexing side will not be aware of any collision | collision handling since, unless SSRC translation is applied on the | |||
unless SSRC translation is applied on the RTP translator. | RTP translator, there may be a collision on the SSRC multiplexing | |||
side 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 no participants are using the less | can be successful, even if none of the participants are using the | |||
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 uses 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 incoming packets and | of SRTP, the gateway needs to be able to decrypt and verify source | |||
re-encrypt them in the other application's security context. This is | integrity of the incoming packets, and re-encrypt, integrity protect, | |||
necessary even if all that's needed is a simple remapping of SSRC | and sign the packets as peer in the other application's security | |||
numbers. If this is done, the gateway also needs to be a member of | context. This is necessary even if all that's needed is a simple | |||
the security contexts of both sides, of course. | 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. | ||||
Other tasks a gateway might need to apply include transcoding (for | The gateway might also need to apply transcoding (for incompatible | |||
incompatible codec types), media-level adaptations that cannot be | codec types), media-level adaptations that cannot be solved through | |||
solved through media negotiation (such as rescaling for incompatible | media negotiation (such as rescaling for incompatible video size | |||
video size requirements), suppression of content that is known not to | requirements), suppression of content that is known not to be handled | |||
be handled in the destination application, or the addition or removal | in the destination application, or the addition or removal of | |||
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. | |||
This fact reveals the potential for these gateways to block | These gateways might therefore potentially block application | |||
application evolution by blocking RTP and RTCP extensions that the | evolution by blocking RTP and RTCP extensions that the applications | |||
applications have been extended with but that are unknown to the | have been extended with but that are unknown to the gateway. | |||
gateway. | ||||
If one uses security functions, like SRTP, and as can be seen from | If one uses security functions, like SRTP, and as can be seen from | |||
above, they incur both additional risk due to the requirement to have | above, they incur both additional risk due to the requirement to have | |||
the gateway in the security association between the endpoints (unless | the gateway in the security association between the endpoints (unless | |||
the gateway is on the transport level), and additional complexities | the gateway is on the transport level), and additional complexities | |||
in form of the decrypt-encrypt cycles needed for each forwarded | in form of the decrypt-encrypt cycles needed for each forwarded | |||
packet. SRTP, due to its keying structure, also requires that each | packet. SRTP, due to its keying structure, also requires that each | |||
RTP session needs different master keys, as use of the same key in | RTP session needs different master keys, as use of the same key in | |||
two RTP sessions can for some ciphers result in two-time pads that | two RTP sessions can for some ciphers result in two-time pads that | |||
completely breaks the confidentiality of the packets. | completely breaks the confidentiality of the packets. | |||
4.1.4. Multiple SSRC Legacy Considerations | 4.1.4. Multiple SSRC Legacy Considerations | |||
Historically, the most common RTP use cases have been point to point | Historically, the most common RTP use cases have been point-to-point | |||
Voice over IP (VoIP) or streaming applications, commonly with no more | Voice over IP (VoIP) or streaming applications, commonly with no more | |||
than one media source per endpoint and media type (typically audio 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 with a | the conference focus or bridge has provided a single stream to each | |||
mix of the other participants to each participant. It is also common | participant containing a mix of the other participants. It is also | |||
to have individual RTP sessions between each endpoint and the RTP | common to have individual RTP sessions between each endpoint and the | |||
mixer, meaning that the mixer functions as an RTP-terminating | RTP mixer, meaning that the mixer functions as an RTP-terminating | |||
gateway. | gateway. | |||
When establishing RTP sessions that can contain endpoints that aren't | Endpoints that aren't updated to handle multiple streams following | |||
updated to handle multiple streams following these recommendations, a | these recommendations can have issues with participating in RTP | |||
particular application can have issues with multiple SSRCs within a | sessions containing multiple SSRCs within a single session, such as: | |||
single session. These issues include: | ||||
1. Need to handle more than one stream simultaneously rather than | 1. Need to handle more than one stream simultaneously rather than | |||
replacing an already existing stream with a new one. | replacing an already existing stream with a new one. | |||
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 has to make sure that only one RTP stream of each type | of devices have to make sure that only one RTP stream of each media | |||
gets delivered to the endpoint if it's expecting only one, and that | type gets delivered to the endpoint if it's expecting only one, and | |||
the multiplexing format is what the device expects. It is highly | that the multiplexing format is what the device expects. It is | |||
unlikely that RTP translator-based interworking can be made to | highly unlikely that RTP translator-based interworking can be made to | |||
function successfully in such a context. | function successfully in such a context. | |||
4.2. Network Considerations | 4.2. Network Considerations | |||
The RTP multiplexing choice has impact on network level mechanisms | The RTP implementer needs to consider that the RTP multiplexing | |||
that need to be considered by the implementer. | choice also impacts network level mechanisms. | |||
4.2.1. Quality of Service | 4.2.1. Quality of Service | |||
When it comes to Quality of Service mechanisms, they are either flow | Quality of Service mechanisms are either flow based or packet marking | |||
based or packet marking based. RSVP [RFC2205] is an example of a | based. RSVP [RFC2205] is an example of a flow based mechanism, while | |||
flow based mechanism, while Diff-Serv [RFC2474] is an example of a | Diff-Serv [RFC2474] is an example of a packet marking based one. | |||
packet marking based one. For a packet marking based scheme, the | ||||
method of multiplexing will not affect the possibility to use QoS. | ||||
However, for a flow based scheme there is a clear difference between | For a flow based scheme, additional SSRC will receive the same QoS as | |||
the multiplexing methods. Additional SSRC will result in all RTP | all other RTP streams being part of the same 5-tuple (protocol, | |||
streams being part of the same 5-tuple (protocol, source address, | source address, destination address, source port, destination port), | |||
destination address, source port, destination port) which is the most | which is the most common selector for flow based QoS. | |||
common selector for flow based QoS. | ||||
It must also be noted that packet marking based QoS mechanisms can | For a packet marking based scheme, the method of multiplexing will | |||
have limitations. A general observation is that different | not affect the possibility to use QoS. Different Differentiated | |||
Differentiated Services Code Points (DSCP) can be assigned to | Services Code Points (DSCP) can be assigned to different packets | |||
different packets within a flow as well as within an RTP stream. | within a flow as well as within an RTP stream. However, care must be | |||
However, care must be taken when considering which forwarding | taken when considering which forwarding behaviours that are applied | |||
behaviours that are applied on path due to these DSCPs. In some | on path due to these DSCPs. In some cases the forwarding behaviour | |||
cases the forwarding behaviour can result in packet reordering. For | can result in packet reordering. For more discussion of this see | |||
more discussion of this see [RFC7657]. | [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 | |||
In today's network there exist a large number of middleboxes. The | In today's networks there exist a large number of middleboxes. The | |||
ones that normally have most impact on RTP are Network Address | ones that normally have most impact on RTP are Network Address | |||
Translators (NAT) and Firewalls (FW). | Translators (NAT) and Firewalls (FW). | |||
Below we analyse and comment on the impact of requiring more | Below we analyse and comment on the impact of requiring more | |||
underlying transport flows in the presence of NATs and Firewalls: | underlying transport flows in the presence of NATs and Firewalls: | |||
End-Point Port Consumption: A given IP address only has 65536 | End-Point Port Consumption: A given IP address only has 65536 | |||
available local ports per transport protocol for all consumers of | available local ports per transport protocol for all consumers of | |||
ports that exist on the machine. This is normally never an issue | ports that exist on the machine. This is normally never an issue | |||
for an end-user machine. It can become an issue for servers that | for an end-user machine. It can become an issue for servers that | |||
handle large number of simultaneous streams. However, if the | handle large number of simultaneous streams. However, if the | |||
application uses ICE to authenticate STUN requests, a server can | application uses ICE to authenticate STUN requests, a server can | |||
serve multiple endpoints from the same local port, and use the | serve multiple endpoints from the same local port, and use the | |||
whole 5-tuple (source and destination address, source and | whole 5-tuple (source and destination address, source and | |||
destination port, protocol) as identifier of flows after having | destination port, protocol) as identifier of flows after having | |||
securely bound them to the remote endpoint address using the STUN | securely bound them to the remote endpoint address using the STUN | |||
request. In theory the minimum number of media server ports | request. In theory, the minimum number of media server ports | |||
needed are the maximum number of simultaneous RTP Sessions a | needed are the maximum number of simultaneous RTP sessions a | |||
single endpoint can use. In practice, implementation will | single endpoint can use. In practice, implementation will | |||
probably benefit from using more server ports to simplify | probably benefit from using more server ports to simplify | |||
implementation or avoid performance bottlenecks. | implementation or avoid performance bottlenecks. | |||
NAT State: If an endpoint sits behind a NAT, each flow it generates | NAT State: If an endpoint sits behind a NAT, each flow it generates | |||
to an external address will result in a state that has to be kept | to an external address will result in a state that has to be kept | |||
in the NAT. That state is a limited resource. In home or Small | in the NAT. That state is a limited resource. In home or Small | |||
Office/Home Office (SOHO) NATs, memory or processing are usually | Office/Home Office (SOHO) NATs, memory or processing are usually | |||
the most limited resources. For large scale NATs serving many | the most limited resources. For large scale NATs serving many | |||
internal endpoints, available external ports are likely the scarce | internal endpoints, available external ports are likely the scarce | |||
resource. Port limitations is primarily a problem for larger | resource. Port limitations is primarily a problem for larger | |||
centralised NATs where endpoint independent mapping requires each | centralised NATs where endpoint independent mapping requires each | |||
flow to use one port for the external IP address. This affects | flow to use one port for the external IP address. This affects | |||
the maximum number of internal users per external IP address. | the maximum number of internal users per external IP address. | |||
However, it is worth pointing out that a real-time video | However, as a comparison, a real-time video conference session | |||
conference session with audio and video is likely using less than | with audio and video likely uses less than 10 UDP flows, compared | |||
10 UDP flows, compared to certain web applications that can use | to certain web applications that can use 100+ TCP flows to various | |||
100+ TCP flows to various servers from a single browser instance. | servers from a single browser instance. | |||
NAT Traversal Extra Delay: Performing the NAT/FW traversal takes a | NAT Traversal Extra Delay: Performing the NAT/FW traversal takes a | |||
certain amount of time for each flow. It also takes time in a | certain amount of time for each flow. It also takes time in a | |||
phase of communication between accepting to communicate and the | phase of communication between accepting to communicate and the | |||
media path being established which is fairly critical. The best | media path being established, which is fairly critical. The best | |||
case scenario for how much extra time it takes after finding the | case scenario for additional NAT/FW traversal time after finding | |||
first valid candidate pair following the specified ICE procedures | the first valid candidate pair following the specified ICE | |||
are: 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the pacing | procedures is 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the | |||
timer. That assumes a message in one direction, and then an | pacing timer. That assumes a message in one direction, | |||
immediate triggered check back. The reason it isn't more, is that | immediately followed by a check back. The reason it isn't more, | |||
ICE first finds one candidate pair that works prior to attempting | is that ICE first finds one candidate pair that works prior to | |||
to establish multiple flows. Thus, there is no extra time until | attempting to establish multiple flows. Thus, there is no extra | |||
one has found a working candidate pair. Based on that working | time until one has found a working candidate pair. Based on that | |||
pair the needed extra time is to in parallel establish the, in | working pair, the extra time is needed to in parallel establish | |||
most cases 2-3, additional flows. However, packet loss causes | the, in most cases 2-3, additional flows. However, packet loss | |||
extra delays, at least 100 ms, which is the minimal retransmission | causes extra delays, at least 100 ms, which is the minimal | |||
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 potential that | deeply they inspect packets. There exist some risk that deeply | |||
deeply inspecting firewalls will have similar legacy issues with | inspecting firewalls will have similar legacy issues with multiple | |||
multiple SSRCs as some stack implementations. | 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 | |||
Multicast groups provides a powerful tool for a number of real-time | Multicast groups provides a powerful tool for a number of real-time | |||
applications, especially the ones that desire broadcast-like | applications, especially the ones that desire broadcast-like | |||
behaviours with one endpoint transmitting to a large number of | behaviours with one endpoint transmitting to a large number of | |||
receivers, like in IPTV. There are also the RTP/RTCP extension to | receivers, like in IPTV. There is also the RTP/RTCP extension to | |||
better support Source Specific Multicast (SSM) [RFC5760]. Another | better support Source Specific Multicast (SSM) [RFC5760]. Many-to- | |||
application is the Many to Many communication, which RTP [RFC3550] | many communication, which RTP [RFC3550] was originally built to | |||
was originally built to support, but the multicast semantics do | support, has several limitations in common with multicast. | |||
result in a certain number of limitations. | ||||
One limitation is that for any group, sender side adaptation to the | One limitation is that, for any group, sender side adaptation with | |||
actual receiver properties causes degradation for all participants to | the intent to suit all receivers would have to adapt to the most | |||
what is supported by the receiver with the worst conditions among the | limited receiver experiencing the worst conditions among the group | |||
group participants. For broadcast type of applications this is not | participants, which imposes degradation for all participants. For | |||
acceptable. Instead, various receiver-based solutions are employed | broadcast-type applications with a large number of receivers, this is | |||
to ensure that the receivers achieve best possible performance. By | not acceptable. Instead, various receiver-based solutions are | |||
using scalable encoding and placing each scalability layer in a | employed to ensure that the receivers achieve best possible | |||
different multicast group, the receiver can control the amount of | performance. By using scalable encoding and placing each scalability | |||
traffic it receives. To have each scalability layer on a different | layer in a different multicast group, the receiver can control the | |||
multicast group, one RTP session per multicast group is used. | amount of traffic it receives. To have each scalability layer on a | |||
different multicast group, one RTP session per multicast group is | ||||
used. | ||||
In addition, the transport flow considerations in multicast are a bit | In addition, the transport flow considerations in multicast are a bit | |||
different from unicast; NATs with port translation are not useful in | different from unicast; NATs with port translation are not useful in | |||
the multicast environment, meaning that the entire port range of each | the multicast environment, meaning that the entire port range of each | |||
multicast address is available for distinguishing between RTP | multicast address is available for distinguishing between RTP | |||
sessions. | sessions. | |||
Thus, when using broadcast applications it appears easiest and most | Thus, when using broadcast applications it appears easiest and most | |||
straightforward to use multiple RTP sessions for sending different | straightforward to use multiple RTP sessions for sending different | |||
media flows used for adapting to network conditions. It is also | media flows used for adapting to network conditions. It is also | |||
common that streams that improve transport robustness are sent in | common that streams improving transport robustness are sent in their | |||
their own multicast group to allow for interworking with legacy or to | own multicast group to allow for interworking with legacy or to | |||
support different levels of protection. | support different levels of protection. | |||
For many to many applications there are different needs. Here, the | Many-to-many applications have different needs and the most | |||
most appropriate choice will depend on how the actual application is | appropriate multiplexing choice will depend on how the actual | |||
realized. With sender side congestion control there might not exist | application is realized. Multicast applications that are capable of | |||
any benefit with using multiple RTP sessions. | using sender side congestion control can avoid the use of multiple | |||
multicast sessions and RTP sessions that result from use of receiver | ||||
side congestion control. | ||||
The properties of a broadcast application using RTP multicast: | The properties of a broadcast application using RTP multicast: | |||
1. Uses a group of RTP sessions, not one. Each endpoint will need | 1. Uses a group of RTP sessions, not just one. Each endpoint will | |||
to be a member of a number of RTP sessions in order to perform | need to be a member of a number of RTP sessions in order to | |||
well. | perform well. | |||
2. Within each RTP session, the number of RTP receivers is likely to | 2. Within each RTP session, the number of RTP receivers is likely to | |||
be much larger than the number of RTP senders. | be much larger than the number of RTP senders. | |||
3. The applications need signalling functions to identify the | 3. The applications need signalling functions to identify the | |||
relationships between RTP sessions. | relationships between RTP sessions. | |||
4. The applications need signalling or RTP/RTCP functions to | 4. The applications need signalling or RTP/RTCP functions to | |||
identify the relationships between SSRCs in different RTP | identify the relationships between SSRCs in different RTP | |||
sessions when needs beyond CNAME exist. | sessions when needs beyond CNAME exist. | |||
Both broadcast and many to many multicast applications do share a | Both broadcast and many-to-many multicast applications share a | |||
signalling requirement; all of the participants will need to have the | signalling requirement; all of the participants need the same RTP and | |||
same RTP and payload type configuration. Otherwise, A could for | payload type configuration. Otherwise, A could for example be using | |||
example be using payload type 97 as the video codec H.264 while B | payload type 97 as the video codec H.264 while B thinks it is MPEG-2. | |||
thinks it is MPEG-2. It is to be noted that SDP offer/answer | SDP offer/answer [RFC3264] is not appropriate for ensuring this | |||
[RFC3264] is not appropriate for ensuring this property in broadcast/ | property in broadcast/multicast context. The signalling aspects of | |||
multicast context. The signalling aspects of broadcast/multicast are | broadcast/multicast are not explored further in this memo. | |||
not explored further in this memo. | ||||
Security solutions for this type of group communications are also | Security solutions for this type of group communication are also | |||
challenging. First, the key-management and the security protocol | challenging. First, the key-management and the security protocol | |||
need to support group communication. Second, source authentication | need to support group communication. Second, source authentication | |||
requires special solutions. For more discussion on this please | requires special solutions. For more discussion on this please | |||
review Options for Securing RTP Sessions [RFC7201]. | review Options for Securing RTP Sessions [RFC7201]. | |||
4.3. Security and Key Management Considerations | 4.3. Security and Key Management Considerations | |||
When dealing with point-to-point, 2-member RTP sessions only, there | When dealing with point-to-point, 2-member RTP sessions only, there | |||
are few security issues that are relevant to the choice of having one | are few security issues that are relevant to the choice of having one | |||
RTP session or multiple RTP sessions. However, there are a few | RTP session or multiple RTP sessions. However, there are a few | |||
aspects of multiparty sessions that might warrant consideration. For | aspects of multiparty sessions that might warrant consideration. For | |||
general information of possible methods of securing RTP, please | general information of possible methods of securing RTP, please | |||
review RTP Security Options [RFC7201]. | review RTP Security Options [RFC7201]. | |||
4.3.1. Security Context Scope | 4.3.1. Security Context Scope | |||
When using SRTP [RFC3711] the security context scope is important and | When using SRTP [RFC3711], the security context scope is important | |||
can be a necessary differentiation in some applications. As SRTP's | and can be a necessary differentiation in some applications. As | |||
crypto suites are (so far) built around symmetric keys, the receiver | SRTP's crypto suites are (so far) built around symmetric keys, the | |||
will need to have the same key as the sender. This results in that | receiver will need to have the same key as the sender. This results | |||
no one in a multi-party session can be certain that a received packet | in that no one in a multi-party session can be certain that a | |||
really was sent by the claimed sender and not by another party having | received packet really was sent by the claimed sender and not by | |||
access to the key. At least unless TESLA source authentication | another party having access to the key. The single SRTP algorithm | |||
[RFC4383], which adds delay to achieve source authentication. In | not having this propery is the TESLA source authentication [RFC4383]. | |||
most cases symmetric ciphers provide sufficient security properties, | However, TESLA adds delay to achieve source authentication. In most | |||
but there are a few cases where this does create issues. | cases, symmetric ciphers provide sufficient security properties but | |||
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 | |||
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 | |||
differentiation. Take for example a scalable layer or a high quality | stream access differentiation between different receivers. Take for | |||
simulcast version that only premium users are allowed to access. The | example a scalable layer or a high quality simulcast version that | |||
mechanism preventing a receiver from getting the high quality stream | only premium users are allowed to access. The mechanism preventing a | |||
can be based on the stream being encrypted with a key that user can't | receiver from getting the high quality stream can be based on the | |||
access without paying premium, having the key-management limit access | stream being encrypted with a key that user can't access without | |||
to the key. | paying premium, using the key-management to limit access to the key. | |||
SRTP [RFC3711] has no special functions for dealing with different | SRTP [RFC3711] has no special functions for dealing with different | |||
sets of master keys for different SSRCs. The key-management | sets of master keys for different SSRCs. The key-management | |||
functions have different capabilities to establish different sets of | functions have different capabilities to establish different sets of | |||
keys, normally on a per endpoint basis. For example, DTLS-SRTP | keys, normally on a per-endpoint basis. For example, DTLS-SRTP | |||
[RFC5764] and Security Descriptions [RFC4568] establish different | [RFC5764] and Security Descriptions [RFC4568] establish different | |||
keys for outgoing and incoming traffic from an endpoint. This key | keys for outgoing and incoming traffic from an endpoint. This key | |||
usage has to be written into the cryptographic context, possibly | usage has to be written into the cryptographic context, possibly | |||
associated with different SSRCs. | associated with different SSRCs. | |||
4.3.2. Key Management for Multi-party sessions | 4.3.2. Key Management for Multi-party Sessions | |||
Performing key-management for multi-party sessions can be a | The capabilities of the key-management combined with the RTP | |||
challenge. This section considers some of the issues. | multiplexing choices affects the resulting security properties, | |||
control over the secured media, and who have access to it. | ||||
Multi-party sessions, such as transport translator based sessions and | Multi-party sessions contain at least one RTP stream from each active | |||
multicast sessions, can neither use Security Description [RFC4568] | participant. Depending on the multi-party topology [RFC7667], each | |||
nor DTLS-SRTP [RFC5764] without an extension as each endpoint | participant can both send and receive multiple RTP streams. | |||
provides its set of keys. In centralised conferences, the signalling | ||||
counterpart is a conference server and the media plane unicast | Transport translator-based sessions and multicast sessions, can | |||
counterpart (to which DTLS messages would be sent) is the transport | neither use Security Description [RFC4568] nor DTLS-SRTP [RFC5764] | |||
translator. Thus, an extension like Encrypted Key Transport | without an extension as each endpoint provides its set of keys. In | |||
[I-D.ietf-perc-srtp-ekt-diet] or a MIKEY [RFC3830] based solution | centralised conferences, the signalling counterpart is a conference | |||
that allows for keying all session participants with the same master | server, and the transport translator is the media plane unicast | |||
key is needed. | counterpart (to which DTLS messages would be sent). Thus, an | |||
extension like Encrypted Key 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 | ||||
trust model with semi-trusted media switching RTP middleboxes | ||||
[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 | |||
that processes or modifies RTP/RTCP packets. Where there is very | that processes or modifies RTP/RTCP packets. While there is very | |||
small overhead for an RTP translator or mixer to rewrite an SSRC | small overhead for an RTP translator or mixer to rewrite an SSRC | |||
value in the RTP packet of an unencrypted session, the cost is higher | value in the RTP packet of an unencrypted session, the cost is higher | |||
when using cryptographic security functions. For example, if using | when using cryptographic security functions. For example, if using | |||
SRTP [RFC3711], the actual security context and exact crypto key are | SRTP [RFC3711], the actual security context and exact crypto key are | |||
determined by the SSRC field value. If one changes SSRC, the | determined by the SSRC field value. If one changes SSRC, the | |||
encryption and authentication must use another key. Thus, changing | encryption and authentication must use another key. Thus, changing | |||
the SSRC value implies a decryption using the old SSRC and its | the SSRC value implies a decryption using the old SSRC and its | |||
security context, followed by an encryption using the new one. | security context, followed by an encryption using the new one. | |||
5. RTP Multiplexing Design Choices | 5. RTP Multiplexing Design Choices | |||
This section discusses how some RTP multiplexing design choices can | This section discusses how some RTP multiplexing design choices can | |||
be used in applications to achieve certain goals, and a summary of | be used in applications to achieve certain goals, and a summary of | |||
the implications of such choices. For each design there is | the implications of such choices. For each design there is | |||
discussion of benefits and downsides. | discussion of benefits and downsides. | |||
5.1. Multiple Media Types in one Session | 5.1. Multiple Media Types in One Session | |||
This design uses a single RTP session for multiple different media | This design uses a single RTP session for multiple different media | |||
types, like audio and video, and possibly also transport robustness | types, like audio and video, and possibly also transport robustness | |||
mechanisms like FEC or Retransmission. An endpoint can have zero, | mechanisms like FEC or retransmission. An endpoint can send zero, | |||
one or more media sources per media type, resulting in a number of | one or more media sources per media type, resulting in a number of | |||
RTP streams of various media types and both source and redundancy | RTP streams of various media types for both source and redundancy | |||
type. | streams. | |||
The Pros: | The Advantages: | |||
1. Single RTP session which implies: | 1. Only a single RTP session is used, which implies: | |||
* Minimal NAT/FW state. | * Minimal need to keep NAT/FW state. | |||
* Minimal NAT/FW Traversal Cost. | * Minimal NAT/FW-traversal cost. | |||
* Fate-sharing for all media flows. | * Fate-sharing for all media flows. | |||
2. Can handle dynamic allocations of RTP streams well on an RTP | * Minimal overhead for security association establishment. | |||
level. Depends on the application's needs for explicit | ||||
indication of the stream usage and how timely that can be | ||||
signalled. | ||||
3. Minimal overhead for security association establishment. | 2. Dynamic allocation of RTP streams can be handled almost entirely | |||
at RTP level. How localized this can be kept to RTP level | ||||
depends on the application's needs for explicit indication of the | ||||
stream usage and how timely that can be signalled. | ||||
The Cons: | The Disadvantages: | |||
a. Less suitable for interworking with other applications that uses | a. It is less suitable for interworking with other applications that | |||
individual RTP sessions per media type or multiple sessions for a | use individual RTP sessions per media type or multiple sessions | |||
single media type, due to the potential need of SSRC translation. | for a single media type, due to the risk of SSRC collision and | |||
thus potential need for SSRC translation. | ||||
b. Negotiation of bandwidth for the different media types is | b. Negotiation of individual bandwidths for the different media | |||
currently only possible using RID [I-D.ietf-mmusic-rid] in SDP. | types is currently only possible in SDP when using RID | |||
[I-D.ietf-mmusic-rid]. | ||||
c. Not suitable for Split Component Terminal (see Section 3.10 of | c. It is not suitable for Split Component Terminal (see Section 3.10 | |||
[RFC7667]). | of [RFC7667]). | |||
d. Flow-based QoS cannot provide separate treatment of RTP streams | d. Flow-based QoS cannot be used to provide separate treatment of | |||
compared to others in the single RTP session. | RTP streams compared to others in the single RTP session. | |||
e. If there is significant asymmetry between the RTP streams' RTCP | e. If there is significant asymmetry between the RTP streams' RTCP | |||
reporting needs, there are some challenges in configuration and | reporting needs, there are some challenges in configuration and | |||
usage to avoid wasting RTCP reporting on the RTP stream that does | usage to avoid wasting RTCP reporting on the RTP stream that does | |||
not need that frequent reporting. | not need that frequent reporting. | |||
f. 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. Additional concern with legacy implementations that do not | g. There is some additional concern with legacy implementations that | |||
support the RTP specification fully when it comes to handling | do not support the RTP specification fully when it comes to | |||
multiple SSRC per endpoint, as also multiple simultaneous media | handling multiple SSRC per endpoint, as multiple simultaneous | |||
types need to be handled. | 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 that are included in different sets of security | |||
associations, most key-management will have difficulties | associations, most key-management will have difficulties | |||
establishing such a session. | 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. | RTP/RTCP multiplexing [RFC5761]. | |||
The Pros: | The Advantages | |||
1. Works well with Split Component Terminal (see Section 3.10 of | 1. It works well with Split Component Terminal (see Section 3.10 of | |||
[RFC7667]) where the split is per media type. | [RFC7667]) where the split is per media type. | |||
2. Enables Flow-based QoS with different prioritisation between | 2. It enables flow-based QoS with different prioritisation between | |||
media types. | media types. | |||
3. For applications with dynamic usage of RTP streams, i.e. | 3. For applications with dynamic usage of RTP streams, i.e. | |||
frequently added and removed, having much of the state associated | frequently added and removed, having much of the state associated | |||
with the RTP session rather than per individual SSRC can avoid | with the RTP session rather than per individual SSRC can avoid | |||
the need for in-session signalling of meta-information about each | the need for in-session signalling of meta-information about each | |||
SSRC. | SSRC. | |||
4. Low overhead for security association establishment. | 4. There is low overhead for security association establishment. | |||
The Cons: | The Disadvantages | |||
a. Slightly higher number of RTP sessions needed compared to | a. There are a slightly higher number of RTP sessions needed | |||
Multiple Media Types in one Session Section 5.1. This implies: | compared to Multiple Media Types in one Session Section 5.1. | |||
This implies: | ||||
* More NAT/FW state | * More NAT/FW state is needed. | |||
* Increased NAT/FW Traversal Cost in both processing and delay. | * There is increased NAT/FW-traversal cost in both processing | |||
and delay. | ||||
b. Some potential for concern with legacy implementations that don't | b. There is some potential for concern with legacy implementations | |||
support the RTP specification fully when it comes to handling | that don't support the RTP specification fully when it comes to | |||
multiple SSRC per endpoint. | handling multiple SSRC per endpoint. | |||
c. Not possible to control security association for sets of RTP | c. It is not possible to control security association for sets of | |||
streams within the same media type with today's key- management | RTP streams within the same media type with today's key- | |||
mechanisms, unless these are split into different RTP sessions. | management mechanisms, unless these are split into different RTP | |||
sessions (Section 5.3). | ||||
For RTP applications where all RTP streams of the same media type | For RTP applications where all RTP streams of the same media type | |||
share same usage, this structure provides efficiency gains in amount | share same usage, this structure provides efficiency gains in amount | |||
of network state used and provides more fate sharing with other media | of network state used and provides more fate sharing with other media | |||
flows of the same type. At the same time, it is still maintaining | flows of the same type. At the same time, it is still maintaining | |||
almost all functionalities when it comes to negotiation in the | almost all functionalities for the negotiation signaling of | |||
signalling of the properties for the individual media type, and also | properties per individual media type, and also enables flow based QoS | |||
enables flow based QoS prioritisation between media types. It | prioritisation between media types. It handles multi-party sessions | |||
handles multi-party session well, independently of multicast or | well, independently of multicast or centralised transport | |||
centralised transport distribution, as additional sources can | distribution, as additional sources can dynamically enter and leave | |||
dynamically enter and leave the session. | the session. | |||
5.3. Multiple Sessions for one Media type | 5.3. Multiple Sessions for One Media Type | |||
This design goes one step further than above (Section 5.2) by using | This design goes one step further than above (Section 5.2) by using | |||
multiple RTP sessions also for a single media type. The main reason | multiple RTP sessions also for a single media type. The main reason | |||
for going in this direction is that the RTP application needs | for going in this direction is that the RTP application needs | |||
separation of the RTP streams due to their usage. Some typical | separation of the RTP streams due to their usage, such as e.g. | |||
reasons for going to this design are scalability over multicast, | scalability over multicast, simulcast, need for extended QoS | |||
simulcast, need for extended QoS prioritisation of RTP streams due to | prioritisation, or the need for fine-grained signalling using RTP | |||
their usage in the application, or the need for fine- grained | session-focused signalling tools. | |||
signalling using today's tools. | ||||
The Pros: | The Advantages: | |||
1. 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, in case multiple different usages exist. | |||
3. Less need for SSRC specific explicit signalling for each media | 3. There is less need for SSRC-specific explicit signalling for each | |||
stream and thus reduced need for explicit and timely signalling. | media stream and thus reduced need for explicit and timely | |||
signalling when RTP streams are added or removed. | ||||
4. Enables detailed QoS prioritisation for flow-based mechanisms. | 4. It enables detailed QoS prioritisation for flow-based mechanisms. | |||
5. 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]). | |||
6. The scope for who is included in a security association can be | 6. The scope for who is included in a security association can be | |||
structured around the different RTP sessions, thus enabling such | structured around the different RTP sessions, thus enabling such | |||
functionality with existing key-management. | functionality with existing key-management. | |||
The Cons: | The Disadvantages: | |||
a. Increases the amount of RTP sessions compared to Multiple SSRCs | ||||
of the Same Media Type. | ||||
b. Increased amount of session configuration state. | a. There is an increased amount of session configuration state | |||
compared to Multiple SSRCs of the Same Media Type, due to the | ||||
increased amount of RTP sessions. | ||||
c. For RTP streams that are part of scalability, simulcast or | b. For RTP streams that are part of scalability, simulcast or | |||
transport robustness, a method to bind sources across multiple | transport robustness, a method to bind sources across multiple | |||
RTP sessions is needed. | RTP sessions is needed. | |||
d. Some potential for concern with legacy implementations that does | c. There is some potential for concern with legacy implementations | |||
not support the RTP specification fully when it comes to handling | that don't support the RTP specification fully when it comes to | |||
multiple SSRC per endpoint. | handling multiple SSRC per endpoint. | |||
e. Higher overhead for security association establishment due to the | d. There is higher overhead for security association establishment, | |||
increased number of RTP sessions. | due to the increased number of RTP sessions. | |||
f. If the applications need finer control than on RTP session level | e. If the applications need more fine-grained control than per RTP | |||
over which participants that are included in different sets of | session over which participants that are included in different | |||
security associations, most of today's key-management will have | sets of security associations, most of today's key-management | |||
difficulties establishing such a session. | will have difficulties establishing such a session. | |||
For more complex RTP applications that have several different usages | For more complex RTP applications that have several different usages | |||
for RTP streams of the same media type, or uses scalability or | for RTP streams of the same media type, or uses scalability or | |||
simulcast, this solution can enable those functions at the cost of | simulcast, this solution can enable those functions at the cost of | |||
increased overhead associated with the additional sessions. This | increased overhead associated with the additional sessions. This | |||
type of structure is suitable for more advanced applications as well | type of structure is suitable for more advanced applications as well | |||
as multicast-based applications requiring differentiation to | as multicast-based applications requiring differentiation to | |||
different participants. | different participants. | |||
5.4. Single SSRC per Endpoint | 5.4. Single SSRC per Endpoint | |||
In this design each endpoint in a point-to-point session has only a | In this design each endpoint in a point-to-point session has only a | |||
single SSRC, thus the RTP session contains only two SSRCs, one local | single SSRC, thus the RTP session contains only two SSRCs, one local | |||
and one remote. This session can be used both unidirectional, i.e. | and one remote. This session can be used both unidirectional, i.e. | |||
only a single RTP stream or bi-directional, i.e. both endpoints have | only a single RTP stream, or bi-directional, i.e. both endpoints have | |||
one RTP stream each. If the application needs additional media flows | one RTP stream each. If the application needs additional media flows | |||
between the endpoints, they will have to establish additional RTP | between the endpoints, it will have to establish additional RTP | |||
sessions. | sessions. | |||
The Pros: | The Advantages: | |||
1. This design has great legacy interoperability potential as it | 1. This design has great legacy interoperability potential as it | |||
will not tax any RTP stack implementations. | will not tax any RTP stack implementations. | |||
2. The signalling has good possibilities to negotiate and describe | 2. The signalling has good possibilities to negotiate and describe | |||
the exact formats and bit-rates for each RTP stream, especially | the exact formats and bitrates for each RTP stream, especially | |||
using today's tools in SDP. | using today's tools in SDP. | |||
3. It is possible to control security association per RTP stream | 3. It is possible to control security association per RTP stream | |||
with current key-management, since each RTP stream is directly | with current key-management, since each RTP stream is directly | |||
related to an RTP session, and the most used keying mechanisms | related to an RTP session, and the most used keying mechanisms | |||
operates on a per-session basis. | operates on a per-session basis. | |||
The Cons: | The Disadvantages: | |||
a. The number of RTP sessions grows directly in proportion with the | ||||
number of RTP streams, which has the implications: | ||||
* Linear growth of the amount of NAT/FW state with number of RTP | a. There is a linear growth of the amount of NAT/FW state with | |||
streams. | number of RTP streams. | |||
* Increased delay and resource consumption from NAT/FW | b. There is increased delay and resource consumption from NAT/FW- | |||
traversal. | traversal. | |||
* Likely larger signalling message and signalling processing | c. There are likely larger signalling message and signalling | |||
requirement due to the amount of session related information. | processing requirements due to the increased amount of session- | |||
related information. | ||||
* Higher potential for a single RTP stream to fail during | d. There is higher potential for a single RTP stream to fail during | |||
transport between the endpoints. | transport between the endpoints, due to the need for separate | |||
NAT/FW- traversal for every RTP stream since there is only one | ||||
stream per session. | ||||
b. When the number of RTP sessions grows, the amount of explicit | e. The amount of explicit state for relating RTP streams grows, | |||
state for relating RTP streams also grows, depending on how the | depending on how the application relates RTP streams. | |||
application needs to relate RTP streams. | ||||
c. The port consumption might become a problem for centralised | f. The port consumption might become a problem for centralised | |||
services, where the central node's port or 5-tuple filter | services, where the central node's port or 5-tuple filter | |||
consumption grows rapidly with the number of sessions. | consumption grows rapidly with the number of sessions. | |||
d. For applications where the RTP stream usage is highly dynamic, | g. For applications where the RTP stream usage is highly dynamic, | |||
i.e. entering and leaving, the amount of signalling can grow | i.e. entering and leaving, the amount of signalling can become | |||
high. Issues can also arise from the timely establishment of | high. Issues can also arise from the need for timely | |||
additional RTP sessions. | establishment of additional RTP sessions. | |||
e. If, against the recommendation, the same SSRC value is reused in | h. If, against the recommendation, the same SSRC value is reused in | |||
multiple RTP sessions rather than being randomly chosen, | multiple RTP sessions rather than being randomly chosen, | |||
interworking with applications that use a different multiplexing | interworking with applications that use a different multiplexing | |||
structure will require SSRC translation. | structure will require SSRC translation. | |||
RTP applications that need to interwork with legacy RTP applications | RTP applications with a strong need to interwork with legacy RTP | |||
can potentially benefit from this structure. However, a large number | applications can potentially benefit from this structure. However, a | |||
of media descriptions in SDP can also run into issues with existing | large number of media descriptions in SDP can also run into issues | |||
implementations. For any application needing a larger number of | with existing implementations. For any application needing a larger | |||
media flows, the overhead can become very significant. This | number of media flows, the overhead can become very significant. | |||
structure is also not suitable for multi-party sessions, as any given | This structure is also not suitable for non-mixed multi-party | |||
RTP stream from each participant, although having same usage in the | sessions, as any given RTP stream from each participant, although | |||
application, needs its own RTP session. In addition, the dynamic | having same usage in the application, needs its own RTP session. In | |||
behaviour that can arise in multi-party applications can tax the | addition, the dynamic behaviour that can arise in multi-party | |||
signalling system and make timely media establishment more difficult. | applications can tax the signalling system and make timely media | |||
establishment more difficult. | ||||
5.5. Summary | 5.5. Summary | |||
There are some clear similarities between these designs. Both the | Both the "Single SSRC per Endpoint" and the "Multiple Media Types in | |||
"Single SSRC per Endpoint" and the "Multiple Media Types in one | One Session" are cases that require full explicit signalling of the | |||
Session" are cases that require full explicit signalling of the media | media stream relations. However, they operate on two different | |||
stream relations. However, they operate on two different levels | levels where the first primarily enables session level binding, and | |||
where the first primarily enables session level binding, and the | the second needs SSRC level binding. From another perspective, the | |||
second needs SSRC level binding. From another perspective, the two | two solutions are the two extreme points when it comes to number of | |||
solutions are the two extreme points when it comes to number of RTP | RTP sessions needed. | |||
sessions needed. | ||||
The two other designs "Multiple SSRCs of the Same Media Type" and | The two other designs, "Multiple SSRCs of the Same Media Type" and | |||
"Multiple Sessions for one Media Type" are two examples that | "Multiple Sessions for One Media Type", are two examples that | |||
primarily allows for some implicit mapping of the role or usage of | primarily allows for some implicit mapping of the role or usage of | |||
the RTP streams based on which RTP session they appear in. It thus | the RTP streams based on which RTP session they appear in. It thus | |||
potentially allows for less signalling and in particular reduces the | potentially allows for less signalling and in particular reduces the | |||
need for real-time signalling in dynamic sessions. They also | need for real-time signalling in sessions with dynamically changing | |||
represent points in between the first two designs when it comes to | number of RTP streams. They also represent points in-between the | |||
amount of RTP sessions established, i.e. representing an attempt to | first two designs when it comes to amount of RTP sessions | |||
balance the amount of RTP sessions with the functionality the | established, i.e. representing an attempt to balance the amount of | |||
communication session provides both on network level and on | RTP sessions with the functionality the communication session | |||
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 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 | |||
skipping to change at page 32, line 16 ¶ | skipping to change at page 32, line 4 ¶ | |||
suggested to send them in the same RTP session. For example a | suggested to send them in the same RTP session. For example a | |||
telepresence room where there are three cameras, and each camera | telepresence room where there are three cameras, and each camera | |||
captures 2 persons sitting at the table, sending each camera as | captures 2 persons sitting at the table, sending each camera as | |||
its own RTP stream within a single RTP session is suggested. | its own RTP stream within a single RTP session is suggested. | |||
Use additional RTP sessions for streams with different requirements: | Use additional RTP sessions for streams with different requirements: | |||
When RTP streams have different processing requirements from the | When RTP streams have different processing requirements from the | |||
network or the RTP layer at the endpoints, it is suggested that | network or the RTP layer at the endpoints, it is suggested that | |||
the different types of streams are put in different RTP sessions. | the different types of streams are put in different RTP sessions. | |||
This includes the case where different participants want different | This includes the case where different participants want different | |||
subsets of the set of RTP streams. | subsets of the set of RTP streams. | |||
When using multiple RTP Sessions, use grouping: When using Multiple | When using multiple RTP sessions, use grouping: When using multiple | |||
RTP session solutions, it is suggested to explicitly group the | RTP session solutions, it is suggested to explicitly group the | |||
involved RTP sessions when needed using a signalling mechanism, | involved RTP sessions when needed using a signalling mechanism, | |||
for example The Session Description Protocol (SDP) Grouping | for example The Session Description Protocol (SDP) Grouping | |||
Framework [RFC5888], using some appropriate grouping semantics. | Framework [RFC5888], using some appropriate grouping semantics. | |||
RTP/RTCP Extensions Support Multiple RTP Streams as well as Multiple | RTP/RTCP Extensions Support Multiple RTP Streams as Well as Multiple | |||
RTP sessions: | RTP Sessions: | |||
When defining an RTP or RTCP extension, the creator needs to | When defining an RTP or RTCP extension, the creator needs to | |||
consider if this extension is applicable to use with additional | consider if this extension is applicable to use with additional | |||
SSRCs and multiple RTP sessions. Any extension intended to be | SSRCs and multiple RTP sessions. Any extension intended to be | |||
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 | Transport Support Extensions: When defining new RTP/RTCP extensions | |||
intended for transport support, like the retransmission or FEC | intended for transport support, like the retransmission or FEC | |||
mechanisms, they must include support for both multiple RTP | mechanisms, they must include support for both multiple RTP | |||
streams in the same RTP sessions and multiple RTP sessions, such | streams in the same RTP 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 | |||
RFC. | RFC. | |||
8. Security Considerations | 8. Security Considerations | |||
The security considerations of the RTP specification [RFC3550] and | The security considerations of the RTP specification [RFC3550], any | |||
any applicable RTP profile [RFC3551],[RFC4585],[RFC3711], the | applicable RTP profile [RFC3551],[RFC4585],[RFC3711], and the | |||
extensions for sending multiple media types in a single RTP session | extensions for sending multiple media types in a single RTP session | |||
[I-D.ietf-avtcore-multi-media-rtp-session], RID | [I-D.ietf-avtcore-multi-media-rtp-session], RID | |||
[I-D.ietf-mmusic-rid], BUNDLE | [I-D.ietf-mmusic-rid], BUNDLE | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation], [RFC5760], [RFC5761], apply | [I-D.ietf-mmusic-sdp-bundle-negotiation], [RFC5760], [RFC5761], apply | |||
if selected and thus needs to be considered in the evaluation. | if selected and thus need to be considered in the evaluation. | |||
There is discussion of the security implications of choosing multiple | There is discussion of the security implications of choosing multiple | |||
SSRC vs multiple RTP sessions in Section 4.3. | SSRC vs multiple RTP sessions in Section 4.3. | |||
9. Contributors | 9. Contributors | |||
Hui Zheng (Marvin) from Huawei contributed to WG draft versions -04 | Hui Zheng (Marvin) contributed to WG draft versions -04 and -05 of | |||
and -05 of the document. | the document. | |||
10. References | 10. Acknowledgments | |||
10.1. Normative References | The Authors like to acknowledge and thank Cullen Jennings, Dale R | |||
Worley, Huang Yihong (Rachel), and Vijay Gurbani for review and | ||||
comments. | ||||
11. References | ||||
11.1. Normative References | ||||
[I-D.ietf-avtcore-multi-media-rtp-session] | ||||
Westerlund, M., Perkins, C., and J. Lennox, "Sending | ||||
Multiple Types of Media in a Single RTP Session", draft- | ||||
ietf-avtcore-multi-media-rtp-session-13 (work in | ||||
progress), December 2015. | ||||
[I-D.ietf-mmusic-rid] | ||||
Roach, A., "RTP Payload Format Restrictions", draft-ietf- | ||||
mmusic-rid-15 (work in progress), May 2018. | ||||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | ||||
Holmberg, C., Alvestrand, H., and C. Jennings, | ||||
"Negotiating Media Multiplexing Using the Session | ||||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | ||||
negotiation-54 (work in progress), December 2018. | ||||
[I-D.ietf-mmusic-sdp-simulcast] | ||||
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, | ||||
"Using Simulcast in SDP and RTP Sessions", draft-ietf- | ||||
mmusic-sdp-simulcast-14 (work in progress), March 2019. | ||||
[I-D.ietf-perc-srtp-ekt-diet] | ||||
Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. | ||||
Andreasen, "Encrypted Key Transport for DTLS and Secure | ||||
RTP", draft-ietf-perc-srtp-ekt-diet-10 (work in progress), | ||||
July 2019. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <https://www.rfc-editor.org/info/rfc3550>. | July 2003, <https://www.rfc-editor.org/info/rfc3550>. | |||
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and | ||||
Video Conferences with Minimal Control", STD 65, RFC 3551, | ||||
DOI 10.17487/RFC3551, July 2003, | ||||
<https://www.rfc-editor.org/info/rfc3551>. | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | ||||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | ||||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | ||||
<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, | ||||
"Extended RTP Profile for Real-time Transport Control | ||||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | ||||
DOI 10.17487/RFC4585, July 2006, | ||||
<https://www.rfc-editor.org/info/rfc4585>. | ||||
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific | ||||
Media Attributes in the Session Description Protocol | ||||
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, | ||||
<https://www.rfc-editor.org/info/rfc5576>. | ||||
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control | ||||
Protocol (RTCP) Extensions for Single-Source Multicast | ||||
Sessions with Unicast Feedback", RFC 5760, | ||||
DOI 10.17487/RFC5760, February 2010, | ||||
<https://www.rfc-editor.org/info/rfc5760>. | ||||
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and | ||||
Control Packets on a Single Port", RFC 5761, | ||||
DOI 10.17487/RFC5761, April 2010, | ||||
<https://www.rfc-editor.org/info/rfc5761>. | ||||
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and | [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and | |||
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms | B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms | |||
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, | for Real-Time Transport Protocol (RTP) Sources", RFC 7656, | |||
DOI 10.17487/RFC7656, November 2015, | DOI 10.17487/RFC7656, November 2015, | |||
<https://www.rfc-editor.org/info/rfc7656>. | <https://www.rfc-editor.org/info/rfc7656>. | |||
10.2. Informative References | [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | |||
DOI 10.17487/RFC7667, November 2015, | ||||
<https://www.rfc-editor.org/info/rfc7667>. | ||||
11.2. Informative References | ||||
[ALF] Clark, D. and D. Tennenhouse, "Architectural | [ALF] Clark, D. and D. Tennenhouse, "Architectural | |||
Considerations for a New Generation of Protocols", SIGCOMM | Considerations for a New Generation of Protocols", SIGCOMM | |||
Symposium on Communications Architectures and | Symposium on Communications Architectures and | |||
Protocols (Philadelphia, Pennsylvania), pp. 200--208, IEEE | Protocols (Philadelphia, Pennsylvania), pp. 200--208, IEEE | |||
Computer Communications Review, Vol. 20(4), September | Computer Communications Review, Vol. 20(4), September | |||
1990. | 1990. | |||
[I-D.ietf-avtcore-multi-media-rtp-session] | ||||
Westerlund, M., Perkins, C., and J. Lennox, "Sending | ||||
Multiple Types of Media in a Single RTP Session", draft- | ||||
ietf-avtcore-multi-media-rtp-session-13 (work in | ||||
progress), December 2015. | ||||
[I-D.ietf-avtext-rid] | [I-D.ietf-avtext-rid] | |||
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream | Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream | |||
Identifier Source Description (SDES)", draft-ietf-avtext- | Identifier Source Description (SDES)", draft-ietf-avtext- | |||
rid-09 (work in progress), October 2016. | rid-09 (work in progress), October 2016. | |||
[I-D.ietf-mmusic-rid] | [I-D.ietf-perc-private-media-framework] | |||
Roach, A., "RTP Payload Format Restrictions", draft-ietf- | Jones, P., Benham, D., and C. Groves, "A Solution | |||
mmusic-rid-15 (work in progress), May 2018. | Framework for Private Media in Privacy Enhanced RTP | |||
Conferencing (PERC)", draft-ietf-perc-private-media- | ||||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | framework-12 (work in progress), June 2019. | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | ||||
"Negotiating Media Multiplexing Using the Session | ||||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | ||||
negotiation-53 (work in progress), September 2018. | ||||
[I-D.ietf-mmusic-sdp-simulcast] | ||||
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, | ||||
"Using Simulcast in SDP and RTP Sessions", draft-ietf- | ||||
mmusic-sdp-simulcast-13 (work in progress), June 2018. | ||||
[I-D.ietf-perc-srtp-ekt-diet] | [JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, | |||
Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. | S., and J. Hildebrand, "XEP-0166: Jingle", XMPP.org | |||
Andreasen, "Encrypted Key Transport for DTLS and Secure | https://xmpp.org/extensions/xep-0166.html, September 2018. | |||
RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), | ||||
October 2018. | ||||
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., | [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., | |||
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- | Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- | |||
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, | Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, | |||
DOI 10.17487/RFC2198, September 1997, | DOI 10.17487/RFC2198, September 1997, | |||
<https://www.rfc-editor.org/info/rfc2198>. | <https://www.rfc-editor.org/info/rfc2198>. | |||
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | |||
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | |||
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | |||
skipping to change at page 35, line 20 ¶ | skipping to change at page 36, line 20 ¶ | |||
[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>. | |||
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and | ||||
Video Conferences with Minimal Control", STD 65, RFC 3551, | ||||
DOI 10.17487/RFC3551, July 2003, | ||||
<https://www.rfc-editor.org/info/rfc3551>. | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | ||||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | ||||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | ||||
<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>. | ||||
[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>. | |||
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, | Description Protocol", RFC 4566, DOI 10.17487/RFC4566, | |||
July 2006, <https://www.rfc-editor.org/info/rfc4566>. | July 2006, <https://www.rfc-editor.org/info/rfc4566>. | |||
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | |||
Description Protocol (SDP) Security Descriptions for Media | Description Protocol (SDP) Security Descriptions for Media | |||
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, | Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, | |||
<https://www.rfc-editor.org/info/rfc4568>. | <https://www.rfc-editor.org/info/rfc4568>. | |||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | ||||
"Extended RTP Profile for Real-time Transport Control | ||||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | ||||
DOI 10.17487/RFC4585, July 2006, | ||||
<https://www.rfc-editor.org/info/rfc4585>. | ||||
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | |||
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | |||
DOI 10.17487/RFC4588, July 2006, | DOI 10.17487/RFC4588, July 2006, | |||
<https://www.rfc-editor.org/info/rfc4588>. | <https://www.rfc-editor.org/info/rfc4588>. | |||
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | |||
"Codec Control Messages in the RTP Audio-Visual Profile | "Codec Control Messages in the RTP Audio-Visual Profile | |||
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, | with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, | |||
February 2008, <https://www.rfc-editor.org/info/rfc5104>. | February 2008, <https://www.rfc-editor.org/info/rfc5104>. | |||
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error | [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error | |||
Correction", RFC 5109, DOI 10.17487/RFC5109, December | Correction", RFC 5109, DOI 10.17487/RFC5109, December | |||
2007, <https://www.rfc-editor.org/info/rfc5109>. | 2007, <https://www.rfc-editor.org/info/rfc5109>. | |||
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific | [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, | |||
Media Attributes in the Session Description Protocol | "Session Traversal Utilities for NAT (STUN)", RFC 5389, | |||
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, | DOI 10.17487/RFC5389, October 2008, | |||
<https://www.rfc-editor.org/info/rfc5576>. | <https://www.rfc-editor.org/info/rfc5389>. | |||
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control | ||||
Protocol (RTCP) Extensions for Single-Source Multicast | ||||
Sessions with Unicast Feedback", RFC 5760, | ||||
DOI 10.17487/RFC5760, February 2010, | ||||
<https://www.rfc-editor.org/info/rfc5760>. | ||||
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and | ||||
Control Packets on a Single Port", RFC 5761, | ||||
DOI 10.17487/RFC5761, April 2010, | ||||
<https://www.rfc-editor.org/info/rfc5761>. | ||||
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | |||
Security (DTLS) Extension to Establish Keys for the Secure | Security (DTLS) Extension to Establish Keys for the Secure | |||
Real-time Transport Protocol (SRTP)", RFC 5764, | Real-time Transport Protocol (SRTP)", RFC 5764, | |||
DOI 10.17487/RFC5764, May 2010, | DOI 10.17487/RFC5764, May 2010, | |||
<https://www.rfc-editor.org/info/rfc5764>. | <https://www.rfc-editor.org/info/rfc5764>. | |||
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | |||
Protocol (SDP) Grouping Framework", RFC 5888, | Protocol (SDP) Grouping Framework", RFC 5888, | |||
DOI 10.17487/RFC5888, June 2010, | DOI 10.17487/RFC5888, June 2010, | |||
skipping to change at page 37, line 20 ¶ | skipping to change at page 37, line 36 ¶ | |||
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | |||
<https://www.rfc-editor.org/info/rfc7201>. | <https://www.rfc-editor.org/info/rfc7201>. | |||
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services | [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services | |||
(Diffserv) and Real-Time Communication", RFC 7657, | (Diffserv) and Real-Time Communication", RFC 7657, | |||
DOI 10.17487/RFC7657, November 2015, | DOI 10.17487/RFC7657, November 2015, | |||
<https://www.rfc-editor.org/info/rfc7657>. | <https://www.rfc-editor.org/info/rfc7657>. | |||
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | ||||
DOI 10.17487/RFC7667, November 2015, | ||||
<https://www.rfc-editor.org/info/rfc7667>. | ||||
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | |||
and M. Stiemerling, Ed., "Real-Time Streaming Protocol | and M. Stiemerling, Ed., "Real-Time Streaming Protocol | |||
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December | Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December | |||
2016, <https://www.rfc-editor.org/info/rfc7826>. | 2016, <https://www.rfc-editor.org/info/rfc7826>. | |||
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme | ||||
Updates for Secure Real-time Transport Protocol (SRTP) | ||||
Extension for Datagram Transport Layer Security (DTLS)", | ||||
RFC 7983, DOI 10.17487/RFC7983, September 2016, | ||||
<https://www.rfc-editor.org/info/rfc7983>. | ||||
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", | [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", | |||
RFC 8088, DOI 10.17487/RFC8088, May 2017, | RFC 8088, DOI 10.17487/RFC8088, May 2017, | |||
<https://www.rfc-editor.org/info/rfc8088>. | <https://www.rfc-editor.org/info/rfc8088>. | |||
[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, | [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, | |||
"Sending Multiple RTP Streams in a Single RTP Session", | "Sending Multiple RTP Streams in a Single RTP Session", | |||
RFC 8108, DOI 10.17487/RFC8108, March 2017, | RFC 8108, DOI 10.17487/RFC8108, March 2017, | |||
<https://www.rfc-editor.org/info/rfc8108>. | <https://www.rfc-editor.org/info/rfc8108>. | |||
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive | [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive | |||
Connectivity Establishment (ICE): A Protocol for Network | Connectivity Establishment (ICE): A Protocol for Network | |||
Address Translator (NAT) Traversal", RFC 8445, | Address Translator (NAT) Traversal", RFC 8445, | |||
DOI 10.17487/RFC8445, July 2018, | DOI 10.17487/RFC8445, July 2018, | |||
<https://www.rfc-editor.org/info/rfc8445>. | <https://www.rfc-editor.org/info/rfc8445>. | |||
Appendix A. Dismissing Payload Type Multiplexing | Appendix A. Dismissing Payload Type Multiplexing | |||
This section documents a number of reasons why using the payload type | This section documents a number of reasons why using the payload type | |||
as a multiplexing point is unsuitable for most things related to | as a multiplexing point is unsuitable for most issues related to | |||
multiple RTP streams. If one attempts to use Payload type | multiple RTP streams. Attempting to use Payload type multiplexing | |||
multiplexing beyond its defined usage, that has well known negative | beyond its defined usage has well known negative effects on RTP | |||
effects on RTP. To use payload type as the single discriminator for | discussed below. To use payload type as the single discriminator for | |||
multiple streams implies that all the different RTP streams are being | multiple streams implies that all the different RTP streams are being | |||
sent with the same SSRC, thus using the same timestamp and sequence | sent with the same SSRC, thus using the same timestamp and sequence | |||
number space. This has many effects: | number space. This has many effects: | |||
1. Putting restraint on RTP timestamp rate for the multiplexed | 1. Putting constraints on RTP timestamp rate for the multiplexed | |||
media. For example, RTP streams that use different RTP | media. For example, RTP streams that use different RTP | |||
timestamp rates cannot be combined, as the timestamp values need | timestamp rates cannot be combined, as the timestamp values need | |||
to be consistent across all multiplexed media frames. Thus | to be consistent across all multiplexed media frames. Thus | |||
streams are forced to use the same RTP timestamp rate. When | streams are forced to use the same RTP timestamp rate. When | |||
this is not possible, payload type multiplexing cannot be used. | this is not possible, payload type multiplexing cannot be used. | |||
2. Many RTP payload formats can fragment a media object over | 2. Many RTP payload formats can fragment a media object over | |||
multiple RTP packets, like parts of a video frame. These | multiple RTP packets, like parts of a video frame. These | |||
payload formats need to determine the order of the fragments to | payload formats need to determine the order of the fragments to | |||
correctly decode them. Thus, it is important to ensure that all | correctly decode them. Thus, it is important to ensure that all | |||
skipping to change at page 38, line 49 ¶ | skipping to change at page 39, line 21 ¶ | |||
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 | |||
feedback on RTP streams based on stream ID (SSRC), packet | feedback on RTP streams based on stream ID (SSRC), packet | |||
(sequence numbers) and time interval (RTP Timestamps). There is | (sequence numbers) and time interval (RTP timestamps). There is | |||
almost never a field to indicate which payload type is reported, | almost never a field to indicate which payload type is reported, | |||
so sending feedback for a specific RTP payload type is difficult | so sending feedback for a specific RTP payload type is difficult | |||
without extending existing RTCP reporting. | without extending existing RTCP reporting. | |||
7. The current RTCP media control messages [RFC5104] specification | 7. The current RTCP media control messages [RFC5104] specification | |||
is oriented around controlling particular media flows, i.e. | is oriented around controlling particular media flows, i.e. | |||
requests are done addressing a particular SSRC. Such mechanisms | requests are done addressing a particular SSRC. Such mechanisms | |||
would need to be redefined to support payload type multiplexing. | would need to be redefined to support payload type multiplexing. | |||
8. The number of payload types are inherently limited. | 8. The number of payload types are inherently limited. | |||
skipping to change at page 39, line 38 ¶ | skipping to change at page 40, line 8 ¶ | |||
context. | context. | |||
12. A legacy endpoint that does not understand the indication that | 12. A legacy endpoint that does not understand the indication that | |||
different RTP payload types are different RTP streams might be | different RTP payload types are different RTP streams might be | |||
slightly confused by the large amount of possibly overlapping or | slightly confused by the large amount of possibly overlapping or | |||
identically defined RTP payload types. | identically defined RTP payload types. | |||
Appendix B. Signalling Considerations | Appendix B. Signalling Considerations | |||
Signalling is not an architectural consideration for RTP itself, so | Signalling is not an architectural consideration for RTP itself, so | |||
this discussion has been moved to an appendix. However, it is hugely | this discussion has been moved to an appendix. However, it is | |||
important for anyone building complete applications, so it is | extremely important for anyone building complete applications, so it | |||
deserving of discussion. | is deserving of discussion. | |||
The issues raised here need to be addressed in the WGs that deal with | We document salient issues here that need to be addressed by the WGs | |||
signalling; they cannot be addressed by tweaking, extending or | that use some form of signaling to establish RTP sessions. These | |||
profiling RTP. | issues cannot simply be addressed by tweaking, extending, or | |||
profiling RTP, but require a dedicated and indepth look at the | ||||
signaling primitives that set up the RTP sessions. | ||||
There exist various signalling solutions for establishing RTP | There exist various signalling solutions for establishing RTP | |||
sessions. Many are SDP [RFC4566] based, however SDP functionality is | sessions. Many are SDP [RFC4566] based, however SDP functionality is | |||
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 around | One aspect of the existing signalling is that it is focused on RTP | |||
RTP sessions, or at least in the case of SDP the media description. | sessions, or at least in the case of SDP the media description. | |||
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 is used. | |||
o Which SSRC that will use which RTP payload types (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 | |||
enable negotiation of the parameters for each set. If insisting on | enable negotiation of the parameters for each set. If insisting on | |||
additional SSRC only, a number of signalling extensions are needed to | additional SSRC only, a number of signalling extensions are needed to | |||
skipping to change at page 41, line 10 ¶ | skipping to change at page 41, line 27 ¶ | |||
type for identifying the actual payload format and is bound to a | type for identifying the actual payload format and is bound to a | |||
particular payload type using the rtpmap attribute. This binding has | particular payload type using the rtpmap attribute. This binding has | |||
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 has 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- | |||
skipping to change at page 41, line 44 ¶ | skipping to change at page 42, line 15 ¶ | |||
If this signalling affects how any RTP central node, like an RTP | If this signalling affects how any RTP central node, like an RTP | |||
mixer or translator that selects, mixes or processes streams, treats | mixer or translator that selects, mixes or processes streams, treats | |||
the streams, the node will also need to receive the same signalling | the streams, the node will also need to receive the same signalling | |||
to know how to treat RTP streams with different usage in the right | to know how to treat RTP streams with different usage in the right | |||
fashion. | fashion. | |||
Authors' Addresses | Authors' Addresses | |||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Torshamsgatan 23 | Torshamnsgatan 23 | |||
SE-164 80 Kista | SE-164 80 Kista | |||
Sweden | Sweden | |||
Phone: +46 10 714 82 87 | Phone: +46 10 714 82 87 | |||
Email: magnus.westerlund@ericsson.com | Email: magnus.westerlund@ericsson.com | |||
Bo Burman | Bo Burman | |||
Ericsson | Ericsson | |||
Gronlandsgatan 31 | Gronlandsgatan 31 | |||
SE-164 60 Kista | SE-164 60 Kista | |||
Sweden | Sweden | |||
Phone: +46 10 714 13 11 | ||||
Email: bo.burman@ericsson.com | Email: bo.burman@ericsson.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
End of changes. 182 change blocks. | ||||
619 lines changed or deleted | 646 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/ |