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