draft-ietf-avtcore-multiplex-guidelines-03.txt | draft-ietf-avtcore-multiplex-guidelines-04.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: April 11, 2015 C. Perkins | Expires: May 3, 2018 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
H. Alvestrand | H. Alvestrand | |||
October 08, 2014 | R. Even | |||
H. Zheng | ||||
Huawei | ||||
October 30, 2017 | ||||
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-03 | draft-ietf-avtcore-multiplex-guidelines-04 | |||
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 | |||
multiplexing features of RTP to support multiple media streams. | multiplexing features of RTP to support multiple media streams. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 http://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 April 11, 2015. | This Internet-Draft will expire on May 3, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
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 . . . . . . . . . . . . . . . . . . 6 | 2.2. Subjects Out of Scope . . . . . . . . . . . . . . . . . . 5 | |||
3. Reasons for Multiplexing and Grouping RTP Media Streams . . . 6 | 3. RTP Multiplexing Overview . . . . . . . . . . . . . . . . . . 5 | |||
4. RTP Multiplexing Points . . . . . . . . . . . . . . . . . . . 7 | 3.1. Reasons for Multiplexing and Grouping RTP Media Streams . 5 | |||
4.1. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.2. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6 | |||
4.2. Synchronisation Source (SSRC) . . . . . . . . . . . . . . 9 | 3.2.1. RTP Session . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. Contributing Source (CSRC) . . . . . . . . . . . . . . . 10 | 3.2.2. Synchronisation Source (SSRC) . . . . . . . . . . . . 8 | |||
4.4. RTP Payload Type . . . . . . . . . . . . . . . . . . . . 11 | 3.2.3. Contributing Source (CSRC) . . . . . . . . . . . . . 10 | |||
5. RTP Topologies and Issues . . . . . . . . . . . . . . . . . . 12 | 3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 10 | |||
5.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 12 | 3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 | |||
5.2. Translators & Gateways . . . . . . . . . . . . . . . . . 13 | 3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 13 | |||
5.3. Point to Multipoint Using Multicast . . . . . . . . . . . 13 | 3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 13 | |||
5.4. Point to Multipoint Using an RTP Transport Translator . . 14 | 3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 15 | |||
5.5. Point to Multipoint Using an RTP Mixer . . . . . . . . . 15 | 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15 | |||
6. RTP Multiplexing: When to Use Multiple RTP Sessions . . . . . 15 | 3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17 | |||
6.1. RTP and RTCP Protocol Considerations . . . . . . . . . . 16 | 4. Particular Considerations for RTP Multiplexing . . . . . . . 17 | |||
6.1.1. The RTP Specification . . . . . . . . . . . . . . . . 16 | 4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 | |||
6.1.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 18 | 4.1.1. Types of Interworking . . . . . . . . . . . . . . . . 17 | |||
6.1.3. Handling Varying Sets of Senders . . . . . . . . . . 19 | 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18 | |||
6.1.4. Cross Session RTCP Requests . . . . . . . . . . . . . 19 | 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 | |||
6.1.5. Binding Related Sources . . . . . . . . . . . . . . . 19 | 4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 | |||
6.1.6. Forward Error Correction . . . . . . . . . . . . . . 21 | 4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 | |||
6.1.7. Transport Translator Sessions . . . . . . . . . . . . 21 | 4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 | |||
6.2. Interworking Considerations . . . . . . . . . . . . . . . 21 | 4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 20 | |||
6.2.1. Types of Interworking . . . . . . . . . . . . . . . . 22 | 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 | |||
6.2.2. RTP Translator Interworking . . . . . . . . . . . . . 22 | 4.3. Security and Key Management Considerations . . . . . . . 23 | |||
6.2.3. Gateway Interworking . . . . . . . . . . . . . . . . 22 | 4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 | |||
6.2.4. Multiple SSRC Legacy Considerations . . . . . . . . . 23 | 4.3.2. Key Management for Multi-party session . . . . . . . 24 | |||
6.3. Network Considerations . . . . . . . . . . . . . . . . . 24 | 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 | |||
6.3.1. Quality of Service . . . . . . . . . . . . . . . . . 24 | ||||
6.3.2. NAT and Firewall Traversal . . . . . . . . . . . . . 25 | ||||
6.3.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 27 | ||||
6.3.4. Multiplexing multiple RTP Session on a Single | ||||
Transport . . . . . . . . . . . . . . . . . . . . . . 27 | ||||
6.4. Security and Key Management Considerations . . . . . . . 28 | 5. Archetypes . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
6.4.1. Security Context Scope . . . . . . . . . . . . . . . 28 | 5.1. Single SSRC per Session . . . . . . . . . . . . . . . . . 25 | |||
6.4.2. Key Management for Multi-party session . . . . . . . 28 | 5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27 | |||
6.4.3. Complexity Implications . . . . . . . . . . . . . . . 29 | 5.3. Multiple Sessions for one Media type . . . . . . . . . . 28 | |||
7. Archetypes . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 5.4. Multiple Media Types in one Session . . . . . . . . . . . 30 | |||
7.1. Single SSRC per Session . . . . . . . . . . . . . . . . . 29 | 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
7.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 31 | 6. Summary considerations and guidelines . . . . . . . . . . . . 31 | |||
7.3. Multiple Sessions for one Media type . . . . . . . . . . 32 | 6.1. Guidelines . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
7.4. Multiple Media Types in one Session . . . . . . . . . . . 34 | 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
7.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
8. Summary considerations and guidelines . . . . . . . . . . . . 36 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
8.1. Guidelines . . . . . . . . . . . . . . . . . . . . . . . 36 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | 10.2. Informative References . . . . . . . . . . . . . . . . . 34 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 38 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 | Appendix B. Signalling considerations . . . . . . . . . . . . . 40 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 37 | B.1. Signalling Aspects . . . . . . . . . . . . . . . . . . . 40 | |||
Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 41 | B.1.1. Session Oriented Properties . . . . . . . . . . . . . 40 | |||
Appendix B. Proposals for Future Work . . . . . . . . . . . . . 43 | B.1.2. SDP Prevents Multiple Media Types . . . . . . . . . . 41 | |||
Appendix C. Signalling considerations . . . . . . . . . . . . . 44 | B.1.3. Signalling Media Stream Usage . . . . . . . . . . . . 41 | |||
C.1. Signalling Aspects . . . . . . . . . . . . . . . . . . . 44 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
C.1.1. Session Oriented Properties . . . . . . . . . . . . . 44 | ||||
C.1.2. SDP Prevents Multiple Media Types . . . . . . . . . . 45 | ||||
C.1.3. Signalling Media Stream Usage . . . . . . . . . . . . 45 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | ||||
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 has several multiplexing points designed for | applications. RTP was from the beginning designed for multiple | |||
different purposes. These enable support of multiple media streams | participants in a communication session. It supports many paradigms | |||
and switching between different encoding or packetization of the | of topologies and usages, as defined in [RFC7667]. RTP has several | |||
media. By using multiple RTP sessions, sets of media streams can be | multiplexing points designed for different purposes. These enable | |||
structured for efficient processing or identification. Thus the | support of multiple media streams and switching between different | |||
question for any RTP application designer is how to best use the RTP | encoding or packetization of the media. By using multiple RTP | |||
session, the SSRC and the payload type to meet the application's | sessions, sets of media streams can be structured for efficient | |||
needs. | processing or identification. Thus the question for any RTP | |||
application designer is how to best use the RTP session, the SSRC and | ||||
the payload type to meet the application's needs. | ||||
There have been increased interest in more advanced usage of RTP, for | ||||
example, multiple streams can occur when a single endpoint have | ||||
multiple media sources, like multiple cameras or microphones that | ||||
need to be sent simultaneously. Consequently, questions are raised | ||||
regarding the most appropriate RTP usage. The limitations in some | ||||
implementations, RTP/RTCP extensions, and signalling has also been | ||||
exposed. The authors also hope that clarification on the usefulness | ||||
of some functionalities in RTP will result in more complete | ||||
implementations in the future. | ||||
The purpose of this document is to provide clear information about | The purpose of this document is to provide clear information about | |||
the possibilities of RTP when it comes to multiplexing. The RTP | the possibilities of RTP when it comes to multiplexing. The RTP | |||
application designer needs to understand the implications that come | application designer needs to understand the implications that come | |||
from a particular usage of the RTP multiplexing points. The document | from a particular usage of the RTP multiplexing points. The document | |||
will recommend against some usages as being unsuitable, in general or | will recommend against some usages as being unsuitable, in general or | |||
for particular purposes. | for particular purposes. | |||
RTP was from the beginning designed for multiple participants in a | ||||
communication session. This is not restricted to multicast, as some | ||||
believe, but also provides functionality over unicast, using either | ||||
multiple transport flows below RTP or a network node that re- | ||||
distributes the RTP packets. The re-distributing node can for | ||||
example be a transport translator (relay) that forwards the packets | ||||
unchanged, a translator performing media or protocol translation in | ||||
addition to forwarding, or an RTP mixer that creates new sources from | ||||
the received streams. In addition, multiple streams can occur when a | ||||
single endpoint have multiple media sources, like multiple cameras or | ||||
microphones that need to be sent simultaneously. | ||||
This document has been written due to increased interest in more | ||||
advanced usage of RTP, resulting in questions regarding the most | ||||
appropriate RTP usage. The limitations in some implementations, RTP/ | ||||
RTCP extensions, and signalling has also been exposed. It is | ||||
expected that some limitations will be addressed by updates or new | ||||
extensions resolving the shortcomings. The authors also hope that | ||||
clarification on the usefulness of some functionalities in RTP will | ||||
result in more complete implementations in the future. | ||||
The document starts with some definitions and then goes into the | The document starts with some definitions and then goes into the | |||
existing RTP functionalities around multiplexing. Both the desired | existing RTP functionalities around multiplexing. Both the desired | |||
behaviour and the implications of a particular behaviour depend on | behaviour and the implications of a particular behaviour depend on | |||
which topologies are used, which requires some consideration. This | which topologies are used, which requires some consideration. This | |||
is followed by a discussion of some choices in multiplexing behaviour | is followed by a discussion of some choices in multiplexing behaviour | |||
and their impacts. Some archetypes of RTP usage are discussed. | and their impacts. Some archetypes of RTP usage are discussed. | |||
Finally, some recommendations and examples are provided. | Finally, some recommendations and examples are provided. | |||
2. Definitions | 2. Definitions | |||
2.1. Terminology | 2.1. Terminology | |||
The following terms and abbreviations are used in this document: | The definitions in Section 3 of [RFC3550] are referenced normatively. | |||
Endpoint: A single entity sending or receiving RTP packets. It can | The taxonomy defined in [RFC7656] is referenced normatively. | |||
be decomposed into several functional blocks, but as long as it | ||||
behaves a single RTP stack entity it is classified as a single | The following terms and abbreviations are used in this document: | |||
endpoint. | ||||
Multiparty: A communication situation including multiple endpoints. | Multiparty: A communication situation including multiple endpoints. | |||
In this document it will be used to refer to situations where more | In this document it will be used to refer to situations where more | |||
than two endpoints communicate. | than two endpoints communicate. | |||
Media Source: The source of a stream of data of one Media Type, It | ||||
can either be a single media capturing device such as a video | ||||
camera, a microphone, or a specific output of a media production | ||||
function, such as an audio mixer, or some video editing function. | ||||
Sending data from a Media Source can cause multiple RTP sources to | ||||
send multiple Media Streams. | ||||
Media Stream: A sequence of RTP packets using a single SSRC that | ||||
together carries part or all of the content of a specific Media | ||||
Type from a specific sender source within a given RTP session. | ||||
RTP Source: The originator or source of a particular Media Stream. | RTP Source: The originator or source of a particular Media Stream. | |||
Identified using an SSRC in a particular RTP session. An RTP | Identified using an SSRC in a particular RTP session. An RTP | |||
source is the source of a single media stream, and is associated | source is the source of a single media stream, and is associated | |||
with a single endpoint and a single Media Source. An RTP Source | with a single endpoint and a single Media Source. An RTP Source | |||
is just called a Source in RFC 3550. | is just called a Source in RFC 3550. | |||
RTP Sink: A recipient of a Media Stream. The Media Sink is | RTP Sink: A recipient of a Media Stream. The Media Sink is | |||
identified using one or more SSRCs. There can be more than one | identified using one or more SSRCs. There can be more than one | |||
RTP Sink for one RTP source. | RTP Sink for one RTP source. | |||
CNAME: "Canonical name" - identifier associated with one or more RTP | ||||
sources from a single endpoint. Defined in the RTP specification | ||||
[RFC3550]. A CNAME identifies a synchronisation context. A CNAME | ||||
is associated with a single endpoint, although some RTP nodes will | ||||
use an endpoint's CNAME on that endpoints behalf. An endpoint can | ||||
use multiple CNAMEs. A CNAME is intended to be globally unique | ||||
and stable for the full duration of a communication session. | ||||
[RFC6222][I-D.ietf-avtcore-6222bis] gives updated guidelines for | ||||
choosing CNAMEs. | ||||
Media Type: Audio, video, text or data whose form and meaning are | ||||
defined by a specific real-time application. | ||||
Multiplexing: The operation of taking multiple entities as input, | Multiplexing: The operation of taking multiple entities as input, | |||
aggregating them onto some common resource while keeping the | aggregating them onto some common resource while keeping the | |||
individual entities addressable such that they can later be fully | individual entities addressable such that they can later be fully | |||
and unambiguously separated (de-multiplexed) again. | and unambiguously separated (de-multiplexed) again. | |||
RTP Session: As defined by [RFC3550], the endpoints belonging to the | ||||
same RTP Session are those that share a single SSRC space. That | ||||
is, those endpoints can see an SSRC identifier transmitted by any | ||||
one of the other endpoints. An endpoint can receive an SSRC | ||||
either as SSRC or as CSRC in RTP and RTCP packets. Thus, the RTP | ||||
Session scope is decided by the endpoints' network interconnection | ||||
topology, in combination with RTP and RTCP forwarding strategies | ||||
deployed by endpoints and any interconnecting middle nodes. | ||||
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. | RTP sessions. | |||
Source: Term that ought not be used alone. An RTP Source, as | ||||
identified by its SSRC, is the source of a single Media Stream; a | ||||
Media Source can be the source of mutiple Media Streams. | ||||
SSRC: A 32-bit unsigned integer used as identifier for a RTP Source. | ||||
CSRC: Contributing Source, A SSRC identifier used in a context, like | ||||
the RTP headers CSRC list, where it is clear that the Media Source | ||||
is not the source of the media stream, instead only a contributor | ||||
to the Media Stream. | ||||
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. | |||
2.2. Subjects Out of Scope | 2.2. Subjects Out of Scope | |||
This document is focused on issues that affect RTP. Thus, issues | This document is focused on issues that affect RTP. Thus, issues | |||
that involve signalling protocols, such as whether SIP, Jingle or | that involve signalling protocols, such as whether SIP, Jingle or | |||
some other protocol is in use for session configuration, the | some other protocol is in use for session configuration, the | |||
particular syntaxes used to define RTP session properties, or the | particular syntaxes used to define RTP session properties, or the | |||
constraints imposed by particular choices in the signalling | constraints imposed by particular choices in the signalling | |||
protocols, are mentioned only as examples in order to describe the | protocols, are mentioned only as examples in order to describe the | |||
RTP issues more precisely. | RTP issues more precisely. | |||
This document assumes the applications will use RTCP. While there | This document assumes the applications will use RTCP. While there | |||
are such applications that don't send RTCP, they do not conform to | are such applications that don't send RTCP, they do not conform to | |||
the RTP specification, and thus can be regarded as reusing the RTP | the RTP specification, and thus can be regarded as reusing the RTP | |||
packet format but not implementing the RTP protocol. | packet format but not implementing the RTP protocol. | |||
3. Reasons for Multiplexing and Grouping RTP Media Streams | 3. RTP Multiplexing Overview | |||
3.1. Reasons for Multiplexing and Grouping RTP Media Streams | ||||
The reasons why an endpoint might choose to send multiple media | The reasons why an endpoint might choose to send multiple media | |||
streams are widespread. In the below discussion, please keep in mind | streams are widespread. In the below discussion, please keep in mind | |||
that the reasons for having multiple media streams vary and include | that the reasons for having multiple media streams vary and include | |||
but are not limited to the following: | but are not limited to the following: | |||
o Multiple Media Sources | o Multiple Media Sources | |||
o Multiple Media Streams might be needed to represent one Media | o Multiple Media Streams might be needed to represent one Media | |||
Source (for instance when using layered encodings) | Source (for instance when using layered encodings) | |||
skipping to change at page 7, line 18 ¶ | skipping to change at page 6, line 9 ¶ | |||
o Alternative Encodings, for instance different codecs for the same | o Alternative Encodings, for instance different codecs for the same | |||
audio stream | audio stream | |||
o Alternative formats, for instance multiple resolutions of the same | o Alternative formats, for instance multiple resolutions of the same | |||
video stream | video stream | |||
For each of these, it is necessary to decide if each additional media | For each of these, it is necessary to decide if each additional media | |||
stream gets its own SSRC multiplexed within a RTP Session, or if it | stream gets its own SSRC multiplexed within a RTP Session, or if it | |||
is necessary to use additional RTP sessions to group the media | is necessary to use additional RTP sessions to group the media | |||
streams. The choice between these made due to one reason might not | streams. The choice between these made due to one reason might not | |||
be the choice suitable for another reason. In the above list, the | be the choice suitable for another reason. The clearest | |||
different items have different levels of maturity in the discussion | understanding is associated with multiple media sources of the same | |||
on how to solve them. The clearest understanding is associated with | media type. However, all warrant discussion and clarification on how | |||
multiple media sources of the same media type. However, all warrant | to deal with them. As the discussion below will show, in reality we | |||
discussion and clarification on how to deal with them. As the | cannot choose a single one of the two solutions. To utilise RTP well | |||
discussion below will show, in reality we cannot choose a single one | and as efficiently as possible, both are needed. The real issue is | |||
of the two solutions. To utilise RTP well and as efficiently as | finding the right guidance on when to create RTP sessions and when | |||
possible, both are needed. The real issue is finding the right | additional SSRCs in an RTP session is the right choice. | |||
guidance on when to create RTP sessions and when additional SSRCs in | ||||
an RTP session is the right choice. | ||||
4. 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 media streams and groups of | protocol that can be used to distinguish media streams and groups of | |||
media streams. Figure 1 outlines the process of demultiplexing | media streams. Figure 1 outlines the process of demultiplexing | |||
incoming RTP streams: | incoming RTP streams: | |||
| | | | |||
| packets | | packets | |||
+-- v | +-- v | |||
| +------------+ | | +------------+ | |||
| | Socket | | | | Socket | | |||
| +------------+ | | +------------+ | |||
| || || | | || || | |||
RTP | RTP/ || |+-----> SCTP ( ...and any other protocols) | RTP | RTP/ || |+-----> SCTP ( ...and any other protocols) | |||
Session | RTCP || +------> STUN (multiplexed using same port) | Session | RTCP || +------> STUN (multiplexed using same port) | |||
+-- || | +-- || | |||
+-- || | +-- || | |||
| (split by SSRC) | | (split by SSRC) | |||
| || || || | | || || || | |||
| || || || | | || || || | |||
Media | +--+ +--+ +--+ | Media | +--+ +--+ +--+ | |||
Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, FEC, etc. | Streams | |PB| |PB| |PB| Jitter buffer, process RTCP, FEC, etc. | |||
| +--+ +--+ +--+ | | +--+ +--+ +--+ | |||
+-- | | | | +-- | | | | |||
(pick rending context based on PT) | ||||
(pick rendering context based on PT) | ||||
+-- | / | | +-- | / | | |||
| +---+ | | | +---+ | | |||
| / | | | | / | | | |||
Payload | +--+ +--+ +--+ | Payload | +--+ +--+ +--+ | |||
Formats | |CR| |CR| |CR| Codecs and rendering | Formats | |CR| |CR| |CR| Codecs and rendering | |||
| +--+ +--+ +--+ | | +--+ +--+ +--+ | |||
+-- | +-- | |||
Figure 1: RTP Demultiplexing Process | Figure 1: RTP Demultiplexing Process | |||
4.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. | |||
The set of participants that form an RTP session is defined as those | The set of participants that form an RTP session is defined as those | |||
that share a single synchronisation source space [RFC3550]. That is, | that share a single synchronisation source space [RFC3550]. That is, | |||
if a group of participants are each aware of the synchronisation | if a group of participants are each aware of the synchronisation | |||
source identifiers belonging to the other participants, then those | source identifiers belonging to the other participants, then those | |||
participants are in a single RTP session. A participant can become | participants are in a single RTP session. A participant can become | |||
aware of a synchronisation source identifier by receiving an RTP | aware of a synchronisation source identifier by receiving an RTP | |||
packet containing it in the SSRC field or CSRC list, by receiving an | packet containing it in the SSRC field or CSRC list, by receiving an | |||
RTCP packet mentioning it in an SSRC field, or through signalling | RTCP packet mentioning it in an SSRC field, or through signalling | |||
(e.g., the SDP "a=ssrc:" attribute). Thus, the scope of an RTP | (e.g., the SDP OCGBPa=ssrc:OCOe attribute). Thus, the scope of an | |||
session is determined by the participants' network interconnection | RTP session is determined by the participants' network | |||
topology, in combination with RTP and RTCP forwarding strategies | interconnection topology, in combination with RTP and RTCP forwarding | |||
deployed by the endpoints and any middleboxes, and by the signalling. | strategies deployed by the endpoints and any middleboxes, and by the | |||
signalling. | ||||
RTP does not contain a session identifier. Rather, it relies on the | RTP does not contain a session identifier. Rather, it relies on the | |||
underlying transport layer to separate different sessions, and on the | underlying transport layer to separate different sessions, and on the | |||
signalling to identify sessions in a manner that is meaningful to the | signalling to identify sessions in a manner that is meaningful to the | |||
application. The signalling layer might give sessions an explicit | application. The signalling layer might give sessions an explicit | |||
identifier, or their identification might be implicit based on the | identifier, or their identification might be implicit based on the | |||
addresses and ports used. Accordingly, a single RTP Session can have | addresses and ports used. Accordingly, a single RTP Session can have | |||
multiple associated identifiers, explicit and implicit, belonging to | multiple associated identifiers, explicit and implicit, belonging to | |||
different contexts. For example, when running RTP on top of UDP/IP, | different contexts. For example, when running RTP on top of UDP/IP, | |||
an RTP endpoint can identify and delimit an RTP Session from other | an RTP endpoint can identify and delimit an RTP Session from other | |||
RTP Sessions using the UDP source and destination IP addresses and | RTP Sessions using the UDP source and destination IP addresses and | |||
UDP port numbers. Another example is when using SDP grouping | UDP port numbers. Another example is when using SDP grouping | |||
framework [RFC5888] which uses an identifier per "m="-line; if there | framework [RFC5888] which uses an identifier per OCGBPm=OCOe-line; if | |||
is a one-to-one mapping between "m="-lines and RTP sessions, that | there is a one-to-one mapping between OCGBPm=OCOe-lines and RTP | |||
grouping framework identifier will identify an RTP Session. | sessions, that grouping framework identifier will identify an RTP | |||
Session. [I-D.ietf-mmusic-sdp-bundle-negotiation] extends the | ||||
OCGBPm-OCGBP-line for bundled media, which adds complexity to | ||||
demultiplexing media stream. Section 10.2 of | ||||
[I-D.ietf-mmusic-sdp-bundle-negotiation] provides information about | ||||
how RTP/RTCP streams are associated with SDP media description. | ||||
RTP sessions are globally unique, but their identity can only be | RTP sessions are globally unique, but their identity can only be | |||
determined by the communication context at an endpoint of the | determined by the communication context at an endpoint of the | |||
session, or by a middlebox that is aware of the session context. The | session, or by a middlebox that is aware of the session context. The | |||
relationship between RTP sessions depending on the underlying | relationship between RTP sessions depending on the underlying | |||
application, transport, and signalling protocol. The RTP protocol | application, transport, and signalling protocol. The RTP protocol | |||
makes no normative statements about the relationship between | makes no normative statements about the relationship between | |||
different RTP sessions, however the applications that use more than | different RTP sessions, however the applications that use more than | |||
one RTP session will have some higher layer understanding of the | one RTP session will have some higher layer understanding of the | |||
relationship between the sessions they create. | relationship between the sessions they create. | |||
4.2. Synchronisation Source (SSRC) | 3.2.2. Synchronisation Source (SSRC) | |||
A synchronisation source (SSRC) identifies an RTP source or an RTP | A synchronisation source (SSRC) identifies an RTP source or an RTP | |||
sink. Every endpoint will have at least one synchronisation source | sink. Every endpoint will have at least one synchronisation source | |||
identifier, even if it does not send media (endpoints that are only | identifier, even if it does not send media (endpoints that are only | |||
RTP sinks still send RTCP, and use their synchronisation source | RTP sinks still send RTCP, and use their synchronisation source | |||
identifier in the RTCP packets they send). An endpoint can have | identifier in the RTCP packets they send). An endpoint can have | |||
multiple synchronisation sources identifiers if it contains multiple | multiple synchronisation sources identifiers if it contains multiple | |||
RTP sources (i.e., if it sends multiple media streams). Endpoints | RTP sources (i.e., if it sends multiple media streams). Endpoints | |||
that are both RTP sources and RTP sinks use the same synchronisation | that are both RTP sources and RTP sinks use the same synchronisation | |||
sources in both roles. At any given time, a RTP source has one and | sources in both roles. At any given time, a RTP source has one and | |||
only one SSRC - although that can change over the lifetime of the RTP | only one SSRC - although that can change over the lifetime of the RTP | |||
source or sink. | source or sink. | |||
The synchronisation Source identifier is a 32-bit unsigned integer. | The synchronisation Source identifier is a 32-bit unsigned integer. | |||
It is present in every RTP and RTCP packet header, and in the payload | It is present in every RTP and RTCP packet header, and in the payload | |||
of some RTCP packet types. It can also be present in SDP signalling. | of some RTCP packet types. It can also be present in SDP signalling. | |||
Unless pre-signalled using the SDP "a=ssrc:" attribute [RFC5576], the | Unless pre-signalled using the SDP OCGBPa=ssrc:OCOe attribute | |||
synchronisation source identifier is chosen at random. It is not | [RFC5576], the synchronisation source identifier is chosen at random. | |||
dependent on the network address of the endpoint, and is intended to | It is not dependent on the network address of the endpoint, and is | |||
be unique within an RTP session. Synchronisation source identifier | intended to be unique within an RTP session. Synchronisation source | |||
collisions can occur, and are handled as specified in [RFC3550] and | identifier collisions can occur, and are handled as specified in | |||
[RFC5576], resulting in the synchronisation source identifier of the | [RFC3550] and [RFC5576], resulting in the synchronisation source | |||
affecting RTP sources and/or sinks changing. An RTP source that | identifier of the affecting RTP sources and/or sinks changing. An | |||
changes its RTP Session identifier (e.g. source transport address) | RTP source that changes its RTP Session identifier (e.g. source | |||
during a session has to choose a new SSRC identifier to avoid being | transport address) during a session has to choose a new SSRC | |||
interpreted as looped source. | identifier to avoid being interpreted as looped source. | |||
Synchronisation source identifiers that belong to the same | Synchronisation source identifiers that belong to the same | |||
synchronisation context (i.e., that represent media streams that can | synchronisation context (i.e., that represent media streams that can | |||
be synchronised using information in RTCP SR packets) are indicated | be synchronised using information in RTCP SR packets) are indicated | |||
by use of identical CNAME chunks in corresponding RTCP SDES packets. | by use of identical CNAME chunks in corresponding RTCP SDES packets. | |||
SDP signalling can also be used to provide explicit grouping of | SDP signalling can also be used to provide explicit grouping of | |||
synchronisation sources [RFC5576]. | synchronisation sources [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 Multi-Session | streams in two different RTP Sessions, such as in Multi-Session | |||
Transmission of scalable video [RFC6190]. This is NOT RECOMMENDED | Transmission of scalable video [RFC6190]. This is to be avoided | |||
since there is no guarantee of uniqueness in SSRC values across | since there is no guarantee of uniqueness in SSRC values across | |||
RTP sessions. | RTP sessions. | |||
Note that RTP sequence number and RTP timestamp are scoped by the | Note that RTP sequence number and RTP timestamp are scoped by the | |||
synchronisation source. Each RTP source will have a different | synchronisation source. Each RTP source will have a different | |||
synchronisation source, and the corresponding media stream will have | synchronisation source, and the corresponding media stream will have | |||
a separate RTP sequence number and timestamp space. | a separate RTP sequence number and timestamp space. | |||
An SSRC identifier is used by different type of sources as well as | An SSRC identifier is used by different type of sources as well as | |||
sinks: | sinks: | |||
Real Media Source: Connected to a "physical" media source, for | Real Media Source: Connected to a OCGBPphysicalOCOe media source, | |||
example a camera or microphone. | for example a camera or microphone. | |||
Processed Media Source: A source with some attributed property | Processed Media Source: A source with some attributed property | |||
generated by some network node, for example a filtering function | generated by some network node, for example a filtering function | |||
in an RTP mixer that provides the most active speaker based on | in an RTP mixer that provides the most active speaker based on | |||
some criteria, or a mix representing a set of other sources. | some criteria, or a mix representing a set of other sources. | |||
RTP Sink: A source that does not generate any RTP media stream in | RTP Sink: A source that does not generate any RTP media stream in | |||
itself (e.g. an endpoint or middlebox only receiving in an RTP | itself (e.g. an endpoint or middlebox only receiving in an RTP | |||
session). It still needs a sender SSRC for use as source in RTCP | session). It still needs a sender SSRC for use as source in RTCP | |||
reports. | reports. | |||
Note that a endpoint that generates more than one media type, e.g. a | Note that an endpoint that generates more than one media type, e.g. | |||
conference participant sending both audio and video, need not (and | a conference participant sending both audio and video, need not (and | |||
commonly does not) use the same SSRC value across RTP sessions. RTCP | commonly does not) use the same SSRC value across RTP sessions. RTCP | |||
Compound packets containing the CNAME SDES item is the designated | Compound packets containing the CNAME SDES item is the designated | |||
method to bind an SSRC to a CNAME, effectively cross-correlating | method to bind an SSRC to a CNAME, effectively cross-correlating | |||
SSRCs within and between RTP Sessions as coming from the same | SSRCs within and between RTP Sessions as coming from the same | |||
endpoint. The main property attributed to SSRCs associated with the | endpoint. The main property attributed to SSRCs associated with the | |||
same CNAME is that they are from a particular synchronisation context | same CNAME is that they are from a particular synchronisation context | |||
and can be synchronised at playback. | and can be synchronised at playback. | |||
An RTP receiver receiving a previously unseen SSRC value will | An RTP receiver receiving a previously unseen SSRC value will | |||
interpret it as a new source. It might in fact be a previously | interpret it as a new source. It might in fact be a previously | |||
existing source that had to change SSRC number due to an SSRC | existing source that had to change SSRC number due to an SSRC | |||
conflict. However, the originator of the previous SSRC ought to have | conflict. However, the originator of the previous SSRC ought to have | |||
ended the conflicting source by sending an RTCP BYE for it prior to | ended the conflicting source by sending an RTCP BYE for it prior to | |||
starting to send with the new SSRC, so the new SSRC is anyway | starting to send with the new SSRC, so the new SSRC is anyway | |||
effectively a new source. | effectively a new source. | |||
4.3. Contributing Source (CSRC) | 3.2.3. Contributing Source (CSRC) | |||
The Contributing Source (CSRC) is not a separate identifier. Rather | The Contributing Source (CSRC) is not a separate identifier. Rather | |||
a synchronisation source identifier is listed as a CSRC in the RTP | a synchronisation source identifier is listed as a CSRC in the RTP | |||
header of a packet generated by an RTP mixer if the corresponding | header of a packet generated by an RTP mixer if the corresponding | |||
SSRC was in the header of one of the packets that contributed to the | SSRC was in the header of one of the packets that contributed to the | |||
mix. | mix. | |||
It is not possible, in general, to extract media represented by an | It is not possible, in general, to extract media represented by an | |||
individual CSRC since it is typically the result of a media mixing | individual CSRC since it is typically the result of a media mixing | |||
(merge) operation by an RTP mixer on the individual media streams | (merge) operation by an RTP mixer on the individual media streams | |||
corresponding to the CSRC identifiers. The exception is the case | corresponding to the CSRC identifiers. The exception is the case | |||
when only a single CSRC is indicated as this represent forwarding of | when only a single CSRC is indicated as this represent forwarding of | |||
a media stream, possibly modified. The RTP header extension for | a media stream, possibly modified. The RTP header extension for | |||
Mixer-to-Client Audio Level Indication [RFC6465] expands on the | Mixer-to-Client Audio Level Indication [RFC6465] expands on the | |||
receivers information about a packet with a CSRC list. Due to these | receivers information about a packet with a CSRC list. Due to these | |||
restrictions, CSRC will not be considered a fully qualified | restrictions, CSRC will not be considered a fully qualified | |||
multiplexing point and will be disregarded in the rest of this | multiplexing point and will be disregarded in the rest of this | |||
document. | document. | |||
4.4. RTP Payload Type | 3.2.4. RTP Payload Type | |||
Each Media Stream utilises one or more RTP payload formats. An RTP | Each Media Stream utilises one or more RTP payload formats. An RTP | |||
payload format describes how the output of a particular media codec | payload format describes how the output of a particular media codec | |||
is framed and encoded into RTP packets. The payload format used is | is framed and encoded into RTP packets. The payload format used is | |||
identified by the payload type field in the RTP data packet header. | identified by the payload type field in the RTP data packet header. | |||
The combination therefore identifies a specific Media Stream encoding | The combination therefore identifies a specific Media Stream encoding | |||
format. The format definition can be taken from [RFC3551] for | format. The format definition can be taken from [RFC3551] for | |||
statically allocated payload types, but ought to be explicitly | statically allocated payload types, but ought to be explicitly | |||
defined in signalling, such as SDP, both for static and dynamic | defined in signalling, such as SDP, both for static and dynamic | |||
Payload Types. The term "format" here includes whatever can be | Payload Types. The term OCGBPformatOCOe here includes whatever can | |||
described by out-of-band signalling means. In SDP, the term "format" | be described by out-of-band signalling means. In SDP, the term | |||
includes media type, RTP timestamp sampling rate, codec, codec | OCGBPformatOCOe includes media type, RTP timestamp sampling rate, | |||
configuration, payload format configurations, and various robustness | codec, codec configuration, payload format configurations, and | |||
mechanisms such as redundant encodings [RFC2198]. | various robustness mechanisms such as redundant encodings [RFC2198]. | |||
The payload type is scoped by sending endpoint within an RTP Session. | The payload type is scoped by sending endpoint within an RTP Session. | |||
All synchronisation sources sent from an single endpoint share the | All synchronisation sources sent from a single endpoint share the | |||
same payload types definitions. The RTP Payload Type is designed | same payload types definitions. The RTP Payload Type is designed | |||
such that only a single Payload Type is valid at any time instant in | such that only a single Payload Type is valid at any time instant in | |||
the RTP source's RTP timestamp time line, effectively time- | the RTP source's RTP timestamp time line, effectively time- | |||
multiplexing different Payload Types if any change occurs. The | multiplexing different Payload Types if any change occurs. The | |||
payload type used can change on a per-packet basis for an SSRC, for | payload type used can change on a per-packet basis for an SSRC, for | |||
example a speech codec making use of generic comfort noise [RFC3389]. | example a speech codec making use of generic comfort noise [RFC3389]. | |||
If there is a true need to send multiple Payload Types for the same | If there is a true need to send multiple Payload Types for the same | |||
SSRC that are valid for the same instant, then redundant encodings | SSRC that are valid for the same instant, then redundant encodings | |||
[RFC2198] can be used. Several additional constraints than the ones | [RFC2198] can be used. Several additional constraints than the ones | |||
mentioned above need to be met to enable this use, one of which is | mentioned above need to be met to enable this use, one of which is | |||
that the combined payload sizes of the different Payload Types ought | that the combined payload sizes of the different Payload Types ought | |||
not exceed the transport MTU. | not exceed the transport MTU. | |||
Other aspects of RTP payload format use are described in RTP Payload | Other aspects of RTP payload format use are described in RTP Payload | |||
HowTo [I-D.ietf-payload-rtp-howto]. | HowTo [RFC8088]. | |||
The payload type is not a multiplexing point at the RTP layer (see | The payload type is not a multiplexing point at the RTP layer (see | |||
Appendix A for a detailed discussion of why using the payload type as | Appendix A for a detailed discussion of why using the payload type as | |||
an RTP multiplexing point does not work). The RTP payload type is, | an RTP multiplexing point does not work). The RTP payload type is, | |||
however, used to determine how to render a media stream, and so can | however, used to determine how to render a media stream, and so can | |||
be viewed as selecting a rendering context. The rendering context | be viewed as selecting a rendering context. The rendering context | |||
can be defined by the signalling, and the RTP payload type number is | can be defined by the signalling, and the RTP payload type number is | |||
sometimes used to associate an RTP media stream with the signalling. | sometimes used to associate an RTP media stream with the signalling. | |||
This association is possible provided unique RTP payload type numbers | This association is possible provided unique RTP payload type numbers | |||
are used in each context. For example, an RTP media stream can be | are used in each context. For example, an RTP media stream can be | |||
associated with an SDP "m=" line by comparing the RTP payload type | associated with an SDP OCGBPm=OCOe line by comparing the RTP payload | |||
numbers used by the media stream with payload types signalled in the | type numbers used by the media stream with payload types signalled in | |||
"a=rtpmap:" lines in the media sections of the SDP. If RTP media | the OCGBPa=rtpmap:OCOe lines in the media sections of the SDP. If | |||
streams are being associated with signalling contexts based on the | RTP media streams are being associated with signalling contexts based | |||
RTP payload type, then the assignment of RTP payload type numbers | on the RTP payload type, then the assignment of RTP payload type | |||
MUST be unique across signalling contexts; if the same RTP payload | numbers needs to be unique across signalling contexts; if the same | |||
format configuration is used in multiple contexts, then a different | RTP payload format configuration is used in multiple contexts, then a | |||
RTP payload type number has to be assigned in each context to ensure | different RTP payload type number has to be assigned in each context | |||
uniqueness. If the RTP payload type number is not being used to | to ensure uniqueness. If the RTP payload type number is not being | |||
associated RTP media streams with a signalling context, then the same | used to associated RTP media streams with a signalling context, then | |||
RTP payload type number can be used to indicate the exact same RTP | the same RTP payload type number can be used to indicate the exact | |||
payload format configuration in multiple contexts. | same RTP payload format configuration in multiple contexts. In case | |||
of bundled media, Section 10.2 of | ||||
[I-D.ietf-mmusic-sdp-bundle-negotiation] provides more information on | ||||
SDP signalling. | ||||
5. RTP Topologies and Issues | 3.3. Issues Related to RTP Topologies | |||
The impact of how RTP multiplexing is performed will in general vary | The impact of how RTP multiplexing is performed will in general vary | |||
with how the RTP Session participants are interconnected, described | with how the RTP Session participants are interconnected, described | |||
by RTP Topology [RFC5117] and its intended successor | by RTP Topology [RFC7667]. | |||
[I-D.westerlund-avtcore-rtp-topologies-update]. | ||||
5.1. Point to Point | ||||
Even the most basic use case, denoted Topo-Point-to-Point in | Even the most basic use case, denoted Topo-Point-to-Point in | |||
[I-D.westerlund-avtcore-rtp-topologies-update], raises a number of | [RFC7667], raises a number of considerations that are discussed in | |||
considerations that are discussed in detail below (Section 6). They | detail in following sections. They range over such aspects as: | |||
range over such aspects as: | ||||
o Does my communication peer support RTP as defined with multiple | o Does my communication peer support RTP as defined with multiple | |||
SSRCs? | SSRCs? | |||
o Do I need network differentiation in form of QoS? | o Do I need network differentiation in form of QoS? | |||
o Can the application more easily process and handle the media | o Can the application more easily process and handle the media | |||
streams if they are in different RTP sessions? | streams if they are in different RTP sessions? | |||
o Do I need to use additional media streams for RTP retransmission | o Do I need to use additional media streams for RTP retransmission | |||
or FEC. | or FEC. | |||
o etc. | o etc. | |||
The point to point topology can contain one to many RTP sessions with | For some Point to Multi-point topologies (e.g. Topo-ASM and Topo-SSM | |||
one to many media sources per session, each having one or more RTP | in [RFC7667]), multicast is used to interconnect the session | |||
sources per media source. | participants. Special considerations (documented in Section 4.2.3) | |||
need to be made as multicast is a one to many distribution system. | ||||
5.2. Translators & Gateways | ||||
A point to point communication can end up in a situation when the | Sometimes an RTP communication can end up in a situation when the | |||
peer it is communicating with is not compatible with the other peer | peer it is communicating with is not compatible with the other peer | |||
for various reasons: | for various reasons: | |||
o No common media codec for a media type thus requiring transcoding | o No common media codec for a media type thus requiring transcoding | |||
o Different support for multiple RTP sources and RTP sessions | o Different support for multiple RTP sources and RTP sessions | |||
o Usage of different media transport protocols, i.e RTP or other. | o Usage of different media transport protocols, i.e RTP or other. | |||
o Usage of different transport protocols, e.g. UDP, DCCP, TCP | o Usage of different transport protocols, e.g. UDP, DCCP, TCP | |||
o Different security solutions, e.g. IPsec, TLS, DTLS, SRTP with | o Different security solutions, e.g. IPsec, TLS, DTLS, 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 | |||
[I-D.westerlund-avtcore-rtp-topologies-update]. The translator's | [RFC7667]. The translator's main purpose is to make the peer look to | |||
main purpose is to make the peer look to the other peer like | the other peer like something it is compatible with. There can also | |||
something it is compatible with. There can also be other reasons | be other reasons than compatibility to insert a translator in the | |||
than compatibility to insert a translator in the form of a middlebox | form of a middlebox or gateway, for example a need to monitor the | |||
or gateway, for example a need to monitor the media streams. If the | media streams. If the stream transport characteristics are changed | |||
stream transport characteristics are changed by the translator, | by the translator, appropriate media handling can require thorough | |||
appropriate media handling can require thorough understanding of the | understanding of the application logic, specifically any congestion | |||
application logic, specifically any congestion control or media | control or media adaptation. | |||
adaptation. | ||||
5.3. Point to Multipoint Using Multicast | ||||
The Point to Multi-point topology is using Multicast to interconnect | ||||
the session participants. This includes both Topo-ASM and Topo-SSM | ||||
in [I-D.westerlund-avtcore-rtp-topologies-update]. | ||||
Special considerations need to be made as multicast is a one to many | ||||
distribution system. For example, the only practical method for | ||||
adapting the bit-rate sent towards a given receiver for large groups | ||||
is to use a set of multicast groups, where each multicast group | ||||
represents a particular bit-rate. Otherwise the whole group gets | ||||
media adapted to the participant with the worst conditions. The | ||||
media encoding is either scalable, where multiple layers can be | ||||
combined, or simulcast, where a single version is selected. By | ||||
either selecting or combing multicast groups, the receiver can | ||||
control the bit-rate sent on the path to itself. It is also common | ||||
that streams that improve transport robustness are sent in their own | ||||
multicast group to allow for interworking with legacy or to support | ||||
different levels of protection. | ||||
The result of this is some common behaviours for RTP multicast: | ||||
1. Multicast applications use a group of RTP sessions, not one. | ||||
Each endpoint will need to be a member of a number of RTP | ||||
sessions in order to perform well. | ||||
2. Within each RTP session, the number of RTP Sinks is likely to be | ||||
much larger than the number of RTP sources. | ||||
3. Multicast applications need signalling functions to identify the | ||||
relationships between RTP sessions. | ||||
4. Multicast applications need signalling functions to identify the | ||||
relationships between SSRCs in different RTP sessions. | ||||
All multicast configurations share a signalling requirement; all of | ||||
the participants will need to have the same RTP and payload type | ||||
configuration. Otherwise, A could for example be using payload type | ||||
97 as the video codec H.264 while B thinks it is MPEG-2. It is to be | ||||
noted that SDP offer/answer [RFC3264] is not appropriate for ensuring | ||||
this property. The signalling aspects of multicast are not explored | ||||
further in this memo. | ||||
Security solutions for this type of group communications are also | ||||
challenging. First of all the key-management and the security | ||||
protocol needs to support group communication. Source authentication | ||||
requires special solutions. For more discussion on this please | ||||
review Options for Securing RTP Sessions | ||||
[I-D.ietf-avtcore-rtp-security-options]. | ||||
5.4. Point to Multipoint Using an RTP Transport Translator | ||||
This mode is described as Topo-Translator in | ||||
[I-D.westerlund-avtcore-rtp-topologies-update]. | ||||
Transport Translators (Relays) result in an RTP session situation | ||||
that is very similar to how an ASM group RTP session would behave. | ||||
One of the most important aspects with the simple relay is that it is | ||||
only rewriting transport headers, no RTP modifications nor media | ||||
transcoding occur. The most obvious downside of this basic relaying | ||||
is that the translator has no control over how many streams need to | ||||
be delivered to a receiver. Nor can it simply select to deliver only | ||||
certain streams, as this creates session inconsistencies: If the | ||||
translator temporarily stops a stream, this prevents some receivers | ||||
from reporting on it. From the sender's perspective it will look | ||||
like a transport failure. Applications needing to stop or switch | ||||
streams in the central node ought to consider using an RTP mixer to | ||||
avoid this issue. | ||||
The Transport Translator has the same signalling requirement as | ||||
multicast: All participants need to have the same payload type | ||||
configuration. Most of the ASM security issues also arise here. | ||||
Some alternatives when it comes to solution do exist, as there exists | ||||
a central node to communicate with, one that also can enforce some | ||||
security policies depending on the level of trust placed in the node. | ||||
5.5. Point to Multipoint Using an RTP Mixer | ||||
A mixer, described by Topo-Mixer in | ||||
[I-D.westerlund-avtcore-rtp-topologies-update], is a centralised node | ||||
that selects or mixes content in a conference to optimise the RTP | ||||
session so that each endpoint only needs connect to one entity, the | ||||
mixer. The media sent from the mixer to the endpoint can be | ||||
optimised in different ways. These optimisations include methods | ||||
like only choosing media from the currently most active speaker or | ||||
mixing together audio so that only one audio stream is needed. | ||||
Mixers have some downsides, the first is that the mixer has to be a | ||||
trusted node as they repacketize the media, and can perform media | ||||
transformation operations. When using SRTP, both media operations | ||||
and repacketization requires that the mixer verifies integrity, | ||||
decrypts the content, performs the operation and forms new RTP | ||||
packets, encrypts and integrity-protects them. This applies to all | ||||
types of mixers. The second downside is that all these operations | ||||
and optimisations of the session requires processing. How much | ||||
depends on the implementation, as will become evident below. | ||||
A mixer, unlike a pure transport translator, is always application | The point to point topology can contain one to many RTP sessions with | |||
specific: the application logic for stream mixing or stream selection | one to many media sources per session, each having one or more RTP | |||
has to be embedded within the mixer, and controlled using application | sources per media source. | |||
specific signalling. The implementation of a mixer can take several | ||||
different forms, as discussed below. | ||||
A Mixer can also contain translator functionalities, like a media | 3.4. Issues Related to RTP and RTCP Protocol | |||
transcoder to adjust the media bit-rate or codec used for a | ||||
particular RTP media stream. | ||||
6. RTP Multiplexing: When to Use Multiple RTP Sessions | ||||
Using multiple media streams is a well supported feature of RTP. | Using multiple media streams is a well supported feature of RTP. | |||
However, it can be unclear for most implementers or people writing | However, it can be unclear for most implementers or people writing | |||
RTP/RTCP applications or extensions attempting to apply multiple | RTP/RTCP applications or extensions attempting to apply multiple | |||
streams when it is most appropriate to add an additional SSRC in an | streams when it is most appropriate to add an additional SSRC in an | |||
existing RTP session and when it is better to use multiple RTP | existing RTP session and when it is better to use multiple RTP | |||
sessions. This section tries to discuss the various considerations | sessions. This section tries to discuss the various considerations | |||
needed. The next section then concludes with some guidelines. | needed. | |||
6.1. RTP and RTCP Protocol Considerations | ||||
This section discusses RTP and RTCP aspects worth considering when | ||||
selecting between using an additional SSRC and Multiple RTP sessions. | ||||
6.1.1. The RTP Specification | 3.4.1. The RTP Specification | |||
RFC 3550 contains some recommendations and a bullet list with 5 | RFC 3550 contains some recommendations and a bullet list with 5 | |||
arguments for different aspects of RTP multiplexing. Let's review | arguments for different aspects of RTP multiplexing. Let's review | |||
Section 5.2 of [RFC3550], reproduced below: | Section 5.2 of [RFC3550], reproduced below: | |||
"For efficient protocol processing, the number of multiplexing points | OCGBPFor efficient protocol processing, the number of multiplexing | |||
should be minimised, as described in the integrated layer processing | points should be minimised, as described in the integrated layer | |||
design principle [ALF]. In RTP, multiplexing is provided by the | processing design principle [ALF]. In RTP, multiplexing is provided | |||
destination transport address (network address and port number) which | by the destination transport address (network address and port | |||
is different for each RTP session. For example, in a teleconference | number) which is different for each RTP session. For example, in a | |||
composed of audio and video media encoded separately, each medium | teleconference composed of audio and video media encoded separately, | |||
SHOULD be carried in a separate RTP session with its own destination | each medium SHOULD be carried in a separate RTP session with its own | |||
transport address. | destination transport address. | |||
Separate audio and video streams SHOULD NOT be carried in a single | Separate audio and video streams SHOULD NOT be carried in a single | |||
RTP session and demultiplexed based on the payload type or SSRC | RTP session and demultiplexed based on the payload type or SSRC | |||
fields. Interleaving packets with different RTP media types but | fields. Interleaving packets with different RTP media types but | |||
using the same SSRC would introduce several problems: | using the same SSRC would introduce several problems: | |||
1. If, say, two audio streams shared the same RTP session and the | 1. If, say, two audio streams shared the same RTP session and the | |||
same SSRC value, and one were to change encodings and thus | same SSRC value, and one were to change encodings and thus | |||
acquire a different RTP payload type, there would be no general | acquire a different RTP payload type, there would be no general | |||
way of identifying which stream had changed encodings. | way of identifying which stream had changed encodings. | |||
skipping to change at page 17, line 27 ¶ | skipping to change at page 14, line 27 ¶ | |||
RTP session would avoid the first three problems but not the last | RTP session would avoid the first three problems but not the last | |||
two. | two. | |||
On the other hand, multiplexing multiple related sources of the same | On the other hand, multiplexing multiple related sources of the same | |||
medium in one RTP session using different SSRC values is the norm for | medium in one RTP session using different SSRC values is the norm for | |||
multicast sessions. The problems listed above don't apply: an RTP | multicast sessions. The problems listed above don't apply: an RTP | |||
mixer can combine multiple audio sources, for example, and the same | mixer can combine multiple audio sources, for example, and the same | |||
treatment is applicable for all of them. It might also be | treatment is applicable for all of them. It might also be | |||
appropriate to multiplex streams of the same medium using different | appropriate to multiplex streams of the same medium using different | |||
SSRC values in other scenarios where the last two problems do not | SSRC values in other scenarios where the last two problems do not | |||
apply." | apply.OCOe | |||
Let's consider one argument at a time. The first is an argument for | Let's consider one argument at a time. The first is an argument for | |||
using different SSRC for each individual media stream, which is very | using different SSRC for each individual media stream, which is very | |||
applicable. | applicable. | |||
The second argument is advocating against using payload type | The second argument is advocating against using payload type | |||
multiplexing, which still stands as can been seen by the extensive | multiplexing, which still stands as can been seen by the extensive | |||
list of issues found in Appendix A. | list of issues found in Appendix A. | |||
The third argument is yet another argument against payload type | The third argument is yet another argument against payload type | |||
multiplexing. | multiplexing. | |||
The fourth is an argument against multiplexing media streams that | The fourth is an argument against multiplexing media streams that | |||
require different handling into the same session. As we saw in the | require different handling into the same session. As we saw in the | |||
discussion of RTP mixers, the RTP mixer has to embed application | discussion of RTP mixers, the RTP mixer has to embed application | |||
logic in order to handle streams anyway; the separation of streams | logic in order to handle streams anyway; the separation of streams | |||
according to stream type is just another piece of application logic, | according to stream type is just another piece of application logic, | |||
which might or might not be appropriate for a particular application. | which might or might not be appropriate for a particular application. | |||
A type of application that can mix different media sources "blindly" | A type of application that can mix different media sources | |||
is the audio only "telephone" bridge; most other type of application | OCGBPblindlyOCOe is the audio only OCGBPtelephoneOCOe bridge; most | |||
needs application-specific logic to perform the mix correctly. | other type of application needs application-specific logic to perform | |||
the mix correctly. | ||||
The fifth argument discusses network aspects that we will discuss | The fifth argument discusses network aspects that we will discuss | |||
more below in Section 6.3. It also goes into aspects of | more below in Section 4.2. It also goes into aspects of | |||
implementation, like decomposed endpoints where different processes | implementation, like decomposed endpoints where different processes | |||
or inter-connected devices handle different aspects of the whole | or inter-connected devices handle different aspects of the whole | |||
multi-media session. | 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 | |||
later is one thing which is further discussed in this document as | later is one thing which needs to be further discussed, as imposing a | |||
something the application developer needs to make a conscious choice | single solution on all usages of RTP is inappropriate. Multiple | |||
for, but where imposing a single solution on all usages of RTP is | Media Types in an RTP Session specification | |||
inappropriate. | [I-D.ietf-avtcore-multi-media-rtp-session] provides a detailed | |||
analysis of the potential issues in having multiple media types in | ||||
6.1.1.1. Different Media Types: Recommendations | the same RTP session. This document tries to provide an wider scoped | |||
The above quote from RTP [RFC3550] includes a strong recommendation: | ||||
"For example, in a teleconference composed of audio and video | ||||
media encoded separately, each medium SHOULD be carried in a | ||||
separate RTP session with its own destination transport address." | ||||
It was identified in "Why RTP Sessions Should Be Content Neutral" | ||||
[I-D.alvestrand-rtp-sess-neutral] that the above statement is poorly | ||||
supported by any of the motivations provided in the RTP | ||||
specification. This has resulted in the creation of a specification | ||||
Multiple Media Types in an RTP Session specification | ||||
[I-D.ietf-avtcore-multi-media-rtp-session] which intends to update | ||||
this recommendation. That document has a detailed analysis of the | ||||
potential issues in having multiple media types in the same RTP | ||||
session. This document tries to provide an moreover arching | ||||
consideration regarding the usage of RTP session and considers | consideration regarding the usage of RTP session and considers | |||
multiple media types in one RTP session as possible choice for the | multiple media types in one RTP session as possible choice for the | |||
RTP application designer. | RTP application designer. | |||
6.1.2. Multiple SSRCs in a Session | 3.4.2. Multiple SSRCs in a Session | |||
Using multiple SSRCs in an RTP session at one endpoint requires | Using multiple SSRCs in an RTP session at one endpoint 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 inefficencies. These are further discussed in | potential significant inefficiencies. These are further discussed in | |||
"RTP Considerations for Endpoints Sending Multiple Media Streams" | OCGBPRTP Considerations for Endpoints Sending Multiple Media | |||
[I-D.lennox-avtcore-rtp-multi-stream]. A application designer needs | StreamsOCOe [RFC8108]. A application designer needs to consider | |||
to consider these issues and the impact availability or lack of the | these issues and the impact availability or lack of the optimization | |||
optimization in the endpoints has on their application. | in the endpoints has on their application. | |||
If an application will become affected by the issues described, using | If an application will become affected by the issues described, using | |||
Multiple RTP sessions can mitigate these issues. | Multiple RTP sessions can mitigate these issues. | |||
6.1.3. Handling Varying Sets of Senders | 3.4.3. Binding Related Sources | |||
In some applications, the set of simultaneously active sources varies | ||||
within a larger set of session members. A receiver can then possibly | ||||
try to use a set of decoding chains that is smaller than the number | ||||
of senders, switching the decoding chains between different senders. | ||||
As each media decoding chain can contain state, either the receiver | ||||
needs to either be able to save the state of swapped-out senders, or | ||||
the sender needs to be able to send data that permits the receiver to | ||||
reinitialise when it resumes activity. | ||||
This behaviour will cause similar issues independent of Additional | ||||
SSRC or Multiple RTP session. | ||||
6.1.4. Cross Session RTCP Requests | ||||
There currently exists no functionality to make truly synchronised | ||||
and atomic RTCP messages with some type of request semantics across | ||||
multiple RTP Sessions. Instead, separate RTCP messages will have to | ||||
be sent in each session. This gives streams in the same RTP session | ||||
a slight advantage as RTCP messages for different streams in the same | ||||
session can be sent in a compound RTCP packet, thus providing an | ||||
atomic operation if different modifications of different streams are | ||||
requested at the same time. | ||||
When using multiple RTP sessions, the RTCP timing rules in the | ||||
sessions and the transport aspects, such as packet loss and jitter, | ||||
prevents a receiver from relying on atomic operations, forcing it to | ||||
use more robust and forgiving mechanisms. | ||||
6.1.5. Binding Related Sources | ||||
A common problem in a number of various RTP extensions has been how | A common problem in a number of various RTP extensions has been how | |||
to bind related RTP sources and their media streams together. This | to bind related RTP sources and their media streams together. This | |||
issue is common to both using additional SSRCs and Multiple RTP | issue is common to both using additional SSRCs and Multiple RTP | |||
sessions. | sessions. | |||
The solutions can be divided into some groups, RTP/RTCP based, | The solutions can be divided into some groups, RTP/RTCP based, | |||
Signalling based (SDP), grouping related RTP sessions, and grouping | Signalling based (SDP), grouping related RTP sessions, and grouping | |||
SSRCs within an RTP session. Most solutions are explicit, but some | SSRCs within an RTP session. Most solutions are explicit, but some | |||
implicit methods have also been applied to the problem. | implicit methods have also been applied to the problem. | |||
skipping to change at page 19, line 51 ¶ | skipping to change at page 16, line 4 ¶ | |||
The solutions can be divided into some groups, RTP/RTCP based, | The solutions can be divided into some groups, RTP/RTCP based, | |||
Signalling based (SDP), grouping related RTP sessions, and grouping | Signalling based (SDP), grouping related RTP sessions, and grouping | |||
SSRCs within an RTP session. Most solutions are explicit, but some | SSRCs within an RTP session. Most solutions are explicit, but some | |||
implicit methods have also been applied to the problem. | implicit methods have also been applied to the problem. | |||
The SDP-based signalling solutions are: | The SDP-based signalling solutions are: | |||
SDP Media Description Grouping: The SDP Grouping Framework [RFC5888] | SDP Media Description Grouping: The SDP Grouping Framework [RFC5888] | |||
uses various semantics to group any number of media descriptions. | uses various semantics to group any number of media descriptions. | |||
These has previously been considered primarily as grouping RTP | These has previously been considered primarily as grouping RTP | |||
sessions, but this might change. | sessions, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple | |||
media descriptors as a single RTP session. | ||||
SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576] | SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576] | |||
includes a solution for grouping SSRCs the same way as the | includes a solution for grouping SSRCs the same way as the | |||
Grouping framework groupes Media Descriptions. | Grouping framework groups Media Descriptions. | |||
SDP MSID grouping: Media Stream Identifiers [I-D.ietf-mmusic-msid] | SDP MSID grouping: Media Stream Identifiers [I-D.ietf-mmusic-msid] | |||
includes a solution for grouping SSRCs that is independent of | includes a solution for grouping SSRCs that is independent of | |||
their allocation to RTP sessions. | their allocation to RTP sessions. | |||
This supports a lot of use cases. All these solutions have | This supports a lot of use cases. All these solutions have | |||
shortcomings in cases where the session's dynamic properties are such | shortcomings in cases where the session's dynamic properties are such | |||
that it is difficult or resource consuming to keep the list of | that it is difficult or resource consuming to keep the list of | |||
related SSRCs up to date. | related SSRCs up to date. | |||
Within RTP/RTCP based solutions when binding to a endpoint or | Within RTP/RTCP based solutions when binding to an endpoint or | |||
synchronization context, i.e. the CNAME has not be sufficient and | synchronization context, i.e. the CNAME has not been sufficient and | |||
one has multiple RTP sessions has been to using the same SSRC value | one way to bind related streams in multiple RTP sessions has been to | |||
across all the RTP sessions. RTP Retransmission [RFC4588] is | use the same SSRC value across all the RTP sessions. RTP | |||
multiple RTP session mode, Generic FEC [RFC5109], as well as the RTP | Retransmission [RFC4588] is multiple RTP session mode, Generic FEC | |||
payload format for Scalable Video Coding [RFC6190] in Multi Session | [RFC5109], as well as the RTP payload format for Scalable Video | |||
Transmission (MST) mode uses this method. This method clearly works | Coding [RFC6190] in Multi Session Transmission (MST) mode uses this | |||
but might have some downside in RTP sessions with many participating | method. This method clearly works but might have some downside in | |||
SSRCs. The birthday paradox ensures that if you populate a single | RTP sessions with many participating SSRCs. The birthday paradox | |||
session with 9292 SSRCs at random, the chances are approximately 1% | ensures that if you populate a single session with 9292 SSRCs at | |||
that at least one collision will occur. When a collision occur this | random, the chances are approximately 1% that at least one collision | |||
will force one to change SSRC in all RTP sessions and thus | will occur. When a collision occur this will force one to change | |||
resynchronizing all of them instead of only the single media stream | SSRC in all RTP sessions and thus resynchronizing all of them instead | |||
having the collision. | of only the single media stream having the collision. Therefore it | |||
is not recommended to use such method. Using [RFC7656] streams from | ||||
the same media source should use the same RTP session. | ||||
It can be noted that Section 8.3 of the RTP Specification [RFC3550] | It can be noted that Section 8.3 of the RTP Specification [RFC3550] | |||
recommends using a single SSRC space across all RTP sessions for | recommends using a single SSRC space across all RTP sessions for | |||
layered coding. | layered coding. | |||
Another solution that has been applied to binding SSRCs has been an | Another solution that has been applied to binding SSRCs has been an | |||
implicit method used by RTP Retransmission [RFC4588] when doing | implicit method used by RTP Retransmission [RFC4588] when doing | |||
retransmissions in the same RTP session as the source RTP media | retransmissions in the same RTP session as the source RTP media | |||
stream. This issues an RTP retransmission request, and then await a | stream. This issues an RTP retransmission request, and then await a | |||
new SSRC carrying the RTP retransmission payload and where that SSRC | new SSRC carrying the RTP retransmission payload and where that SSRC | |||
is from the same CNAME. This limits a requestor to having only one | is from the same CNAME. This limits a requestor to having only one | |||
outstanding request on any new source SSRCs per endpoint. | outstanding request on any new source SSRCs per endpoint. | |||
There exists no RTP/RTCP based mechanism capable of supporting | [I-D.ietf-mmusic-rid] provides an RTP/RTCP based mechanism capable of | |||
explicit association accross multiple RTP sessions as well within an | supporting explicit association within an RTP session. | |||
RTP session. A proposed solution for handling this issue is | ||||
[I-D.westerlund-avtext-rtcp-sdes-srcname]. If accepted, this can | ||||
potentially also be part of an SDP based solution also by reusing the | ||||
same identifiers and name space. | ||||
6.1.6. Forward Error Correction | 3.4.4. Forward Error Correction | |||
There exist a number of Forward Error Correction (FEC) based schemes | There exist a number of Forward Error Correction (FEC) based schemes | |||
for how to reduce the packet loss of the original streams. Most of | for how to reduce the packet loss of the original streams. Most of | |||
the FEC schemes will protect a single source flow. The protection is | the FEC schemes will protect a single source flow. The protection is | |||
achieved by transmitting a certain amount of redundant information | achieved by transmitting a certain amount of redundant information | |||
that is encoded such that it can repair one or more packet losses | that is encoded such that it can repair one or more packet losses | |||
over the set of packets they protect. This sequence of redundant | over the set of packets they protect. This sequence of redundant | |||
information also needs to be transmitted as its own media stream, or | information also needs to be transmitted as its own media stream, or | |||
in some cases instead of the original media stream. Thus many of | in some cases instead of the original media stream. Thus many of | |||
these schemes create a need for binding related flows as discussed | these schemes create a need for binding related flows as discussed | |||
above. Looking at the history of these schemes, there are schemes | above. Looking at the history of these schemes, there are schemes | |||
using multiple SSRCs and schemes using multiple RTP sessions, and | using multiple SSRCs and schemes using multiple RTP sessions, and | |||
some schemes that support both modes of operation. | 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, it can easily be ignored. | placing it in a separate RTP session, it can easily be ignored. | |||
In usages involving multicast, having the FEC information on its own | In usages involving multicast, having the FEC information on its own | |||
multicast group, and therefore in its own RTP session, allows for | multicast group allows for flexibility. This is especially useful | |||
flexibility. This is especially useful when receivers see very | when receivers see very heterogeneous packet loss rates. Those | |||
heterogeneous packet loss rates. Those receivers that are not seeing | receivers that are not seeing packet loss don't need to join the | |||
packet loss don't need to join the multicast group with the FEC data, | multicast group with the FEC data, and so avoid the overhead of | |||
and so avoid the overhead of receiving unnecessary FEC packets, for | receiving unnecessary FEC packets, for example. | |||
example. | ||||
6.1.7. Transport Translator Sessions | ||||
A basic Transport Translator relays any incoming RTP and RTCP packets | 4. Particular Considerations for RTP Multiplexing | |||
to the other participants. The main difference between Additional | ||||
SSRCs and Multiple RTP Sessions resulting from this use case is that | ||||
with Additional SSRCs it is not possible for a particular session | ||||
participant to decide to receive a subset of media streams. When | ||||
using separate RTP sessions for the different sets of media streams, | ||||
a single participant can choose to leave one of the sessions but not | ||||
the other. | ||||
6.2. 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 related ones. The interworking between different | discusses two related ones. The interworking between different | |||
applications and the implications of potentially different choices of | applications and the implications of potentially different choices of | |||
usage of RTP's multiplexing points. The second topic relates to what | usage of RTP's multiplexing points. The second topic relates to what | |||
limitations have to be considered working with some legacy | limitations have to be considered working with some legacy | |||
applications. | applications. | |||
6.2.1. Types of Interworking | 4.1.1. Types of Interworking | |||
It is not uncommon that applications or services of similar usage, | It is not uncommon that applications or services of similar usage, | |||
especially the ones intended for interactive communication, encounter | especially the ones intended for interactive communication, encounter | |||
a situation where one want to interconnect two or more of these | a situation where one want to interconnect two or more of these | |||
applications. | applications. | |||
In these cases one ends up in a situation where one might use a | In these cases one ends up in a situation where one might use a | |||
gateway to interconnect applications. This gateway then needs to | gateway to interconnect applications. This gateway then needs to | |||
change the multiplexing structure or adhere to limitations in each | change the multiplexing structure or adhere to limitations in each | |||
application. | application. | |||
There are two fundamental approaches to gatewaying: RTP Translator | There are two fundamental approaches to gatewaying: RTP Translator | |||
interworking (RTP bridging), where the gateway acts as an RTP | interworking (RTP bridging), where the gateway acts as an RTP | |||
Translator, and the two applications are members of the same RTP | Translator, and the two applications are members of the same RTP | |||
session, and Gateway Interworking (with RTP termination), where there | session, and Gateway Interworking (with RTP termination), where there | |||
are independent RTP sessions running from each interconnected | are independent RTP sessions running from each interconnected | |||
application to the gateway. | application to the gateway. | |||
6.2.2. RTP Translator Interworking | 4.1.2. RTP Translator Interworking | |||
From an RTP perspective the RTP Translator approach could work if all | From an RTP perspective the RTP Translator approach could work if all | |||
the applications are using the same codecs with the same payload | the applications are using the same codecs with the same payload | |||
types, have made the same multiplexing choices, have the same | types, have made the same multiplexing choices, have the same | |||
capabilities in number of simultaneous media streams combined with | capabilities in number of simultaneous media streams combined with | |||
the same set of RTP/RTCP extensions being supported. Unfortunately | the same set of RTP/RTCP extensions being supported. Unfortunately | |||
this might not always be true. | this might not always be true. | |||
When one is gatewaying via an RTP Translator, a natural requirement | When one is gatewaying via an RTP Translator, a natural requirement | |||
is that the two applications being interconnected need to use the | is that the two applications being interconnected need to use the | |||
same approach to multiplexing. Furthermore, if one of the | same approach to multiplexing. Furthermore, if one of the | |||
applications is capable of working in several modes (such as being | applications is capable of working in several modes (such as being | |||
able to use Additional SSRCs or Multiple RTP sessions at will), and | able to use Additional SSRCs or Multiple RTP sessions at will), and | |||
the other one is not, successful interconnection depends on locking | the other one is not, successful interconnection depends on locking | |||
the more flexible application into the operating mode where | the more flexible application into the operating mode where | |||
interconnection can be successful, even if no participants using the | interconnection can be successful, even if no participants using the | |||
less flexible application are present when the RTP sessions are being | less flexible application are present when the RTP sessions are being | |||
created. | created. | |||
6.2.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 media streams | o Generating appropriate RTCP reports for all media streams | |||
(possibly based on incoming RTCP reports), originating from SSRCs | (possibly based on incoming RTCP reports), originating from SSRCs | |||
controlled by the gateway. | controlled 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. | |||
If either of the applications has any security applied, e.g. in the | For applications that uses any security mechanism, e.g. in the form | |||
form of SRTP, the gateway needs to be able to decrypt incoming | of SRTP, then the gateway needs to be able to decrypt incoming | |||
packets and re-encrypt them in the other application's security | packets and re-encrypt them 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, of course. | |||
Other tasks a gateway might need to apply include transcoding (for | Other tasks a gateway might need to apply include transcoding (for | |||
incompatible codec types), rescaling (for incompatible video size | incompatible codec types), 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 need of the | redundancy coding or scalability layers to fit the need of the | |||
skipping to change at page 23, line 39 ¶ | skipping to change at page 19, line 26 ¶ | |||
This fact reveals the potential for these gateways to block evolution | This fact reveals the potential for these gateways to block evolution | |||
of the applications by blocking unknown RTP and RTCP extensions that | of the applications by blocking unknown RTP and RTCP extensions that | |||
the regular application has been extended with. | the regular application has been extended with. | |||
If one uses security functions, like SRTP, they can as seen above | If one uses security functions, like SRTP, they can as seen above | |||
incur both additional risk due to the gateway needing to be in | incur both additional risk due to the gateway needing to be in | |||
security association between the endpoints, unless the gateway is on | security association between the endpoints, unless the gateway is on | |||
the transport level, and additional complexities in form of the | the transport level, and additional complexities in form of the | |||
decrypt-encrypt cycles needed for each forwarded packet. SRTP, due | decrypt-encrypt cycles needed for each forwarded packet. SRTP, due | |||
to its keying structure, also requires that each RTP session needs | to its keying structure, also requires that each RTP session needs | |||
different master keys, as use of the same key in two RTP sessions can | different master keys, as use of the same key in two RTP sessions for | |||
result in two-time pads that completely breaks the confidentiality of | some ciphers can result in two-time pads that completely breaks the | |||
the packets. | confidentiality of the packets. | |||
4.1.4. Multiple SSRC Legacy Considerations | ||||
6.2.4. Multiple SSRC Legacy Considerations | ||||
Historically, the most common RTP use cases have been point to point | Historically, the most common RTP use cases have been point to point | |||
Voice over IP (VoIP) or streaming applications, commonly with no more | Voice over IP (VoIP) or streaming applications, commonly with no more | |||
than one media source per endpoint and media type (typically audio | than one media source per endpoint and media type (typically audio | |||
and video). Even in conferencing applications, especially voice | and video). Even in conferencing applications, especially voice | |||
only, the conference focus or bridge has provided a single stream | only, the conference focus or bridge has provided a single stream | |||
with a mix of the other participants to each participant. It is also | with a mix of the other participants to each participant. 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. | |||
skipping to change at page 24, line 33 ¶ | skipping to change at page 20, line 12 ¶ | |||
3. Be capable of rendering multiple streams simultaneously. | 3. Be capable of rendering multiple streams simultaneously. | |||
This indicates that gateways attempting to interconnect to this class | This indicates that gateways attempting to interconnect to this class | |||
of devices has to make sure that only one media stream of each type | of devices has to make sure that only one media stream of each type | |||
gets delivered to the endpoint if it's expecting only one, and that | gets delivered to the endpoint if it's expecting only one, and that | |||
the multiplexing format is what the device expects. It is highly | the multiplexing format is what the device expects. It is highly | |||
unlikely that RTP translator-based interworking can be made to | unlikely that RTP translator-based interworking can be made to | |||
function successfully in such a context. | function successfully in such a context. | |||
6.3. Network Considerations | 4.2. Network Considerations | |||
The multiplexing choice has impact on network level mechanisms that | The multiplexing choice has impact on network level mechanisms that | |||
need to be considered by the implementor. | need to be considered by the implementer. | |||
6.3.1. Quality of Service | 4.2.1. Quality of Service | |||
When it comes to Quality of Service mechanisms, they are either flow | When it comes to Quality of Service mechanisms, they are either flow | |||
based or marking based. RSVP [RFC2205] is an example of a flow based | based or packet marking based. RSVP [RFC2205] is an example of a | |||
mechanism, while Diff-Serv [RFC2474] is an example of a Marking based | flow based mechanism, while Diff-Serv [RFC2474] is an example of a | |||
one. For a marking based scheme, the method of multiplexing will not | packet marking based one. For a packet marking based scheme, the | |||
affect the possibility to use QoS. | method of multiplexing will not affect the possibility to use QoS. | |||
However, for a flow based scheme there is a clear difference between | However, for a flow based scheme there is a clear difference between | |||
the methods. Additional SSRC will result in all media streams being | the methods. Additional SSRC will result in all media streams being | |||
part of the same 5-tuple (protocol, source address, destination | part of the same 5-tuple (protocol, source address, destination | |||
address, source port, destination port) which is the most common | address, source port, destination port) which is the most common | |||
selector for flow based QoS. Thus, separation of the level of QoS | selector for flow based QoS. | |||
between media streams is not possible. That is however possible when | ||||
using multiple RTP sessions, where each media stream for which a | ||||
separate QoS handling is desired can be in a different RTP session | ||||
that can be sent over different 5-tuples. | ||||
It also needs to be noted that packet marking based QoS mechanisms | It also needs to be noted that packet marking based QoS mechanisms | |||
can have limitations. A general observation is that different DSCP | can have limitations. A general observation is that different DSCP | |||
can be assigned to different packets within in a flow as well as | can be assigned to different packets within a flow as well as within | |||
within an RTP Media Stream. However, care needs to be taken when | an RTP Media Stream. However, care needs to be taken when | |||
considering which forwarding behaviours that are applied on path due | considering which forwarding behaviours that are applied on path due | |||
to these DSCPs. In some cases the forwarding behaviour can result in | to these DSCPs. In some cases the forwarding behaviour can result in | |||
packet reordering. For more discussion of this see | packet reordering. For more discussion of this see [RFC7657]. | |||
[I-D.ietf-dart-dscp-rtp]. | ||||
More specific to the choice between using one or more RTP session can | More specific to the choice between using one or more RTP session can | |||
be the method for assigning marking to packets. If this is done | be the method for assigning marking to packets. If this is done | |||
using a network ingress function, it can have issues discriminating | using a network ingress function, it can have issues discriminating | |||
the different RTP media streams. The network API on the endpoint | the different RTP media streams. The network API on the endpoint | |||
also needs to be capable of setting the marking on a per packet basis | also needs to be capable of setting the marking on a per packet basis | |||
to reach the full functionality. | to reach the full functionality. | |||
6.3.2. NAT and Firewall Traversal | 4.2.2. NAT and Firewall Traversal | |||
In today's network there exist a large number of middleboxes. The | In today's network there exist a large number of middleboxes. The | |||
ones that normally have most impact on RTP are Network Address | ones that normally have most impact on RTP are Network Address | |||
Translators (NAT) and Firewalls (FW). | Translators (NAT) and Firewalls (FW). | |||
Below we analyze and comment on the impact of requiring more | Below we analyse and comment on the impact of requiring more | |||
underlying transport flows in the presence of NATs and Firewalls: | underlying transport flows in the presence of NATs and Firewalls: | |||
End-Point Port Consumption: A given IP address only has 65536 | End-Point Port Consumption: A given IP address only has 65536 | |||
available local ports per transport protocol for all consumers of | available local ports per transport protocol for all consumers of | |||
ports that exist on the machine. This is normally never an issue | ports that exist on the machine. This is normally never an issue | |||
for an end-user machine. It can become an issue for servers that | for an end-user machine. It can become an issue for servers that | |||
handle large number of simultaneous streams. However, if the | handle large number of simultaneous streams. However, if the | |||
application uses ICE to authenticate STUN requests, a server can | application uses ICE to authenticate STUN requests, a server can | |||
serve multiple endpoints from the same local port, and use the | serve multiple endpoints from the same local port, and use the | |||
whole 5-tuple (source and destination address, source and | whole 5-tuple (source and destination address, source and | |||
skipping to change at page 26, line 16 ¶ | skipping to change at page 21, line 39 ¶ | |||
internal endpoints, available external ports are likely the scarce | internal endpoints, available external ports are likely the scarce | |||
resource. Port limitations is primarily a problem for larger | resource. Port limitations is primarily a problem for larger | |||
centralised NATs where endpoint independent mapping requires each | centralised NATs where endpoint independent mapping requires each | |||
flow to use one port for the external IP address. This affects | flow to use one port for the external IP address. This affects | |||
the maximum number of internal users per external IP address. | the maximum number of internal users per external IP address. | |||
However, it is worth pointing out that a real-time video | However, it is worth pointing out that a real-time video | |||
conference session with audio and video is likely using less than | conference session with audio and video is likely using less than | |||
10 UDP flows, compared to certain web applications that can use | 10 UDP flows, compared to certain web applications that can use | |||
100+ TCP flows to various servers from a single browser instance. | 100+ TCP flows to various servers from a single browser instance. | |||
NAT Traversal Excess Time: Making the NAT/FW traversal takes a | NAT Traversal Excess Time: Performing the NAT/FW traversal takes a | |||
certain amount of time for each flow. It also takes time in a | certain amount of time for each flow. It also takes time in a | |||
phase of communication between accepting to communicate and the | phase of communication between accepting to communicate and the | |||
media path being established which is fairly critical. The best | media path being established which is fairly critical. The best | |||
case scenario for how much extra time it takes after finding the | case scenario for how much extra time it takes after finding the | |||
first valid candidate pair following the specified ICE procedures | first valid candidate pair following the specified ICE procedures | |||
are: 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the pacing | are: 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the pacing | |||
timer, which ICE specifies to be no smaller than 20 ms. That | timer, which ICE specifies to be no smaller than 20 ms. That | |||
assumes a message in one direction, and then an immediate | assumes a message in one direction, and then an immediate | |||
triggered check back. The reason it isn't more, is that ICE first | triggered check back. The reason it isn't more, is that ICE first | |||
finds one candidate pair that works prior to attempting to | finds one candidate pair that works prior to attempting to | |||
skipping to change at page 26, line 41 ¶ | skipping to change at page 22, line 15 ¶ | |||
delays, at least 100 ms, which is the minimal retransmission timer | delays, at least 100 ms, which is the minimal retransmission timer | |||
for ICE. | for ICE. | |||
NAT Traversal Failure Rate: Due to the need to establish more than a | NAT Traversal Failure Rate: Due to the need to establish more than a | |||
single flow through the NAT, there is some risk that establishing | single flow through the NAT, there is some risk that establishing | |||
the first flow succeeds but that one or more of the additional | the first flow succeeds but that one or more of the additional | |||
flows fail. The risk that this happens is hard to quantify, but | flows fail. The risk that this happens is hard to quantify, but | |||
ought to be fairly low as one flow from the same interfaces has | ought to be fairly low as one flow from the same interfaces has | |||
just been successfully established. Thus only rare events such as | just been successfully established. Thus only rare events such as | |||
NAT resource overload, or selecting particular port numbers that | NAT resource overload, or selecting particular port numbers that | |||
are filtered etc, ought to be reasons for failure. | are filtered etc., ought to be reasons for failure. | |||
Deep Packet Inspection and Multiple Streams: Firewalls differ in how | Deep Packet Inspection and Multiple Streams: Firewalls differ in how | |||
deeply they inspect packets. There exist some potential that | deeply they inspect packets. There exist some potential that | |||
deeply inspecting firewalls will have similar legacy issues with | deeply inspecting firewalls will have similar legacy issues with | |||
multiple SSRCs as some stack implementations. | multiple SSRCs as some stack implementations. | |||
Additional SSRC keeps the additional media streams within one RTP | Additional SSRC keeps the additional media streams within one RTP | |||
Session and transport flow and does not introduce any additional NAT | Session and transport flow and does not introduce any additional NAT | |||
traversal complexities per media stream. This can be compared with | traversal complexities per media stream. This can be compared with | |||
normally one or two additional transport flows per RTP session when | normally one or two additional transport flows per RTP session when | |||
using multiple RTP sessions. Additional lower layer transport flows | using multiple RTP sessions. Additional lower layer transport flows | |||
will be needed, unless an explicit de-multiplexing layer is added | will be needed, unless an explicit de-multiplexing layer is added | |||
between RTP and the transport protocol. A proposal for how to | between RTP and the transport protocol. At time of writing no such | |||
multiplex multiple RTP sessions over the same single lower layer | mechanism was defined. | |||
transport exist in [I-D.westerlund-avtcore-transport-multiplexing]. | ||||
6.3.3. Multicast | 4.2.3. Multicast | |||
Multicast groups provides a powerful semantics for a number of real- | Multicast groups provides a powerful semantics for a number of real- | |||
time applications, especially the ones that desire broadcast-like | time applications, especially the ones that desire broadcast-like | |||
behaviours with one endpoint transmitting to a large number of | behaviours with one endpoint transmitting to a large number of | |||
receivers, like in IPTV. But that same semantics do result in a | receivers, like in IPTV. But that same semantics do result in a | |||
certain number of limitations. | certain number of limitations. | |||
One limitation is that for any group, sender side adaptation to the | One limitation is that for any group, sender side adaptation to the | |||
actual receiver properties causes degradation for all participants to | actual receiver properties causes degradation for all participants to | |||
what is supported by the receiver with the worst conditions among the | what is supported by the receiver with the worst conditions among the | |||
group participants. In most cases this is not acceptable. Instead | group participants. In most cases this is not acceptable. Instead | |||
various receiver based solutions are employed to ensure that the | various receiver based solutions are employed to ensure that the | |||
receivers achieve best possible performance. By using scalable | receivers achieve best possible performance. By using scalable | |||
encoding and placing each scalability layer in a different multicast | encoding and placing each scalability layer in a different multicast | |||
group, the receiver can control the amount of traffic it receives. | group, the receiver can control the amount of traffic it receives. | |||
To have each scalability layer on a different multicast group, one | To have each scalability layer on a different multicast group, one | |||
RTP session per multicast group is used. | RTP session per multicast group is used. | |||
In addition, the transport flow considerations in multicast are a bit | In addition, the transport flow considerations in multicast are a bit | |||
different from unicast; NATs are not useful in the multicast | different from unicast; NATs with port translation are not useful in | |||
environment, meaning that the entire port range of each multicast | the multicast environment, meaning that the entire port range of each | |||
address is available for distinguishing between RTP sessions. | multicast address is available for distinguishing between RTP | |||
sessions. | ||||
Thus it appears easiest and most straightforward to use multiple RTP | Thus it appears easiest and most straightforward to use multiple RTP | |||
sessions for sending different media flows used for adapting to | sessions for sending different media flows used for adapting to | |||
network conditions. | network conditions. It is also common that streams that improve | |||
transport robustness are sent in their own multicast group to allow | ||||
for interworking with legacy or to support different levels of | ||||
protection. | ||||
6.3.4. Multiplexing multiple RTP Session on a Single Transport | Here are some common behaviours for RTP multicast: | |||
For applications that don't need flow based QoS and like to save | 1. Multicast applications use a group of RTP sessions, not one. | |||
ports and NAT/FW traversal costs and where usage of multiple media | Each endpoint will need to be a member of a number of RTP | |||
types in one RTP session is not suitable, there is a proposal for how | sessions in order to perform well. | |||
to achieve multiplexing of multiple RTP sessions over the same lower | ||||
layer transport [I-D.westerlund-avtcore-transport-multiplexing]. | ||||
Using such a solution would allow Multiple RTP session without most | ||||
of the perceived downsides of Multiple RTP sessions creating a need | ||||
for additional transport flows, but this solution would require | ||||
support from all functions that handle RTP packets, including | ||||
firewalls. | ||||
6.4. Security and Key Management Considerations | 2. Within each RTP session, the number of RTP Sinks is likely to be | |||
much larger than the number of RTP sources. | ||||
3. Multicast applications need signalling functions to identify the | ||||
relationships between RTP sessions. | ||||
4. Multicast applications need signalling functions to identify the | ||||
relationships between SSRCs in different RTP sessions. | ||||
All multicast configurations share a signalling requirement; all of | ||||
the participants will need to have the same RTP and payload type | ||||
configuration. Otherwise, A could for example be using payload type | ||||
97 as the video codec H.264 while B thinks it is MPEG-2. It is to be | ||||
noted that SDP offer/answer [RFC3264] is not appropriate for ensuring | ||||
this property. The signalling aspects of multicast are not explored | ||||
further in this memo. | ||||
Security solutions for this type of group communications are also | ||||
challenging. First of all the key-management and the security | ||||
protocol needs to support group communication. Source authentication | ||||
requires special solutions. For more discussion on this please | ||||
review Options for Securing RTP Sessions [RFC7201]. | ||||
4.3. Security and Key Management Considerations | ||||
When dealing with point-to-point, 2-member RTP sessions only, there | When dealing with point-to-point, 2-member RTP sessions only, there | |||
are few security issues that are relevant to the choice of having one | are few security issues that are relevant to the choice of having one | |||
RTP session or multiple RTP sessions. However, there are a few | RTP session or multiple RTP sessions. However, there are a few | |||
aspects of multiparty sessions that might warrant consideration. For | aspects of multiparty sessions that might warrant consideration. For | |||
general information of possible methods of securing RTP, please | general information of possible methods of securing RTP, please | |||
review RTP Security Options [I-D.ietf-avtcore-rtp-security-options]. | review RTP Security Options [RFC7201]. | |||
6.4.1. Security Context Scope | 4.3.1. Security Context Scope | |||
When using SRTP [RFC3711] the security context scope is important and | When using SRTP [RFC3711] the security context scope is important and | |||
can be a necessary differentiation in some applications. As SRTP's | can be a necessary differentiation in some applications. As SRTP's | |||
crypto suites (so far) are built around symmetric keys, the receiver | crypto suites (so far) are built around symmetric keys, the receiver | |||
will need to have the same key as the sender. This results in that | will need to have the same key as the sender. This results in that | |||
no one in a multi-party session can be certain that a received packet | no one in a multi-party session can be certain that a received packet | |||
really was sent by the claimed sender or by another party having | really was sent by the claimed sender or by another party having | |||
access to the key. In most cases this is a sufficient security | access to the key. In most cases this is a sufficient security | |||
property, but there are a few cases where this does create issues. | property, but there are a few cases where this does create issues. | |||
skipping to change at page 28, line 47 ¶ | skipping to change at page 24, line 38 ¶ | |||
SRTP [RFC3711] has no special functions for dealing with different | SRTP [RFC3711] has no special functions for dealing with different | |||
sets of master keys for different SSRCs. The key-management | sets of master keys for different SSRCs. The key-management | |||
functions have different capabilities to establish different set of | functions have different capabilities to establish different set of | |||
keys, normally on a per endpoint basis. For example, DTLS-SRTP | keys, normally on a per endpoint basis. For example, DTLS-SRTP | |||
[RFC5764] and Security Descriptions [RFC4568] establish different | [RFC5764] and Security Descriptions [RFC4568] establish different | |||
keys for outgoing and incoming traffic from an endpoint. This key | keys for outgoing and incoming traffic from an endpoint. This key | |||
usage has to be written into the cryptographic context, possibly | usage has to be written into the cryptographic context, possibly | |||
associated with different SSRCs. | associated with different SSRCs. | |||
6.4.2. Key Management for Multi-party session | 4.3.2. Key Management for Multi-party session | |||
Performing key-management for multi-party session can be a challenge. | Performing key-management for multi-party session can be a challenge. | |||
This section considers some of the issues. | This section considers some of the issues. | |||
Multi-party sessions, such as transport translator based sessions and | Multi-party sessions, such as transport translator based sessions and | |||
multicast sessions, cannot use Security Description [RFC4568] nor | multicast sessions, cannot use Security Description [RFC4568] nor | |||
DTLS-SRTP [RFC5764] without an extension as each endpoint provides | DTLS-SRTP [RFC5764] without an extension as each endpoint provides | |||
its set of keys. In centralised conferences, the signalling | its set of keys. In centralised conferences, the signalling | |||
counterpart is a conference server and the media plane unicast | counterpart is a conference server and the media plane unicast | |||
counterpart (to which DTLS messages would be sent) is the transport | counterpart (to which DTLS messages would be sent) is the transport | |||
translator. Thus an extension like Encrypted Key Transport | translator. Thus an extension like Encrypted Key Transport | |||
[I-D.ietf-avt-srtp-ekt] is needed or a MIKEY [RFC3830] based solution | [I-D.ietf-avt-srtp-ekt] is needed or a MIKEY [RFC3830] based solution | |||
that allows for keying all session participants with the same master | that allows for keying all session participants with the same master | |||
key. | key. | |||
6.4.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 | |||
of the choice of multiplexing and topology. This becomes especially | of the choice of multiplexing and topology. This becomes especially | |||
evident in RTP topologies having any type of middlebox that processes | evident in RTP topologies having any type of middlebox that processes | |||
or modifies RTP/RTCP packets. Where there is very small overhead for | or modifies RTP/RTCP packets. Where there is very small overhead for | |||
an RTP translator or mixer to rewrite an SSRC value in the RTP packet | an RTP translator or mixer to rewrite an SSRC value in the RTP packet | |||
of an unencrypted session, the cost of doing it when using | of an unencrypted session, the cost of doing it when using | |||
cryptographic security functions is higher. For example if using | cryptographic security functions is higher. For example if using | |||
SRTP [RFC3711], the actual security context and exact crypto key are | SRTP [RFC3711], the actual security context and exact crypto key are | |||
determined by the SSRC field value. If one changes it, the | determined by the SSRC field value. If one changes it, the | |||
encryption and authentication tag needs to be performed using another | encryption and authentication tag needs to be performed using another | |||
key. Thus changing the SSRC value implies a decryption using the old | key. Thus changing the SSRC value implies a decryption using the old | |||
SSRC and its security context followed by an encryption using the new | SSRC and its security context followed by an encryption using the new | |||
one. | one. | |||
7. Archetypes | 5. Archetypes | |||
This section discusses some archetypes of how RTP multiplexing can be | This section discusses some archetypes of how RTP multiplexing can be | |||
used in applications to achieve certain goals and a summary of their | used in applications to achieve certain goals and a summary of their | |||
implications. For each archetype there is discussion of benefits and | implications. For each archetype there is discussion of benefits and | |||
downsides. | downsides. | |||
7.1. Single SSRC per Session | 5.1. Single SSRC per Session | |||
In this archetype each endpoint in a point-to-point session has only | In this archetype each endpoint in a point-to-point session has only | |||
a single SSRC, thus the RTP session contains only two SSRCs, one | a single SSRC, thus the RTP session contains only two SSRCs, one | |||
local and one remote. This session can be used both unidirectional, | local and one remote. This session can be used both unidirectional, | |||
i.e. only a single media stream or bi-directional, i.e. both | i.e. only a single media stream or bi-directional, i.e. both | |||
endpoints have one media stream each. If the application needs | endpoints have one media stream each. If the application needs | |||
additional media flows between the endpoints, they will have to | additional media flows between the endpoints, they will have to | |||
establish additional RTP sessions. | establish additional RTP sessions. | |||
The Pros: | The Pros: | |||
1. This archetype has great legacy interoperability potential as it | 1. This archetype has great legacy interoperability potential as it | |||
will not tax any RTP stack implementations. | will not tax any RTP stack implementations. | |||
2. The signalling has good possibilities to negotiate and describe | 2. The signalling has good possibilities to negotiate and describe | |||
skipping to change at page 30, line 45 ¶ | skipping to change at page 26, line 34 ¶ | |||
b. When the number of RTP sessions grows, the amount of explicit | b. When the number of RTP sessions grows, the amount of explicit | |||
state for relating media stream also grows, linearly or possibly | state for relating media stream also grows, linearly or possibly | |||
exponentially, depending on how the application needs to relate | exponentially, depending on how the application needs to relate | |||
media streams. | media streams. | |||
c. The port consumption might become a problem for centralised | c. The port consumption might become a problem for centralised | |||
services, where the central node's port consumption grows rapidly | services, where the central node's port consumption grows rapidly | |||
with the number of sessions. | with the number of sessions. | |||
d. For applications where the media streams are highly dynamic in | d. For applications where the media streams are highly dynamic in | |||
their usage, i.e. entering and leaving, the amount of signalling | their usage, i.e. entering and leaving, the amount of signalling | |||
can grow high. Issues arising from the timely establishment of | can grow high. Issues arising from the timely establishment of | |||
additional RTP sessions can also arise. | additional RTP sessions can also arise. | |||
e. Cross session RTCP requests might be needed, and the fact that | e. Cross session RTCP requests might be needed, and the fact that | |||
they're impossible can cause issues. | they're impossible can cause issues. | |||
f. If the same SSRC value is reused in multiple RTP sessions rather | f. If the same SSRC value is reused in multiple RTP sessions rather | |||
than being randomly chosen, interworking with applications that | than being randomly chosen, interworking with applications that | |||
uses another multiplexing structure than this application will | uses another multiplexing structure than this application will | |||
require SSRC translation. | require SSRC translation. | |||
skipping to change at page 31, line 32 ¶ | skipping to change at page 27, line 22 ¶ | |||
large number of media descriptions in SDP can also run into issues | large number of media descriptions in SDP can also run into issues | |||
with existing implementations. For any application needing a larger | with existing implementations. For any application needing a larger | |||
number of media flows, the overhead can become very significant. | number of media flows, the overhead can become very significant. | |||
This structure is also not suitable for multi-party sessions, as any | This structure is also not suitable for multi-party sessions, as any | |||
given media stream from each participant, although having same usage | given media stream from each participant, although having same usage | |||
in the application, needs its own RTP session. In addition, the | in the application, needs its own RTP session. In addition, the | |||
dynamic behaviour that can arise in multi-party applications can tax | dynamic behaviour that can arise in multi-party applications can tax | |||
the signalling system and make timely media establishment more | the signalling system and make timely media establishment more | |||
difficult. | difficult. | |||
7.2. Multiple SSRCs of the Same Media Type | 5.2. Multiple SSRCs of the Same Media Type | |||
In this archetype, each RTP session serves only a single media type. | In this archetype, each RTP session serves only a single media type. | |||
The RTP session can contain multiple media streams, either from a | The RTP session can contain multiple media streams, either from a | |||
single endpoint or from multiple endpoints. This commonly creates a | single endpoint or from multiple endpoints. This commonly creates a | |||
low number of RTP sessions, typically only one for audio and one for | low number of RTP sessions, typically only one for audio and one for | |||
video, with a corresponding need for two listening ports when using | video, with a corresponding need for two listening ports when using | |||
RTP/RTCP multiplexing. | RTP/RTCP multiplexing. | |||
The Pros: | The Pros: | |||
skipping to change at page 32, line 10 ¶ | skipping to change at page 27, line 49 ¶ | |||
2. Allows for early de-multiplexing in the processing chain in RTP | 2. Allows for early de-multiplexing in the processing chain in RTP | |||
applications where all media streams of the same type have the | applications where all media streams of the same type have the | |||
same usage in the application. | same usage in the application. | |||
3. Works well with media type de-composite endpoints. | 3. Works well with media type de-composite endpoints. | |||
4. Enables Flow-based QoS with different prioritisation between | 4. Enables Flow-based QoS with different prioritisation between | |||
media types. | media types. | |||
5. For applications with dynamic usage of media streams, i.e. they | 5. For applications with dynamic usage of media streams, i.e. they | |||
come and go frequently, having much of the state associated with | come and go frequently, having much of the state associated with | |||
the RTP session rather than an individual SSRC can avoid the need | the RTP session rather than an individual SSRC can avoid the need | |||
for in-session signalling of meta-information about each SSRC. | for in-session signalling of meta-information about each SSRC. | |||
6. Low overhead for security association establishment. | 6. Low overhead for security association establishment. | |||
The Cons: | The Cons: | |||
a. May have some need for cross session RTCP requests for things | a. May have some need for cross session RTCP requests for things | |||
that affect both media types in an asynchronous way. | that affect both media types in an asynchronous way. | |||
skipping to change at page 32, line 42 ¶ | skipping to change at page 28, line 32 ¶ | |||
share same usage, this structure provides efficiency gains in amount | share same usage, this structure provides efficiency gains in amount | |||
of network state used and provides more fate sharing with other media | of network state used and provides more fate sharing with other media | |||
flows of the same type. At the same time, it is still maintaining | flows of the same type. At the same time, it is still maintaining | |||
almost all functionalities when it comes to negotiation in the | almost all functionalities when it comes to negotiation in the | |||
signalling of the properties for the individual media type and also | signalling of the properties for the individual media type and also | |||
enabling flow based QoS prioritisation between media types. It | enabling flow based QoS prioritisation between media types. It | |||
handles multi-party session well, independently of multicast or | handles multi-party session well, independently of multicast or | |||
centralised transport distribution, as additional sources can | centralised transport distribution, as additional sources can | |||
dynamically enter and leave the session. | dynamically enter and leave the session. | |||
7.3. Multiple Sessions for one Media type | 5.3. Multiple Sessions for one Media type | |||
In this archetype one goes one step further than in the above | In this archetype one goes one step further than in the above | |||
(Section 7.2) by using multiple RTP sessions also for a single media | (Section 5.2) by using multiple RTP sessions also for a single media | |||
type, but still not as far as having a single SSRC per RTP session. | type, but still not as far as having a single SSRC per RTP session. | |||
The main reason for going in this direction is that the RTP | The main reason for going in this direction is that the RTP | |||
application needs separation of the media streams due to their usage. | application needs separation of the media streams due to their usage. | |||
Some typical reasons for going to this archetype are scalability over | Some typical reasons for going to this archetype are scalability over | |||
multicast, simulcast, need for extended QoS prioritisation of media | multicast, simulcast, need for extended QoS prioritisation of media | |||
streams due to their usage in the application, or the need for fine- | streams due to their usage in the application, or the need for fine- | |||
grained signalling using today's tools. | grained signalling using today's tools. | |||
The Pros: | The Pros: | |||
skipping to change at page 34, line 15 ¶ | skipping to change at page 30, line 7 ¶ | |||
will have difficulties establishing such a session. | will have difficulties establishing such a session. | |||
For more complex RTP applications that have several different usages | For more complex RTP applications that have several different usages | |||
for media streams of the same media type and / or uses scalability or | for media streams of the same media type and / or uses scalability or | |||
simulcast, this solution can enable those functions at the cost of | simulcast, this solution can enable those functions at the cost of | |||
increased overhead associated with the additional sessions. This | increased overhead associated with the additional sessions. This | |||
type of structure is suitable for more advanced applications as well | type of structure is suitable for more advanced applications as well | |||
as multicast based applications requiring differentiation to | as multicast based applications requiring differentiation to | |||
different participants. | different participants. | |||
7.4. Multiple Media Types in one Session | 5.4. Multiple Media Types in one Session | |||
This archetype is to use a single RTP session for multiple different | This archetype is to use a single RTP session for multiple different | |||
media types, like audio and video, and possibly also transport | media types, like audio and video, and possibly also transport | |||
robustness mechanisms like FEC or Retransmission. Each media stream | robustness mechanisms like FEC or Retransmission. Each media stream | |||
will use its own SSRC and a given SSRC value from a particular | will use its own SSRC and a given SSRC value from a particular | |||
endpoint will never use the SSRC for more than a single media type. | endpoint will never use the SSRC for more than a single media type. | |||
The Pros: | The Pros: | |||
1. Single RTP session which implies: | 1. Single RTP session which implies: | |||
skipping to change at page 35, line 31 ¶ | skipping to change at page 31, line 24 ¶ | |||
g. Additional concern with legacy implementations that do not | g. Additional concern with legacy implementations that do not | |||
support the RTP specification fully when it comes to handling | support the RTP specification fully when it comes to handling | |||
multiple SSRC per endpoint, as also multiple simultaneous media | multiple SSRC per endpoint, as also multiple simultaneous media | |||
types needs to be handled. | types needs to be handled. | |||
h. If the applications need finer control over which session | h. If the applications need finer control over which session | |||
participants that are included in different sets of security | participants that are included in different sets of security | |||
associations, most key-management will have difficulties | associations, most key-management will have difficulties | |||
establishing such a session. | establishing such a session. | |||
7.5. Summary | 5.5. Summary | |||
There are some clear relations between these archetypes. Both the | There are some clear relations between these archetypes. Both the | |||
"single SSRC per RTP session" and the "multiple media types in one | OCGBPsingle SSRC per RTP sessionOCOe and the OCGBPmultiple media | |||
session" are cases which require full explicit signalling of the | types in one sessionOCOe are cases which require full explicit | |||
media stream relations. However, they operate on two different | signalling of the media stream relations. However, they operate on | |||
levels where the first primarily enables session level binding, and | two different levels where the first primarily enables session level | |||
the second needs to do it all on SSRC level. From another | binding, and the second needs to do it all on SSRC level. From | |||
perspective, the two solutions are the two extreme points when it | another perspective, the two solutions are the two extreme points | |||
comes to number of RTP sessions needed. | when it comes to number of RTP sessions needed. | |||
The two other archetypes "Multiple SSRCs of the Same Media Type" and | ||||
"Multiple Sessions for one Media Type" are examples of two other | ||||
cases that first of all allows for some implicit mapping of the role | ||||
or usage of the media streams based on which RTP session they appear | ||||
in. It thus potentially allows for less signalling and in particular | ||||
reduced need for real-time signalling in dynamic sessions. They also | ||||
represent points in between the first two when it comes to amount of | ||||
RTP sessions established, i.e. representing an attempt to reduce the | ||||
amount of sessions as much as possible without compromising the | ||||
functionality the session provides both on network level and on | ||||
signalling level. | ||||
8. Summary considerations and guidelines | The two other archetypes OCGBPMultiple SSRCs of the Same Media | |||
TypeOCOe and OCGBPMultiple Sessions for one Media TypeOCOe are | ||||
examples of two other cases that first of all allows for some | ||||
implicit mapping of the role or usage of the media streams based on | ||||
which RTP session they appear in. It thus potentially allows for | ||||
less signalling and in particular reduced need for real-time | ||||
signalling in dynamic sessions. They also represent points in | ||||
between the first two when it comes to amount of RTP sessions | ||||
established, i.e. representing an attempt to reduce the amount of | ||||
sessions as much as possible without compromising the functionality | ||||
the session provides both on network level and on signalling level. | ||||
8.1. Guidelines | 6. Summary considerations and guidelines | |||
6.1. Guidelines | ||||
This section contains a number of recommendations for implementors or | This section contains a number of recommendations for implementers or | |||
specification writers when it comes to handling multi-stream. | specification writers when it comes to handling multi-stream. | |||
Do not Require the same SSRC across Sessions: As discussed in | Do not Require the same SSRC across Sessions: As discussed in | |||
Section 6.1.5 there exist drawbacks in using the same SSRC in | Section 3.4.3 there exist drawbacks in using the same SSRC in | |||
multiple RTP sessions as a mechanism to bind related media streams | multiple RTP sessions as a mechanism to bind related media streams | |||
together. It is instead suggested that a mechanism to explicitly | together. It is instead suggested that a mechanism to explicitly | |||
signal the relation is used, either in RTP/RTCP or in the used | signal the relation is used, either in RTP/RTCP or in the used | |||
signalling mechanism that establishes the RTP session(s). | signalling mechanism that establishes the RTP session(s). | |||
Use additional SSRCs additional Media Sources: In the cases where an | Use additional SSRCs for additional Media Sources: In the cases | |||
RTP endpoint needs to transmit additional media streams of the | where an RTP endpoint needs to transmit additional media streams | |||
same media type in the application, with the same processing | of the same media type in the application, with the same | |||
requirements at the network and RTP layers, it is suggested to | processing requirements at the network and RTP layers, it is | |||
send them as additional SSRCs in the same RTP session. For | suggested to send them as additional SSRCs in the same RTP | |||
example a telepresence room where there are three cameras, and | session. For example a telepresence room where there are three | |||
each camera captures 2 persons sitting at the table, sending each | cameras, and each camera captures 2 persons sitting at the table, | |||
camera as its own SSRC within a single RTP session is suggested. | sending each camera as its own SSRC within a single RTP session is | |||
suggested. | ||||
Use additional RTP sessions for streams with different requirements: | Use additional RTP sessions for streams with different requirements: | |||
When media streams have different processing requirements from the | When media streams have different processing requirements from the | |||
network or the RTP layer at the endpoints, it is suggested that | network or the RTP layer at the endpoints, it is suggested that | |||
the different types of streams are put in different RTP sessions. | the different types of streams are put in different RTP sessions. | |||
This includes the case where different participants want different | This includes the case where different participants want different | |||
subsets of the set of RTP streams. | subsets of the set of RTP streams. | |||
When using multiple RTP Sessions use grouping: When using Multiple | When using multiple RTP Sessions use grouping: When using Multiple | |||
RTP session solutions, it is suggested to explicitly group the | RTP session solutions, it is suggested to explicitly group the | |||
involved RTP sessions when needed using the signalling mechanism, | involved RTP sessions when needed using the signalling mechanism, | |||
for example The Session Description Protocol (SDP) Grouping | for example The Session Description Protocol (SDP) Grouping | |||
skipping to change at page 37, line 5 ¶ | skipping to change at page 32, line 40 ¶ | |||
the different types of streams are put in different RTP sessions. | the different types of streams are put in different RTP sessions. | |||
This includes the case where different participants want different | This includes the case where different participants want different | |||
subsets of the set of RTP streams. | subsets of the set of RTP streams. | |||
When using multiple RTP Sessions use grouping: When using Multiple | When using multiple RTP Sessions use grouping: When using Multiple | |||
RTP session solutions, it is suggested to explicitly group the | RTP session solutions, it is suggested to explicitly group the | |||
involved RTP sessions when needed using the signalling mechanism, | involved RTP sessions when needed using the signalling mechanism, | |||
for example The Session Description Protocol (SDP) Grouping | for example The Session Description Protocol (SDP) Grouping | |||
Framework. [RFC5888], using some appropriate grouping semantics. | Framework. [RFC5888], using some appropriate grouping semantics. | |||
RTP/RTCP Extensions May Support Additional SSRCs as well as Multiple RTP sessions: | RTP/RTCP Extensions May Support Additional SSRCs as well as Multiple | |||
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 usage with additional | consider if this extension is applicable to usage with additional | |||
SSRCs and Multiple RTP sessions. Any extension intended to be | SSRCs and Multiple RTP sessions. Any extension intended to be | |||
generic is suggested to support both. Applications that are not | generic is suggested to support both. Applications that are not | |||
as generally applicable will have to consider if interoperability | as generally applicable will have to consider if interoperability | |||
is better served by defining a single solution or providing both | is better served by defining a single solution or providing both | |||
options. | options. | |||
Transport Support Extensions: When defining new RTP/RTCP extensions | Transport Support Extensions: When defining new RTP/RTCP extensions | |||
intended for transport support, like the retransmission or FEC | intended for transport support, like the retransmission or FEC | |||
mechanisms, they are expected to include support for both | mechanisms, they are expected to include support for both | |||
additional SSRCs and multiple RTP sessions so that application | additional SSRCs and multiple RTP sessions so that application | |||
developers can choose freely from the set of mechanisms without | developers can choose freely from the set of mechanisms without | |||
concerning themselves with which of the multiplexing choices a | concerning themselves with which of the multiplexing choices a | |||
particular solution supports. | particular solution supports. | |||
9. IANA Considerations | 7. Open Issues | |||
There are currently some issues that needs to be resolved before this | ||||
document is ready to be published: | ||||
1. Use of RFC 2119 language is section on SSRC (3.2.2) | ||||
2. Better align source and sink terminolgy with Taxonomy | ||||
(Section 3.2.2) | ||||
3. Section on Binding Related Sources (Section 3.4.3) needs more | ||||
text on usage of the RID and other SDES based mechanisms created. | ||||
4. Does the MSID text need to be updated and clarified based on the | ||||
evoulsion of MSID since previous version. Section 3.4.3. | ||||
5. Section 4.1.2 (RTP Translator Interworking) needs to be updated. | ||||
It is not obvious that it is a natural requirement that the same | ||||
multiplexing is used. This needs better discussion. | ||||
6. Refernce to Ta for ICE being 20 ms will need to be updated due to | ||||
ICE update. | ||||
7. In Section 4.3.2 (Key Management for Multi-party session) the | ||||
reference to EKT needs to be updated, question is if draft-ietf- | ||||
perc-ekt-diet is appropriate here? | ||||
8. Can we find a more approriate term than archetypes? | ||||
9. | ||||
8. IANA Considerations | ||||
This document makes no request of IANA. | This document makes no request of IANA. | |||
Note to RFC Editor: this section can be removed on publication as an | Note to RFC Editor: this section can be removed on publication as an | |||
RFC. | RFC. | |||
10. Security Considerations | 9. Security Considerations | |||
There is discussion of the security implications of choosing SSRC vs | There is discussion of the security implications of choosing SSRC vs | |||
Multiple RTP session in Section 6.4. | Multiple RTP session in Section 4.3. | |||
11. References | 10. References | |||
11.1. Normative References | 10.1. Normative References | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <https://www.rfc-editor.org/info/rfc3550>. | ||||
11.2. Informative References | [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and | |||
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms | ||||
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, | ||||
DOI 10.17487/RFC7656, November 2015, | ||||
<https://www.rfc-editor.org/info/rfc7656>. | ||||
10.2. Informative References | ||||
[ALF] Clark, D. and D. Tennenhouse, "Architectural | [ALF] Clark, D. and D. Tennenhouse, "Architectural | |||
Considerations for a New Generation of Protocols", SIGCOMM | Considerations for a New Generation of Protocols", SIGCOMM | |||
Symposium on Communications Architectures and Protocols | Symposium on Communications Architectures and | |||
(Philadelphia, Pennsylvania), pp. 200--208, IEEE Computer | Protocols (Philadelphia, Pennsylvania), pp. 200--208, IEEE | |||
Communications Review, Vol. 20(4), September 1990. | Computer Communications Review, Vol. 20(4), September | |||
1990. | ||||
[I-D.alvestrand-rtp-sess-neutral] | ||||
Alvestrand, H., "Why RTP Sessions Should Be Content | ||||
Neutral", draft-alvestrand-rtp-sess-neutral-01 (work in | ||||
progress), June 2012. | ||||
[I-D.ietf-avt-srtp-ekt] | [I-D.ietf-avt-srtp-ekt] | |||
Wing, D., McGrew, D., and K. Fischer, "Encrypted Key | Wing, D., McGrew, D., and K. Fischer, "Encrypted Key | |||
Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 | Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 | |||
(work in progress), October 2011. | (work in progress), October 2011. | |||
[I-D.ietf-avtcore-6222bis] | ||||
Begen, A., Perkins, C., Wing, D., and E. Rescorla, | ||||
"Guidelines for Choosing RTP Control Protocol (RTCP) | ||||
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 | ||||
(work in progress), July 2013. | ||||
[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-05 (work in | ietf-avtcore-multi-media-rtp-session-13 (work in | |||
progress), February 2014. | progress), December 2015. | |||
[I-D.ietf-avtcore-rtp-security-options] | ||||
Westerlund, M. and C. Perkins, "Options for Securing RTP | ||||
Sessions", draft-ietf-avtcore-rtp-security-options-10 | ||||
(work in progress), January 2014. | ||||
[I-D.ietf-avtext-multiple-clock-rates] | ||||
Petit-Huguenin, M. and G. Zorn, "Support for Multiple | ||||
Clock Rates in an RTP Session", draft-ietf-avtext- | ||||
multiple-clock-rates-11 (work in progress), November 2013. | ||||
[I-D.ietf-dart-dscp-rtp] | ||||
Black, D. and P. Jones, "Differentiated Services | ||||
(DiffServ) and Real-time Communication", draft-ietf-dart- | ||||
dscp-rtp-07 (work in progress), September 2014. | ||||
[I-D.ietf-mmusic-msid] | [I-D.ietf-mmusic-msid] | |||
Alvestrand, H., "WebRTC MediaStream Identification in the | Alvestrand, H., "WebRTC MediaStream Identification in the | |||
Session Description Protocol", draft-ietf-mmusic-msid-06 | Session Description Protocol", draft-ietf-mmusic-msid-16 | |||
(work in progress), June 2014. | (work in progress), February 2017. | |||
[I-D.ietf-mmusic-rid] | ||||
Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., | ||||
Roach, A., and B. Campen, "RTP Payload Format | ||||
Restrictions", draft-ietf-mmusic-rid-11 (work in | ||||
progress), July 2017. | ||||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | [I-D.ietf-mmusic-sdp-bundle-negotiation] | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | Holmberg, C., Alvestrand, H., and C. Jennings, | |||
"Negotiating Media Multiplexing Using the Session | "Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | |||
negotiation-11 (work in progress), September 2014. | negotiation-39 (work in progress), August 2017. | |||
[I-D.ietf-payload-rtp-howto] | ||||
Westerlund, M., "How to Write an RTP Payload Format", | ||||
draft-ietf-payload-rtp-howto-13 (work in progress), | ||||
January 2014. | ||||
[I-D.lennox-avtcore-rtp-multi-stream] | ||||
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "RTP | ||||
Considerations for Endpoints Sending Multiple Media | ||||
Streams", draft-lennox-avtcore-rtp-multi-stream-02 (work | ||||
in progress), February 2013. | ||||
[I-D.lennox-mmusic-sdp-source-selection] | [I-D.lennox-mmusic-sdp-source-selection] | |||
Lennox, J. and H. Schulzrinne, "Mechanisms for Media | Lennox, J. and H. Schulzrinne, "Mechanisms for Media | |||
Source Selection in the Session Description Protocol | Source Selection in the Session Description Protocol | |||
(SDP)", draft-lennox-mmusic-sdp-source-selection-05 (work | (SDP)", draft-lennox-mmusic-sdp-source-selection-05 (work | |||
in progress), October 2012. | in progress), October 2012. | |||
[I-D.westerlund-avtcore-max-ssrc] | ||||
Westerlund, M., Burman, B., and F. Jansson, "Multiple | ||||
Synchronization sources (SSRC) in RTP Session Signaling", | ||||
draft-westerlund-avtcore-max-ssrc-02 (work in progress), | ||||
July 2012. | ||||
[I-D.westerlund-avtcore-rtp-topologies-update] | ||||
Westerlund, M. and S. Wenger, "RTP Topologies", draft- | ||||
westerlund-avtcore-rtp-topologies-update-02 (work in | ||||
progress), February 2013. | ||||
[I-D.westerlund-avtcore-transport-multiplexing] | ||||
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP | ||||
Sessions onto a Single Lower-Layer Transport", draft- | ||||
westerlund-avtcore-transport-multiplexing-07 (work in | ||||
progress), October 2013. | ||||
[I-D.westerlund-avtext-rtcp-sdes-srcname] | ||||
Westerlund, M., "RTCP Source Description Item SRCNAME to | ||||
Label Individual Media Sources", draft-westerlund-avtext- | ||||
rtcp-sdes-srcname-03 (work in progress), October 2013. | ||||
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., | [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., | |||
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- | Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- | |||
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, | Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, | |||
September 1997. | DOI 10.17487/RFC2198, September 1997, | |||
<https://www.rfc-editor.org/info/rfc2198>. | ||||
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. | [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | |||
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | |||
Functional Specification", RFC 2205, September 1997. | Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | |||
September 1997, <https://www.rfc-editor.org/info/rfc2205>. | ||||
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time | ||||
Streaming Protocol (RTSP)", RFC 2326, April 1998. | ||||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D.L. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, December | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
1998. | DOI 10.17487/RFC2474, December 1998, | |||
<https://www.rfc-editor.org/info/rfc2474>. | ||||
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | |||
Announcement Protocol", RFC 2974, October 2000. | Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, | |||
October 2000, <https://www.rfc-editor.org/info/rfc2974>. | ||||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | A., Peterson, J., Sparks, R., Handley, M., and E. | |||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | Schooler, "SIP: Session Initiation Protocol", RFC 3261, | |||
June 2002. | DOI 10.17487/RFC3261, June 2002, | |||
<https://www.rfc-editor.org/info/rfc3261>. | ||||
[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, June | with Session Description Protocol (SDP)", RFC 3264, | |||
2002. | DOI 10.17487/RFC3264, June 2002, | |||
<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, September 2002. | Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, | |||
September 2002, <https://www.rfc-editor.org/info/rfc3389>. | ||||
[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, | |||
July 2003. | DOI 10.17487/RFC3551, July 2003, | |||
<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, March 2004. | RFC 3711, DOI 10.17487/RFC3711, March 2004, | |||
<https://www.rfc-editor.org/info/rfc3711>. | ||||
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. | [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. | |||
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, | Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, | |||
August 2004. | 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, June 2005. | Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, | |||
<https://www.rfc-editor.org/info/rfc4103>. | ||||
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, July 2006. | Description Protocol", RFC 4566, DOI 10.17487/RFC4566, | |||
July 2006, <https://www.rfc-editor.org/info/rfc4566>. | ||||
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | |||
Description Protocol (SDP) Security Descriptions for Media | Description Protocol (SDP) Security Descriptions for Media | |||
Streams", RFC 4568, July 2006. | Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, | |||
<https://www.rfc-editor.org/info/rfc4568>. | ||||
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | |||
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | |||
July 2006. | DOI 10.17487/RFC4588, July 2006, | |||
<https://www.rfc-editor.org/info/rfc4588>. | ||||
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | |||
"Codec Control Messages in the RTP Audio-Visual Profile | "Codec Control Messages in the RTP Audio-Visual Profile | |||
with Feedback (AVPF)", RFC 5104, February 2008. | with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, | |||
February 2008, <https://www.rfc-editor.org/info/rfc5104>. | ||||
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error | ||||
Correction", RFC 5109, December 2007. | ||||
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, | [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error | |||
January 2008. | Correction", RFC 5109, DOI 10.17487/RFC5109, December | |||
2007, <https://www.rfc-editor.org/info/rfc5109>. | ||||
[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, June 2009. | (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, | |||
<https://www.rfc-editor.org/info/rfc5576>. | ||||
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding | ||||
Dependency in the Session Description Protocol (SDP)", RFC | ||||
5583, July 2009. | ||||
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and | [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and | |||
Control Packets on a Single Port", RFC 5761, April 2010. | Control Packets on a Single Port", RFC 5761, | |||
DOI 10.17487/RFC5761, April 2010, | ||||
<https://www.rfc-editor.org/info/rfc5761>. | ||||
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | |||
Security (DTLS) Extension to Establish Keys for the Secure | Security (DTLS) Extension to Establish Keys for the Secure | |||
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. | Real-time Transport Protocol (SRTP)", RFC 5764, | |||
DOI 10.17487/RFC5764, May 2010, | ||||
<https://www.rfc-editor.org/info/rfc5764>. | ||||
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | |||
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. | Protocol (SDP) Grouping Framework", RFC 5888, | |||
DOI 10.17487/RFC5888, June 2010, | ||||
<https://www.rfc-editor.org/info/rfc5888>. | ||||
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. | [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, | |||
Eleftheriadis, "RTP Payload Format for Scalable Video | "RTP Payload Format for Scalable Video Coding", RFC 6190, | |||
Coding", RFC 6190, May 2011. | DOI 10.17487/RFC6190, May 2011, | |||
<https://www.rfc-editor.org/info/rfc6190>. | ||||
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for | [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- | |||
Choosing RTP Control Protocol (RTCP) Canonical Names | time Transport Protocol (RTP) Header Extension for Mixer- | |||
(CNAMEs)", RFC 6222, April 2011. | to-Client Audio Level Indication", RFC 6465, | |||
DOI 10.17487/RFC6465, December 2011, | ||||
<https://www.rfc-editor.org/info/rfc6465>. | ||||
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, | [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
"Unicast-Based Rapid Acquisition of Multicast RTP | Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | |||
Sessions", RFC 6285, June 2011. | <https://www.rfc-editor.org/info/rfc7201>. | |||
[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time | [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services | |||
Transport Protocol (RTP) Header Extension for Mixer-to- | (Diffserv) and Real-Time Communication", RFC 7657, | |||
Client Audio Level Indication", RFC 6465, December 2011. | DOI 10.17487/RFC7657, November 2015, | |||
<https://www.rfc-editor.org/info/rfc7657>. | ||||
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | ||||
DOI 10.17487/RFC7667, November 2015, | ||||
<https://www.rfc-editor.org/info/rfc7667>. | ||||
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | ||||
and M. Stiemerling, Ed., "Real-Time Streaming Protocol | ||||
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December | ||||
2016, <https://www.rfc-editor.org/info/rfc7826>. | ||||
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", | ||||
RFC 8088, DOI 10.17487/RFC8088, May 2017, | ||||
<https://www.rfc-editor.org/info/rfc8088>. | ||||
[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, | ||||
"Sending Multiple RTP Streams in a Single RTP Session", | ||||
RFC 8108, DOI 10.17487/RFC8108, March 2017, | ||||
<https://www.rfc-editor.org/info/rfc8108>. | ||||
Appendix A. Dismissing Payload Type Multiplexing | Appendix A. Dismissing Payload Type Multiplexing | |||
This section documents a number of reasons why using the payload type | This section documents a number of reasons why using the payload type | |||
as a multiplexing point for most things related to multiple streams | as a multiplexing point for most things related to multiple streams | |||
is unsuitable. If one attempts to use Payload type multiplexing | is unsuitable. If one attempts to use Payload type multiplexing | |||
beyond it's defined usage, that has well known negative effects on | beyond it's defined usage, that has well known negative effects on | |||
RTP. To use Payload type as the single discriminator for multiple | RTP. To use Payload type as the single discriminator for multiple | |||
streams implies that all the different media streams are being sent | streams implies that all the different media streams are being sent | |||
with the same SSRC, thus using the same timestamp and sequence number | with the same SSRC, thus using the same timestamp and sequence number | |||
skipping to change at page 43, line 31 ¶ | skipping to change at page 39, line 49 ¶ | |||
is currently possible for RTP Sessions and for SSRC, but there | is currently possible for RTP Sessions and for SSRC, but there | |||
is no defined way to group Payload Types. | is no defined way to group Payload Types. | |||
10. It is currently not possible to signal bandwidth requirements | 10. It is currently not possible to signal bandwidth requirements | |||
per media stream when using Payload Type Multiplexing. | per media stream when using Payload Type Multiplexing. | |||
11. Most existing SDP media level attributes cannot be applied on a | 11. Most existing SDP media level attributes cannot be applied on a | |||
per Payload Type level and would require re-definition in that | per Payload Type level and would require re-definition in that | |||
context. | context. | |||
12. A legacy endpoint that doesn't understand the indication that | 12. A legacy endpoint that does not understand the indication that | |||
different RTP payload types are different media streams might be | different RTP payload types are different media streams might be | |||
slightly confused by the large amount of possibly overlapping or | slightly confused by the large amount of possibly overlapping or | |||
identically defined RTP Payload Types. | identically defined RTP Payload Types. | |||
Appendix B. Proposals for Future Work | Appendix B. Signalling considerations | |||
The above discussion and guidelines indicates that a small set of | ||||
extension mechanisms could greatly improve the situation when it | ||||
comes to using multiple streams independently of Multiple RTP session | ||||
or Additional SSRC. These extensions are: | ||||
Media Source Identification: A Media source identification that can | ||||
be used to bind together media streams that are related to the | ||||
same media source. A proposal | ||||
[I-D.westerlund-avtext-rtcp-sdes-srcname] exist for a new SDES | ||||
item SRCNAME that also can be used with the a=ssrc SDP attribute | ||||
to provide signalling layer binding information. | ||||
MSID: A Media Stream identification scheme that can be used to | ||||
signal relationships between SSRCs that can be in the same or in | ||||
different RTP sessions. Described in [I-D.ietf-mmusic-msid] | ||||
SSRC limitations within RTP sessions: By providing a signalling | ||||
solution that allows the signalling peers to explicitly express | ||||
both support and limitations on how many simultaneous media | ||||
streams an endpoint can handle within a given RTP Session. That | ||||
ensures that usage of Additional SSRC occurs when supported and | ||||
without overloading an endpoint. This extension is proposed in | ||||
[I-D.westerlund-avtcore-max-ssrc]. | ||||
Appendix C. Signalling considerations | ||||
Signalling is not an architectural consideration for RTP itself, so | Signalling is not an architectural consideration for RTP itself, so | |||
this discussion has been moved to an appendix. However, it is hugely | this discussion has been moved to an appendix. However, it is hugely | |||
important for anyone building complete applications, so it is | important for anyone building complete applications, so it is | |||
deserving of discussion. | deserving of discussion. | |||
The issues raised here need to be addressed in the WGs that deal with | The issues raised here need to be addressed in the WGs that deal with | |||
signalling; they cannot be addressed by tweaking, extending or | signalling; they cannot be addressed by tweaking, extending or | |||
profiling RTP. | profiling RTP. | |||
C.1. Signalling Aspects | B.1. Signalling Aspects | |||
There exist various signalling solutions for establishing RTP | There exist various signalling solutions for establishing RTP | |||
sessions. Many are SDP [RFC4566] based, however SDP functionality is | sessions. Many are SDP [RFC4566] based, however SDP functionality is | |||
also dependent on the signalling protocols carrying the SDP. Where | also dependent on the signalling protocols carrying the SDP. Where | |||
RTSP [RFC2326] and SAP [RFC2974] both use SDP in a declarative | RTSP [RFC7826] and SAP [RFC2974] both use SDP in a declarative | |||
fashion, while SIP [RFC3261] uses SDP with the additional definition | fashion, while SIP [RFC3261] uses SDP with the additional definition | |||
of Offer/Answer [RFC3264]. The impact on signalling and especially | of Offer/Answer [RFC3264]. The impact on signalling and especially | |||
SDP needs to be considered as it can greatly affect how to deploy a | SDP needs to be considered as it can greatly affect how to deploy a | |||
certain multiplexing point choice. | certain multiplexing point choice. | |||
C.1.1. Session Oriented Properties | B.1.1. Session Oriented Properties | |||
One aspect of the existing signalling is that it is focused around | One aspect of the existing signalling is that it is focused around | |||
sessions, or at least in the case of SDP the media description. | sessions, or at least in the case of SDP the media description. | |||
There are a number of things that are signalled on a session level/ | There are a number of things that are signalled on a session level/ | |||
media description but those are not necessarily strictly bound to an | media description but those are not necessarily strictly bound to an | |||
RTP session and could be of interest to signal specifically for a | RTP session and could be of interest to signal specifically for a | |||
particular media stream (SSRC) within the session. The following | particular media stream (SSRC) within the session. The following | |||
properties have been identified as being potentially useful to signal | properties have been identified as being potentially useful to signal | |||
not only on RTP session level: | not only on RTP session level: | |||
skipping to change at page 45, line 13 ¶ | skipping to change at page 41, line 4 ¶ | |||
limiting or RTCP signalling using TMMBR is used. | limiting or RTCP signalling using TMMBR is used. | |||
o Which SSRC that will use which RTP Payload Types (this will be | o Which SSRC that will use which RTP Payload Types (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 media streams with | additional SSRCs that contains several sets of media streams with | |||
different properties (encoding/packetization parameter, bit-rate, | different properties (encoding/packetization parameter, bit-rate, | |||
etc), putting each set in a different RTP session would directly | etc.), putting each set in a different RTP session would directly | |||
enable negotiation of the parameters for each set. If insisting on | enable negotiation of the parameters for each set. If insisting on | |||
additional SSRC only, a number of signalling extensions are needed to | additional SSRC only, a number of signalling extensions are needed to | |||
clarify that there are multiple sets of media streams with different | clarify that there are multiple sets of media streams with different | |||
properties and that they need in fact be kept different, since a | properties and that they need in fact be kept different, since a | |||
single set will not satisfy the application's requirements. | single set will not satisfy the application's requirements. | |||
For some parameters, such as resolution and framerate, a SSRC-linked | For some parameters, such as resolution and framerate, a SSRC-linked | |||
mechanism has been proposed: | mechanism has been proposed: | |||
[I-D.lennox-mmusic-sdp-source-selection]. | [I-D.lennox-mmusic-sdp-source-selection]. | |||
C.1.2. SDP Prevents Multiple Media Types | B.1.2. SDP Prevents Multiple Media Types | |||
SDP chose to use the m= line both to delineate an RTP session and to | SDP chose to use the m= line both to delineate an RTP session and to | |||
specify the top level of the MIME media type; audio, video, text, | specify the top level of the MIME media type; audio, video, text, | |||
image, application. This media type is used as the top-level media | image, application. This media type is used as the top-level media | |||
type for identifying the actual payload format bound to a particular | type for identifying the actual payload format bound to a particular | |||
payload type using the rtpmap attribute. This binding has to be | payload type using the rtpmap attribute. This binding has to be | |||
loosened in order to use SDP to describe RTP sessions containing | loosened in order to use SDP to describe RTP sessions containing | |||
multiple MIME top level types. | multiple MIME top level types. | |||
There is an accepted WG item in the MMUSIC WG to define how multiple | There is an accepted WG item in the MMUSIC WG to define how multiple | |||
media lines describe a single underlying transport | media lines describe a single underlying transport | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] and thus it becomes possible | [I-D.ietf-mmusic-sdp-bundle-negotiation] and thus it becomes possible | |||
in SDP to define one RTP session with media types having different | in SDP to define one RTP session with media types having different | |||
MIME top level types. | MIME top level types. | |||
C.1.3. Signalling Media Stream Usage | B.1.3. Signalling Media Stream Usage | |||
Media streams being transported in RTP has some particular usage in | Media streams being transported in RTP has some particular usage in | |||
an RTP application. This usage of the media stream is in many | an RTP application. This usage of the media 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 media streams there will be more than a single usage or | use multiple media streams there will be more than a single usage or | |||
purpose among the set of media streams being sent or received. RTP | purpose among the set of media 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 media streams affected by their RTP- | used will have to identify the media streams affected by their RTP- | |||
skipping to change at page 46, line 25 ¶ | skipping to change at page 42, line 17 ¶ | |||
If this signalling affects how any RTP central node, like an RTP | If this signalling affects how any RTP central node, like an RTP | |||
mixer or translator that selects, mixes or processes streams, treats | mixer or translator that selects, mixes or processes streams, treats | |||
the streams, the node will also need to receive the same signalling | the streams, the node will also need to receive the same signalling | |||
to know how to treat media streams with different usage in the right | to know how to treat media streams with different usage in the right | |||
fashion. | fashion. | |||
Authors' Addresses | Authors' Addresses | |||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Farogatan 6 | Torshamsgatan 23 | |||
SE-164 80 Kista | SE-164 80 Kista | |||
Sweden | Sweden | |||
Phone: +46 10 714 82 87 | Phone: +46 10 714 82 87 | |||
Email: magnus.westerlund@ericsson.com | Email: magnus.westerlund@ericsson.com | |||
Bo Burman | Bo Burman | |||
Ericsson | Ericsson | |||
Farogatan 6 | Farogatan 6 | |||
SE-164 80 Kista | SE-164 80 Kista | |||
skipping to change at page 47, line 4 ¶ | skipping to change at page 42, line 40 ¶ | |||
Phone: +46 10 714 13 11 | Phone: +46 10 714 13 11 | |||
Email: bo.burman@ericsson.com | Email: bo.burman@ericsson.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
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 | ||||
Huawei | ||||
Email: roni.even@huawei.com | ||||
Hui Zheng | ||||
Huawei | ||||
Email: marvin.zhenghui@huawei.com | ||||
End of changes. 183 change blocks. | ||||
703 lines changed or deleted | 520 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/ |