draft-ietf-avtcore-multiplex-guidelines-07.txt | draft-ietf-avtcore-multiplex-guidelines-08.txt | |||
---|---|---|---|---|
Network Working Group M. Westerlund | Network Working Group M. Westerlund | |||
Internet-Draft B. Burman | Internet-Draft B. Burman | |||
Intended status: Informational Ericsson | Intended status: Informational Ericsson | |||
Expires: June 10, 2019 C. Perkins | Expires: June 17, 2019 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
H. Alvestrand | H. Alvestrand | |||
R. Even | R. Even | |||
Huawei | Huawei | |||
December 07, 2018 | December 14, 2018 | |||
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-07 | draft-ietf-avtcore-multiplex-guidelines-08 | |||
Abstract | Abstract | |||
The Real-time Transport Protocol (RTP) is a flexible protocol that | The Real-time Transport Protocol (RTP) is a flexible protocol that | |||
can be used in a wide range of applications, networks, and system | can be used in a wide range of applications, networks, and system | |||
topologies. That flexibility makes for wide applicability, but can | topologies. That flexibility makes for wide applicability, but can | |||
complicate the application design process. One particular design | complicate the application design process. One particular design | |||
question that has received much attention is how to support multiple | question that has received much attention is how to support multiple | |||
media streams in RTP. This memo discusses the available options and | media streams in RTP. This memo discusses the available options and | |||
design trade-offs, and provides guidelines on how to use the | design trade-offs, and provides guidelines on how to use the | |||
skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 10, 2019. | This Internet-Draft will expire on June 17, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Subjects Out of Scope . . . . . . . . . . . . . . . . . . 5 | 2.2. Subjects Out of Scope . . . . . . . . . . . . . . . . . . 5 | |||
3. RTP Multiplexing Overview . . . . . . . . . . . . . . . . . . 5 | 3. RTP Multiplexing Overview . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Reasons for Multiplexing and Grouping RTP Streams . . . . 5 | 3.1. Reasons for Multiplexing and Grouping RTP Streams . . . . 5 | |||
3.2. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6 | 3.2. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6 | |||
3.2.1. RTP Session . . . . . . . . . . . . . . . . . . . . . 7 | 3.2.1. RTP Session . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.2. Synchronisation Source (SSRC) . . . . . . . . . . . . 8 | 3.2.2. Synchronisation Source (SSRC) . . . . . . . . . . . . 8 | |||
3.2.3. Contributing Source (CSRC) . . . . . . . . . . . . . 9 | 3.2.3. Contributing Source (CSRC) . . . . . . . . . . . . . 10 | |||
3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 10 | 3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 10 | |||
3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 | 3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 11 | |||
3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 12 | 3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 12 | |||
3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 12 | 3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 13 | |||
3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 14 | 3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 15 | |||
3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 14 | 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15 | |||
3.4.4. Forward Error Correction . . . . . . . . . . . . . . 16 | 3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17 | |||
4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17 | 4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17 | |||
4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 | 4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 | |||
4.1.1. Application Interworking . . . . . . . . . . . . . . 17 | 4.1.1. Application Interworking . . . . . . . . . . . . . . 17 | |||
4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 17 | 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18 | |||
4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 | 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 18 | |||
4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 | 4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 19 | |||
4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 | 4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 | |||
4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 | 4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 | |||
4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 20 | 4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 21 | |||
4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 | 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 22 | |||
4.3. Security and Key Management Considerations . . . . . . . 23 | 4.3. Security and Key Management Considerations . . . . . . . 24 | |||
4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 | 4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 | |||
4.3.2. Key Management for Multi-party sessions . . . . . . . 24 | 4.3.2. Key Management for Multi-party sessions . . . . . . . 25 | |||
4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 | 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 25 | |||
5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 25 | 5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26 | |||
5.1. Multiple Media Types in one Session . . . . . . . . . . . 25 | 5.1. Multiple Media Types in one Session . . . . . . . . . . . 26 | |||
5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 26 | 5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 27 | |||
5.3. Multiple Sessions for one Media type . . . . . . . . . . 28 | 5.3. Multiple Sessions for one Media type . . . . . . . . . . 28 | |||
5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 29 | 5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 29 | |||
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 33 | 10.2. Informative References . . . . . . . . . . . . . . . . . 33 | |||
Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 37 | Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 37 | |||
Appendix B. Signalling Considerations . . . . . . . . . . . . . 39 | Appendix B. Signalling Considerations . . . . . . . . . . . . . 39 | |||
B.1. Session Oriented Properties . . . . . . . . . . . . . . . 39 | B.1. Session Oriented Properties . . . . . . . . . . . . . . . 40 | |||
B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 40 | B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 40 | |||
B.3. Signalling RTP stream Usage . . . . . . . . . . . . . . . 40 | B.3. Signalling RTP stream Usage . . . . . . . . . . . . . . . 41 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used | The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used | |||
protocol for real-time media transport. It is a protocol that | protocol for real-time media transport. It is a protocol that | |||
provides great flexibility and can support a large set of different | provides great flexibility and can support a large set of different | |||
applications. RTP was from the beginning designed for multiple | applications. RTP was from the beginning designed for multiple | |||
participants in a communication session. It supports many topology | participants in a communication session. It supports many topology | |||
paradigms and usages, as defined in [RFC7667]. RTP has several | paradigms and usages, as defined in [RFC7667]. RTP has several | |||
skipping to change at page 4, line 39 ¶ | skipping to change at page 4, line 39 ¶ | |||
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 | In this document, it will be used to refer to situations where | |||
more than two endpoints communicate. | more than two endpoints communicate. | |||
Multiplexing: The operation of taking multiple entities as input, | Multiplexing: The operation of taking multiple entities as input, | |||
aggregating them onto some common resource while keeping the | aggregating them onto some common resource while keeping the | |||
individual entities addressable such that they can later be fully | individual entities addressable such that they can later be fully | |||
and unambiguously separated (de-multiplexed) again. | and unambiguously separated (de-multiplexed) again. | |||
RTP Receiver: An Endpoint or Middlebox receiving RTP streams and | ||||
RTCP messages. It uses at least one SSRC to send RTCP messages. | ||||
An RTP Receiver may also be an RTP sender. | ||||
RTP Sender: An Endpoint sending one or more RTP streams, but also | ||||
sending RTCP messages. | ||||
RTP Session Group: One or more RTP sessions that are used together | RTP Session Group: One or more RTP sessions that are used together | |||
to perform some function. Examples are multiple RTP sessions used | to perform some function. Examples are multiple RTP sessions used | |||
to carry different layers of a layered encoding. In an RTP | to carry different layers of a layered encoding. In an RTP | |||
Session Group, CNAMEs are assumed to be valid across all RTP | Session Group, CNAMEs are assumed to be valid across all RTP | |||
sessions, and designate synchronisation contexts that can cross | sessions, and designate synchronisation contexts that can cross | |||
RTP sessions; i.e. SSRCs that map to a common CNAME can be assumed | RTP sessions; i.e. SSRCs that map to a common CNAME can be assumed | |||
to have RTCP SR timing information derived from a common clock | to have RTCP SR timing information derived from a common clock | |||
such that they can be synchronised for playout. | such that they can be synchronised for playout. | |||
Signalling: The process of configuring endpoints to participate in | Signalling: The process of configuring endpoints to participate in | |||
one or more RTP sessions. | one or more RTP sessions. | |||
Note: The above definitions of RTP Receiver and RTP sender are | ||||
intended to be consistent with the usage in [RFC3550]. | ||||
2.2. Subjects Out of Scope | 2.2. Subjects Out of Scope | |||
This document is focused on issues that affect RTP. Thus, issues | This document is focused on issues that affect RTP. Thus, issues | |||
that involve signalling protocols, such as whether SIP, Jingle or | that involve signalling protocols, such as whether SIP, 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. | |||
skipping to change at page 7, line 38 ¶ | skipping to change at page 8, line 20 ¶ | |||
For RTP session separation within a single endpoint, RTP relies on | For RTP session separation within a single endpoint, RTP relies on | |||
the underlying transport layer, and on the signalling to identify RTP | the underlying transport layer, and on the signalling to identify RTP | |||
sessions in a manner that is meaningful to the application. A single | sessions in a manner that is meaningful to the application. A single | |||
endpoint can have one or more transport flows for the same RTP | endpoint can have one or more transport flows for the same RTP | |||
session, and a single RTP session can span multiple transport layer | session, and a single RTP session can span multiple transport layer | |||
flows. The signalling layer might give RTP sessions an explicit | flows. The signalling layer might give RTP sessions an explicit | |||
identifier, or the identification might be implicit based on the | identifier, or the 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 endpoint can identify and delimit an RTP session from other RTP | |||
RTP sessions by receiving the multiple UDP flows used as identified | sessions by receiving the multiple UDP flows used as identified based | |||
based on their UDP source and destination IP addresses and UDP port | on their UDP source and destination IP addresses and UDP port | |||
numbers. Another example is SDP media descriptions (the "m=" line | numbers. Another example is SDP media descriptions (the "m=" line | |||
and the following associated lines) signals the transport flow and | and the following associated lines) signals the transport flow and | |||
RTP session configuration for the endpoints part of the RTP session. | RTP session configuration for the endpoints part of the RTP session. | |||
SDP grouping framework [RFC5888] allows labeling of the media | SDP grouping framework [RFC5888] allows labeling of the media | |||
descriptions, for example used so that RTP Session Groups can be | descriptions, for example used so that RTP Session Groups can be | |||
created. With Negotiating Media Multiplexing Using the Session | created. With Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)[I-D.ietf-mmusic-sdp-bundle-negotiation], | Description Protocol (SDP)[I-D.ietf-mmusic-sdp-bundle-negotiation], | |||
multiple media descriptions where each represents the RTP streams | multiple media descriptions where each represents the RTP streams | |||
sent or received for a media source are part of a common RTP session. | sent or received for a media source are part of a common RTP session. | |||
skipping to change at page 8, line 15 ¶ | skipping to change at page 8, line 46 ¶ | |||
of the relationship between the sessions they create. | of the relationship between the sessions they create. | |||
3.2.2. Synchronisation Source (SSRC) | 3.2.2. Synchronisation Source (SSRC) | |||
A synchronisation source (SSRC) identifies an source of an RTP stream | A synchronisation source (SSRC) identifies an source of an RTP stream | |||
or an RTP receiver when sending RTCP. Every endpoint has at least | or an RTP receiver when sending RTCP. Every endpoint has at least | |||
one SSRC identifier, even if it does not send RTP packets. RTP | one SSRC identifier, even if it does not send RTP packets. RTP | |||
endpoints that are only RTP receivers still send RTCP and use their | endpoints that are only RTP receivers still send RTCP and use their | |||
SSRC identifiers in the RTCP packets they send. An endpoint can have | SSRC identifiers in the RTCP packets they send. An endpoint can have | |||
multiple SSRC identifiers if it sends multiple RTP streams. | multiple SSRC identifiers if it sends multiple RTP streams. | |||
Endpoints that are both RTP streams sender and RTP receiver use the | Endpoints that are both RTP sender and RTP receiver use the same SSRC | |||
same SSRC in both roles. | in both roles. | |||
The SSRC is a 32-bit identifier. It is present in every RTP and RTCP | The SSRC is a 32-bit identifier. It is present in every RTP and RTCP | |||
packet header, and in the payload of some RTCP packet types. It can | packet header, and in the payload of some RTCP packet types. It can | |||
also be present in SDP signalling. Unless pre-signalled, e.g. using | also be present in SDP signalling. Unless pre-signalled, e.g. using | |||
the SDP "a=ssrc:" attribute [RFC5576], the SSRC is chosen at random. | the SDP "a=ssrc:" attribute [RFC5576], the SSRC is chosen at random. | |||
It is not dependent on the network address of the endpoint, and is | It is not dependent on the network address of the endpoint, and is | |||
intended to be unique within an RTP session. SSRC collisions can | intended to be unique within an RTP session. SSRC collisions can | |||
occur, and are handled as specified in [RFC3550] and [RFC5576], | occur, and are handled as specified in [RFC3550] and [RFC5576], | |||
resulting in the SSRC of the colliding RTP streams or receivers | resulting in the SSRC of the colliding RTP streams or receivers | |||
changing. An RTP sending endpoint that changes its network transport | changing. An endpoint that changes its network transport address | |||
address during a session have to choose a new SSRC identifier to | during a session have to choose a new SSRC identifier to avoid being | |||
avoid being interpreted as looped source, unless the transport layer | interpreted as looped source, unless the transport layer mechanism, | |||
mechanism, e.g ICE [RFC8445], handles such changes. | e.g ICE [RFC8445], handles such changes. | |||
SSRC identifiers that belong to the same synchronisation context | SSRC identifiers that belong to the same synchronisation context | |||
(i.e., that represent RTP streams that can be synchronised using | (i.e., that represent RTP streams that can be synchronised using | |||
information in RTCP SR packets) use identical CNAME chunks in | information in RTCP SR packets) use identical CNAME chunks in | |||
corresponding RTCP SDES packets. SDP signalling can also be used to | corresponding RTCP SDES packets. SDP signalling can also be used to | |||
provide explicit SSRC grouping [RFC5576]. | provide explicit SSRC grouping [RFC5576]. | |||
In some cases, the same SSRC identifier value is used to relate | In some cases, the same SSRC identifier value is used to relate | |||
streams in two different RTP sessions, such as in RTP retransmission | streams in two different RTP sessions, such as in RTP retransmission | |||
[RFC4588]. This is to be avoided since there is no guarantee that | [RFC4588]. This is to be avoided since there is no guarantee that | |||
SSRC values are unique across RTP sessions. For the RTP | SSRC values are unique across RTP sessions. For the RTP | |||
retransmission [RFC4588] case it is recommended to use explicit | retransmission [RFC4588] case it is recommended to use explicit | |||
binding of the source RTP stream and the redundancy stream, e.g. | binding of the source RTP stream and the redundancy stream, e.g. | |||
using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. | using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. | |||
Note that RTP sequence number and RTP timestamp are scoped by the | Note that RTP sequence number and RTP timestamp are scoped by the | |||
SSRC and thus specific per RTP stream. | SSRC and thus specific per RTP stream. | |||
An SSRC identifier is used by different type of sources as well as | Different types of entities use a SSRC to identify themselves, as | |||
receivers: | follows: | |||
Real Media Source: Connected to a "physical" media source, for | A real media source: Uses the SSRC to identify a "physical" media | |||
example a camera or microphone. | source. | |||
Conceptual Media Source: A media source with some attributed | A conceptual media source: Uses the SSRC to identify the result of | |||
property generated by some network node, for example a filtering | applying some filtering function in a network node, for example a | |||
function in an RTP mixer that provides the most active speaker | filtering function in an RTP mixer that provides the most active | |||
based on some criteria, or a mix representing a set of other | speaker based on some criteria, or a mix representing a set of | |||
sources. | other sources. | |||
RTP receiver: A receiver that does not generate any RTP stream | An RTP receiver: Uses the SSRC to identify itself as the source of | |||
themself (e.g. an endpoint or middlebox only receiving in an RTP | its RTCP reports. | |||
session). It still needs an SSRC for use as source in RTCP | ||||
reports. | ||||
Note that an endpoint that generates more than one media type, e.g. | Note that an endpoint that generates more than one media type, e.g. | |||
a conference participant sending both audio and video, need not (and | a conference participant sending both audio and video, need not (and | |||
should not) use the same SSRC value across RTP sessions. RTCP | should 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 | |||
skipping to change at page 15, line 4 ¶ | skipping to change at page 15, line 33 ¶ | |||
3.4.3. Binding Related Sources | 3.4.3. Binding Related Sources | |||
A common problem in a number of various RTP extensions has been how | A common problem in a number of various RTP extensions has been how | |||
to bind related RTP streams together. This issue is common to both | to bind related RTP streams together. This issue is common to both | |||
using additional SSRCs and multiple RTP sessions. | using additional SSRCs and multiple RTP sessions. | |||
The solutions can be divided into a few groups: | The solutions can be divided into a few groups: | |||
o RTP/RTCP based | o RTP/RTCP based | |||
o Signalling based (SDP) | o Signalling based (SDP) | |||
o grouping related RTP sessions | o Grouping related RTP sessions | |||
o grouping SSRCs within an RTP session | o Grouping SSRCs within an RTP session | |||
Most solutions are explicit, but some implicit methods have also been | Most solutions are explicit, but some implicit methods have also been | |||
applied to the problem. | applied to the problem. | |||
The SDP-based signalling solutions are: | The SDP-based signalling solutions are: | |||
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, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple | sessions, [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple | |||
skipping to change at page 17, line 38 ¶ | skipping to change at page 18, line 19 ¶ | |||
There are two fundamental approaches to building a gateway: using an | There are two fundamental approaches to building a gateway: using an | |||
RTP Translator interworking (RTP bridging), where the gateway acts as | RTP Translator interworking (RTP bridging), where the gateway acts as | |||
an RTP Translator, with the two applications being members of the | an RTP Translator, with the two applications being members of the | |||
same RTP session; or Gateway Interworking with RTP termination, where | same RTP session; or Gateway Interworking with RTP termination, where | |||
there are independent RTP sessions running from each interconnected | there are independent RTP sessions running from each interconnected | |||
application to the gateway. | application to the gateway. | |||
4.1.2. RTP Translator Interworking | 4.1.2. RTP Translator Interworking | |||
From an RTP perspective the RTP Translator approach could work if all | From an RTP perspective, the RTP Translator approach could work if | |||
the applications are using the same codecs with the same payload | all the applications are using the same codecs with the same payload | |||
types, have made the same multiplexing choices, and have the same | types, have made the same multiplexing choices, and have the same | |||
capabilities in number of simultaneous RTP streams combined with the | capabilities in number of simultaneous RTP streams combined with the | |||
same set of RTP/RTCP extensions being supported. Unfortunately, this | same set of RTP/RTCP extensions being supported. Unfortunately, this | |||
might not always be true. | might not always be true. | |||
When a gateway is implemented via an RTP Translator, an important | When a gateway is implemented via an RTP Translator, an important | |||
consideration is if the two applications being interconnected need to | consideration is if the two applications being interconnected need to | |||
use the same approach to multiplexing. If one side is using RTP | use the same approach to multiplexing. If one side is using RTP | |||
session multiplexing and the other is using SSRC multiplexing with | session multiplexing and the other is using SSRC multiplexing with | |||
bundle, the mapping of SDP "m=" lines between both sides requires | bundle, it is possible for the RTP translator to map the RTP streams | |||
that the order in bundled and not bundled sides will be the same to | between both sides if the order of SDP "m=" lines between both sides | |||
allow routing without mapping, it is possible for the RTP translator | are the same. There are also challenges with SSRC collision handling | |||
to map the RTP streams between both sides. There are also challenges | since there may be a collision on the SSRC multiplexing side but the | |||
with SSRC collision handling since there may be a collision on the | RTP session multiplexing side will not be aware of any collision | |||
SSRC multiplexing side but the RTP session multiplexing side will not | unless SSRC translation is applied on the RTP translator. | |||
be aware of any collision unless SSRC translation is applied on the | Furthermore, if one of the applications is capable of working in | |||
RTP translator. Furthermore, if one of the applications is capable | several modes (such as being able to use additional RTP streams in | |||
of working in several modes (such as being able to use additional RTP | one RTP session or multiple RTP sessions at will), and the other one | |||
streams in one RTP session or multiple RTP sessions at will), and the | is not, successful interconnection depends on locking the more | |||
other one is not, successful interconnection depends on locking the | flexible application into the operating mode where interconnection | |||
more flexible application into the operating mode where | can be successful, even if no participants are using the less | |||
interconnection can be successful, even if no participants are using | flexible application when the RTP sessions are being created. | |||
the less flexible application when the RTP sessions are being | ||||
created. | ||||
4.1.3. Gateway Interworking | 4.1.3. Gateway Interworking | |||
When one terminates RTP sessions at the gateway, there are certain | When one terminates RTP sessions at the gateway, there are certain | |||
tasks that the gateway has to carry out: | tasks that the gateway has to carry out: | |||
o Generating appropriate RTCP reports for all RTP streams (possibly | o Generating appropriate RTCP reports for all RTP streams (possibly | |||
based on incoming RTCP reports), originating from SSRCs controlled | based on incoming RTCP reports), originating from SSRCs controlled | |||
by the gateway. | by the gateway. | |||
skipping to change at page 22, line 30 ¶ | skipping to change at page 23, line 6 ¶ | |||
protocol. At time of writing no such mechanism was defined. | protocol. At time of writing no such mechanism was defined. | |||
4.2.3. Multicast | 4.2.3. Multicast | |||
Multicast groups provides a powerful tool for a number of real-time | Multicast groups provides a powerful tool for a number of real-time | |||
applications, especially the ones that desire broadcast-like | applications, especially the ones that desire broadcast-like | |||
behaviours with one endpoint transmitting to a large number of | behaviours with one endpoint transmitting to a large number of | |||
receivers, like in IPTV. There are also the RTP/RTCP extension to | receivers, like in IPTV. There are also the RTP/RTCP extension to | |||
better support Source Specific Multicast (SSM) [RFC5760]. Another | better support Source Specific Multicast (SSM) [RFC5760]. Another | |||
application is the Many to Many communication, which RTP [RFC3550] | application is the Many to Many communication, which RTP [RFC3550] | |||
was originally built to support. But the multicast semantics do | was originally built to support, but the multicast semantics do | |||
result in a certain number of limitations. | result in a certain number of limitations. | |||
One limitation is that for any group, sender side adaptation to the | One limitation is that for any group, sender side adaptation 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. For broadcast type of applications this is not | group participants. For broadcast type of applications this is not | |||
acceptable. Instead, various receiver-based solutions are employed | acceptable. Instead, various receiver-based solutions are employed | |||
to ensure that the receivers achieve best possible performance. By | to ensure that the receivers achieve best possible performance. By | |||
using scalable encoding and placing each scalability layer in a | using scalable encoding and placing each scalability layer in a | |||
different multicast group, the receiver can control the amount of | different multicast group, the receiver can control the amount of | |||
skipping to change at page 23, line 9 ¶ | skipping to change at page 23, line 33 ¶ | |||
multicast address is available for distinguishing between RTP | multicast address is available for distinguishing between RTP | |||
sessions. | sessions. | |||
Thus, when using broadcast applications it appears easiest and most | Thus, when using broadcast applications it appears easiest and most | |||
straightforward to use multiple RTP sessions for sending different | straightforward to use multiple RTP sessions for sending different | |||
media flows used for adapting to network conditions. It is also | media flows used for adapting to network conditions. It is also | |||
common that streams that improve transport robustness are sent in | common that streams that improve transport robustness are sent in | |||
their own multicast group to allow for interworking with legacy or to | their own multicast group to allow for interworking with legacy or to | |||
support different levels of protection. | support different levels of protection. | |||
For many to many applications there is different needs. Here it will | For many to many applications there are different needs. Here, the | |||
depend on how the actual application is realized what is the most | most appropriate choice will depend on how the actual application is | |||
appropriate choice. With sender side congestion control there might | realized. With sender side congestion control there might not exist | |||
not exist any benefit with using multiple RTP session. | any benefit with using multiple RTP sessions. | |||
The properties of a broadcast application using RTP multicast: | The properties of a broadcast application using RTP multicast: | |||
1. Uses a group of RTP sessions, not one. Each endpoint will need | 1. Uses a group of RTP sessions, not one. Each endpoint will need | |||
to be a member of a number of RTP sessions in order to perform | to be a member of a number of RTP sessions in order to perform | |||
well. | well. | |||
2. Within each RTP session, the number of RTP receivers is likely to | 2. Within each RTP session, the number of RTP receivers is likely to | |||
be much larger than the number of RTP senders. | be much larger than the number of RTP senders. | |||
3. The applications need signalling functions to identify the | 3. The applications need signalling functions to identify the | |||
relationships between RTP sessions. | relationships between RTP sessions. | |||
4. The applications need signalling or RTP/RTCP functions to | 4. The applications need signalling or RTP/RTCP functions to | |||
identify the relationships between SSRCs in different RTP | identify the relationships between SSRCs in different RTP | |||
sessions when needs beyond CNAME exists. | sessions when needs beyond CNAME exist. | |||
Both broadcast and many to many multicast applications do share a | Both broadcast and many to many multicast applications do share a | |||
signalling requirement; all of the participants will need to have the | signalling requirement; all of the participants will need to have the | |||
same RTP and payload type configuration. Otherwise, A could for | same RTP and payload type configuration. Otherwise, A could for | |||
example be using payload type 97 as the video codec H.264 while B | 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 | thinks it is MPEG-2. It is to be noted that SDP offer/answer | |||
[RFC3264] is not appropriate for ensuring this property in broadcast/ | [RFC3264] is not appropriate for ensuring this property in broadcast/ | |||
multicast context. The signalling aspects of broadcast/multicast are | multicast context. The signalling aspects of broadcast/multicast are | |||
not explored further in this memo. | not explored further in this memo. | |||
Security solutions for this type of group communications are also | Security solutions for this type of group communications are also | |||
challenging. First, the key-management and the security protocol | challenging. First, the key-management and the security protocol | |||
needs to support group communication. Second, source authentication | need to support group communication. Second, source authentication | |||
requires special solutions. For more discussion on this please | requires special solutions. For more discussion on this please | |||
review Options for Securing RTP Sessions [RFC7201]. | review Options for Securing RTP Sessions [RFC7201]. | |||
4.3. Security and Key Management Considerations | 4.3. Security and Key Management Considerations | |||
When dealing with point-to-point, 2-member RTP sessions only, there | When dealing with point-to-point, 2-member RTP sessions only, there | |||
are few security issues that are relevant to the choice of having one | are few security issues that are relevant to the choice of having one | |||
RTP session or multiple RTP sessions. However, there are a few | RTP session or multiple RTP sessions. However, there are a few | |||
aspects of multiparty sessions that might warrant consideration. For | aspects of multiparty sessions that might warrant consideration. For | |||
general information of possible methods of securing RTP, please | general information of possible methods of securing RTP, please | |||
skipping to change at page 24, line 44 ¶ | skipping to change at page 25, line 21 ¶ | |||
sets of master keys for different SSRCs. The key-management | sets of master keys for different SSRCs. The key-management | |||
functions have different capabilities to establish different sets of | functions have different capabilities to establish different sets of | |||
keys, normally on a per endpoint basis. For example, DTLS-SRTP | keys, normally on a per endpoint basis. For example, DTLS-SRTP | |||
[RFC5764] and Security Descriptions [RFC4568] establish different | [RFC5764] and Security Descriptions [RFC4568] establish different | |||
keys for outgoing and incoming traffic from an endpoint. This key | keys for outgoing and incoming traffic from an endpoint. This key | |||
usage has to be written into the cryptographic context, possibly | usage has to be written into the cryptographic context, possibly | |||
associated with different SSRCs. | associated with different SSRCs. | |||
4.3.2. Key Management for Multi-party sessions | 4.3.2. Key Management for Multi-party sessions | |||
Performing key-management for multi-party session can be a challenge. | Performing key-management for multi-party sessions can be a | |||
This section considers some of the issues. | challenge. 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, can neither use Security Description [RFC4568] | |||
DTLS-SRTP [RFC5764] without an extension as each endpoint provides | nor DTLS-SRTP [RFC5764] without an extension as each endpoint | |||
its set of keys. In centralised conferences, the signalling | provides 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-perc-srtp-ekt-diet] or a MIKEY [RFC3830] based solution | [I-D.ietf-perc-srtp-ekt-diet] 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 is needed. | key is needed. | |||
4.3.3. Complexity Implications | 4.3.3. Complexity Implications | |||
The usage of security functions can surface complexity implications | The usage of security functions can surface complexity implications | |||
skipping to change at page 25, line 37 ¶ | skipping to change at page 26, line 17 ¶ | |||
This section discusses how some RTP multiplexing design choices can | This section discusses how some RTP multiplexing design choices can | |||
be used in applications to achieve certain goals, and a summary of | be used in applications to achieve certain goals, and a summary of | |||
the implications of such choices. For each design there is | the implications of such choices. For each design there is | |||
discussion of benefits and downsides. | discussion of benefits and downsides. | |||
5.1. Multiple Media Types in one Session | 5.1. Multiple Media Types in one Session | |||
This design uses a single RTP session for multiple different media | This design uses a single RTP session for multiple different media | |||
types, like audio and video, and possibly also transport robustness | types, like audio and video, and possibly also transport robustness | |||
mechanisms like FEC or Retransmission. An endpoint can have zero, | mechanisms like FEC or Retransmission. An endpoint can have zero, | |||
one or more media sources per media type. Resulting in a number of | one or more media sources per media type, resulting in a number of | |||
RTP streams of various media types and both source and redundancy | RTP streams of various media types and both source and redundancy | |||
type. | type. | |||
The Pros: | The Pros: | |||
1. Single RTP session which implies: | 1. Single RTP session which implies: | |||
* Minimal NAT/FW state. | * Minimal NAT/FW state. | |||
* Minimal NAT/FW Traversal Cost. | * Minimal NAT/FW Traversal Cost. | |||
skipping to change at page 26, line 39 ¶ | skipping to change at page 27, line 17 ¶ | |||
usage to avoid wasting RTCP reporting on the RTP stream that does | usage to avoid wasting RTCP reporting on the RTP stream that does | |||
not need that frequent reporting. | not need that frequent reporting. | |||
f. Not suitable for applications where some receivers like to | f. Not suitable for applications where some receivers like to | |||
receive only a subset of the RTP streams, especially if multicast | receive only a subset of the RTP streams, especially if multicast | |||
or transport translator is being used. | or transport translator is being used. | |||
g. Additional concern with legacy implementations that do not | g. 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 need 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. | |||
5.2. Multiple SSRCs of the Same Media Type | 5.2. Multiple SSRCs of the Same Media Type | |||
In this design, each RTP session serves only a single media type. | In this design, each RTP session serves only a single media type. | |||
The RTP session can contain multiple RTP streams, either from a | The RTP session can contain multiple RTP streams, either from a | |||
skipping to change at page 30, line 15 ¶ | skipping to change at page 30, line 37 ¶ | |||
* Increased delay and resource consumption from NAT/FW | * Increased delay and resource consumption from NAT/FW | |||
traversal. | traversal. | |||
* Likely larger signalling message and signalling processing | * Likely larger signalling message and signalling processing | |||
requirement due to the amount of session related information. | requirement due to the amount of session related information. | |||
* Higher potential for a single RTP stream to fail during | * Higher potential for a single RTP stream to fail during | |||
transport between the endpoints. | transport between the endpoints. | |||
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 RTP stream also grows, depending on how the | state for relating RTP streams also grows, depending on how the | |||
application needs to relate RTP streams. | application needs to relate RTP 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 or 5-tuple filter | services, where the central node's port or 5-tuple filter | |||
consumption grows rapidly with the number of sessions. | consumption grows rapidly with the number of sessions. | |||
d. For applications where the RTP stream usage is highly dynamic, | d. For applications where the RTP stream usage is highly dynamic, | |||
i.e. entering and leaving, the amount of signalling can grow | i.e. entering and leaving, the amount of signalling can grow | |||
high. Issues can also arise from the timely establishment of | high. Issues can also arise from the timely establishment of | |||
additional RTP sessions. | additional RTP sessions. | |||
skipping to change at page 31, line 22 ¶ | skipping to change at page 31, line 44 ¶ | |||
amount of RTP sessions established, i.e. representing an attempt to | amount of RTP sessions established, i.e. representing an attempt to | |||
balance the amount of RTP sessions with the functionality the | balance the amount of RTP sessions with the functionality the | |||
communication session provides both on network level and on | communication session provides both on network level and on | |||
signalling level. | signalling level. | |||
6. Guidelines | 6. Guidelines | |||
This section contains a number of multi-stream guidelines for | This section contains a number of multi-stream guidelines for | |||
implementers or specification writers. | implementers or specification writers. | |||
Do not require us of the same SSRC value across RTP sessions: As dis | Do not require use of the same SSRC value across RTP sessions: | |||
cussed in Section 3.4.3 there exist drawbacks in using the same | As discussed in Section 3.4.3 there exist drawbacks in using the | |||
SSRC in multiple RTP sessions as a mechanism to bind related RTP | same SSRC in multiple RTP sessions as a mechanism to bind related | |||
streams together. It is instead recommended to use a mechanism to | RTP streams together. It is instead recommended to use a | |||
explicitly signal the relation, either in RTP/RTCP or in the | mechanism to explicitly signal the relation, either in RTP/RTCP or | |||
signalling mechanism used to establish the RTP session(s). | in the signalling mechanism used to establish the RTP session(s). | |||
Use additional RTP streams for additional media sources: In the | Use additional RTP streams for additional media sources: In the | |||
cases where an RTP endpoint needs to transmit additional RTP | cases where an RTP endpoint needs to transmit additional RTP | |||
streams of the same media type in the application, with the same | streams of the same media type in the application, with the same | |||
processing requirements at the network and RTP layers, it is | processing requirements at the network and RTP layers, it is | |||
suggested to send them in the same RTP session. For example a | suggested to send them in the same RTP session. For example a | |||
telepresence room where there are three cameras, and each camera | telepresence room where there are three cameras, and each camera | |||
captures 2 persons sitting at the table, sending each camera as | captures 2 persons sitting at the table, sending each camera as | |||
its own RTP stream within a single RTP session is suggested. | its own RTP stream within a single RTP session is suggested. | |||
skipping to change at page 41, line 26 ¶ | skipping to change at page 42, line 4 ¶ | |||
Authors' Addresses | Authors' Addresses | |||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Torshamsgatan 23 | 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 | |||
Gronlandsgatan 31 | Gronlandsgatan 31 | |||
SE-164 80 Kista | SE-164 60 Kista | |||
Sweden | Sweden | |||
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 | |||
End of changes. 43 change blocks. | ||||
87 lines changed or deleted | 94 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/ |