draft-ietf-avtcore-rtp-multi-stream-03.txt   draft-ietf-avtcore-rtp-multi-stream-04.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: August 18, 2014 Q. Wu Expires: November 29, 2014 Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
February 14, 2014 May 28, 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-03 draft-ietf-avtcore-rtp-multi-stream-04
Abstract Abstract
This document expands and clarifies the behavior of the Real-Time This document expands and clarifies the behavior of the Real-Time
Transport Protocol (RTP) endpoints when they are using multiple Transport Protocol (RTP) endpoints when they are using multiple
synchronization sources (SSRCs), e.g. for sending multiple media synchronization sources (SSRCs), e.g. for sending multiple media
streams, in a single RTP session. In particular, issues involving streams, in a single RTP session. In particular, issues involving
RTCP Control Protocol (RTCP) messages are described. RTCP Control Protocol (RTCP) messages are described.
This document updates RFC 3550 in regards to handling of multiple This document updates RFC 3550 in regards to handling of multiple
SSRCs per endpoint in RTP sessions. It also updates RFC 4585 to SSRCs per endpoint in RTP sessions. It also updates RFC 4585 to
clarify the calculation of the timeout of SSRCs and the inclusion of update and clarify the calculation of the timeout of SSRCs and the
feeback messages. inclusion of feeback messages.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on November 29, 2014.
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 41 skipping to change at page 2, line 41
5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5 5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5
5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 6 5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 6
5.3. Compound RTCP Packets . . . . . . . . . . . . . . . . . . 6 5.3. 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. RTP/AVPF Feedback Packets . . . . . . . . . . . . . . . . 10 5.4. RTP/AVPF Feedback Packets . . . . . . . . . . . . . . . . 10
5.4.1. The SSRC Used . . . . . . . . . . . . . . . . . . . . 10 5.4.1. The SSRC Used . . . . . . . . . . . . . . . . . . . . 10
5.4.2. Scheduling a Feedback Packet . . . . . . . . . . . . 11 5.4.2. Scheduling a 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.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 14 6.1.1. AVPF T_rr_interval Behavior . . . . . . . . . . . . . 13
6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 14 6.1.2. Avoiding Pre-mature Timeout . . . . . . . . . . . . . 14
6.2.2. RT/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . . 16 6.1.3. AVP and AVPF Interoperability . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.1.4. Specified Behavior . . . . . . . . . . . . . . . . . 16
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2.2. RT/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 18 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
A.1. Changes From WG Draft -02 . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2. Changes From WG Draft -01 . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
A.3. Changes From WG Draft -00 . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 21
A.4. Changes From Individual Draft -02 . . . . . . . . . . . . 20 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 22
A.5. Changes From Individual Draft -01 . . . . . . . . . . . . 20 A.1. Changes From WG Draft -02 . . . . . . . . . . . . . . . . 22
A.6. Changes From Individual Draft -00 . . . . . . . . . . . . 21 A.2. Changes From WG Draft -01 . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 A.3. Changes From WG Draft -00 . . . . . . . . . . . . . . . . 22
A.4. Changes From Individual Draft -02 . . . . . . . . . . . . 23
A.5. Changes From Individual Draft -01 . . . . . . . . . . . . 23
A.6. Changes From Individual Draft -00 . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 written, and for quite some time after, endpoints in RTP originally written, 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. type.
skipping to change at page 3, line 33 skipping to change at page 3, line 37
design did consider such scenarios, the specification was not design did consider such scenarios, the specification was not
consistently written with such use cases in mind. The specifications consistently written with such use cases in mind. The specifications
are thus somewhat unclear. are thus somewhat unclear.
The purpose of this document is to expand and clarify [RFC3550]'s The purpose of this document is to expand and clarify [RFC3550]'s
language for these use cases. The authors believe this does not language for these use cases. The authors believe this does not
result in any major normative changes to the RTP specification, result in any major normative changes to the RTP specification,
however this document defines how the RTP specification is to be however this document defines how the RTP specification is to be
interpreted. In these cases, this document updates RFC3550. The interpreted. In these cases, this document updates RFC3550. The
document also updates RFC 4585 in regards to the timeout of inactive document also updates RFC 4585 in regards to the timeout of inactive
SSRCs as specificed in Section 6.1 as well as clarifying the SSRCs as specificed in Section 6.1 to resolve problematic behavior as
inclusion of feedback messages. well as clarifying the inclusion of feedback messages.
The document starts with terminology and some use cases where The document starts with terminology and some use cases where
multiple sources will occur. This is followed by RTP and RTCP multiple sources will occur. This is followed by RTP and RTCP
recommendations to resolve issues. Next are security considerations recommendations to resolve issues. Next are security considerations
and remaining open issues. and remaining open issues.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 13, line 35 skipping to change at page 13, line 35
might not be applicable to all media types. Instead, all RTP/RTCP might not be applicable to all media types. Instead, all RTP/RTCP
endpoints need to correlate the media type of the SSRC being endpoints need to correlate the media type of the SSRC being
referenced in a message or packet and only use those that apply to referenced in a message or packet and only use those 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 6.1. Timing out SSRCs
All SSRCs used in an RTP session MUST use the same timeout behaviour This section discusses issues around timing out SSRCs. After the
to avoid premature timeouts. This will depend on the RTP profile and discussion, clarified and mandated behavior for SSRC timeout is
its configuration. The RTP specification provides several options specified.
that can influence the values used when calculating the time
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 with T_rr_interval = 6.1.1. AVPF T_rr_interval Behavior
0, the timeout interval SHALL be calculated using a multiplier of 5,
i.e. the timeout interval becomes 5*Td. The Td calculation SHALL be The RTP/AVPF profile includes a mechanism for suppressing regular
done using a Tmin value of 5 seconds, not the reduced minimal RTCP reporting from being sent unnecessarily frequently if sufficient
interval even if used to calculate RTCP packet transmission RTCP bandwidth is configured. This mechanism is defined in
intervals. If using either the RTP/AVPF or RTP/SAVPF profiles with Section 3.5.3 of [RFC4585], and can be summarized as follows: if less
T_rr_interval != 0 then the calculation as specified in Section 3.5.4 than a randomized T_rr_interval value has passed since the last
of RFC 4585 SHALL be used with a multiplier of 5, i.e. Tmin in the Td regular report, and no feedback messages need to be sent, then the
calculation is the T_rr_interval. RTCP regular report is suppressed. The randomization is done by a
linear randomizer 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 behaviors that are
less than ideal. First of all, the randomized T_rr_interval is
distributed over a larger range than the actual transmission interval
for RTCP would be if T_rr_interval and Td had the same value. The
reconsideration mechanism and its compensation factor result in the
actual RTCP transmission intervals for a Td having a distribution
that is exponentially growing more likely with higher values, and is
bounded to the interval [0.5/1.21828, 1.5/1.21828]*Td, i.e. with a Td
value of 5 s [2.052, 6.156]. In comparison, the suppression acts in
an interval that is 0.5 to 1.5 times the T_rr_interval, i.e. for
T_rr_interval = 5 s this is [2.5, 7.5].
The effect of the above is that the time period between two RTCP
packets when using T_rr_interval suppression can become very long
compared to the average input values. The longest time interval
between one transmitted regular RTCP compound packet and the next
when T_rr_interval suppression is being used are: First the maximum
T_rr_interval, i.e. 1.5*T_rr_interval. Assuming that the last
suppressed packet would have been sent at 1.5*T_rr_interval, the
maximum interval until a packet can be sent under the regular
scheduling is 1.5/1.21828*Td. Thus, the maximum time in total is
1.5*T_rr_interval + 1.5/1.21828*Td.
If Td and T_rr_interval have the same value, i.e. the minimal
interval desired (T_rr_interval) and the actual actual average
interval specified by the RTCP scheduling algorithm (Td) are the
same, one might expect that RTCP packets would be sent according to
the regular mechanism. Instead, this algorithm results in the RTCP
packets being sent anywhere from 0.5*Td to ~2.731*Td. The
probability distribution over that time is also non-trivial in its
shape, somewhat similar to a saw tooth.
Thus, we recommend that the AVPF regular transmission mechanism is
revised in the future. This issue also has further implications as
discussed in the next section.
6.1.2. Avoiding Pre-mature Timeout
In RTP/AVP [RFC3550] the timeout behavior is simple and is 5 times
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
frequent than every 5 seconds on average, then timeout happened after
5*Td = 25 seconds of no activity from the SSRC (RTP or RTCP),
otherwise it was 5 average reporting intervals.
RTP/AVPF [RFC4585] introduced two different behaviors depending on
the value of T_rr_interval. When T_rr_interval was 0, it defaulted
to the same Td calculation in RTP/AVP [RFC3550]. However, when
T_rr_interval is non-zero the Tmin value become T_rr_interval in that
calculation, most likely to enable speed up the detection of timed
out SSRCs. However, using a non-zero T_rr_interval has two
consequences for RTP's behavior.
First, the number of actually sent RTCP packets for an SSRC that
currently is not an active RTP sender can become very low due to the
issue discussed above 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
may 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
losses in RTCP result in timing out an SSRC.
Second, the change also increased RTP/AVPF's brittleness to both
packet loss and configuration errors. In many cases, when one
desires to use RTP/AVPF for its feedback, one will ensure that RTCP
is configured for more frequent transmissions on average than every 5
seconds. Thus, many more RTP and RTCP packets can be transmitted
during the time interval. Lets consider an implementation that would
follow the AVP or AVPF with T_rr_interval = 0 rules for timeout, also
when T_rr_interval is not zero. In such a case when the configured
value of the T_rr_interval is significantly smaller than 5 seconds,
e.g. less than 1 second, then a difference between using 0.1 seconds
and 0.6 seconds has no significant impact on when an SSRC will be
timed out. However, such a configuration difference between two
endpoints following RFC 4585 will result in that the endpoint
configured with T_rr_interval = 0.1 will frequently timeout SSRCs
currently not sending RTP, from the endpoint configured with 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. AVP and AVPF Interoperability
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 in a single RTP session, and the RTP/
AVPF endpoints use a non-zero T_rr_interval that is significantly 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 lower than 5 seconds, then there is a risk that the RTP/AVPF
endpoints will prematurely timeout the RTP/AVP SSRCs due to their endpoints will prematurely timeout the RTP/AVP SSRCs due to their
different RTCP timeout intervals. Conversely, if the RTP/AVPF different RTCP timeout intervals. Conversely, if the RTP/AVPF
endpoints use a T_rr_interval that is significant larger than 5 endpoints use a T_rr_interval that is significant larger than 5
seconds, there is a risk that the RTP/AVP endpoints will timeout the seconds, there is a risk that the RTP/AVP endpoints will timeout the
RTP/AVPF SSRCs. If such mixed RTP profiles are used, (though this is RTP/AVPF SSRCs.
NOT RECOMMENDED), the RTP/AVPF session SHOULD use a non-zero
If such mixed RTP profiles are used, (though this is NOT
RECOMMENDED), and the AVPF endpoint is not updated to follow this
specification, then the RTP/AVPF session SHOULD use a non-zero
T_rr_interval that is 4 seconds. T_rr_interval that is 4 seconds.
Note: It might appear strange to use a T_rr_interval of 4 seconds. It might appear strange to use a T_rr_interval of 4 seconds. It
It might be intuitive that this value ought to be 5 seconds, as might be intuitive that this value ought to be 5 seconds, as then
then both the RTP/AVP and RTP/AVPF would use the same timeout both the RTP/AVP and RTP/AVPF would use the same timeout period.
period. However, considering regular RTCP transmission and their However, considering regular RTCP transmission and their packet
packet intervals for RTP/AVPF its mean value will (with non-zero intervals for RTP/AVPF its mean value will (with non-zero
T_rr_interval) be larger than T_rr_interval due to the scheduling T_rr_interval) be larger than T_rr_interval due to the scheduling
algorithm. Thus, to enable an equal amount of regular RTCP algorithm's behavior as discussed in Section 6.1.1. Thus, to enable
transmissions in each directions between RTP/AVP and RTP/AVPF an equal amount of regular RTCP transmissions in each directions
endpoints, taking the altered timeout intervals into account, the between RTP/AVP and RTP/AVPF endpoints, taking the altered timeout
optimal value is around four (4), where almost four transmissions intervals into account, the optimal value is around four (4), where
will on average occur in each direction between the different almost four transmissions will on average occur in each direction
profile types given an otherwise good configuration of parameters between the different profile types given an otherwise good
in regards to T_rr_interval. If the RTCP bandwidth paramters are configuration of parameters in regards to T_rr_interval. If the RTCP
selected so that Td based on bandwidth is close to 4, i.e. close bandwidth parameters are selected so that Td based on bandwidth is
to T_rr_interval the risk increases that RTP/AVPF SSRCs will be close to 4, i.e. close to T_rr_interval the risk increases that RTP/
timed out by RTP/AVP endpoints, as the RTP/AVPF SSRC might only AVPF SSRCs will be timed out by RTP/AVP endpoints, as the RTP/AVPF
manage two transmissions in the timeout period. SSRC might only manage two transmissions in the timeout period.
6.1.4. Specified Behavior
The above considerations result in the following clarification and
RTP/AVPF specification change.
All SSRCs used in an RTP session MUST use the same timeout behaviour
to avoid premature timeouts. This will depend on the RTP profile and
its configuration. The RTP specification provides several options
that can influence the values used when calculating the time
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
SHALL be calculated using a multiplier of 5, i.e. the timeout
interval becomes 5*Td. The Td calculation SHALL be done using a Tmin
value of 5 seconds, not the reduced minimal interval even if used to
calculate RTCP packet transmission intervals. This changes the
behavior for the RTP/AVPF or RTP/SAVPF profiles when T_rr_interval !=
0, a behavior defined in Section 3.5.4 of RFC 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 possibilites exist for the RTP/AVP [RFC3551] profile, considered what possibilites exist for the RTP/AVP [RFC3551] profile,
then what additional tools are provided by RTP/AVPF [RFC4585]. then what additional tools are provided by RTP/AVPF [RFC4585].
6.2.1. RTP/AVP and RTP/SAVP 6.2.1. RTP/AVP and RTP/SAVP
skipping to change at page 15, line 39 skipping to change at page 18, line 9
all SSRC being senders, resulting in everyone sharing the all SSRC being senders, resulting in everyone sharing the
available bandwidth. Secondly we will select an average RTCP available bandwidth. Secondly we will select an average RTCP
packet size. This packet will consist of an SR, containing (n-1) 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 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 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 be 800 bytes for n>=32. With these parameters, and as the
bandwidth goes up the time interval is proportionally decreased bandwidth goes up the time interval is proportionally decreased
(due to minimal scaling), thus all the example bandwidths 72 (due to minimal scaling), thus all the example bandwidths 72
kbps, 360 kbps and 9 Mbps all support 9 SSRCs. 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
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], which means that for Td = 5
interval is actually [2.052,6.156] and the distribution is not seconds, the interval is actually [2.052,6.156] and the
uniform, but rather exponentially-increasing. The probability distribution is not uniform, but rather exponentially-increasing.
for sending at time X, given it is within the interval, is The probability for sending at time X, given it is within the
probability of picking X in the interval times the probability to interval, is probability of picking X in the interval times the
randomly picking a number that is <=X within the interval with an probability to randomly picking a number that is <=X within the
uniform probability distribution. This results in that the interval with an uniform probability distribution. This results
majority of the probability mass is above the Td value. in that the majority of the probability mass is above the Td
value.
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. RT/AVPF and RTP/SAVPF 6.2.2. RT/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 get a quite powerful additional
skipping to change at page 18, line 49 skipping to change at page 21, line 23
[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-04 (work in ietf-avtcore-multi-media-rtp-session-05 (work in
progress), January 2014. progress), February 2014.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-01 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work
in progress), January 2014. in progress), February 2014.
[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-01 (work in progress), ietf-avtcore-rtp-topologies-update-02 (work in progress),
October 2013. May 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-14 (work in progress), February 2014. framework-15 (work in progress), May 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,
"Multiplexing Negotiation Using Session Description "Negotiating Media Multiplexing Using the Session
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
bundle-negotiation-05 (work in progress), October 2013. negotiation-07 (work in progress), April 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.
 End of changes. 17 change blocks. 
79 lines changed or deleted 193 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/