draft-ietf-avtcore-rtp-multi-stream-06.txt   draft-ietf-avtcore-rtp-multi-stream-07.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: April 30, 2015 Q. Wu Expires: September 10, 2015 Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
October 27, 2014 March 9, 2015
Sending Multiple Media Streams in a Single RTP Session Sending Multiple Media Streams in a Single RTP Session
draft-ietf-avtcore-rtp-multi-stream-06 draft-ietf-avtcore-rtp-multi-stream-07
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 media streams in a single RTP session. This memo updates RFC 3550
with regards to handling multiple SSRCs per endpoint in RTP sessions, with regards to handling multiple SSRCs per endpoint in RTP sessions,
with a particular focus on RTCP behaviour. It also updates RFC 4585 with a particular focus on RTCP behaviour. It also updates RFC 4585
to update and clarify the calculation of the timeout of SSRCs and the to update and clarify the calculation of the timeout of SSRCs and the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 30, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases For Multi-Stream Endpoints . . . . . . . . . . . . 3 3. Use Cases For Multi-Stream Endpoints . . . . . . . . . . . . 3
3.1. Endpoints with Multiple Capture Devices . . . . . . . . . 3 3.1. Endpoints with Multiple Capture Devices . . . . . . . . . 3
3.2. Multiple Media Types in a Single RTP Session . . . . . . 3 3.2. Multiple Media Types in a Single RTP Session . . . . . . 4
3.3. Multiple Stream Mixers . . . . . . . . . . . . . . . . . 4 3.3. Multiple Stream Mixers . . . . . . . . . . . . . . . . . 4
3.4. Multiple SSRCs for a Single Media Source . . . . . . . . 4 3.4. Multiple SSRCs for a Single Media Source . . . . . . . . 4
4. Use of RTP by endpoints that send multiple media streams . . 5 4. Use of RTP by endpoints that send multiple media streams . . 5
5. Use of RTCP by Endpoints that send multiple media streams . . 5 5. Use of RTCP by Endpoints that send multiple media streams . . 5
5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5 5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5
5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 5 5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 6
5.3. Aggregation of Reports into Compound RTCP Packets . . . . 6 5.3. Aggregation of Reports into Compound RTCP Packets . . . . 6
5.3.1. Maintaining AVG_RTCP_SIZE . . . . . . . . . . . . . . 7 5.3.1. Maintaining AVG_RTCP_SIZE . . . . . . . . . . . . . . 7
5.3.2. Scheduling RTCP with Multiple Reporting SSRCs . . . . 8 5.3.2. Scheduling RTCP with Multiple Reporting SSRCs . . . . 8
5.4. Use of RTP/AVPF Feedback . . . . . . . . . . . . . . . . 10 5.4. Use of RTP/AVPF Feedback . . . . . . . . . . . . . . . . 11
5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 10 5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 11
5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 11 5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 12
6. RTCP Considerations for Streams with Disparate Rates . . . . 12 6. RTCP Considerations for Streams with Disparate Rates . . . . 14
6.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 13 6.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Problems with RTP/AVPF the T_rr_interval Parameter . 13 6.1.1. Problems with RTP/AVPF the T_rr_interval Parameter . 16
6.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 14 6.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 17
6.1.3. Interoperability Between RTP/AVP and RTP/AVPF . . . . 15 6.1.3. Interoperability Between RTP/AVP and RTP/AVPF . . . . 18
6.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 15 6.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 18
6.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 16 6.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 19
6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 16 6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 19
6.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 18 6.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 stream, and thus
used a single synchronization source (SSRC) per RTP session, where used a single synchronization source (SSRC) per RTP session, where
separate RTP sessions were typically used for each distinct media separate RTP sessions were typically used for each distinct media
type. Recently, however, a number of scenarios have emerged in which type. Recently, however, a number of scenarios have emerged in which
endpoints wish to send multiple RTP media streams, distinguished by endpoints wish to send multiple RTP media streams, distinguished by
distinct RTP synchronization source (SSRC) identifiers, in a single distinct RTP synchronization source (SSRC) identifiers, in a single
RTP session. These are outlined in Section 3. Although the initial RTP session. These are outlined in Section 3. Although the initial
design of RTP did consider such scenarios, the specification was not design of RTP did consider such scenarios, the specification was not
skipping to change at page 6, line 4 skipping to change at page 6, line 6
If the endpoint has some SSRCs that are sending data and some that If the endpoint has some SSRCs that are sending data and some that
are only receivers, then they will receive different shares of the are only receivers, then they will receive different shares of the
RTCP bandwidth and calculate different base RTCP reporting intervals. RTCP bandwidth and calculate different base RTCP reporting intervals.
Otherwise, all SSRCs at an endpoint will calculate the same base RTCP Otherwise, all SSRCs at an endpoint will calculate the same base RTCP
reporting interval. The actual reporting intervals for each SSRC are reporting interval. The actual reporting intervals for each SSRC are
randomised in the usual way, but reports can be aggregated as randomised in the usual way, but reports can be aggregated as
described in Section 5.3. described in Section 5.3.
5.2. Initial Reporting Interval 5.2. Initial Reporting Interval
When a participant joins a unicast session, the following text from When a participant joins a unicast session, the following text from
Section 6.2 of [RFC3550] applies: "For unicast sessions... the delay Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the
before sending the initial compound RTCP packet MAY be zero." This delay before sending the initial compound RTCP packet MAY be zero."
also applies to the individual SSRCs of an endpoint that has multiple The basic assumption is that this also ought to apply in the case of
SSRCs, and such endpoints MAY send an initial RTCP packet for each of multiple SSRCs. Caution has to be exercised, however, when an
their SSRCs immediately upon joining a unicast session. endpoint (or middlebox) with a large number of SSRCs joins a unicast
session, since immediate transmission of many RTCP reports can create
a significant burst of traffic, leading to transient congestion and
packet loss due to queue overflows.
Caution has to be exercised, however, when an endpoint (or middlebox) To ensure that the initial burst of traffic generated by an RTP
with a large number of SSRCs joins a unicast session, since immediate endpoint is no larger than would be generated by a TCP connection, an
transmission of many RTCP reports can create a significant burst of RTP endpoint MUST NOT send more than four compound RTCP packets with
traffic, leading to transient congestion and packet loss due to queue zero initial delay when it joins a session. Each of those initial
overflows. Implementers are advised to consider sending immediate compound RTCP packets MAY include aggregated reports from multiple
RTCP packets for only a small number of SSRCs (e.g., the one or two SSRCs, provided the total compound RTCP packet size does not exceed
SSRCs they consider most important), with the initial RTCP packets the MTU, and the avg_rtcp_packet_size is maintained as in
for their other SSRCs being sent after the calculated initial RTCP Section 5.3.1. Aggregating reports from several SSRCs in the initial
reporting interval, to avoid self congestion. compound RTCP packets allows a substantial number of SSRCs to report
immediately. Endpoints SHOULD prioritize reports on SSRCs that are
likely to be most immediately useful, e.g., for SSRCs that are
initially senders.
(TBD: is this recommendation sufficiently strong?) 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
other reports later, following the usual RTCP timing rules including
timer reconsideration. Those reports MAY be aggregated as described
in Section 5.3.
Note: The above is based on an TCP initial window of 4 packets,
not the larger initial windows which there is an ongoing
experiment with. The reason for this is a desire to be
conservative as an RTP endpoint will also in many cases commence
RTP transmission at the same time 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 6, line 47 skipping to change at page 7, line 18
packet overhead (see Section 7). An example RTCP compound packet packet overhead (see Section 7). An example RTCP compound packet
as might be produced by a mixer is shown in Fig. 1. If the as might be produced by a mixer is shown in Fig. 1. If the
overall length of a compound packet would exceed the MTU of the overall length of a compound packet would exceed the MTU of the
network path, it SHOULD be segmented into multiple shorter network path, it SHOULD be segmented into multiple shorter
compound packets to be transmitted in separate packets of the compound packets to be transmitted in separate packets of the
underlying protocol. This does not impair the RTCP bandwidth underlying protocol. This does not impair the RTCP bandwidth
estimation because each compound packet represents at least one estimation because each compound packet represents at least one
distinct participant. Note that each of the compound packets MUST distinct participant. Note that each of the compound packets MUST
begin with an SR or RR packet." begin with an SR or RR packet."
The allows RTP translators and mixers to generate compound RTCP This allows RTP translators and mixers to generate compound RTCP
packets that contain multiple SR or RR packets from different SSRCs, packets that contain multiple SR or RR packets from different SSRCs,
as well as any of the other packet types. There are no restrictions as well as any of the other packet types. There are no restrictions
on the order in which the RTCP packets can occur within the compound on the order in which the RTCP packets can occur within the compound
packet, except the regular rule that the compound RTCP packet starts packet, except the regular rule that the compound RTCP packet starts
with an SR or RR packet. Due to this rule, correctly implemented RTP with an SR or RR packet. Due to this rule, correctly implemented RTP
endpoints will be able to handle compound RTCP packets that contain endpoints will be able to handle compound RTCP packets that contain
RTCP packets relating to multiple SSRCs. RTCP packets relating to multiple SSRCs.
Accordingly, endpoints that use multiple SSRCs MAY aggregate the RTCP Accordingly, endpoints that use multiple SSRCs MAY aggregate the RTCP
packets sent by their different SSRCs into compound RTCP packets, packets sent by their different SSRCs into compound RTCP packets,
skipping to change at page 7, line 41 skipping to change at page 8, line 11
size: size:
avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size
where div_packet_size is packet_size divided by the number of SSRCs where div_packet_size is packet_size divided by the number of SSRCs
reporting in that compound packet. The number of SSRCs reporting in reporting in that compound packet. The number of SSRCs reporting in
a compound packet is determined by counting the number of different a compound packet is determined by counting the number of different
SSRCs that are the source of Sender Report (SR) or Receiver Report SSRCs that are the source of Sender Report (SR) or Receiver Report
(RR) RTCP packets within the compound RTCP packet. Non-compound RTCP (RR) RTCP packets within the compound RTCP packet. Non-compound RTCP
packets (i.e., RTCP packets that do not contain an SR or RR packet packets (i.e., RTCP packets that do not contain an SR or RR packet
[RFC5506]) are considered report on a single SSRC. [RFC5506]) are considered to report on a single SSRC.
An SSRC doesn't follow the above rule, and instead uses the full RTCP An SSRC that doesn't follow the above rule, and instead uses the full
compound packet size to calculate avg_rtcp_size, will derive an RTCP RTCP compound packet size to calculate avg_rtcp_size, will derive an
reporting interval that is overly large by a factor that is RTCP reporting interval that is overly large by a factor that is
proportional to the number of SSRCs aggregated into compound RTCP proportional to the number of SSRCs aggregated into compound RTCP
packets and the size of set of SSRCs being aggregated relative to the packets and the size of set of SSRCs being aggregated relative to the
total number of participants. This increased RTCP reporting interval total number of participants. This increased RTCP reporting interval
can cause premature timeouts if it is more than five times the can cause premature timeouts if it is more than five times the
interval chosen by the SSRCs that understand compound RTCP that interval chosen by the SSRCs that understand compound RTCP that
aggregate reports from many SSRCs. A 1500 octet MTU can fit six aggregate reports from many SSRCs. A 1500 octet MTU can fit five
typical size reports into a compound RTCP packet, so this is a real typical size reports into a compound RTCP packet, so this is a real
concern if endpoints aggregate RTCP reports from multiple SSRCs. If concern if endpoints aggregate RTCP reports from multiple SSRCs.
compatibility with non-updated endpoints is a concern, the number of
reports from different SSRCs aggregated into a single compound RTCP The issue raised in the previous paragraph is mitigated by the
packet SHOULD be limited. modification in timeout behaviour specified in Section 6.1.2. This
mitigation is in place in those cases where the RTCP bandwidth is
sufficiently high that an endpoint, using an avg_rtcp_size calculated
without taking into account the number of reporting SSRCs, can
transmit more frequently than approximately every 5 seconds. Note,
however, that the non-modified endpoint's RTCP reporting is still
negatively impacted even if the premature timeout of its SSRCs are
avoided. If compatibility with non-updated endpoints is a concern,
the number of reports from different SSRCs aggregated into a single
compound RTCP packet SHOULD either be limited to two reports, or
aggregation ought not used at all. This will limit the non-updated
endpoint's RTCP reporting interval to be no larger than twice the
RTCP reporting interval that would be chosen by an endpoint following
this specification.
5.3.2. Scheduling RTCP with Multiple Reporting SSRCs 5.3.2. Scheduling RTCP with Multiple Reporting SSRCs
When implementing RTCP packet scheduling for cases where multiple When implementing RTCP packet scheduling for cases where multiple
reporting SSRCs are aggregating their RTCP packets in the same reporting SSRCs are aggregating their RTCP packets in the same
compound packet there are a number of challenges. First of all, we compound packet there are a number of challenges. First of all, we
have the goal of not changing the general properties of the RTCP have the goal of not changing the general properties of the RTCP
packet transmissions, which include the general inter-packet packet transmissions, which include the general inter-packet
distribution, and the behaviour for dealing with flash joins as well distribution, and the behaviour for dealing with flash joins as well
as other dynamic events. as other dynamic events.
skipping to change at page 8, line 34 skipping to change at page 9, line 16
are to be sent, or their size, prior to generating the packets. are to be sent, or their size, prior to generating the packets.
In which case, the time from generation to transmission ought to In which case, the time from generation to transmission ought to
be as short as possible to minimize the information that becomes be as short as possible to minimize the information that becomes
stale. stale.
o That one has an MTU limit, that one ought to avoid exceeding, as o That one has an MTU limit, that one ought to avoid exceeding, as
that requires lower-layer fragmentation (e.g., IP fragmentation) that requires lower-layer fragmentation (e.g., IP fragmentation)
which impacts the packets' probability of reaching the which impacts the packets' probability of reaching the
receiver(s). receiver(s).
The below text modifies and extends the behavior defined in
Section 6.3 of [RFC3550], and in Section 3.5.3 of [RFC4585] if the
AVPF or SAVPF profile is used, regarding actions to take when
scheduling and sending an RTCP packet. It uses the variable names
tn, tp, tc, T and Td defined in Section 6.3 of [RFC3550]. The
variable T_rr_last is defined in [RFC4585].
Schedule all the endpoint's local SSRCs individually for transmission Schedule all the endpoint's local SSRCs individually for transmission
using the regular calculation of Tn for the profile being used. Each using the regular calculation of tn for the profile being used. Each
time a SSRC's Tn timer expires, do the regular reconsideration. If time an SSRC's tn timer expires, do the regular reconsideration and,
the reconsideration indicates that an RTCP packet is to be sent: if applicable, T_rr_int based suppression. If the result indicates
that an RTCP packet is to be sent and the transmission is a regular
RTCP packet:
1. Consider if an additional SSRC can be added. That consideration 1. Consider if an additional SSRC can be added. That consideration
is done by picking the SSRC which has the Tn value closest in is done by picking the SSRC which has the tn value closest in
time to now (Tc). time to the current time (tc).
2. Calculate how much space for RTCP packets would be needed to add 2. Calculate how much space for RTCP packets would be needed to add
that SSRC. that SSRC.
3. If the considered SSRC's RTCP Packets fit within the lower layer 3. If the considered SSRC's RTCP Packets fit within the lower layer
datagram's Maximum Transmission Unit, taking the necessary datagram's Maximum Transmission Unit, taking the necessary
protocol headers into account and the consumed space by prior protocol headers and the space consumed by prior SSRCs into
SSRCs, then add that SSRC's RTCP packets to the compound packet account, then add that SSRC's RTCP packets to the compound packet
and go again to Step 1. and go again to Step 1.
4. If the considered SSRC's RTCP Packets will not fit within the 4. Otherwise, if the considered SSRC's RTCP Packets will not fit
compound packet, then transmit the generated compound packet. within the compound packet, then transmit the generated compound
packet.
5. Update the RTCP Parameters for each SSRC that has been included 5. Update the RTCP Parameters for each SSRC that has been included
in the sent RTCP packet. The Tp value for each SSRC MUST be in the sent RTCP packet. The previous RTCP transmit time (tp)
updated as follows: value for each SSRC MUST be updated as follows:
For the first SSRC: As this SSRC was the one that was A. For the first SSRC set the transmission time (tt) to tc.
reconsidered the tp value is set to the tc as defined in
RTP [RFC3550].
For any additional SSRC: The tp value SHALL be set to the B. For any additional SSRC calculate the transmission time that
transmission time this SSRC would have had it not been each of these SSRCs would have had it not been aggregated and
aggregated and given the current existing session context. given the current existing session context. This value is
This value is derived by taking this SSRC's Tn value and derived by taking this SSRC's tn value and performing
performing reconsideration and updating tn until tp + T <= reconsideration and updating tn until tp + T <= tn, then set
tn. Then set tp to this tn value. tt = tn. If AVPF or SAVPF is being used, then T_rr_int based
suppression MUST NOT be used in this calcualtion.
C. Calculate average transmission time (tt_avg) using the tt of
all the SSRCs included in the packet.
D. Now update tp for all the sent SSRCs to tt_avg.
E. If AVPF or SAVPF profile is being used update T_rr_last to
tt_avg.
6. For the sent SSRCs calculate new tn values based on the updated 6. For the sent SSRCs calculate new tn values based on the updated
parameters and reschedule the timers. parameters and reschedule the timers.
When using AVPF or SAVPF profile, when following the scheduling
algorithm for regular transmission in Section 3.5.3 then the case of
T_rr_interval == 0, as well as option 1, 2a and 2b for T_rr_interval
!= 0, results in transmission of a regular RTCP packet that follows
the above and updates the necessary variables. However, when the
transmission is suppressed per 2c, then tp is updated to tc, as no
aggregation has taken place.
Reverse reconsideration needs to be performed as specified in RTP Reverse reconsideration needs to be performed as specified in RTP
[RFC3550]. It is important to note that under the above algorithm [RFC3550]. It is important to note that under the above algorithm
when performing reconsideration, the value of tp can actually be when performing reconsideration, the value of tp can actually be
larger than tc. However, that still has the desired effect of larger than tc. However, that still has the desired effect of
proportionally pulling the tp value towards tc (as well as tn) as the proportionally pulling the tp value towards tc (as well as tn) as the
group size shrinks in direct proportion the reduced group size. group size shrinks in 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 to maintain the
inter-RTCP-packet transmission distribution for the SSRCs and consume inter-RTCP-packet transmission distribution for the SSRCs and consume
the same amount of bandwidth as non-aggregated packets in RTP the same amount of bandwidth as non-aggregated packets in RTP
sessions with static sets of participants. With this algorithm the sessions. With this algorithm the actual transmission interval for
actual transmission interval for any SSRC triggering an RTCP compound any SSRC triggering an RTCP compound packet transmission is following
packet transmission is following the regular transmission rules. It the regular transmission rules. The value tp is set to somewhere in
also handles the cases where the number of SSRCs that can be included the interval [0,1.5/1.21828*Td] ahead of tc. The actual value is
in an aggregated packet varies. An SSRC that previously was average of one instance of tc and the randomized transmission times
aggregated and fails to fit in a packet still has its own of the additional SSRCs, thus the lower range of the interval is more
transmission scheduled according to normal rules. Thus, it will probable. This setting is performed to compensate for the bias that
trigger a transmission in due time, or the SSRC will be included in is otherwise introduced by picking the shortest tn value out of the N
another aggregate. SSRCs included in aggregate.
The algorithm's behaviour under SSRC group size changes is under The algorithm also handles the cases where the number of SSRCs that
investigation. However, it is expected to be well behaved based on can be included in an aggregated packet varies. An SSRC that
the following analyses. previously was aggregated and fails to fit in a packet still has its
own transmission scheduled according to normal rules. Thus, it will
trigger a transmission in due time, or the SSRC will be included in
another aggregate. The algorithm's behaviour under SSRC group size
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
size is growing, the Td values grow in proportion to the number of size is growing, the Td values grow in proportion to the number of
new SSRCs in the group. The reconsideration when the timer for new SSRCs in the group. When reconsideration is done when the
the tn expires, that SSRC will reconsider the transmission and timer for the tn expires, that SSRC will reconsider the
with a certain probability reschedule the tn timer. This part of transmission and with a certain probability reschedule the tn
the reconsideration algorithm is only impacted by the above timer. This part of the reconsideration algorithm is only
algorithm by having tp values that are in the future instead of impacted by the above algorithm by having tp values that were in
set to the time of the actual last transmission at the time of the future instead of set to the time of the actual last
updating tp. Thus the scheduling causes in worst case a plateau transmission at the time of updating tp.
effect for that SSRC. That effect depends on how far into the
future tp can advance.
RTP sessions where the number of SSRC are shrinking: When the group RTP sessions where the number of SSRC are shrinking: When the group
shrinks, reverse reconsideration moves the tp and tn values shrinks, reverse reconsideration moves the tp and tn values
towards tc proportionally to the number of SSRCs that leave the towards tc proportionally to the number of SSRCs that leave the
session compared to the total number of participants when they session compared to the total number of participants when they
left. Thus the also group size reductions need to be handled. left. The setting of the tp value forward in time related to the
tc could be believed to have negative effect. However, the reason
for this setting is to compensate for bias caused by picking the
shortest tn out of the N aggregated. This bias remains over a
reduction in the number of SSRCs. The reverse reconsideration
compensates the reduction independently of aggregation being used
or not. The negative effect that can occur on removing an SSRC is
that the most favourable tn belonged to the removed SSRC. The
impact of this is limited to delaying the transmission, in the
worst case, one reporting interval.
In general the potential issue that might exist depends on how far In conclusion the investigations performed has found no significant
into the future the tp value can drift compared to the actual packet negative impact on the scheduling algorithm.
transmissions that occur. That drift can only occur for an SSRC that
never is the trigger for RTCP packet transmission and always gets
aggregated and where the calculated packet transmission interval
randomly occurs so that tn - tp for this SSRC is on average larger
than the ones that gets transmitted.
5.4. Use of RTP/AVPF Feedback 5.4. Use of RTP/AVPF Feedback
This section discusses the transmission of RTP/AVPF feedback packets This section discusses the transmission of RTP/AVPF feedback packets
when the transmitting endpoint has multiple SSRCs. when the transmitting endpoint has multiple SSRCs.
5.4.1. Choice of SSRC for Feedback Packets 5.4.1. Choice of SSRC for Feedback Packets
When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC
to use as the source for the RTCP feedback packets it sends. Several to use as the source for the RTCP feedback packets it sends. Several
skipping to change at page 10, line 48 skipping to change at page 12, line 15
o RTCP feedback packets relating to a particular media type SHOULD o RTCP feedback packets relating to a particular media type SHOULD
be sent by an SSRC that receives that media type. For example, be sent by an SSRC that receives that media type. For example,
when audio and video are multiplexed onto a single RTP session, when audio and video are multiplexed onto a single RTP session,
endpoints will use their audio SSRC to send feedback on the audio endpoints will use their audio SSRC to send feedback on the audio
received from other participants. received from other participants.
o RTCP feedback packets and RTCP codec control messages that are o RTCP feedback packets and RTCP codec control messages that are
notifications or indications regarding RTP data processed by an notifications or indications regarding RTP data processed by an
endpoint MUST be sent from the SSRC used by that RTP data. This endpoint MUST be sent from the SSRC used by that RTP data. This
includes notifications that relate to a previously received includes notifications that relate to a previously received
request or command. request or command [RFC4585][RFC5104].
o If separate SSRCs are used to send and receive media, then the o If separate SSRCs are used to send and receive media, then the
corresponding SSRC SHOULD be used for feedback, since they have corresponding SSRC SHOULD be used for feedback, since they have
differing RTCP bandwidth fractions. This can also effect the differing RTCP bandwidth fractions. This can also affect the
consideration if the SSRC can be used in immediate mode or not. consideration if the SSRC can be used in immediate mode or not.
o Some RTCP feedback packet types requires consistency in the SSRC o Some RTCP feedback packet types require consistency in the SSRC
used. For example, if one sets a TMMBR limitation, the same SSRC used. For example, if a TMMBR limitation [RFC5104] is set by an
needs to be used to remove the limitation. SSRC, the same SSRC needs to be used to remove the limitation.
o If several SSRCs are suitable for sending feedback, if might be
desirable to use an SSRC that allows the sending of feedback as an
early RTCP packet.
When an RTCP feedback packet is sent as part of a compound RTCP When an RTCP feedback packet is sent as part of a compound RTCP
packet that aggregates reports from multiple SSRCs, there is no packet that aggregates reports from multiple SSRCs, there is no
requirement that the compound packet contains an SR or RR packet requirement that the compound packet contains an SR or RR packet
generated by the sender of the RTCP feedback packet. For reduced- generated by the sender of the RTCP feedback packet. For reduced-
size RTCP packets, aggregation of RTCP feedback packets from multiple size RTCP packets, aggregation of RTCP feedback packets from multiple
sources is not limited further than Section 4.2.2 of [RFC5506]. sources is not limited further than Section 4.2.2 of [RFC5506].
5.4.2. Scheduling an RTCP Feedback Packet 5.4.2. Scheduling an RTCP Feedback Packet
When an SSRC has a need to transmit a feedback packet in early mode When an SSRC has a need to transmit a feedback packet in early mode
it follows the scheduling rules defined in Section 3.5 in RTP/AVPF it follows the scheduling rules defined in Section 3.5 in RTP/AVPF
[RFC4585]. When following these rules the following clarifications [RFC4585]. When following these rules the following clarifications
need to be taken into account: need to be taken into account:
o That a session is considered to be point-to-point or multiparty o Whether a session is considered to be point-to-point or multiparty
not based on the number of SSRCs, but the number of endpoints is not based on the number of SSRCs, but the number of endpoints
directly seen in the RTP session by the endpoint. TBD: Clarify one directly interacts with in the RTP session. This is
what is considered to "see" an endpoint? determined by counting the number of CNAMEs used by the SSRCs
received. A RTP session MUST be considered multiparty if more
than one CNAME is received, unless signalling explicitly indicates
that the session is to be handled as point to point, or RTCP
reporting groups [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
are used. If RTCP reporting groups are used, the classification
is solely based on whether the endpoint receives a single
reporting group, indicating point to point, or if multiple
reporting groups are received (or a mixture of sources using and
sources not using reporting groups), which is classified as
multiparty. Note that contributing sources (CSRCs) can be bound
to any number of different CNAMEs and do not affect the
determination of whether the session is multiparty. Similarly,
SSRC/CSRC values that are only seen in the source field of an SDES
packet do not affect this determination.
o Note that when checking if there is already a scheduled compound o Note that when checking if there is already a scheduled compound
RTCP packet containing feedback messages (Step 2 in RTCP packet containing feedback messages (Step 2 in
Section 3.5.2), that check is done considering all local SSRCs. Section 3.5.2), that check is done considering all local SSRCs.
TBD: The above does not allow an SSRC that is unable to send either o If the SSRC is not allowed to send an early RTCP packet, then the
an early or regular RTCP packet with the feedback message within the feedback message MAY be queued for transmission as part of any
T_max_fb_delay to trigger another SSRC to send an early packet to early or regular scheduled transmission that can occur within the
which it could piggyback. Nor does it allow feedback to piggyback on maximum useful lifetime of the feedback message (T_max_fb_delay).
even regular RTCP packet transmissions that occur within This modifies the behaviour in bullet 4a) in Section 3.5.2 of
T_max_fb_delay. A question is if either of these behaviours ought to [RFC4585].
be allowed. The latter appears simple and straight forward. Instead
of discarding a FB message in step 4a: alternative 2, one could place The above rule for determining if a RTP session is to be considered
such messages in a cache with a discard time equal to T_max_fb_delay, point-to-point or multiparty is simple and straightforward and works
and in case any of the SSRCs schedule an RTCP packet for transmission in most cases. The goal with the above classification is to
within that time, it includes this message. The former case can have determine if the resources associated with RTP and RTCP are shared
more widespread impact on the application, and possibly also on the with only one peer or multiple other endpoints. This is significant
RTCP bandwidth consumption as it allows for more massive bursts of as it affects the impact and the necessary processing and resource
RTCP packets. Still, on a time scale of a regular reporting consumption. Relying on only CNAME will result in classifying some
interval, it ought to have no effect on the RTCP bandwidth as the few situations where one might actually have only one peer as a
extra feedback messages increase the avg_rtcp_size. multiparty situation. The known situations are the following ones:
Endpoint with multiple synchronization contexts: An endpoint that is
part of a point-to-point session can have multiple synchronization
contexts, for example due to forwarding an external media source
into a interactive real-time conversation. In this case the
classification will consider the peer as two endpoints, while the
actual RTP/RTCP transmission will be under the control of one
endpoint.
Selective Forwarding Middlebox: The SFM as defined in Section 3.7 of
[I-D.ietf-avtcore-rtp-topologies-update] has control over the
transmission and configurations between itself and each peer
endpoint individually. It also fully controls the RTCP packets
being forwarded between the individual legs. Thus, this type of
middlebox can be compared to the RTP mixer, which uses its own
SSRCs to mix or select the media it forwards, that will be
classified as a point-to-point RTP session by the above rule.
In the above cases it is very reasonable to use RTCP reporting groups
[I-D.ietf-avtcore-rtp-multi-stream-optimisation]. If that extension
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
single reporting group.
The above rules will also classify some sessions where the endpoint
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
session for the discussed endpoint. However, this will in most cases
be okay, as the RTP mixer provides separation between the two parts
of the session. The responsibility falls on the mixer to act
accordingly in each domain.
Note: The above usage of point-to-point or multiparty as classifiers
is actually misleading, but we maintain these labels to match what is
used in [RFC4585] as this ensures that the right algorithms are
applied.
To conclude we note that in some cases signalling can be used to
override the rule when it would result in the wrong classification.
6. RTCP Considerations for Streams with Disparate Rates 6. RTCP Considerations for Streams with Disparate Rates
An RTP session has a single set of parameters that configure the An RTP session has a single set of parameters that configure the
session bandwidth. These are the RTCP sender and receiver fractions session bandwidth. These are the RTCP sender and receiver fractions
(e.g., the SDP "b=RR:" and "b=RS:" lines), and the parameters of the (e.g., the SDP "b=RR:" and "b=RS:" lines), and the parameters of the
RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its
secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence, secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence,
the base RTCP reporting interval, before randomisation, will be the the base RTCP reporting interval, before randomisation, will be the
same for every sending SSRC in an RTP session. Similarly, every same for every sending SSRC in an RTP session. Similarly, every
receiving SSRC in an RTP session will have the same base reporting receiving SSRC in an RTP session will have the same base reporting
interval, although this can differ from the reporting interval chosen interval, although this can differ from the reporting interval chosen
by sending SSRCs. This uniform RTCP reporting interval for all SSRCs by sending SSRCs. This uniform RTCP reporting interval for all SSRCs
can result in RTCP reports being sent more often than is considered can result in RTCP reports being sent more often, or too seldom, than
desirable for a particular media type. is considered desirable for a RTP stream.
For example, consider a scenario when an audio flow sending at tens For example, consider a scenario when an audio flow sending at tens
of kilobits per second is multiplexed into an RTP session with a of kilobits per second is multiplexed into an RTP session with a
multi-megabit high quality video flow. If the session bandwidth is multi-megabit high quality video flow. If the session bandwidth is
configured based on the video sending rate, and the default RTCP configured based on the video sending rate, and the default RTCP
bandwidth fraction of 5% of the session bandwidth is used, it is bandwidth fraction of 5% of the session bandwidth is used, it is
likely that the RTCP bandwidth will exceed the audio sending rate. likely that the RTCP bandwidth will exceed the audio sending rate.
If the reduced minimum RTCP interval described in Section 6.2 of If the reduced minimum RTCP interval described in Section 6.2 of
[RFC3550] is then used in the session, as appropriate for video where [RFC3550] is then used in the session, as appropriate for video where
rapid feedback on damaged I-frames is wanted, the uniform reporting rapid feedback on damaged I-frames is wanted, the uniform reporting
skipping to change at page 12, line 31 skipping to change at page 15, line 4
of kilobits per second is multiplexed into an RTP session with a of kilobits per second is multiplexed into an RTP session with a
multi-megabit high quality video flow. If the session bandwidth is multi-megabit high quality video flow. If the session bandwidth is
configured based on the video sending rate, and the default RTCP configured based on the video sending rate, and the default RTCP
bandwidth fraction of 5% of the session bandwidth is used, it is bandwidth fraction of 5% of the session bandwidth is used, it is
likely that the RTCP bandwidth will exceed the audio sending rate. likely that the RTCP bandwidth will exceed the audio sending rate.
If the reduced minimum RTCP interval described in Section 6.2 of If the reduced minimum RTCP interval described in Section 6.2 of
[RFC3550] is then used in the session, as appropriate for video where [RFC3550] is then used in the session, as appropriate for video where
rapid feedback on damaged I-frames is wanted, the uniform reporting rapid feedback on damaged I-frames is wanted, the uniform reporting
interval for all senders could mean that audio sources are expected interval for all senders could mean that audio sources are expected
to send RTCP packets more often than they send audio data packets. to send RTCP packets more often than they send audio data packets.
This bandwidth mismatch can be reduced by careful tuning of the RTCP This bandwidth mismatch can be reduced by careful tuning of the RTCP
parameters, especially trr_int when the RTP/AVPF profile is used, parameters, especially trr_int when the RTP/AVPF profile is used,
cannot be avoided entirely, as it is inherent in the design of the cannot be avoided entirely, as it is inherent in the design of the
RTCP timing rules, and affects all RTP sessions that contain flows RTCP timing rules, and affects all RTP sessions that contain flows
with greatly mismatched bandwidth. with greatly mismatched bandwidth.
Different media rates or desired RTCP behaviours can also occur
between SSRCs carrying the same media type. A common case in
multiparty conferencing is when only one or two video source are
shown in higher resolution, while the others are shown as small
thumbnails, with the choice of which is shown in high resolution
being voice activity controlled. Here the differences are both in
actual media rate and in choices for what feedback messages might be
needed. Other examples of differences that can exist are due to the
intended usage of a media source. A media source carrying the video
of the speaker in a conference is different from a document camera.
Basic parameters that can differ in this case are frame-rate,
acceptable end-to-end delay, and the SNR fidelity of the image.
These differences affect not only the needed bit-rates, but also
possible transmission behaviours, usable repair mechanisms, what
feedback messages the control and repair requires, the transmission
requirements on those feedback messages, and monitoring of the RTP
stream delivery.
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 flow in a single RTP session, that session will
comprise four SSRCs, but if separate RTP sessions had been used for comprise four SSRCs, but if separate RTP sessions had been used for
audio and video, each of those two RTP sessions would comprise only audio and video, each of those two RTP sessions would comprise only
two SSRCs. Sending multiple media streams in an RTP session hence two SSRCs. Sending multiple media 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
skipping to change at page 16, line 11 skipping to change at page 18, line 51
previous specification are inconsistent in this regard. To avoid previous specification are inconsistent in this regard. To avoid
interoperability issues, this memo updates the timeout rules as interoperability issues, this memo updates the timeout rules as
follows: follows:
o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the
timeout interval SHALL be calculated using a multiplier of five timeout interval SHALL be calculated using a multiplier of five
times the deterministic RTCP reporting interval. That is, the times the deterministic RTCP reporting interval. That is, the
timeout interval SHALL be 5*Td. timeout interval SHALL be 5*Td.
o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles,
calculation of Td SHALL be done using a Tmin value of 5 seconds calculation of Td, for the purpose of calculating the participant
and not the reduced minimal interval, even if the reduced minimum timeout only, SHALL be done using a Tmin value of 5 seconds and
not the reduced minimal interval, even if the reduced minimum
interval is used to calculate RTCP packet transmission intervals. interval is used to calculate RTCP packet transmission intervals.
This changes the behaviour for the RTP/AVPF or RTP/SAVPF profiles This changes the behaviour for the RTP/AVPF or RTP/SAVPF profiles
when T_rr_interval != 0, a behaviour defined in Section 3.5.4 of RFC when T_rr_interval != 0, a behaviour defined in Section 3.5.4 of RFC
4585, i.e. Tmin in the Td calculation is the T_rr_interval. 4585, i.e. Tmin in the Td calculation is the T_rr_interval.
6.2. Tuning RTCP transmissions 6.2. Tuning RTCP transmissions
This sub-section discusses what tuning can be done to reduce the This sub-section discusses what tuning can be done to reduce the
downsides of the shared RTCP packet intervals. First, it is downsides of the shared RTCP packet intervals. First, it is
considered what possibilities exist for the RTP/AVP [RFC3551] considered what possibilities exist for the RTP/AVP [RFC3551]
profile, then what additional tools are provided by RTP/AVPF profile, then what additional tools are provided by RTP/AVPF
[RFC4585]. [RFC4585].
6.2.1. RTP/AVP and RTP/SAVP 6.2.1. RTP/AVP and RTP/SAVP
skipping to change at page 18, line 14 skipping to change at page 21, line 6
6.2.2. RTP/AVPF and RTP/SAVPF 6.2.2. RTP/AVPF and RTP/SAVPF
When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool
for tuning RTCP transmissions: the T_rr_interval parameter. Use of for tuning RTCP transmissions: the T_rr_interval parameter. Use of
this parameter allows short RTCP reporting intervals; alternatively this parameter allows short RTCP reporting intervals; alternatively
it gives the ability to sent frequent RTCP feedback without sending it gives the ability to sent frequent RTCP feedback without sending
frequent regular RTCP reports. frequent regular RTCP reports.
The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set
to a value greater than zero allows more frequent RTCP feedback than to a value greater than zero but smaller than Tmin allows more
the RTP/AVP or RTP/SAVP profiles, for a given RTCP bandwidth. This frequent RTCP feedback than the RTP/AVP or RTP/SAVP profiles, for a
happens because Tmin is set to zero after the transmission of the given RTCP bandwidth. This happens because Tmin is set to zero after
initial RTCP report, causing the reporting interval for later packet the transmission of the initial RTCP report, causing the reporting
to be determined by the usual RTCP bandwidth-based calculation, with interval for later packet to be determined by the usual RTCP
Tmin=0, and the T_rr_interval. This has the effect that we are no bandwidth-based calculation, with Tmin=0, and the T_rr_interval.
longer restricted by the minimal interval (whether the default 5 This has the effect that we are no longer restricted by the minimal
second minimum, or the reduced minimum interval). Rather, the RTCP interval (whether the default 5 second minimum, or the reduced
bandwidth and the T_rr_interval are the governing factors, allowing minimum interval). Rather, the RTCP bandwidth and the T_rr_interval
faster feedback. Applications that care about rapid regular RTCP are the governing factors, allowing faster feedback. Applications
feedback ought to consider using the RTP/AVPF or RTP/SAVPF profile, that care about rapid regular RTCP feedback ought to consider using
even if they don't use the feedback features of that profile. the RTP/AVPF or RTP/SAVPF profile, even if they don't use the
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 media streams, e.g., video streams, but don't want
frequent regular reporting for other media streams, can configure the frequent regular reporting for other media 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.
skipping to change at page 19, line 8 skipping to change at page 21, line 50
When T_rr_interval is non-zero, there are configurations that need to When T_rr_interval is non-zero, there are configurations that need to
be avoided. If the RTCP bandwidth chosen is such that the Td value be avoided. If the RTCP bandwidth chosen is such that the Td value
is smaller than, but close to, T_rr_interval, then the actual regular is smaller than, but close to, T_rr_interval, then the actual regular
RTCP packet transmission interval can become very large, as discussed RTCP packet transmission interval can become very large, as discussed
in Section 6.1.1. Therefore, for configuration where one intends to in Section 6.1.1. Therefore, for configuration where one intends to
have Td smaller than T_rr_interval, then Td is RECOMMENDED to be have Td smaller than T_rr_interval, then Td is RECOMMENDED to be
targeted at values less than 1/4th of T_rr_interval which results in targeted at values less than 1/4th of T_rr_interval which results in
that the range becomes [0.5*T_rr_interval, 1.81*T_rr_interval]. that the range becomes [0.5*T_rr_interval, 1.81*T_rr_interval].
With the RTP/AVPF or RTP/SAVPF profile, using T_rr_interval = 0 with With the RTP/AVPF or RTP/SAVPF profiles, using T_rr_interval = 0 has
another low value significantly lower than Td still has utility, and utility, and results in a behaviour where the RTCP transmission is
different behaviour compared to the RTP/AVP profile. This avoids the only limited by the bandwidth, i.e., no Tmin limitations at all.
Tmin limitations of RTP/AVP, thus allowing more frequent regular RTCP
reporting. In fact this will result that the RTCP traffic becomes as
high as the configured values.
(TBD: a future version of this memo will include examples of how to This allows more frequent regular RTCP reporting than can be achieved
choose RTCP parameters for common scenarios) using the RTP/AVP profile. Many configurations of RTCP will not
consume all the bandwidth that they have been configured to use, but
this configuration will consume what it has been given. Note that
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
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 media stream,
other than using a separate RTP session for the other stream. other than using a separate RTP session for each type or stream.
7. Security Considerations 7. 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 media 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 media streams spread across different RTP
sessions. sessions.
8. IANA Considerations 8. IANA Considerations
No IANA actions are required. No IANA actions are needed.
9. Open Issues
At this stage this document contains a number of open issues. The
below list tries to summarize the issues:
1. Do we need to provide a recommendation for unicast session
joiners with many sources to not use 0 initial minimal interval
from bit-rate burst perspective?
2. RTCP parameters for common scenarios in Section 6.2?
3. Is scheduling algorithm working well with dynamic changes?
4. Are the scheduling algorithm changes impacting previous
implementations in such a way that the report aggregation has to
be agreed on, and thus needs to be considered as an optimization?
5. An open question is if any improvements or clarifications ought
to be allowed regarding FB message scheduling in multi-SSRC
endpoints.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
skipping to change at page 20, line 42 skipping to change at page 23, line 18
2006. 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[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, April 2009. and Consequences", RFC 5506, April 2009.
10.2. Informative References 9.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-06 (work in ietf-avtcore-multi-media-rtp-session-07 (work in
progress), October 2014. progress), March 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, Q., 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-00 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work
in progress), July 2013. in progress), February 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-04 (work in progress), ietf-avtcore-rtp-topologies-update-06 (work in progress),
August 2014. March 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-18 (work in progress), October 2014. framework-21 (work in progress), March 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-12 (work in progress), October 2014. negotiation-18 (work in progress), March 2015.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
Eleftheriadis, "RTP Payload Format for Scalable Video "Codec Control Messages in the RTP Audio-Visual Profile
Coding", RFC 6190, May 2011. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011.
[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, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
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
 End of changes. 60 change blocks. 
193 lines changed or deleted 316 lines changed or added

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