draft-ietf-rmcat-rtp-cc-feedback-00.txt | draft-ietf-rmcat-rtp-cc-feedback-01.txt | |||
---|---|---|---|---|
Network Working Group C. S. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational July 24, 2014 | Intended status: Informational July 8, 2016 | |||
Expires: January 25, 2015 | Expires: January 9, 2017 | |||
Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia | Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia | |||
Congestion Control | Congestion Control | |||
draft-ietf-rmcat-rtp-cc-feedback-00 | draft-ietf-rmcat-rtp-cc-feedback-01 | |||
Abstract | Abstract | |||
This memo discusses the types of congestion control feedback that it | This memo discusses the types of congestion control feedback that it | |||
is possible to send using the RTP Control Protocol (RTCP), and their | is possible to send using the RTP Control Protocol (RTCP), and their | |||
suitability of use in implementing congestion control for unicast | suitability of use in implementing congestion control for unicast | |||
multimedia applications. | multimedia applications. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
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 25, 2015. | This Internet-Draft will expire on January 9, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 2 | 2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 2 | |||
3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 | 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 | |||
3.1. Per-packet Feedback . . . . . . . . . . . . . . . . . . . 4 | 3.1. Per-packet Feedback . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . 4 | 3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . 4 | |||
3.3. Per-RTT Feedback . . . . . . . . . . . . . . . . . . . . 6 | 3.3. Per-RTT Feedback . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 6 | 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 7 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 7 | 8. Informative References . . . . . . . . . . . . . . . . . . . 7 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
The coming deployment of WebRTC systems raises the prospect that high | The coming deployment of WebRTC systems raises the prospect that high | |||
quality video conferencing will see extremely wide use. To ensure | quality video conferencing will see extremely wide use. To ensure | |||
the stability of the network in the face of this use, WebRTC systems | the stability of the network in the face of this use, WebRTC systems | |||
will need to use some form of congestion control for their RTP-based | will need to use some form of congestion control for their RTP-based | |||
media traffic. To develop such congestion control, it is necessary | media traffic. To develop such congestion control, it is necessary | |||
to understand the sort of congestion feedback that can be provided | to understand the sort of congestion feedback that can be provided | |||
within the framework of RTP [RFC3550] and the RTP Control Protocol | within the framework of RTP [RFC3550] and the RTP Control Protocol | |||
skipping to change at page 4, line 41 ¶ | skipping to change at page 4, line 40 ¶ | |||
3.2. Per-frame Feedback | 3.2. Per-frame Feedback | |||
Consider one of the simplest scenarios for WebRTC: a point to point | Consider one of the simplest scenarios for WebRTC: a point to point | |||
video call between two end systems. There will be four RTP flows in | video call between two end systems. There will be four RTP flows in | |||
this scenario, two audio and two video, with all four flows being | this scenario, two audio and two video, with all four flows being | |||
active for essentially all the time (the audio flows will likely use | active for essentially all the time (the audio flows will likely use | |||
voice activity detection and comfort noise to reduce the packet rate | voice activity detection and comfort noise to reduce the packet rate | |||
during silent periods, and does not cause the transmissions to stop). | during silent periods, and does not cause the transmissions to stop). | |||
Assume all four flows are sent in a single RTP session, each using a | Assume all four flows are sent in a single RTP session, each using a | |||
separate SSRC. Further, assume each SSRC sends RTCP reports for all | separate SSRC; the RTCP reports from co-located audio and video SSRCs | |||
other SSRCs in the session (i.e., the optimisations in | at each end point are aggregated [RFC3550], | |||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not used, giving | [I-D.ietf-avtcore-rtp-multi-stream]; the optimisations in | |||
the worst case for the RTCP overhead). When all members are senders | [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used; and | |||
like this, the RTCP timing rules in Sections 6.2 and 6.3 of [RFC3550] | congestion control feedback is sent [I-D.dt-rmcat-feedback-message]. | |||
and [RFC4585] reduce to: | ||||
rtcp_interval = avg_rtcp_size * n / rtcp_bw | When all members are senders, the RTCP timing rules in Section 6.2 | |||
and 6.3 of [RFC3550] and [RFC4585] reduce to: | ||||
rtcp_interval = avg_rtcp_size * n / rtcp_bw | ||||
where n is the number of members in the session, the avg_rtcp_size is | where n is the number of members in the session, the avg_rtcp_size is | |||
measured in octets, and the rtcp_bw is the bandwidth available for | measured in octets, and the rtcp_bw is the bandwidth available for | |||
RTCP, measured in octets per second (this will typically be 5% of the | RTCP, measured in octets per second (this will typically be 5% of the | |||
session bandwidth). | session bandwidth). | |||
The average RTCP size will depend on the amount of feedback that is | The average RTCP size will depend on the amount of feedback that is | |||
sent in each RTCP packet, on the number of members in the session, | sent in each RTCP packet, on the number of members in the session, on | |||
and on the size of source description (RTCP SDES) information sent. | the size of source description (RTCP SDES) information sent, and on | |||
the amount of congestion control feedback sent in each packet. | ||||
As a baseline, each RTCP packet will be a compound RTCP packet that | As a baseline, each RTCP packet will be a compound RTCP packet that | |||
contains an RTCP SR and an RTCP SDES packet. In the scenario above, | contains an aggregate of a compound RTCP packet generated by the | |||
each RTCP SR packet will contain three report blocks, once for each | video SSRC and a compound RTCP packet generated by the audio SSRC. | |||
of the other RTP SSRCs sending data, for a total of 100 octets (this | Since the RTCP reporting group extensions are used, one of these | |||
is 8 octets header, 20 octets sender info, and 3 * 24 octets report | SSRCs will be a reporting SSRC, and the other will delegate its | |||
blocks). The RTCP SDES packet will comprise a header (4 octets), an | reports to that. | |||
originating SSRC (4 octets), a CNAME chunk, and padding. If the | ||||
CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 19 | The aggregated compound RTCP packet from the non-reporting SSRC will | |||
octets in size, and require 1 octet of padding. The resulting | contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS | |||
compound RTCP packet will be 128 octets in size. If sent in UDP/IPv4 | packet. The RTCP SR packet contains the 28 octet header and sender | |||
with no IP options and using Secure RTP, which adds 20 (IPv4) + 8 | information, but no report blocks (since the reporting is delegated). | |||
(UDP) + 14 (SRTP with 80 bit Authentication tag), the avg_rtcp_size | The RTCP SDES packet will comprise a header (4 octets), originating | |||
will therefore be 170 octets, including the header overhead. The | SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. | |||
value n is this scenario is 4, and the rtcp_bw is assumed to be 5% of | If the CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it | |||
the session bandwidth. | will be 18 octets in size, and will need 1 octet of padding, making | |||
the SDES packet 28 octets in size. The RTCP RGRS packet will be 12 | ||||
octets in size. This gives a total of 28 + 28 + 12 = 68 octets. | ||||
The aggregated compound RTCP packet from the reporting SSRC will | ||||
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP XR | ||||
congestion control feedback packet. The RTCP SR packet will contain | ||||
two report blocks, one for each of the remote SSRCs (the report for | ||||
the other local SSRC is suppressed by the reporting group extension), | ||||
for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will | ||||
comprise a header (4 octets), originating SSRC (4 octets), a CNAME | ||||
chunk, an RGRP chunk, a terminating chunk, and any padding. If the | ||||
CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 18 | ||||
octets in size. The RGRP chunk similarly comprises 18 octets, and 3 | ||||
octets of padding are needed, for a total of 48 octets. The RTCP XR | ||||
congestion control feedback report comprises an 8 octet XR header, | ||||
then for each of the remote audio and video SSRCs, a 12 octet report | ||||
header, and 2 octets per packet reported upon, and padding to a 4 | ||||
octet boundary, if needed; that is 8 + 12 + (2 * | ||||
video_packets_per_report) + 12 + (2 * audio_packets_per_report). = | ||||
32 + (2 * video_packets_per_report) + (2 * audio_packets_per_report). | ||||
The compound RTCP packet will be 156 + (2 * video_packets_per_report) | ||||
+ (2 * audio_packets_per_report). | ||||
The resulting aggregate RTCP packet, containing both compound RTCP | ||||
packets, will be sent in UDP/IPv4 with no IP options and using Secure | ||||
RTP, which adds 20 (IPv4) + 8 (UDP) + 14 (SRTP with 80 bit | ||||
Authentication tag) = 42 octets, the avg_rtcp_size will therefore be | ||||
42 + 68 + 156 + (2 * video_packets_per_report) + (2 * | ||||
audio_packets_per_report). (FIXME: this ignores padding in RTCP) | ||||
Since the aggregate RTCP packet contains reports from two SSRCs, the | ||||
avg_rtcp_packet size is halved before use | ||||
[I-D.ietf-avtcore-rtp-multi-stream]. The value n is this scenario is | ||||
4, and the rtcp_bw is assumed to be 5% of the session bandwidth. | ||||
How many packets does the RTCP XR congestion control feedback packet | ||||
report on? This is obviously highly dependent on the choice of codec | ||||
and encoding parameters, and might be quite bursty if the codec sends | ||||
I-frames from which later frames are predicted. For now, assume | ||||
video_packets_per_second = (video_bit_rate_bps / 8) / mtu and | ||||
video_packets_per_report = video_packets_per_seconds / fps. For | ||||
audio, assume 50 packets per second, with audio_packets_per_report | ||||
based on the video frame rate (i.e., RTCP packets for the audio SSRC | ||||
are aggregated with those from the video SSRC). | ||||
If it is desired to send RTCP feedback packets on average 30 times | If it is desired to send RTCP feedback packets on average 30 times | |||
per second, to correspond to one RTCP report every frame for 30fps | per second, to correspond to one RTCP report every frame for 30fps | |||
video, one can invert the above rtcp_interval calculation to get an | video, one can solve the above expressions to determine the session | |||
rtcp_bw that gives an interval of 1/30th of a second or lower. This | bandwidth needed to give an RTCP reporting interval of 1/30 second. | |||
corresponds to an rtcp_bw of 20400 octets per second (since 1/30 = | This is approximately 2.5Mbps. That is, provided the video session | |||
170 * 4 / 20400). This is 163200 bits per second, which if 5% of the | bandwidth is greater than approximately 2.5Mbps, one can report on | |||
session bandwidth, gives a session bandwidth of approximately 3.3Mbps | each packet arrival (with ECN marks and arrival time) for every frame | |||
(i.e., 3.3Mbps media rate, plus an additional 5% for RTCP, to give a | of 30 fps video, using existing RTCP mechanisms. This is not out of | |||
total data rate of approximately 3.4Mbps). That is, RTCP can report | line with the expected session bandwidth for this type of | |||
on every frame of video provided the session bandwidth is 3.3Mbps or | application, suggesting the RTCP feedback can be used to provide per- | |||
larger, when every SSRC sends a report for every video frame (due to | frame congestion control feedback for WebRTC-style applications. | |||
randomisation inherent in the RTCP timing rules, the actual RTCP | ||||
transmission intervals will be within the range [0.0135, 0.0406]s, | ||||
but will maintain an average RTCP transmission interval of 0.033s). | ||||
This is not out of line with the expected session bandwidth for this | ||||
type of application, suggesting the RTCP feedback can be used to | ||||
provide per-frame congestion control feedback for WebRTC-style | ||||
applications. | ||||
Note: To achieve the RTCP transmission intervals above the RTP/ | Note: To achieve the RTCP transmission intervals above the RTP/ | |||
SAVPF profile with T_rr_interval=0 is used, since even when using | SAVPF profile with T_rr_interval=0 is used, since even when using | |||
the reduced minimal transmission interval, the RTP/SAVP profile | the reduced minimal transmission interval, the RTP/SAVP profile | |||
would only allow sending RTCP at most every 0.11s (every third | would only allow sending RTCP at most every 0.11s (every third | |||
frame of video). Using RTP/SAVPF with T_rr_interval=0 however is | frame of video). Using RTP/SAVPF with T_rr_interval=0 however is | |||
capable of fully utilizing the configured 5% RTCP bandwidth | capable of fully utilizing the configured 5% RTCP bandwidth | |||
fraction. | fraction. | |||
If additional feedback beyond the standard report block is needed, | ||||
the session bandwidth needed will increase slightly. For example, | ||||
with an additional 20 octets data being reported in each RTCP packet, | ||||
the session bandwidth needed increases to 3.5Mbps for every SSRC to | ||||
be able to report on every frame. | ||||
The above calculations highlight the baseline feasibility of RTCP | ||||
congestion control feedback, but might not be the most appropriate | ||||
usage of the RTCP bandwidth of all applications. Depending on needs, | ||||
a less frequent usage of regular RTCP compound packets, controlled by | ||||
T_rr_interval combined with using the reduced size RTCP packets, can | ||||
achieve more frequent and useful reporting. Also the optimisations | ||||
defined in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] will | ||||
reduce the amount of bandwidth consumed for reporting when each | ||||
endpoint has multiple SSRCs. | ||||
It might also seem unnecessary to assign the same fraction of the | ||||
RTCP bandwidth to reporting on the audio and video, since video is | ||||
much higher rate, and so is presumably more likely to cause | ||||
congestion. Sending audio and video in separate RTCP sessions with | ||||
their own RTCP bandwidth fraction would give essentially double the | ||||
RTCP bandwidth for each video source, since RTCP bandwidth fraction | ||||
would be shared between two reporting SSRCs, rather than between the | ||||
four reporting SSRCs in the single session case. This would hence | ||||
reduce the session bandwidth needed to allow reports on every frame. | ||||
Extensions to split RTCP bandwidth unequally between participants in | ||||
a single session could be defined to allow this to work with a single | ||||
RTP session on a single UDP port, or two standard RTP sessions could | ||||
be run on a single port, using a demultiplexing shim. RTCP already | ||||
allows for different bandwidth fractions between senders and | ||||
receivers, so this is a relatively small change to the protocol. | ||||
3.3. Per-RTT Feedback | 3.3. Per-RTT Feedback | |||
The arguments made in Section 3.2 apply to this case as well. The | The arguments made in Section 3.2 apply to this case as well. The | |||
network RTT will usually be larger than the media framing interval, | network RTT will usually be larger than the media framing interval, | |||
so sending feedback per RTT is less of a load on RTCP than sending | so sending feedback per RTT is less of a load on RTCP than sending | |||
feedback per frame. | feedback per frame. | |||
4. Discussion and Conclusions | 4. Discussion and Conclusions | |||
RTCP as it is currently specified cannot be used to send per-packet | RTCP as it is currently specified cannot be used to send per-packet | |||
congestion feedback. RTCP can, however, be used to send congestion | congestion feedback. RTCP can, however, be used to send congestion | |||
feedback on each frame of video sent, provided the session bandwidth | feedback on each frame of video sent, provided the session bandwidth | |||
exceeds a couple of megabits per second (the exact rate depending on | exceeds a couple of megabits per second (the exact rate depending on | |||
the number of session participants, the RTCP bandwidth fraction, and | the number of session participants, the RTCP bandwidth fraction, and | |||
whether audio and video are sent in one or two RTP sessions). RTCP | what RTCP extensions are enabled, and how much detail of feedback is | |||
can likely also be used to send feedback on a per-RTT basis, provided | needed). RTCP can likely also be used to send feedback on a per-RTT | |||
the RTT is not too low. | basis, provided the RTT is not too low. | |||
If it is desired to use RTCP in something close to it's current form | If it is desired to use RTCP in something close to it's current form | |||
for congestion feedback in WebRTC, the multimedia congestion control | for congestion feedback in WebRTC, the multimedia congestion control | |||
algorithm needs be designed to work with feedback sent roughly each | algorithm needs be designed to work with feedback sent roughly each | |||
frame or each RTT, rather than per packet, since that fits within the | frame or each RTT, rather than per packet, since that fits within the | |||
limitations of RTCP. That feedback can be a little more complex than | limitations of RTCP. That feedback can be a little more complex than | |||
just an acknowledgement, provided care is taken to consider the | just an acknowledgement, provided care is taken to consider the | |||
impact of the extra feedback on the overhead, possibly allowing for a | impact of the extra feedback on the overhead, possibly allowing for a | |||
degree of semantic feedback, meaningful to the codec layer as well as | degree of semantic feedback, meaningful to the codec layer as well as | |||
the congestion control algorithm. | the congestion control algorithm. | |||
skipping to change at page 7, line 38 ¶ | skipping to change at page 7, line 45 ¶ | |||
6. IANA Considerations | 6. IANA Considerations | |||
There are no actions for IANA. | There are no actions for IANA. | |||
7. Acknowledgements | 7. Acknowledgements | |||
Thanks to Magnus Westerlund for his feedback on Section 3.2. | Thanks to Magnus Westerlund for his feedback on Section 3.2. | |||
8. Informative References | 8. Informative References | |||
[I-D.dt-rmcat-feedback-message] | ||||
Sarker, Z., Perkins, D., Singh, V., and D. Ramalho, "RTP | ||||
Control Protocol (RTCP) Feedback for Congestion Control", | ||||
draft-dt-rmcat-feedback-message-00 (work in progress), | ||||
July 2016. | ||||
[I-D.ietf-avtcore-rtp-multi-stream] | ||||
Lennox, J., Westerlund, M., Wu, Q., and D. Perkins, | ||||
"Sending Multiple RTP Streams in a Single RTP Session", | ||||
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), | ||||
December 2015. | ||||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] | [I-D.ietf-avtcore-rtp-multi-stream-optimisation] | |||
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, | Lennox, J., Westerlund, M., Wu, Q., and D. Perkins, | |||
"Sending Multiple Media Streams in a Single RTP Session: | "Sending Multiple RTP 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-03 (work | draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work | |||
in progress), July 2014. | in progress), March 2016. | |||
[I-D.ietf-rtcweb-rtp-usage] | [I-D.ietf-rtcweb-rtp-usage] | |||
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time | Perkins, D., Westerlund, M., and J. Ott, "Web Real-Time | |||
Communication (WebRTC): Media Transport and Use of RTP", | Communication (WebRTC): Media Transport and Use of RTP", | |||
draft-ietf-rtcweb-rtp-usage-16 (work in progress), July | draft-ietf-rtcweb-rtp-usage-26 (work in progress), March | |||
2014. | 2016. | |||
[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, DOI 10.17487/RFC3550, | |||
July 2003, <http://www.rfc-editor.org/info/rfc3550>. | ||||
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control | [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | |||
Protocol Extended Reports (RTCP XR)", RFC 3611, November | "RTP Control Protocol Extended Reports (RTCP XR)", | |||
2003. | RFC 3611, DOI 10.17487/RFC3611, November 2003, | |||
<http://www.rfc-editor.org/info/rfc3611>. | ||||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | |||
2006. | DOI 10.17487/RFC4585, July 2006, | |||
<http://www.rfc-editor.org/info/rfc4585>. | ||||
[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, DOI 10.17487/RFC5124, February | |||
2008, <http://www.rfc-editor.org/info/rfc5124>. | ||||
[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, DOI 10.17487/RFC7022, | |||
September 2013, <http://www.rfc-editor.org/info/rfc7022>. | ||||
Author's Address | Author's Address | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
End of changes. 24 change blocks. | ||||
97 lines changed or deleted | 122 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |