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
Google Google
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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/