draft-ietf-avtcore-rtp-multi-stream-05.txt   draft-ietf-avtcore-rtp-multi-stream-06.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: January 04, 2015 Q. Wu Expires: April 30, 2015 Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
July 03, 2014 October 27, 2014
Sending Multiple Media Streams in a Single RTP Session Sending Multiple Media Streams in a Single RTP Session
draft-ietf-avtcore-rtp-multi-stream-05 draft-ietf-avtcore-rtp-multi-stream-06
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 January 04, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 36 skipping to change at page 2, line 36
5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5 5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5
5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 5 5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 10
5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 10 5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 10
5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 11 5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 11
6. RTCP Considerations for Streams with Disparate Rates . . . . 12 6. RTCP Considerations for Streams with Disparate Rates . . . . 12
6.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 13 6.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 13
6.1.1. AVPF T_rr_interval Behaviour . . . . . . . . . . . . 13 6.1.1. Problems with RTP/AVPF the T_rr_interval Parameter . 13
6.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 14 6.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 14
6.1.3. RTP/AVP and RTP/AVPF Interoperability . . . . . . . . 15 6.1.3. Interoperability Between RTP/AVP and RTP/AVPF . . . . 15
6.1.4. Specified Behaviour . . . . . . . . . . . . . . . . . 16 6.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 15
6.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 16 6.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 16
6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 16 6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 16
6.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 18 6.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
Caution has to be exercised, however, when an endpoint (or middlebox) Caution has to be exercised, however, when an endpoint (or middlebox)
with a large number of SSRCs joins a unicast session, since immediate with a large number of SSRCs joins a unicast session, since immediate
transmission of many RTCP reports can create a significant burst of transmission of many RTCP reports can create a significant burst of
traffic, leading to transient congestion and packet loss due to queue traffic, leading to transient congestion and packet loss due to queue
overflows. Implementers are advised to consider sending immediate overflows. Implementers are advised to consider sending immediate
RTCP packets for only a small number of SSRCs (e.g., the one or two RTCP packets for only a small number of SSRCs (e.g., the one or two
SSRCs they consider most important), with the initial RTCP packets SSRCs they consider most important), with the initial RTCP packets
for their other SSRCs being sent after the calculated initial RTCP for their other SSRCs being sent after the calculated initial RTCP
reporting interval, to avoid self congestion. reporting interval, to avoid self congestion.
(tbd: is this recommendation sufficiently strong?) (TBD: is this recommendation sufficiently strong?)
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 7, line 10 skipping to change at page 7, line 10
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,
provided they maintain the average RTCP packet size as described in provided 1) the resulting compound RTCP packets begin with an SR or
Section 5.3.1, and schedule packet transmission and aggregation as RR packet; 2) they maintain the average RTCP packet size as described
described in Section 5.3.2. in Section 5.3.1; and 3) they schedule packet transmission and manage
aggregation as described in Section 5.3.2.
5.3.1. Maintaining AVG_RTCP_SIZE 5.3.1. Maintaining AVG_RTCP_SIZE
The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis.
Each SSRC sends a single compound RTCP packet in each RTCP reporting Each SSRC sends a single compound RTCP packet in each RTCP reporting
interval. When an endpoint uses multiple SSRCs, it is desirable to interval. When an endpoint uses multiple SSRCs, it is desirable to
aggregate the compound RTCP packets sent by its SSRCs, reducing the aggregate the compound RTCP packets sent by its SSRCs, reducing the
overhead by forming a larger compound RTCP packet. This aggregation overhead by forming a larger compound RTCP packet. This aggregation
can be done as described in Section 5.3.2, provided the average RTCP can be done as described in Section 5.3.2, provided the average RTCP
packet size calculation is updated as follows. packet size calculation is updated as follows.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
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 That a session is considered to be point-to-point or multiparty
not based on the number of SSRCs, but the number of endpoints not based on the number of SSRCs, but the number of endpoints
directly seen in the RTP session by the endpoint. tbd: Clarify directly seen in the RTP session by the endpoint. TBD: Clarify
what is considered to "see" an endpoint? what is considered to "see" an endpoint?
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 TBD: The above does not allow an SSRC that is unable to send either
an early or regular RTCP packet with the feedback message within the an early or regular RTCP packet with the feedback message within the
T_max_fb_delay to trigger another SSRC to send an early packet to T_max_fb_delay to trigger another SSRC to send an early packet to
which it could piggyback. Nor does it allow feedback to piggyback on which it could piggyback. Nor does it allow feedback to piggyback on
skipping to change at page 12, line 7 skipping to change at page 12, line 7
and in case any of the SSRCs schedule an RTCP packet for transmission and in case any of the SSRCs schedule an RTCP packet for transmission
within that time, it includes this message. The former case can have within that time, it includes this message. The former case can have
more widespread impact on the application, and possibly also on the more widespread impact on the application, and possibly also on the
RTCP bandwidth consumption as it allows for more massive bursts of RTCP bandwidth consumption as it allows for more massive bursts of
RTCP packets. Still, on a time scale of a regular reporting RTCP packets. Still, on a time scale of a regular reporting
interval, it ought to have no effect on the RTCP bandwidth as the interval, it ought to have no effect on the RTCP bandwidth as the
extra feedback messages increase the avg_rtcp_size. extra feedback messages increase the avg_rtcp_size.
6. RTCP Considerations for Streams with Disparate Rates 6. RTCP Considerations for Streams with Disparate Rates
It is possible for a single RTP session to carry streams of greatly
differing bandwidth. There are two scenarios where this can occur.
The first is when a single RTP session carries multiple flows of the
same media type, but with very different quality; for example a video
switching multi-point conference unit might send a full rate high-
definition video stream of the active speaker but only thumbnails for
the other participants, all sent in a single RTP session. The second
scenarios occurs when audio and video flows are sent in a single RTP
session, as discussed in [I-D.ietf-avtcore-multi-media-rtp-session].
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, the RTCP sender and receiver fractions (e.g., via session bandwidth. These are the RTCP sender and receiver fractions
the SDP "b=RR:" and "b=RS:" lines), and the parameters of the RTP/ (e.g., the SDP "b=RR:" and "b=RS:" lines), and the parameters of the
AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its secure RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its
extension, RTP/SAVPF [RFC5124]) is used. As a consequence, the RTCP secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence,
reporting interval will be the same for every SSRC in an RTP session. the base RTCP reporting interval, before randomisation, will be the
This uniform RTCP reporting interval can result in RTCP reports being same for every sending SSRC in an RTP session. Similarly, every
sent more often than is considered desirable for a particular media receiving SSRC in an RTP session will have the same base reporting
type. For example, if an audio flow is multiplexed with a high interval, although this can differ from the reporting interval chosen
quality video flow where the session bandwidth is configured to match by sending SSRCs. This uniform RTCP reporting interval for all SSRCs
the video bandwidth, this can result in the RTCP packets having a can result in RTCP reports being sent more often than is considered
greater bandwidth allocation than the audio data rate. If the desirable for a particular media type.
reduced minimum RTCP interval described in Section 6.2 of [RFC3550]
is used in the session, which might be appropriate for video where
rapid feedback is wanted, the audio sources could be expected to send
RTCP packets more often than they send audio data packets. This is
most likely undesirable, and while the mismatch can be reduced
through careful tuning of the RTCP parameters, particularly trr_int
in RTP/AVPF sessions, it is inherent in the design of the RTCP timing
rules, and affects all RTP sessions containing flows with mismatched
bandwidth.
Having multiple media types in one RTP session also results in more For example, consider a scenario when an audio flow sending at tens
SSRCs being present in this RTP session. This increasing the amount of kilobits per second is multiplexed into an RTP session with a
of cross reporting between the SSRCs. From an RTCP perspective, two multi-megabit high quality video flow. If the session bandwidth is
RTP sessions with half the number of SSRCs in each will be slightly configured based on the video sending rate, and the default RTCP
more efficient. If someone needs either the higher efficiency due to bandwidth fraction of 5% of the session bandwidth is used, it is
the lesser number of SSRCs or the fact that one can't tailor RTCP likely that the RTCP bandwidth will exceed the audio sending rate.
usage per media type, they need to use independent RTP sessions. If the reduced minimum RTCP interval described in Section 6.2 of
[RFC3550] is then used in the session, as appropriate for video where
rapid feedback on damaged I-frames is wanted, the uniform reporting
interval for all senders could mean that audio sources are expected
to send RTCP packets more often than they send audio data packets.
This bandwidth mismatch can be reduced by careful tuning of the RTCP
parameters, especially trr_int when the RTP/AVPF profile is used,
cannot be avoided entirely, as it is inherent in the design of the
RTCP timing rules, and affects all RTP sessions that contain flows
with greatly mismatched bandwidth.
When it comes to configuring RTCP the need for regular periodic Sending multiple media types in a single RTP session causes that
reporting needs to be weighted against any feedback or control session to contain more SSRCs than if each media type was sent in a
messages being sent. Applications using RTP/AVPF or RTP/SAVPF are separate RTP session. For example, if two participants each send an
RECOMMENDED to consider setting the trr-int parameter to a value audio and a video flow in a single RTP session, that session will
suitable for the application's needs, thus potentially reducing the comprise four SSRCs, but if separate RTP sessions had been used for
need for regular reporting and thus releasing more bandwidth for use audio and video, each of those two RTP sessions would comprise only
for feedback or control. two SSRCs. Sending multiple media streams in an RTP session hence
increases the amount of cross reporting between the SSRCs, as each
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
would be the case if separate RTP sessions where used for a given
RTCP bandwidth.
Another aspect of an RTP session with multiple media types is that Finally, when an RTP session contains multiple media types, it is
the RTCP packets, RTCP Feedback Messages, or RTCP XR metrics used important to note that the RTCP reception quality reports, feedback
might not be applicable to all media types. Instead, all RTP/RTCP messages, and extended report blocks used might not be applicable to
endpoints need to correlate the media type of the SSRC being all media types. Endpoints will need to consider the media type of
referenced in a message or packet and only use those 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.
6.1. Timing out SSRCs From an RTCP perspective, therefore, it can be seen that there are
advantages to using separate RTP sessions for each media stream,
rather than sending multiple media streams in a single RTP session.
However, these are frequently offset by the need to reduce port use,
to ease NAT/firewall traversal, achieved by combining media streams
into a single RTP session. The following sections consider some of
the issues with using RTCP in sessions with multiple media streams in
more detail.
This section discusses issues around timing out SSRCs. After the 6.1. Timing out SSRCs
discussion, clarified and mandated behaviour for SSRC timeout is
specified.
6.1.1. AVPF T_rr_interval Behaviour Various issues have been identified with timing out SSRC values when
sending multiple media streams in an RTP session.
The RTP/AVPF profile includes a mechanism for suppressing regular 6.1.1. Problems with RTP/AVPF the T_rr_interval Parameter
RTCP reporting from being sent unnecessarily frequently if sufficient
RTCP bandwidth is configured. This mechanism is defined in
Section 3.5.3 of [RFC4585], and can be summarized as follows: if less
than a randomized T_rr_interval value has passed since the last
regular report, and no feedback messages need to be sent, then the
RTCP regular report is suppressed. The randomization is done
linearly in the interval 0.5 to 1.5 times T_rr_interval. The
randomized T_rr_interval is recalculated after every transmitted
regular packet, i.e when t_rr_last was updated. The benefit of the
suppression mechanism is that it avoids wasting bandwidth when there
is nothing requiring frequent RTCP transmissions, but still allows
utilization of the configured bandwidth when feedback is needed.
Unfortunately this suppression mechanism has some behaviour that is The RTP/AVPF profile includes a method to prevent RTCP reports from
less than ideal. First of all, the randomized T_rr_interval is being sent too often. This mechanism is described in Section 3.5.3
distributed over a larger range than the actual transmission interval of [RFC4585], and is controlled by the T_rr_interval parameter. It
for RTCP would be if T_rr_interval and Td had the same value. The works as follows. When a regular RTCP report is sent, a new random
reconsideration mechanism and its compensation factor result in the value, T_rr_current_interval, is generated, drawn evenly in the range
actual RTCP transmission intervals for a Td having a distribution 0.5 to 1.5 times T_rr_interval. If a regular RTCP packet is to be
that is exponentially growing more likely with higher values, and is sent earlier then T_rr_current_interval seconds after the previous
bounded to the interval [0.5/1.21828, 1.5/1.21828]*Td, i.e. with a regular RTCP packet, and there are no feedback messages to be sent,
Td value of 5 s [2.052, 6.156]. In comparison, the suppression acts then that regular RTCP packet is suppressed, and the next regular
in an interval that is 0.5 to 1.5 times the T_rr_interval, i.e. for RTCP packet is scheduled. The T_rr_current_interval is recalculated
T_rr_interval = 5 s this is [2.5, 7.5]. each time a regular RTCP packet is sent. The benefit of suppression
is that it avoids wasting bandwidth when there is nothing requiring
frequent RTCP transmissions, but still allows utilization of the
configured bandwidth when feedback is needed.
The effect of the above is that the time period between two RTCP Unfortunately this suppression mechanism skews the distribution of
packets when using T_rr_interval suppression can become very long the RTCP sending intervals compared to the regular RTCP reporting
compared to the average input values. The longest time interval intervals. The standard RTCP timing rules, including reconsideration
between one transmitted regular RTCP compound packet and the next and the compensation factor, result in the intervals between sending
when T_rr_interval suppression is being used are: First the maximum RTCP packets having a distribution that is skewed towards the upper
T_rr_interval, i.e. 1.5*T_rr_interval. Assuming that the last end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the
suppressed packet would have been sent at 1.5*T_rr_interval, the deterministic calculated RTCP reporting interval. With Td = 5s this
maximum interval until a packet can be sent under the regular distribution covers the range [2.052s, 6.156s]. In comparison, the
scheduling is 1.5/1.21828*Td. Thus, the maximum time in total is RTP/AVPF suppression rules act in an interval that is 0.5 to 1.5
1.5*T_rr_interval + 1.5/1.21828*Td. times T_rr_interval; for T_rr_interval = 5s this is [2.5s, 7.5s].
If Td and T_rr_interval have the same value, i.e. the minimal The effect of this is that the time between consecutive RTCP packets
interval desired (T_rr_interval) and the actual actual average when using T_rr_interval suppression can become large. The maximum
interval specified by the RTCP scheduling algorithm (Td) are the time interval between sending one regular RTCP packet and the next,
same, one might expect that RTCP packets would be sent according to when T_rr_interval is being used, occurs when T_rr_current_interval
the regular mechanism. Instead, this algorithm results in the RTCP takes its maximum value and a regular RTCP packet is suppressed at
packets being sent anywhere from 0.5*Td to ~2.731*Td. The the end of the suppression period, then the next regular RTCP packet
probability distribution over that time is also non-trivial in its is scheduled after its largest possible reporting interval. Taking
shape, somewhat similar to a saw tooth. the worst case of the two intervals gives a maximum time between two
RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td.
Thus, we recommend that the AVPF regular transmission mechanism is This behaviour can be surprising when Td and T_rr_interval have the
revised in the future. This issue also has further implications as same value. That is, when T_rr_interval is configured to match the
discussed in the next section. regular RTCP reporting interval. In this case, one might expect that
regular RTCP packets are sent according to their usual schedule, but
feedback packets can be sent early. However, the above-mentioned
issue results in the RTCP packets actually being sent in the range
[0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather
than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but
is not a problem in itself. However, when coupled with packet loss,
it raises the issue of premature timeout.
6.1.2. Avoiding Premature Timeout 6.1.2. Avoiding Premature Timeout
In RTP/AVP [RFC3550] the timeout behaviour is simple and is 5 times In RTP/AVP [RFC3550] the timeout behaviour is simple, and is 5 times
Td, where Td is calculated with a Tmin value of 5 seconds. In other Td, where Td is calculated with a Tmin value of 5 seconds. In other
words, if the RTCP bandwidth allowed for an RTCP interval more words, if the configured RTCP bandwidth allows for an average RTCP
frequent than every 5 seconds on average, then timeout happened after reporting interval shorter than 5 seconds, the timeout is 25 seconds
5*Td = 25 seconds of no activity from the SSRC (RTP or RTCP), of no activity from the SSRC (RTP or RTCP), otherwise the timeout is
otherwise it was 5 average reporting intervals. 5 average reporting intervals.
RTP/AVPF [RFC4585] introduced two different behaviours depending on RTP/AVPF [RFC4585] introduces different timeout behaviours depending
the value of T_rr_interval. When T_rr_interval was 0, it defaulted on the value of T_rr_interval. When T_rr_interval is 0, it uses the
to the same Td calculation in RTP/AVP [RFC3550]. However, when same timeout calculation as RTP/AVP. However, when T_rr_interval is
T_rr_interval is non-zero the Tmin value become T_rr_interval in that non-zero, it replaces Tmin in the timeout calculation, most likely to
calculation, most likely to enable speed up the detection of timed speed up detection of timed out SSRCs. However, using a non-zero
out SSRCs. However, using a non-zero T_rr_interval has two T_rr_interval has two consequences for RTP behaviour.
consequences for RTP behaviour.
First, the number of actually sent RTCP packets for an SSRC that First, due to suppression, the number of RTP and RTCP packets sent by
currently is not an active RTP sender can become very low due to the an SSRC that is not an active RTP sender can become very low, because
issue discussed above in Section 6.1.1. As the RTCP packet interval of the issue discussed in Section 6.1.1. As the RTCP packet interval
can be as long as 2.73*Td, then during a 5*Td time period an endpoint can be as long as 2.73*Td, then during a 5*Td time period an endpoint
may in fact transmit only a single RTCP packet. The long intervals might in fact transmit only a single RTCP packet. The long intervals
result in fewer RTCP packets, to a point where a one or two packet result in fewer RTCP packets, to a point where a single RTCP packet
losses in RTCP result in timing out an SSRC. loss can sometimes result in timing out an SSRC.
Second, the change also increased RTP/AVPF's brittleness to both Second, the RTP/AVPF changes to the timeout rules reduce robustness
packet loss and configuration errors. In many cases, when one to misconfiguration. It is common to use RTP/AVPF configured such
desires to use RTP/AVPF for its feedback, one will ensure that RTCP that RTCP packets can be sent frequently, to allow rapid feedback,
is configured for more frequent transmissions on average than every 5 however this makes timeouts very sensitive to T_rr_interval. For
seconds. Thus, many more RTP and RTCP packets can be transmitted example, if two SSRCs are configured one with T_rr_interval = 0.1s
during the time interval. Lets consider an implementation that would and the other with T_rr_interval = 0.6s, then this small difference
follow the RTP/AVP or RTP/AVPF with T_rr_interval = 0 rules for will result in the SSRC with the shorter T_rr_interval timing out the
timeout, also when T_rr_interval is not zero. In such a case when other if it stops sending RTP packets, since the other RTCP reporting
the configured value of the T_rr_interval is significantly smaller interval is more than five times its own. When RTP/AVP is used, or
than 5 seconds, e.g. less than 1 second, then a difference between RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout
using 0.1 seconds and 0.6 seconds has no significant impact on when period will be 25s, and differences between configured RTCP bandwidth
an SSRC will be timed out. However, such a configuration difference can only cause premature timeouts when the reporting intervals are
between two endpoints following RFC 4585 will result in that the greater than 5s and differ by a factor of five. To limit the scope
endpoint configured with T_rr_interval = 0.1 will frequently timeout for such problematic misconfiguration, we propose an update to the
SSRCs currently not sending RTP, from the endpoint configured with RTP/AVPF timeout rules in Section 6.1.4.
0.6, as that is six times the Td value used by the endpoint
configured with T_rr_interval=0.1, assuming sufficient bandwidth.
For this reason such a change is implemented below in Section 6.1.4.
6.1.3. RTP/AVP and RTP/AVPF Interoperability 6.1.3. Interoperability Between RTP/AVP and RTP/AVPF
If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their
secure variants) are combined in a single RTP session, and the RTP/ secure variants) are combined within a single RTP session, and the
AVPF endpoints use a non-zero T_rr_interval that is significantly RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly
lower than 5 seconds, then there is a risk that the RTP/AVPF below 5 seconds, there is a risk that the RTP/AVPF endpoints will
endpoints will prematurely timeout the RTP/AVP SSRCs due to their prematurely timeout the SSRCs of the RTP/AVP endpoints, due to their
different RTCP timeout intervals. Conversely, if the RTP/AVPF different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints
endpoints use a T_rr_interval that is significant larger than 5 use a T_rr_interval that is significant larger than 5 seconds, there
seconds, there is a risk that the RTP/AVP endpoints will timeout the is a risk that the RTP/AVP endpoints will timeout the SSRCs of the
RTP/AVPF SSRCs. RTP/AVPF endpoints.
If such mixed RTP profiles are used, (though this is NOT Mixing endpoints using two different RTP profiles within a single RTP
RECOMMENDED), and the AVPF endpoint is not updated to follow this session is NOT RECOMMENDED. However, if mixed RTP profiles are used,
specification, then the RTP/AVPF session SHOULD use a non-zero and the RTP/AVPF endpoints are not updated to follow Section 6.1.4 of
T_rr_interval that is 4 seconds. this memo, then the RTP/AVPF session SHOULD be configured to use
T_rr_interval = 4 seconds to avoid premature timeouts.
It might appear strange to use a T_rr_interval of 4 seconds. It The choice of T_rr_interval = 4 seconds for interoperability might
might be intuitive that this value ought to be 5 seconds, as then appear strange. Intuitively, this value ought to be 5 seconds, to
both the RTP/AVP and RTP/AVPF would use the same timeout period. make both the RTP/AVP and RTP/AVPF use the same timeout period.
However, considering regular RTCP transmission and their packet However, the behaviour outlined in Section 6.1.1 shows that actual
intervals for RTP/AVPF its mean value will (with non-zero RTP/AVPF reporting intervals can be longer than expected. Setting
T_rr_interval) be larger than T_rr_interval due to the scheduling T_rr_interval = 4 seconds gives actual RTCP intervals near to those
algorithm's behaviour as discussed in Section 6.1.1. Thus, to enable expected by RTP/AVP, ensuring interoperability.
an equal amount of regular RTCP transmissions in each directions
between RTP/AVP and RTP/AVPF endpoints, taking the altered timeout
intervals into account, the optimal value is around four (4), where
almost four transmissions will on average occur in each direction
between the different profile types given an otherwise good
configuration of parameters in regards to T_rr_interval. If the RTCP
bandwidth parameters are selected so that Td based on bandwidth is
close to 4, i.e. close to T_rr_interval the risk increases that RTP/
AVPF SSRCs will be timed out by RTP/AVP endpoints, as the RTP/AVPF
SSRC might only manage two transmissions in the timeout period.
6.1.4. Specified Behaviour 6.1.4. Updated SSRC Timeout Rules
The above considerations result in the following clarification and To ensure interoperability and avoid premature timeouts, all SSRCs in
RTP/AVPF specification change. an RTP session MUST use the same timeout behaviour. However,
previous specification are inconsistent in this regard. To avoid
interoperability issues, this memo updates the timeout rules as
follows:
All SSRCs used in an RTP session MUST use the same timeout behaviour o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the
to avoid premature timeouts. This will depend on the RTP profile and timeout interval SHALL be calculated using a multiplier of five
its configuration. The RTP specification provides several options times the deterministic RTCP reporting interval. That is, the
that can influence the values used when calculating the time timeout interval SHALL be 5*Td.
interval. To avoid interoperability issues when using this
specification, this document makes several clarifications to the
calculations.
For RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF, the timeout interval o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles,
SHALL be calculated using a multiplier of 5, i.e. the timeout calculation of Td SHALL be done using a Tmin value of 5 seconds
interval becomes 5*Td. The Td calculation SHALL be done using a Tmin and not the reduced minimal interval, even if the reduced minimum
value of 5 seconds, not the reduced minimal interval even if used to interval is used to calculate RTCP packet transmission intervals.
calculate RTCP packet transmission intervals. This changes the
behaviour for the RTP/AVPF or RTP/SAVPF profiles when T_rr_interval This changes the behaviour for the RTP/AVPF or RTP/SAVPF profiles
!= 0, a behaviour defined in Section 3.5.4 of RFC 4585, i.e. Tmin in when T_rr_interval != 0, a behaviour defined in Section 3.5.4 of RFC
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
When using the RTP/AVP or RTP/SAVP profiles the tuning one can do is When using the RTP/AVP or RTP/SAVP profiles, the options for tuning
very limited. The controls one has are limited to the RTCP bandwidth the RTCP reporting intervals are limited to the RTCP sender and
values and whether the minimum RTCP interval is scaled according to receiver bandwidth, and whether the minimum RTCP interval is scaled
the bandwidth. As the scheduling algorithm includes both random according to the bandwidth. As the scheduling algorithm includes
factors and reconsideration, one can't simply calculate the expected both randomisation and reconsideration, one cannot simply calculate
average transmission interval using the formula for Td. But it does the expected average transmission interval using the formula for Td
indicate the important factors affecting the transmission interval, given in Section 6.3.1 of [RFC3550]. However, by considering the
namely the RTCP bandwidth available for the role (Active Sender or inputs to that expression, and the randomisation and reconsideration
Participant), the average RTCP packet size, and the number of SSRCs rules, we can begin to understand the behaviour of the RTCP
classified in the relevant role. Note that if the ratio of senders transmission interval.
to total number of session participants is larger than the ratio of
RTCP bandwidth for senders in relation to the total RTCP bandwidth,
then senders and receivers are treated together.
Let's start with some basic observations: Let's start with some basic observations:
a. Unless the scaled minimum RTCP interval is used, then Td prior to a. Unless the scaled minimum RTCP interval is used, then Td prior to
randomization and reconsideration can never be less than 5 randomization and reconsideration can never be less than Tmin.
seconds (assuming default Tmin of 5 seconds). The default value of Tmin is 5 seconds.
b. If the scaled minimum RTCP interval is used, Td can become as low b. If the scaled minimum RTCP interval is used, Td can become as low
as 360 divided by RTP Session bandwidth in kilobits. In SDP the as 360 divided by RTP Session bandwidth in kilobits per second.
RTP session bandwidth is signalled using b=AS. An RTP Session In SDP the RTP session bandwidth is signalled using a "b=AS"
bandwidth of 72 kbps results in Tmin being 5 seconds. An RTP line. An RTP Session bandwidth of 72kbps results in Tmin being 5
session bandwidth of 360 kbps of course gives a Tmin of 1 second, seconds. An RTP session bandwidth of 360kbps of course gives a
and to achieve a Tmin equal to once every frame for a 25 Hz video Tmin of 1 second, and to achieve a Tmin equal to once every frame
stream requires an RTP session bandwidth of 9 Mbps! (The use of for a 25 frame-per-second video stream requires an RTP session
the RTP/AVPF or RTP/SAVPF profile allows a smaller Tmin, and bandwidth of 9Mbps. Use of the RTP/AVPF or RTP/SAVPF profile
hence more frequent RTCP reports, as discussed below). allows more frequent RTCP reports for the same bandwidth, as
discussed below.
c. Let's calculate the number (n) of SSRCs in the RTP session that c. The value of Td scales with the number of SSRCs and the average
5% of the session bandwidth can support to yield a Td value equal size of the RTCP reports, to keep the overall RTCP bandwidth
to Tmin with minimal scaling. For this calculation we have to constant.
make two assumptions. The first is that we will consider most or
all SSRC being senders, resulting in everyone sharing the
available bandwidth. Secondly we will select an average RTCP
packet size. This packet will consist of an SR, containing (n-1)
report blocks up to 31 report blocks, and an SDES item with at
least a CNAME (17 bytes in size) in it. Such a basic packet will
be 800 bytes for n>=32. With these parameters, and as the
bandwidth goes up the time interval is proportionally decreased
(due to minimal scaling), thus all the example bandwidths 72
kbps, 360 kbps and 9 Mbps all support 9 SSRCs.
d. The actual transmission interval for a Td value is [0.5*Td/ d. The actual transmission interval for a Td value is in the range
1.21828,1.5*Td/1.21828], which means that for Td = 5 seconds, the [0.5*Td/1.21828,1.5*Td/1.21828], and the distribution is skewed,
interval is actually [2.052,6.156] and the distribution is not due to reconsideration, with the majority of the probability mass
uniform, but rather exponentially-increasing. The probability being above Td. This means, for example, that for Td = 5s, the
for sending at time X, given it is within the interval, is actual transmission interval will be distributed in the range
probability of picking X in the interval times the probability to [2.052s, 6.156s], and tending towards the upper half of the
randomly picking a number that is <=X within the interval with an interval. Note that Tmin parameter limits the value of Td before
uniform probability distribution. This results in that the randomisation and reconsideration are applied, so the actual
majority of the probability mass is above the Td value. transmission interval will cover a range extending below Tmin.
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
while maintaining Td equal to Tmin. This will tell us how many media
streams we can report on, keeping the RTCP overhead within acceptable
bounds. We make two assumptions that simplify the calculation: that
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
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
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
RTCP interval calculation in Section 6.3.1 of [RFC3550], and
calculate the value of n needed to give Td = Tmin for the scaled
minimum interval, we find n=9 SSRCs can be supported (irrespective of
the interval, due to the way the reporting interval scales with the
session bandwidth). We see that to support more SSRCs, we need to
increase the RTCP bandwidth fraction from 5%; changing the session
bandwidth does not help due to the limit of Tmin.
To conclude, with RTP/AVP and RTP/SAVP the key limitation for small To conclude, with RTP/AVP and RTP/SAVP the key limitation for small
unicast sessions is going to be the Tmin value. Thus the RTP session unicast sessions is going to be the Tmin value. Thus the RTP session
bandwidth configured in RTCP has to be sufficiently high to reach the bandwidth configured in RTCP has to be sufficiently high to reach the
reporting goals the application has following the rules for the reporting goals the application has following the rules for the
scaled minimal RTCP interval. scaled minimal RTCP interval.
6.2.2. RTP/AVPF and RTP/SAVPF 6.2.2. RTP/AVPF and RTP/SAVPF
When using RTP/AVPF or RTP/SAVPF we get a quite powerful additional When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool
tool, the setting of the T_rr_interval which has several effects on for tuning RTCP transmissions: the T_rr_interval parameter. Use of
the RTCP reporting. First of all as Tmin is set to 0 after the this parameter allows short RTCP reporting intervals; alternatively
initial transmission, the regular reporting interval is instead it gives the ability to sent frequent RTCP feedback without sending
determined by the regular bandwidth based calculation and the frequent regular RTCP reports.
T_rr_interval. This has the effect that we are no longer restricted
by the minimal interval or even the scaling rule for the minimal
rule. Instead the RTCP bandwidth and the T_rr_interval are the
governing factors.
Now it also becomes important to separate between the application's The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set
need for regular reports and RTCP feedback packet types. In both to a value greater than zero allows more frequent RTCP feedback than
regular RTCP mode, as in Early RTCP Mode, the usage of the the RTP/AVP or RTP/SAVP profiles, for a given RTCP bandwidth. This
T_rr_interval prevents regular RTCP packets, i.e. packets without happens because Tmin is set to zero after the transmission of the
any Feedback packets, to be sent more often than T_rr_interval. This initial RTCP report, causing the reporting interval for later packet
value is applied to prevent any regular RTCP packet to be sent less to be determined by the usual RTCP bandwidth-based calculation, with
than T_rr_interval times a uniformly distributed random value from Tmin=0, and the T_rr_interval. This has the effect that we are no
the interval [0.5,1.5] after the previous regular packet packet. The longer restricted by the minimal interval (whether the default 5
random value recalculated after each regular RTCP packet second minimum, or the reduced minimum interval). Rather, the RTCP
transmission. bandwidth and the T_rr_interval are the governing factors, allowing
faster feedback. Applications 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 feedback features of that profile.
So applications that have a use for feedback packets for some media The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback
streams, for example video streams, but don't want frequent regular packets to be sent frequently, without also requiring regular RTCP
reporting for audio, could configure the T_rr_interval to a value so reports to be sent frequently, since T_rr_interval limits the rate at
that the regular reporting for both audio and video is at a level which regular RTCP packets can be sent, while still permitting RTCP
that is considered acceptable for the audio. They could then use feedback packets to be sent. Applications that can use feedback
feedback packets, which will include RTCP SR/RR packets, unless packets for some media streams, e.g., video streams, but don't want
reduced-size RTCP feedback packets [RFC5506] are used, and can frequent regular reporting for other media streams, can configure the
include other report information in addition to the feedback packet T_rr_interval to a value so that the regular reporting for both audio
that needs to be sent. That way the available RTCP bandwidth can be and video is at a level that is considered acceptable for the audio.
focused for the use which provides the most utility for the They could then use feedback packets, which will include RTCP SR/RR
packets unless reduced size RTCP feedback packets [RFC5506] are used,
for the video reporting. This allows the available RTCP bandwidth to
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, in fact it might make it even more for the RTCP bandwidth value. Indeed, it might make this choice even
important, as this is more likely to affect the RTCP behaviour and more important, as this is more likely to affect the RTCP behaviour
performance than when using RTP/AVP, as there are fewer limitations and performance than when using the RTP/AVP or RTP/SAVP profile, as
affecting the RTCP transmission. there are fewer limitations affecting the RTCP transmission.
When using T_rr_interval, i.e. having it be non zero, there are When T_rr_interval is non-zero, there are configurations that need to
configurations that have to be avoided. If the resulting Td value is be avoided. If the RTCP bandwidth chosen is such that the Td value
smaller but close to T_rr_interval then the interval in which the is smaller than, but close to, T_rr_interval, then the actual regular
actual regular RTCP packet transmission falls into becomes very RTCP packet transmission interval can become very large, as discussed
large, from 0.5 times T_rr_interval up to 2.73 times the in Section 6.1.1. Therefore, for configuration where one intends to
T_rr_interval. Therefore for configuration where one intends to have have Td smaller than T_rr_interval, then Td is RECOMMENDED to be
Td smaller than T_rr_interval, then Td is RECOMMENDED to be targeted targeted at values less than 1/4th of T_rr_interval which results in
at values less than 1/4th of T_rr_interval which results in that the that the range becomes [0.5*T_rr_interval, 1.81*T_rr_interval].
range becomes [0.5*T_rr_interval, 1.81*T_rr_interval].
With RTP/AVPF, using a T_rr_interval of 0 or with another low value With the RTP/AVPF or RTP/SAVPF profile, using T_rr_interval = 0 with
significantly lower than Td still has utility, and different another low value significantly lower than Td still has utility, and
behaviour compared to RTP/AVP. This avoids the Tmin limitations of different behaviour compared to the RTP/AVP profile. This avoids the
RTP/AVP, thus allowing more frequent regular RTCP reporting. In fact Tmin limitations of RTP/AVP, thus allowing more frequent regular RTCP
this will result that the RTCP traffic becomes as high as the reporting. In fact this will result that the RTCP traffic becomes as
configured values. high as the configured values.
(tbd: a future version of this memo will include examples of how to (TBD: a future version of this memo will include examples of how to
choose RTCP parameters for common scenarios) choose RTCP parameters for common scenarios)
There exists no method within the specification for using different There exists no method for using different regular RTCP reporting
regular RTCP reporting intervals depending on the media type or intervals depending on the media type or individual media stream,
individual media stream. other than using a separate RTP session for the other stream.
7. Security Considerations 7. Security Considerations
In the secure RTP protocol (SRTP) [RFC3711], the cryptographic When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the
context of a compound SRTCP packet is the SSRC of the sender of the secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the
first RTCP (sub-)packet. This could matter in some cases, especially cryptographic context of a compound secure RTCP packet is the SSRC of
for keying mechanisms such as Mikey [RFC3830] which allow use of per- the sender of the first RTCP (sub-)packet. This could matter in some
SSRC keying. cases, especially for keying mechanisms such as Mikey [RFC3830] which
allow use of per-SSRC keying.
Other than that, the standard security considerations of RTP apply; Otherwise, the standard security considerations of RTP apply; sending
sending multiple media streams from a single endpoint does not appear multiple media streams from a single endpoint in a single RTP session
to have different security consequences than sending the same number does not appear to have different security consequences than sending
of streams. the same number of media streams spread across different RTP
sessions.
8. IANA Considerations 8. IANA Considerations
No IANA actions needed. No IANA actions are required.
9. Open Issues 9. Open Issues
At this stage this document contains a number of open issues. The At this stage this document contains a number of open issues. The
below list tries to summarize the issues: below list tries to summarize the issues:
1. Do we need to provide a recommendation for unicast session 1. Do we need to provide a recommendation for unicast session
joiners with many sources to not use 0 initial minimal interval joiners with many sources to not use 0 initial minimal interval
from bit-rate burst perspective? from bit-rate burst perspective?
skipping to change at page 21, line 6 skipping to change at page 20, line 47
[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 10.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-05 (work in ietf-avtcore-multi-media-rtp-session-06 (work in
progress), February 2014. progress), October 2014.
[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, Q., 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-00 (work
in progress), July 2013. in progress), July 2013.
[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-02 (work in progress), ietf-avtcore-rtp-topologies-update-04 (work in progress),
May 2014. August 2014.
[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-16 (work in progress), June 2014. framework-18 (work in progress), October 2014.
[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-07 (work in progress), April 2014. negotiation-12 (work in progress), October 2014.
[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 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
skipping to change at page 22, line 5 skipping to change at page 21, line 46
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. [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, May 2011. Coding", RFC 6190, May 2011.
Authors' Addresses [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.
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. 59 change blocks. 
310 lines changed or deleted 311 lines changed or added

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