draft-ietf-avtcore-rtp-multi-stream-10.txt   draft-ietf-avtcore-rtp-multi-stream-11.txt 
AVTCORE J. Lennox AVTCORE J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Updates: 3550, 4585 (if approved) M. Westerlund Updates: 3550, 4585 (if approved) M. Westerlund
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: May 27, 2016 Q. Wu Expires: June 13, 2016 Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
November 24, 2015 December 11, 2015
Sending Multiple Media Streams in a Single RTP Session Sending Multiple RTP Streams in a Single RTP Session
draft-ietf-avtcore-rtp-multi-stream-10 draft-ietf-avtcore-rtp-multi-stream-11
Abstract Abstract
This memo expands and clarifies the behaviour of Real-time Transport This memo expands and clarifies the behaviour of Real-time Transport
Protocol (RTP) endpoints that use multiple synchronization sources Protocol (RTP) endpoints that use multiple synchronization sources
(SSRCs). This occurs, for example, when an endpoint sends multiple (SSRCs). This occurs, for example, when an endpoint sends multiple
media streams in a single RTP session. This memo updates RFC 3550 RTP streams in a single RTP session. This memo updates RFC 3550 with
with regards to handling multiple SSRCs per endpoint in RTP sessions, regards to handling multiple SSRCs per endpoint in RTP sessions, with
with a particular focus on RTCP behaviour. It also updates RFC 4585 a particular focus on RTCP behaviour. It also updates RFC 4585 to
to update and clarify the calculation of the timeout of SSRCs and the update and clarify the calculation of the timeout of SSRCs and the
inclusion of feedback messages. inclusion of feedback messages.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 27, 2016. This Internet-Draft will expire on June 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 52 skipping to change at page 2, line 52
7.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 20 7.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 20
7.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 20 7.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 20
7.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 21 7.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 21
7.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 22 7.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
At the time the Real-Time Transport Protocol (RTP) [RFC3550] was At the time the Real-Time Transport Protocol (RTP) [RFC3550] was
originally designed, and for quite some time after, endpoints in RTP originally designed, and for quite some time after, endpoints in RTP
sessions typically only transmitted a single media stream, and thus sessions typically only transmitted a single media source, and thus
used a single synchronization source (SSRC) per RTP session, where used a single RTP stream and thus synchronization source (SSRC) per
separate RTP sessions were typically used for each distinct media RTP session, where separate RTP sessions were typically used for each
type. Recently, however, a number of scenarios have emerged in which distinct media type. Recently, however, a number of scenarios have
endpoints wish to send multiple RTP media streams, distinguished by emerged in which endpoints wish to send multiple RTP streams,
distinct RTP synchronization source (SSRC) identifiers, in a single distinguished by distinct RTP synchronization source (SSRC)
RTP session. These are outlined in Section 3. Although the initial identifiers, in a single RTP session. These are outlined in
design of RTP did consider such scenarios, the specification was not Section 3. Although the initial design of RTP did consider such
consistently written with such use cases in mind. The specification scenarios, the specification was not consistently written with such
is thus somewhat unclear in places. use cases in mind. The specification is thus somewhat unclear in
places.
This memo updates [RFC3550] to clarify behaviour in use cases where This memo updates [RFC3550] to clarify behaviour in use cases where
endpoints use multiple SSRCs. It also updates [RFC4585] to resolve endpoints use multiple SSRCs. It also updates [RFC4585] to resolve
problems with regards to timeout of inactive SSRCs, and to clarify problems with regards to timeout of inactive SSRCs, and to clarify
behaviour around inclusion of feedback messages. behaviour around inclusion of feedback messages.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 4, line 12 skipping to change at page 4, line 12
microphones covering various areas of a room, and hence send several microphones covering various areas of a room, and hence send several
RTP streams of each type within a single RTP session. RTP streams of each type within a single RTP session.
3.2. Multiple Media Types in a Single RTP Session 3.2. Multiple Media Types in a Single RTP Session
Recent work has updated RTP Recent work has updated RTP
[I-D.ietf-avtcore-multi-media-rtp-session] and SDP [I-D.ietf-avtcore-multi-media-rtp-session] and SDP
[I-D.ietf-mmusic-sdp-bundle-negotiation] to remove the historical [I-D.ietf-mmusic-sdp-bundle-negotiation] to remove the historical
assumption in RTP that media sources of different media types would assumption in RTP that media sources of different media types would
always be sent on different RTP sessions. In this work, a single always be sent on different RTP sessions. In this work, a single
endpoint's audio and video RTP media streams (for example) are endpoint's audio and video RTP streams (for example) are instead sent
instead sent in a single RTP session to reduce the number of in a single RTP session to reduce the number of transport layer flows
transport layer flows used. used.
3.3. Multiple Stream Mixers 3.3. Multiple Stream Mixers
There are several RTP topologies which can involve a central device There are several RTP topologies which can involve a central device
that itself generates multiple RTP media streams in a session. An that itself generates multiple RTP streams in a session. An example
example is a mixer providing centralized compositing for a multi- is a mixer providing centralized compositing for a multi-capture
capture scenario like that described in Section 3.1. In this case, scenario like that described in Section 3.1. In this case, the
the centralized node is behaving much like a multi-capturer endpoint, centralized node is behaving much like a multi-capturer endpoint,
generating several similar and related sources. generating several similar and related sources.
A more complex example is the selective forwarding middlebox, A more complex example is the selective forwarding middlebox,
described in Section 3.7 of [I-D.ietf-avtcore-rtp-topologies-update]. described in Section 3.7 of [RFC7667]. This is a middlebox that
This is a middlebox that receives media streams from several receives RTP streams from several endpoints, and then selectively
endpoints, and then selectively forwards modified versions of some forwards modified versions of some RTP streams toward the other
RTP streams toward the other endpoints to which it is connected. For endpoints to which it is connected. For each connected endpoint, a
each connected endpoint, a separate media source appears in the separate media source appears in the session for every other source
session for every other source connected to the middlebox, connected to the middlebox, "projected" from the original streams,
"projected" from the original streams, but at any given time many of but at any given time many of them can appear to be inactive (and
them can appear to be inactive (and thus are receivers, not senders, thus are receivers, not senders, in RTP). This sort of device is
in RTP). This sort of device is closer to being an RTP mixer than an closer to being an RTP mixer than an RTP translator, in that it
RTP translator, in that it terminates RTCP reporting about the mixed terminates RTCP reporting about the mixed streams, and it can re-
streams, and it can re-write SSRCs, timestamps, and sequence numbers, write SSRCs, timestamps, and sequence numbers, as well as the
as well as the contents of the RTP payloads, and can turn sources on contents of the RTP payloads, and can turn sources on and off at will
and off at will without appearing to generate packet loss. Each without appearing to generate packet loss. Each projected stream
projected stream will typically preserve its original RTCP source will typically preserve its original RTCP source description (SDES)
description (SDES) information. information.
3.4. Multiple SSRCs for a Single Media Source 3.4. Multiple SSRCs for a Single Media Source
There are also several cases where multiple SSRCs can be used to send There are also several cases where multiple SSRCs can be used to send
data from a single media source within a single RTP session. These data from a single media source within a single RTP session. These
include, but are not limited to, transport robustness tools, such as include, but are not limited to, transport robustness tools, such as
the RTP retransmission payload format [RFC4588], that require one the RTP retransmission payload format [RFC4588], that require one
SSRC to be used for the media data and another SSRC for the repair SSRC to be used for the media data and another SSRC for the repair
data. Similarly, some layered media encoding schemes, for example data. Similarly, some layered media encoding schemes, for example
H.264 SVC [RFC6190], can be used in a configuration where each layer H.264 SVC [RFC6190], can be used in a configuration where each layer
skipping to change at page 5, line 24 skipping to change at page 5, line 24
since middleboxes can be used to connect multiple transport since middleboxes can be used to connect multiple transport
connections together into a single RTP session (the RTP session is connections together into a single RTP session (the RTP session is
defined by the shared SSRC space, not by the transport connections). defined by the shared SSRC space, not by the transport connections).
Furthermore, if RTP mixers are used, some SSRCs might only be visible Furthermore, if RTP mixers are used, some SSRCs might only be visible
in the contributing source (CSRC) list of an RTP packet and in RTCP, in the contributing source (CSRC) list of an RTP packet and in RTCP,
and might not appear directly as the SSRC of an RTP data packet. and might not appear directly as the SSRC of an RTP data packet.
Every RTP endpoint will have an allocated share of the available Every RTP endpoint will have an allocated share of the available
session bandwidth, as determined by signalling and congestion session bandwidth, as determined by signalling and congestion
control. The endpoint needs to keep its total media sending rate control. The endpoint needs to keep its total media sending rate
within this share. However, endpoints that send multiple media within this share. However, endpoints that send multiple RTP streams
streams do not necessarily need to subdivide their share of the do not necessarily need to subdivide their share of the available
available bandwidth independently or uniformly to each media stream bandwidth independently or uniformly to each RTP stream and its
and its SSRCs. In particular, an endpoint can vary the bandwidth SSRCs. In particular, an endpoint can vary the bandwidth allocation
allocation to different streams depending on their needs, and can to different streams depending on their needs, and can dynamically
dynamically change the bandwidth allocated to different SSRCs (for change the bandwidth allocated to different SSRCs (for example, by
example, by using a variable rate codec), provided the total sending using a variable rate codec), provided the total sending rate does
rate does not exceed its allocated share. This includes enabling or not exceed its allocated share. This includes enabling or disabling
disabling media streams, or their redundancy streams, as more or less RTP streams, or their redundancy streams, as more or less bandwidth
bandwidth becomes available. becomes available.
5. Use of RTCP by Endpoints that send multiple media streams 5. Use of RTCP by Endpoints that send multiple media streams
The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550]. The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550].
The description of the protocol is phrased in terms of the behaviour The description of the protocol is phrased in terms of the behaviour
of "participants" in an RTP session, under the assumption that each of "participants" in an RTP session, under the assumption that each
endpoint is a participant with a single SSRC. However, for correct endpoint is a participant with a single SSRC. However, for correct
operation in cases where endpoints have multiple SSRC values, operation in cases where endpoints have multiple SSRC values,
implementations MUST treat each SSRC as a separate participant in the implementations MUST treat each SSRC as a separate participant in the
RTP session, so that an endpoint that has multiple SSRCs counts as RTP session, so that an endpoint that has multiple SSRCs counts as
skipping to change at page 6, line 46 skipping to change at page 6, line 46
allows a substantial number of SSRCs to report immediately. allows a substantial number of SSRCs to report immediately.
Endpoints SHOULD prioritize reports on SSRCs that are likely to be Endpoints SHOULD prioritize reports on SSRCs that are likely to be
most immediately useful, e.g., for SSRCs that are initially senders. most immediately useful, e.g., for SSRCs that are initially senders.
An endpoint that needs to report on more SSRCs than will fit into the An endpoint that needs to report on more SSRCs than will fit into the
four compound RTCP reports that can be sent immediately MUST send the four compound RTCP reports that can be sent immediately MUST send the
other reports later, following the usual RTCP timing rules including other reports later, following the usual RTCP timing rules including
timer reconsideration. Those reports MAY be aggregated as described timer reconsideration. Those reports MAY be aggregated as described
in Section 5.3. in Section 5.3.
Note: The above is chosen to match the TCP initial window of 4 Note: The above is chosen to match the TCP maximum initial window
packets, not the larger TCP initial windows for which there is an of 4 packets [RFC3390], not the larger TCP initial windows for
ongoing experiment. The reason for this is a desire to be which there is an ongoing experiment [RFC6928]. The reason for
conservative, since an RTP endpoint will also in many cases start this is a desire to be conservative, since an RTP endpoint will
sending RTP data packets at the same time as these initial RTCP also in many cases start sending RTP data packets at the same time
packets are sent. as these initial RTCP packets are sent.
5.3. Aggregation of Reports into Compound RTCP Packets 5.3. Aggregation of Reports into Compound RTCP Packets
As outlined in Section 5.1, an endpoint with multiple SSRCs has to As outlined in Section 5.1, an endpoint with multiple SSRCs has to
treat each SSRC as a separate participant when it comes to sending treat each SSRC as a separate participant when it comes to sending
RTCP reports. This will lead to each SSRC sending a compound RTCP RTCP reports. This will lead to each SSRC sending a compound RTCP
packet in each reporting interval. Since these packets are coming packet in each reporting interval. Since these packets are coming
from the same endpoint, it might reasonably be expected that they can from the same endpoint, it might reasonably be expected that they can
be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550]
allows RTP translators and mixers to aggregate packets in similar allows RTP translators and mixers to aggregate packets in similar
skipping to change at page 10, line 40 skipping to change at page 10, line 40
option 2c of the algorithm, then tp is updated to tc as aggregation option 2c of the algorithm, then tp is updated to tc as aggregation
has not taken place. has not taken place.
Reverse reconsideration MUST be performed following Section 6.3.4 of Reverse reconsideration MUST be performed following Section 6.3.4 of
[RFC3550]. In some cases, this can lead to the value of tp after [RFC3550]. In some cases, this can lead to the value of tp after
reverse reconsideration being larger than tc. This is not a problem, reverse reconsideration being larger than tc. This is not a problem,
and has the desired effect of proportionally pulling the tp value and has the desired effect of proportionally pulling the tp value
towards tc (as well as tn) as the reporting interval shrinks in towards tc (as well as tn) as the reporting interval shrinks in
direct proportion the reduced group size. direct proportion the reduced group size.
The above algorithm has been shown in simulations to maintain the The above algorithm has been shown in simulations [Sim88][Sim92] to
inter-RTCP packet transmission time distribution for each SSRC, and maintain the inter-RTCP packet transmission time distribution for
to consume the same amount of bandwidth as non-aggregated RTCP each SSRC, and to consume the same amount of bandwidth as non-
packets. With this algorithm the actual transmission interval for an aggregated RTCP packets. With this algorithm the actual transmission
SSRC triggering an RTCP compound packet transmission is following the interval for an SSRC triggering an RTCP compound packet transmission
regular transmission rules. The value tp is set to somewhere in the is following the regular transmission rules. The value tp is set to
interval [0,1.5/1.21828*Td] ahead of tc. The actual value is average somewhere in the interval [0,1.5/1.21828*Td] ahead of tc. The actual
of one instance of tc and the randomized transmission times of the value is average of one instance of tc and the randomized
additional SSRCs, thus the lower range of the interval is more transmission times of the additional SSRCs, thus the lower range of
probable. This compensates for the bias that is otherwise introduced the interval is more probable. This compensates for the bias that is
by picking the shortest tn value out of the N SSRCs included in otherwise introduced by picking the shortest tn value out of the N
aggregate. SSRCs included in aggregate.
The algorithm also handles the cases where the number of SSRCs that The algorithm also handles the cases where the number of SSRCs that
can be included in an aggregated packet varies. An SSRC that can be included in an aggregated packet varies. An SSRC that
previously was aggregated and fails to fit in a packet still has its previously was aggregated and fails to fit in a packet still has its
own transmission scheduled according to normal rules. Thus, it will own transmission scheduled according to normal rules. Thus, it will
trigger a transmission in due time, or the SSRC will be included in trigger a transmission in due time, or the SSRC will be included in
another aggregate. The algorithm's behaviour under SSRC group size another aggregate. The algorithm's behaviour under SSRC group size
changes is as follows: changes is as follows:
RTP sessions where the number of SSRC are growing: When the group RTP sessions where the number of SSRC are growing: When the group
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Endpoint with multiple synchronization contexts: An endpoint that is Endpoint with multiple synchronization contexts: An endpoint that is
part of a point-to-point session can have multiple synchronization part of a point-to-point session can have multiple synchronization
contexts, for example due to forwarding an external media source contexts, for example due to forwarding an external media source
into a interactive real-time conversation. In this case the into a interactive real-time conversation. In this case the
classification will consider the peer as two endpoints, while the classification will consider the peer as two endpoints, while the
actual RTP/RTCP transmission will be under the control of one actual RTP/RTCP transmission will be under the control of one
endpoint. endpoint.
Selective Forwarding Middlebox: The SFM as defined in Section 3.7 of Selective Forwarding Middlebox: The SFM as defined in Section 3.7 of
[I-D.ietf-avtcore-rtp-topologies-update] has control over the [RFC7667] has control over the transmission and configurations
transmission and configurations between itself and each peer between itself and each peer endpoint individually. It also fully
endpoint individually. It also fully controls the RTCP packets controls the RTCP packets being forwarded between the individual
being forwarded between the individual legs. Thus, this type of legs. Thus, this type of middlebox can be compared to the RTP
middlebox can be compared to the RTP mixer, which uses its own mixer, which uses its own SSRCs to mix or select the media it
SSRCs to mix or select the media it forwards, that will be forwards, that will be classified as a point-to-point RTP session
classified as a point-to-point RTP session by the above rule. by the above rule.
In the above cases it is very reasonable to use RTCP reporting groups In the above cases it is very reasonable to use RTCP reporting groups
[I-D.ietf-avtcore-rtp-multi-stream-optimisation]. If that extension [I-D.ietf-avtcore-rtp-multi-stream-optimisation]. If that extension
is used, an endpoint can indicate that the multitude of CNAMEs are in is used, an endpoint can indicate that the multitude of CNAMEs are in
fact under a single endpoint or middlebox control by using only a fact under a single endpoint or middlebox control by using only a
single reporting group. single reporting group.
The above rules will also classify some sessions where the endpoint The above rules will also classify some sessions where the endpoint
is connected to an RTP mixer as being point to point. For example is connected to an RTP mixer as being point to point. For example
the mixer could act as gateway to an Any Source Multicast based RTP the mixer could act as gateway to an Any Source Multicast based RTP
skipping to change at page 14, line 20 skipping to change at page 14, line 20
of the session. The responsibility falls on the mixer to act of the session. The responsibility falls on the mixer to act
accordingly in each domain. accordingly in each domain.
Finally, we note that signalling mechanisms could be defined to Finally, we note that signalling mechanisms could be defined to
override the rules when it would result in the wrong classification. override the rules when it would result in the wrong classification.
6. Adding and Removing SSRCs 6. Adding and Removing SSRCs
The set of SSRCs present in a single RTP session can vary over time The set of SSRCs present in a single RTP session can vary over time
due to changes in the number of endpoints in the session, or due to due to changes in the number of endpoints in the session, or due to
changes in the number or type of media streams being sent. changes in the number or type of RTP streams being sent.
Every endpoint in an RTP session will have at least one SSRC that it Every endpoint in an RTP session will have at least one SSRC that it
uses for RTCP reporting, and for sending media if desired. It can uses for RTCP reporting, and for sending media if desired. It can
also have additional SSRCs, for sending extra media streams or for also have additional SSRCs, for sending extra media sources or for
additional RTCP reporting. If the set of media streams being sent additional RTCP reporting. If the set of media sources being sent
changes, then the set of SSRCs being sent will change. Changes in changes, then the set of SSRCs being sent will change. Changes in
the media format or clock rate might also require changes in the set the media format or clock rate might also require changes in the set
of SSRCs used. An endpoint can also have more active SSRCs than it of SSRCs used. An endpoint can also have more SSRCs than it has
has active RTP media streams, and send RTCP relating to SSRCs that active RTP streams, and send RTCP relating to SSRCs that are not
are not currently sending RTP data packets so that its peers are currently sending RTP data packets so that its peers are aware of the
aware of the SSRCs, and have the associated context (e.g., clock SSRCs, and have the associated context (e.g., clock synchronisation
synchronisation and an SDES CNAME) in place to be able to play out and an SDES CNAME) in place to be able to play out media as soon as
media as soon as they becomes active. they becomes active.
In the following, we describe some considerations around adding and In the following, we describe some considerations around adding and
removing RTP streams and their associated SSRCs. removing RTP streams and their associated SSRCs.
6.1. Adding RTP Streams 6.1. Adding RTP Streams
When an endpoint joins an RTP session it can have zero, one, or more When an endpoint joins an RTP session it can have zero, one, or more
RTP streams it will send, or that it is prepared to send. If it has RTP streams it will send, or that it is prepared to send. If it has
no RTP stream it plans to send, it still needs an SSRC that will be no RTP stream it plans to send, it still needs an SSRC that will be
used to send RTCP feedback. If it will send one or more RTP streams, used to send RTCP feedback. If it will send one or more RTP streams,
skipping to change at page 15, line 41 skipping to change at page 15, line 41
by sending an RTCP BYE packet as described in Section 6.3.7 of by sending an RTCP BYE packet as described in Section 6.3.7 of
[RFC3550]. It is RECOMMENDED that SSRCs be removed from use by [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by
sending an RTCP BYE packet. Note that [RFC3550] requires that the sending an RTCP BYE packet. Note that [RFC3550] requires that the
RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session
for an SSRC. If an endpoint needs to restart an RTP stream after for an SSRC. If an endpoint needs to restart an RTP stream after
sending an RTCP BYE for its SSRC, it needs to generate a new SSRC sending an RTCP BYE for its SSRC, it needs to generate a new SSRC
value for that stream. value for that stream.
The finality of sending RTCP BYE, means that endpoints needs to The finality of sending RTCP BYE, means that endpoints needs to
consider if the ceasing of transmission of an RTP stream is temporary consider if the ceasing of transmission of an RTP stream is temporary
or more permanent. Temporary suspension of media transmission using or permanent. Temporary suspension of media transmission using a
a particular RTP stream (SSRC) needs to maintain that SSRC as an particular RTP stream (SSRC) needs to maintain that SSRC as an active
active participant, by continuing RTCP transmission for it. That way participant, by continuing RTCP transmission for it. That way the
the media sending can be resume immediately, knowing that the context media sending can be resume immediately, knowing that the context is
is in place. Permanent transmission halting needs to send RTCP BYE in place. Permanent transmission halting needs to send RTCP BYE to
to allow the other participants to use the RTCP bandwidth resources allow the other participants to use the RTCP bandwidth resources and
and clean up their state databases. clean up their state databases.
An endpoint that ceases transmission of all its RTP streams but An endpoint that ceases transmission of all its RTP streams but
remains in the RTP session MUST maintain at least one SSRC that is to remains in the RTP session MUST maintain at least one SSRC that is to
be used for RTCP reporting and feedback (i.e., it cannot send a BYE be used for RTCP reporting and feedback (i.e., it cannot send a BYE
for all SSRCs, but needs to retain at least one active SSRC). As for all SSRCs, but needs to retain at least one active SSRC). As
some Feedback packets can be bound to media type there might be need some Feedback packets can be bound to media type there might be need
to maintain one SSRC per media type within an RTP session. An to maintain one SSRC per media type within an RTP session. An
alternative can be to create a new SSRC to use for RTCP reporting and alternative can be to create a new SSRC to use for RTCP reporting and
feedback. However, to avoid the perception that an endpoint drops feedback. However, to avoid the perception that an endpoint drops
completely out of an RTP session such a new SSRC ought to be first completely out of an RTP session such a new SSRC ought to be first
skipping to change at page 17, line 16 skipping to change at page 17, line 16
acceptable end-to-end delay, and the SNR fidelity of the image. acceptable end-to-end delay, and the SNR fidelity of the image.
These differences affect not only the needed bit-rates, but also These differences affect not only the needed bit-rates, but also
possible transmission behaviours, usable repair mechanisms, what possible transmission behaviours, usable repair mechanisms, what
feedback messages the control and repair requires, the transmission feedback messages the control and repair requires, the transmission
requirements on those feedback messages, and monitoring of the RTP requirements on those feedback messages, and monitoring of the RTP
stream delivery. Other similar scenarios can also exist. stream delivery. Other similar scenarios can also exist.
Sending multiple media types in a single RTP session causes that Sending multiple media types in a single RTP session causes that
session to contain more SSRCs than if each media type was sent in a session to contain more SSRCs than if each media type was sent in a
separate RTP session. For example, if two participants each send an separate RTP session. For example, if two participants each send an
audio and a video flow in a single RTP session, that session will audio and a video RTP stream in a single RTP session, that session
comprise four SSRCs, but if separate RTP sessions had been used for will comprise four SSRCs, but if separate RTP sessions had been used
audio and video, each of those two RTP sessions would comprise only for audio and video, each of those two RTP sessions would comprise
two SSRCs. Sending multiple media streams in an RTP session hence only two SSRCs. Sending multiple RTP streams in an RTP session hence
increases the amount of cross reporting between the SSRCs, as each increases the amount of cross reporting between the SSRCs, as each
SSRC reports on all other SSRCs in the session. This increases the SSRC reports on all other SSRCs in the session. This increases the
size of the RTCP reports, causing them to be sent less often than size of the RTCP reports, causing them to be sent less often than
would be the case if separate RTP sessions where used for a given would be the case if separate RTP sessions where used for a given
RTCP bandwidth. RTCP bandwidth.
Finally, when an RTP session contains multiple media types, it is Finally, when an RTP session contains multiple media types, it is
important to note that the RTCP reception quality reports, feedback important to note that the RTCP reception quality reports, feedback
messages, and extended report blocks used might not be applicable to messages, and extended report blocks used might not be applicable to
all media types. Endpoints will need to consider the media type of all media types. Endpoints will need to consider the media type of
each SSRC only send or process reports and feedback that apply to each SSRC only send or process reports and feedback that apply to
that particular SSRC and its media type. Signalling solutions might that particular SSRC and its media type. Signalling solutions might
have shortcomings when it comes to indicating that a particular set have shortcomings when it comes to indicating that a particular set
of RTCP reports or feedback messages only apply to a particular media of RTCP reports or feedback messages only apply to a particular media
type within an RTP session. type within an RTP session.
From an RTCP perspective, therefore, it can be seen that there are From an RTCP perspective, therefore, it can be seen that there are
advantages to using separate RTP sessions for each media stream, advantages to using separate RTP sessions for each media source,
rather than sending multiple media streams in a single RTP session. rather than sending multiple media sources in a single RTP session.
However, these are frequently offset by the need to reduce port use, However, these are frequently offset by the need to reduce port use,
to ease NAT/firewall traversal, achieved by combining media streams to ease NAT/firewall traversal, achieved by combining media sources
into a single RTP session. The following sections consider some of into a single RTP session. The following sections consider some of
the issues with using RTCP in sessions with multiple media streams in the issues with using RTCP in sessions with multiple media sources in
more detail. more detail.
7.1. Timing out SSRCs 7.1. Timing out SSRCs
Various issues have been identified with timing out SSRC values when Various issues have been identified with timing out SSRC values when
sending multiple media streams in an RTP session. sending multiple RTP streams in an RTP session.
7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter 7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter
The RTP/AVPF profile includes a method to prevent regular RTCP The RTP/AVPF profile includes a method to prevent regular RTCP
reports from being sent too often. This mechanism is described in reports from being sent too often. This mechanism is described in
Section 3.5.3 of [RFC4585], and is controlled by the T_rr_interval Section 3.5.3 of [RFC4585], and is controlled by the T_rr_interval
parameter. It works as follows. When a regular RTCP report is sent, parameter. It works as follows. When a regular RTCP report is sent,
a new random value, T_rr_current_interval, is generated, drawn evenly a new random value, T_rr_current_interval, is generated, drawn evenly
in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP
packet is to be sent earlier then T_rr_current_interval seconds after packet is to be sent earlier then T_rr_current_interval seconds after
skipping to change at page 22, line 7 skipping to change at page 22, line 7
due to reconsideration, with the majority of the probability mass due to reconsideration, with the majority of the probability mass
being above Td. This means, for example, that for Td = 5s, the being above Td. This means, for example, that for Td = 5s, the
actual transmission interval will be distributed in the range actual transmission interval will be distributed in the range
[2.052s, 6.156s], and tending towards the upper half of the [2.052s, 6.156s], and tending towards the upper half of the
interval. Note that Tmin parameter limits the value of Td before interval. Note that Tmin parameter limits the value of Td before
randomisation and reconsideration are applied, so the actual randomisation and reconsideration are applied, so the actual
transmission interval will cover a range extending below Tmin. transmission interval will cover a range extending below Tmin.
Given the above, we can calculate the number of SSRCs, n, that an RTP Given the above, we can calculate the number of SSRCs, n, that an RTP
session with 5% of the session bandwidth assigned to RTCP can support session with 5% of the session bandwidth assigned to RTCP can support
while maintaining Td equal to Tmin. This will tell us how many media while maintaining Td equal to Tmin. This will tell us how many RTP
streams we can report on, keeping the RTCP overhead within acceptable streams we can report on, keeping the RTCP overhead within acceptable
bounds. We make two assumptions that simplify the calculation: that bounds. We make two assumptions that simplify the calculation: that
all SSRCs are senders, and that they all send compound RTCP packets all SSRCs are senders, and that they all send compound RTCP packets
comprising an SR packet with n-1 report blocks, followed by an SDES comprising an SR packet with n-1 report blocks, followed by an SDES
packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets
will vary in size between 54 and 798 octets depending on n, up to the will vary in size between 54 and 798 octets depending on n, up to the
maximum of 31 report blocks that can be included in an SR packet). maximum of 31 report blocks that can be included in an SR packet).
If we put this packet size, and a 5% RTCP bandwidth fraction into the If we put this packet size, and a 5% RTCP bandwidth fraction into the
RTCP interval calculation in Section 6.3.1 of [RFC3550], and RTCP interval calculation in Section 6.3.1 of [RFC3550], and
calculate the value of n needed to give Td = Tmin for the scaled calculate the value of n needed to give Td = Tmin for the scaled
skipping to change at page 23, line 13 skipping to change at page 23, line 13
are the governing factors, allowing faster feedback. Applications are the governing factors, allowing faster feedback. Applications
that care about rapid regular RTCP feedback ought to consider using that care about rapid regular RTCP feedback ought to consider using
the RTP/AVPF or RTP/SAVPF profile, even if they don't use the the RTP/AVPF or RTP/SAVPF profile, even if they don't use the
feedback features of that profile. feedback features of that profile.
The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback
packets to be sent frequently, without also requiring regular RTCP packets to be sent frequently, without also requiring regular RTCP
reports to be sent frequently, since T_rr_interval limits the rate at reports to be sent frequently, since T_rr_interval limits the rate at
which regular RTCP packets can be sent, while still permitting RTCP which regular RTCP packets can be sent, while still permitting RTCP
feedback packets to be sent. Applications that can use feedback feedback packets to be sent. Applications that can use feedback
packets for some media streams, e.g., video streams, but don't want packets for some RTP streams, e.g., video streams, but don't want
frequent regular reporting for other media streams, can configure the frequent regular reporting for other RTP streams, can configure the
T_rr_interval to a value so that the regular reporting for both audio T_rr_interval to a value so that the regular reporting for both audio
and video is at a level that is considered acceptable for the audio. and video is at a level that is considered acceptable for the audio.
They could then use feedback packets, which will include RTCP SR/RR They could then use feedback packets, which will include RTCP SR/RR
packets unless reduced size RTCP feedback packets [RFC5506] are used, packets unless reduced size RTCP feedback packets [RFC5506] are used,
for the video reporting. This allows the available RTCP bandwidth to for the video reporting. This allows the available RTCP bandwidth to
be devoted on the feedback that provides the most utility for the be devoted on the feedback that provides the most utility for the
application. application.
Using T_rr_interval still requires one to determine suitable values Using T_rr_interval still requires one to determine suitable values
for the RTCP bandwidth value. Indeed, it might make this choice even for the RTCP bandwidth value. Indeed, it might make this choice even
skipping to change at page 23, line 50 skipping to change at page 23, line 50
only limited by the bandwidth, i.e., no Tmin limitations at all. only limited by the bandwidth, i.e., no Tmin limitations at all.
This allows more frequent regular RTCP reporting than can be achieved This allows more frequent regular RTCP reporting than can be achieved
using the RTP/AVP profile. Many configurations of RTCP will not using the RTP/AVP profile. Many configurations of RTCP will not
consume all the bandwidth that they have been configured to use, but consume all the bandwidth that they have been configured to use, but
this configuration will consume what it has been given. Note that this configuration will consume what it has been given. Note that
the same behaviour will be achieved as long as T_rr_interval is the same behaviour will be achieved as long as T_rr_interval is
smaller than 1/3 of Td as that prevents T_rr_interval from affecting smaller than 1/3 of Td as that prevents T_rr_interval from affecting
the transmission. the transmission.
There exists no method for using different regular RTCP reporting There exists no method for using different regular RTCP reporting
intervals depending on the media type or individual media stream, intervals depending on the media type or individual RTP stream, other
other than using a separate RTP session for each type or stream. than using a separate RTP session for each type or stream.
8. Security Considerations 8. Security Considerations
When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the
secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the
cryptographic context of a compound secure RTCP packet is the SSRC of cryptographic context of a compound secure RTCP packet is the SSRC of
the sender of the first RTCP (sub-)packet. This could matter in some the sender of the first RTCP (sub-)packet. This could matter in some
cases, especially for keying mechanisms such as Mikey [RFC3830] which cases, especially for keying mechanisms such as Mikey [RFC3830] which
allow use of per-SSRC keying. allow use of per-SSRC keying.
Otherwise, the standard security considerations of RTP apply; sending Otherwise, the standard security considerations of RTP apply; sending
multiple media streams from a single endpoint in a single RTP session multiple RTP streams from a single endpoint in a single RTP session
does not appear to have different security consequences than sending does not appear to have different security consequences than sending
the same number of media streams spread across different RTP the same number of RTP streams spread across different RTP sessions.
sessions.
9. IANA Considerations 9. IANA Considerations
No IANA actions are needed. No IANA actions are needed.
10. Acknowledgments 10. Acknowledgments
The authors like to thank Harald Alvestrand and everyone else who has The authors like to thank Harald Alvestrand and everyone else who has
been involved in the development of this document. been involved in the development of this document.
skipping to change at page 25, line 20 skipping to change at page 25, line 20
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-11 (work in ietf-avtcore-multi-media-rtp-session-12 (work in
progress), November 2015. progress), December 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-08 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-09 (work
in progress), October 2015. in progress), November 2015.
[I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015.
[I-D.ietf-clue-framework] [I-D.ietf-clue-framework]
Duckworth, M., Pepperell, A., and S. Wenger, "Framework Duckworth, M., Pepperell, A., and S. Wenger, "Framework
for Telepresence Multi-Streams", draft-ietf-clue- for Telepresence Multi-Streams", draft-ietf-clue-
framework-24 (work in progress), November 2015. framework-24 (work in progress), November 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-23 (work in progress), July 2015.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, DOI 10.17487/RFC3390, October
2002, <http://www.rfc-editor.org/info/rfc3390>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>. <http://www.rfc-editor.org/info/rfc3551>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth",
RFC 3556, DOI 10.17487/RFC3556, July 2003, RFC 3556, DOI 10.17487/RFC3556, July 2003,
<http://www.rfc-editor.org/info/rfc3556>. <http://www.rfc-editor.org/info/rfc3556>.
skipping to change at page 26, line 35 skipping to change at page 26, line 35
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <http://www.rfc-editor.org/info/rfc5576>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
DOI 10.17487/RFC6190, May 2011, DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>. <http://www.rfc-editor.org/info/rfc6190>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
<http://www.rfc-editor.org/info/rfc6928>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>. September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014, DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>. <http://www.rfc-editor.org/info/rfc7160>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>.
[Sim88] Westerlund, M., "SIMULATION RESULTS FOR MULTI-STREAM",
IETF Proceedings
https://www.ietf.org/proceedings/92/slides/slides-92-
avtcore-0.pdf, November 2013.
[Sim92] Westerlund, M., "Changes in RTP Multi-stream", IETF
Proceedings
https://www.ietf.org/proceedings/92/slides/slides-92-
avtcore-0.pdf, March 2015.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
USA USA
Email: jonathan@vidyo.com Email: jonathan@vidyo.com
Magnus Westerlund Magnus Westerlund
skipping to change at page 27, line 28 skipping to change at page 27, line 41
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: sunseawq@huawei.com Email: bill.wu@huawei.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 35 change blocks. 
120 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/