draft-ietf-avt-rtcp-guidelines-03.txt   draft-ietf-avt-rtcp-guidelines-04.txt 
AVT Working Group J. Ott AVT Working Group J. Ott
Internet-Draft Aalto University Internet-Draft Aalto University
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: August 25, 2010 University of Glasgow Expires: November 12, 2010 University of Glasgow
February 21, 2010 May 11, 2010
Guidelines for Extending the RTP Control Protocol (RTCP) Guidelines for Extending the RTP Control Protocol (RTCP)
draft-ietf-avt-rtcp-guidelines-03.txt draft-ietf-avt-rtcp-guidelines-04.txt
Abstract Abstract
The RTP Control Protocol (RTCP) is used along with the Real-time The RTP Control Protocol (RTCP) is used along with the Real-time
Transport Protocol (RTP) to provide a control channel between media Transport Protocol (RTP) to provide a control channel between media
senders and receivers. This allows constructing a feedback loop to senders and receivers. This allows constructing a feedback loop to
enable application adaptation and monitoring, among other uses. The enable application adaptation and monitoring, among other uses. The
basic reporting mechanisms offered by RTCP are generic, yet quite basic reporting mechanisms offered by RTCP are generic, yet quite
powerful and suffice to cover a range of uses. This document powerful and suffice to cover a range of uses. This document
provides guidelines on extending RTCP if those basic mechanisms prove provides guidelines on extending RTCP if those basic mechanisms prove
insufficient. insufficient.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 12, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RTP and RTCP Operation Overview . . . . . . . . . . . . . . . 4 3. RTP and RTCP Operation Overview . . . . . . . . . . . . . . . 4
3.1. RTCP Capabilities . . . . . . . . . . . . . . . . . . . . 5 3.1. RTCP Capabilities . . . . . . . . . . . . . . . . . . . . 5
3.2. RTCP Limitations . . . . . . . . . . . . . . . . . . . . . 7 3.2. RTCP Limitations . . . . . . . . . . . . . . . . . . . . . 7
3.3. Interactions with Network and Transport Layer 3.3. Interactions with Network and Transport Layer
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 8 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8 4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 18 skipping to change at page 3, line 18
time-dependent (often continuous) media such as audio or video across time-dependent (often continuous) media such as audio or video across
a packet network in an RTP session. RTP usually runs on top of an a packet network in an RTP session. RTP usually runs on top of an
unreliable transport such as UDP, DTLS, or DCCP, so that RTP packets unreliable transport such as UDP, DTLS, or DCCP, so that RTP packets
are susceptible to loss, re-ordering, or duplication. Associated are susceptible to loss, re-ordering, or duplication. Associated
with RTP is the RTP Control Protocol (RTCP) which provides a control with RTP is the RTP Control Protocol (RTCP) which provides a control
channel for each session: media senders provide information about channel for each session: media senders provide information about
their current sending activities ("feed forward") and media receivers their current sending activities ("feed forward") and media receivers
report on their reception statistics ("feedback") in terms of report on their reception statistics ("feedback") in terms of
received packets, losses, and jitter. Senders and receivers provide received packets, losses, and jitter. Senders and receivers provide
self-descriptions allowing to disambiguate all entities in an RTP self-descriptions allowing to disambiguate all entities in an RTP
session and correlate SSRC identifiers with specific application session and correlate synchronisation source (SSRC) identifiers with
instances. RTCP is carried over the same transport as RTP and is specific application instances. RTCP is carried over the same
hence inherently best-effort and hence the RTCP reports are designed transport as RTP and is hence inherently best-effort and hence the
for such an unreliable environment, e.g., by making them "for RTCP reports are designed for such an unreliable environment, e.g.,
information only". by making them "for information only".
The RTCP control channel provides coarse-grained information about The RTCP control channel provides coarse-grained information about
the session in two respects: 1) the RTCP SR and RR packets contain the session in two respects: 1) the RTCP sender report (SR) and
only cumulative information or means over a certain period of time receiver report (RR) packets contain only cumulative information or
and 2) the time period is in the order of seconds and thus neither means over a certain period of time and 2) the time period is in the
has a high resolution nor does the feedback come back order of seconds and thus neither has a high resolution nor does the
instantaneously. Both these restrictions have their origin in RTP feedback come back instantaneously. Both these restrictions have
being scalable and generic. Even these basic mechanisms (which are their origin in RTP being scalable and generic. Even these basic
still not implemented everywhere despite their simplicity and very mechanisms (which are still not implemented everywhere despite their
precise specification, including sample code) offer substantial simplicity and very precise specification, including sample code)
information for designing adaptive applications and for monitoring offer substantial information for designing adaptive applications and
purposes, among others. for monitoring purposes, among others.
Recently, numerous extensions have been proposed in different Recently, numerous extensions have been proposed in different
contexts to RTCP which significantly increase the complexity of the contexts to RTCP which significantly increase the complexity of the
protocol and the reported values, mutate it toward an command protocol and the reported values, mutate it toward an command
channel, and/or attempt turning it into a reliable messaging channel, and/or attempt turning it into a reliable messaging
protocol. While the reasons for such extensions may be legitimate, protocol. While the reasons for such extensions may be legitimate,
many of the resulting designs appear ill-advised in the light of the many of the resulting designs appear ill-advised in the light of the
RTP architecture. Moreover, extensions are often badly motivated and RTP architecture. Moreover, extensions are often badly motivated and
thus appear unnecessary given what can be achieved with the RTCP thus appear unnecessary given what can be achieved with the RTCP
mechanisms in place today. mechanisms in place today.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
but when there is nothing left to take away" [RFC1925]. Despite (or but when there is nothing left to take away" [RFC1925]. Despite (or
because of) this being an April, 1st, RFC, this specific truth is because of) this being an April, 1st, RFC, this specific truth is
very valid and it applies to RTCP as well. very valid and it applies to RTCP as well.
In this section, we will briefly review what is available from the In this section, we will briefly review what is available from the
basic RTP/RTCP specifications. As specifications, we include those basic RTP/RTCP specifications. As specifications, we include those
which are generic, i.e., do not have dependencies on particular media which are generic, i.e., do not have dependencies on particular media
types. This includes the RTP base specification [RFC3550] and types. This includes the RTP base specification [RFC3550] and
profile [RFC3551], the RTCP bandwidth modifiers for session profile [RFC3551], the RTCP bandwidth modifiers for session
descriptions [RFC3556], the timely feedback extensions (RFC 4585), descriptions [RFC3556], the timely feedback extensions (RFC 4585),
and the extensions to run RTCP over SSM networks and the extensions to run RTCP over source specific multicast (SSM)
[I-D.ietf-avt-rtcpssm]. RTCP XR [RFC3611] provides extended networks [RFC5760]. RTCP extended reports (XR) [RFC3611] provide
reporting mechanisms which are partly generic in nature, partly extended reporting mechanisms which are partly generic in nature,
specific to a certain media stream. partly specific to a certain media stream.
We do not discuss RTP-related documents that are orthogonal to RTCP. We do not discuss RTP-related documents that are orthogonal to RTCP.
The Secure RTP Profile [RFC3711] can be used to secure RTCP in much The Secure RTP Profile [RFC3711] can be used to secure RTCP in much
the same way it secures RTP data, but otherwise does not affect the the same way it secures RTP data, but otherwise does not affect the
behaviour of RTCP. The transport protocol used also has little behaviour of RTCP. The transport protocol used also has little
impact, since RTCP remains a group communication protocol even when impact, since RTCP remains a group communication protocol even when
running over a unicast transport (such as TCP [RFC4571] or DCCP running over a unicast transport (such as TCP [RFC4571] or DCCP
[I-D.ietf-dccp-rtp]), and is little affected by congestion control [RFC5762]), and is little affected by congestion control due to its
due to its low rate relative to the media. The description of RTP low rate relative to the media. The description of RTP topologies
topologies [RFC5117] is useful knowledge, but is functionally not [RFC5117] is useful knowledge, but is functionally not relevant here.
relevant here. The various RTP error correction mechanisms (e.g. The various RTP error correction mechanisms (e.g. [RFC2198],
[RFC2198], [RFC4588], [RFC5109]) are useful for protecting RTP media [RFC4588], [RFC5109]) are useful for protecting RTP media streams,
streams, and may be enabled as a result of RTCP feedback, but do not and may be enabled as a result of RTCP feedback, but do not directly
directly affect RTCP behaviour. affect RTCP behaviour.
3.1. RTCP Capabilities 3.1. RTCP Capabilities
The RTP/RTCP specifications quoted above provide feedback mechanisms The RTP/RTCP specifications quoted above provide feedback mechanisms
with the following properties, which can be considered as "building with the following properties, which can be considered as "building
blocks" for adaptive real-time applications for IP networks. blocks" for adaptive real-time applications for IP networks.
o Sender Reports (SR) indicate to the receivers the total number of o Sender Reports (SR) indicate to the receivers the total number of
packets and octets have been sent (since the beginning of the packets and octets have been sent (since the beginning of the
session or the last change of the sender's SSRC). These values session or the last change of the sender's SSRC). These values
skipping to change at page 5, line 49 skipping to change at page 5, line 49
o Sender Reports also contain NTP and RTP format timestamps. These o Sender Reports also contain NTP and RTP format timestamps. These
allow receivers to synchronise multiple RTP streams, and (when allow receivers to synchronise multiple RTP streams, and (when
used in conjunction with Receiver Reports) allow the sender to used in conjunction with Receiver Reports) allow the sender to
calculate the current RTT to each receiver. This value can be calculate the current RTT to each receiver. This value can be
monitored over time and thus may be used to infer trends at coarse monitored over time and thus may be used to infer trends at coarse
granularity. A similar mechanism is provided by [RFC3611] to granularity. A similar mechanism is provided by [RFC3611] to
allow receivers to calculate the RTT to senders. allow receivers to calculate the RTT to senders.
RTCP sender reports and receiver reports are sent, and the statistics RTCP sender reports and receiver reports are sent, and the statistics
are sampled, at random intervals chosen uniformly in the range 0.5 are sampled, at random intervals chosen uniformly in the range from
... 1.5 times the deterministic calculated interval, T. The interval 0.5 to 1.5 times the deterministic calculated interval, T. The
T is calculated based on the media bit rate, the mean RTCP packet interval T is calculated based on the media bit rate, the mean RTCP
size, whether the sampling node is a sender or a receiver, and the packet size, whether the sampling node is a sender or a receiver, and
number of participants in the session, and will remain constant while the number of participants in the session, and will remain constant
the number of participants in the session remains constant. The while the number of participants in the session remains constant.
lower bound on the base inter-report interval, T, is five seconds, or The lower bound on the base inter-report interval, T, is five
360 seconds divided by the session bandwidth in kilobits/second seconds, or 360 seconds divided by the session bandwidth in kilobits/
(giving an interval smaller than 5 seconds for bandwidths greater second (giving an interval smaller than 5 seconds for bandwidths
than 72 kb/s) [RFC3550]. greater than 72 kbits/s) [RFC3550].
This lower limit can be eliminated, allowing more frequent feedback, This lower limit can be eliminated, allowing more frequent feedback,
when using the early feedback profile for RTCP [RFC4585]. In this when using the early feedback profile for RTCP [RFC4585]. In this
case, the RTCP frequency is only limited by the available bitrate case, the RTCP frequency is only limited by the available bitrate
(usually 5% of the media stream bit rate is allocated for RTCP). If (usually 5% of the media stream bit rate is allocated for RTCP). If
this fraction is insufficient, the RTCP bitrate may be increased in this fraction is insufficient, the RTCP bitrate may be increased in
the session description to enable more frequent feedback [RFC3556]. the session description to enable more frequent feedback [RFC3556].
Ongoing work [RFC5506] may reduce the mean RTCP packet size, further Ongoing work [RFC5506] may reduce the mean RTCP packet size, further
increasing feedback frequency. increasing feedback frequency.
skipping to change at page 8, line 21 skipping to change at page 8, line 21
As discussed above, RTCP flows are used to measure, infer, and convey As discussed above, RTCP flows are used to measure, infer, and convey
information about the performance of an RTP media stream. information about the performance of an RTP media stream.
Inference in baseline RTCP is mainly limited to determining the path Inference in baseline RTCP is mainly limited to determining the path
RTT from pairs of RTCP SR and RR packets. This inference makes the RTT from pairs of RTCP SR and RR packets. This inference makes the
implicit assumption that RTP and RTCP are treated equally: they are implicit assumption that RTP and RTCP are treated equally: they are
routed along the same path, mapped to the same (DiffServ) traffic routed along the same path, mapped to the same (DiffServ) traffic
classes, and treated as part of the same fair queuing classification. classes, and treated as part of the same fair queuing classification.
This is true in many cases, however since RTP and RTCP are generally This is true in many cases, however since RTP and RTCP are generally
sent using different ports, any flow classification based upon the sent using different ports, any flow classification based upon the
quintuple (source and destination IP address and port number, 5-tuple of source and destination IP address and port number,
transport protocol) could lead to a differentiation between RTP and transport protocol could lead to a differentiation between RTP and
RTCP flows, disrupting the statistics. RTCP flows, disrupting the statistics.
While some networks may wish to intentionally prioritise RTCP over While some networks may wish to intentionally prioritise RTCP over
RTP (to provide quicker feedback) or RTP over RTCP (since the media RTP (to provide quicker feedback) or RTP over RTCP (since the media
is considered more important than control), we recommend that they be is considered more important than control), we recommend that they be
treated identically where possible, to enable this inference of treated identically where possible, to enable this inference of
network performance, and hence support application adaptation. network performance, and hence support application adaptation.
When using reliable transport connections for (RTP and) RTCP When using reliable transport connections for (RTP and) RTCP
[RFC2326] [RFC4571], retransmissions and head-of-line blocking may [RFC2326] [RFC4571], retransmissions and head-of-line blocking may
similarly lead to inaccurate RTT estimates derived by RTCP. (These similarly lead to inaccurate RTT estimates derived by RTCP. (These
may, nevertheless, properly reflect the mean RTT for a media packet may, nevertheless, properly reflect the mean RTT for a media packet
including retransmissions.) including retransmissions.)
The conveyance of information in RTCP is affected by the above only The conveyance of information in RTCP is affected by the above only
as soon as the prioritisation leads to RTCP packets being dropped as soon as the prioritisation leads to RTCP packets being dropped
over proportionally. over proportionally.
All of this emphasises the unreliable nature of RTCP. Multiplexing All of this emphasises the unreliable nature of RTCP. Multiplexing
on the same port number [I-D.ietf-avt-rtp-and-rtcp-mux] or inside the on the same port number [RFC5761] or inside the same transport
same transport connection might help mitigating some of these connection might help mitigating some of these effects; but this is
effects; but this is limited to speculation at this point and should limited to speculation at this point and should not be relied upon.
not be relied upon.
4. Issues with RTCP Extensions 4. Issues with RTCP Extensions
Issues that have come up in the past with extensions to RTP and RTCP Issues that have come up in the past with extensions to RTP and RTCP
include (but are probably not limited to) the following: include (but are probably not limited to) the following:
o Defined only or primarily for unicast two-party sessions. RTP is o Defined only or primarily for unicast two-party sessions. RTP is
inherently a group communication protocol, even when operating on inherently a group communication protocol, even when operating on
a unicast connection. Extensions may become useful in the future a unicast connection. Extensions may become useful in the future
well outside their originally intended area of application, and well outside their originally intended area of application, and
should consider this. Stating that something works for unicast should consider this. Stating that something works for unicast
only is not acceptable, particularly since various flavours of only is not acceptable, particularly since various flavours of
multicast have become relevant again, and as middleboxes such as multicast have become relevant again, and as middleboxes such as
repair servers, mixers, and RTCP-supporting MCUs [RFC5117] become repair servers, mixers, and RTCP-supporting Multipoint Control
more widely used. Units (MCUs) [RFC5117] become more widely used.
o Assuming reliable (instant) state synchronisation. RTCP reports o Assuming reliable (instant) state synchronisation. RTCP reports
are sent irregularly and may be lost. Hence, there may be a are sent irregularly and may be lost. Hence, there may be a
significant time lag (several seconds) between intending to send a significant time lag (several seconds) between intending to send a
state update to the RTP peer(s) and the packet being received, in state update to the RTP peer(s) and the packet being received, in
some cases, the packet may not be received at all. some cases, the packet may not be received at all.
o Requiring reliable delivery of RTCP reports. While reliability o Requiring reliable delivery of RTCP reports. While reliability
can be implemented on top of RTCP using acknowledgements, this can be implemented on top of RTCP using acknowledgements, this
will come at the cost of significant additional delay, which may will come at the cost of significant additional delay, which may
skipping to change at page 15, line 10 skipping to change at page 15, line 10
gracefully handle flash crowds and sudden departures [TimerRecon]. gracefully handle flash crowds and sudden departures [TimerRecon].
Proposals that modify the RTCP timer algorithms must be careful to Proposals that modify the RTCP timer algorithms must be careful to
avoid congestion, potentially leading to denial of service, across avoid congestion, potentially leading to denial of service, across
the full range of environments where RTCP is used. the full range of environments where RTCP is used.
o Denial of service: RTCP extensions that change the location where o Denial of service: RTCP extensions that change the location where
feedback is sent must be carefully designed to prevent denial of feedback is sent must be carefully designed to prevent denial of
service attacks against third party nodes. When such extensions service attacks against third party nodes. When such extensions
are signalled, for example in SDP, this typically requires some are signalled, for example in SDP, this typically requires some
form of authentication of the signalling messages (e.g. see the form of authentication of the signalling messages (e.g. see the
security considerations of [I-D.ietf-avt-rtcpssm]). security considerations of [RFC5760]).
The security considerations of the RTP specification [RFC3550] apply, The security considerations of the RTP specification [RFC3550] apply,
along with any applicable profile (e.g. [RFC3551]). along with any applicable profile (e.g. [RFC3551]).
7. IANA Considerations 7. IANA Considerations
No IANA actions are necessary. No IANA actions are necessary.
8. Acknowledgements 8. Acknowledgements
This draft has been motivated by many discussions in the AVT WG. The This draft has been motivated by many discussions in the AVT WG. The
authors would like to acknowledge the active members in the group for authors would like to acknowledge the active members in the group for
providing the inspiration. providing the inspiration.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1996.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[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
skipping to change at page 16, line 30 skipping to change at page 16, line 27
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[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.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
9.2. Informative References 9.2. Informative References
[I-D.ietf-avt-rtcpssm] [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
Ott, J. and J. Chesterfield, "RTCP Extensions for Single- April 1996.
Source Multicast Sessions with Unicast Feedback",
draft-ietf-avt-rtcpssm-19 (work in progress),
November 2009.
[I-D.ietf-dccp-rtp] [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
Perkins, C., "RTP and the Datagram Congestion Control January 2008.
Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in
progress), June 2007.
[I-D.ietf-avt-rtp-and-rtcp-mux] [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Protocol (RTCP) Extensions for Single-Source Multicast
Control Packets on a Single Port", Sessions with Unicast Feedback", RFC 5760, February 2010.
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, April 2010.
[ALF] Clark, D. and D. Tennenhouse, "Architectural [ALF] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of Protocols", Considerations for a New Generation of Protocols",
Proceedings of ACM SIGCOMM 1990, September 1990. Proceedings of ACM SIGCOMM 1990, September 1990.
[TimerRecon] [TimerRecon]
Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration
for Enhanced RTP Scalability", Proceedings of IEEE for Enhanced RTP Scalability", Proceedings of IEEE
Infocom 1998, March 1998. Infocom 1998, March 1998.
 End of changes. 20 change blocks. 
91 lines changed or deleted 65 lines changed or added

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