draft-perkins-rtcweb-rtp-usage-00.txt   draft-perkins-rtcweb-rtp-usage-01.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Informational M. Westerlund Intended status: Informational M. Westerlund
Expires: September 8, 2011 Ericsson Expires: December 7, 2011 Ericsson
J. Ott J. Ott
Aalto University Aalto University
March 7, 2011 June 5, 2011
RTP Requirements for RTC-Web RTP Requirements for RTC-Web
draft-perkins-rtcweb-rtp-usage-00 draft-perkins-rtcweb-rtp-usage-01
Abstract Abstract
This document discusses usage of RTP in the context of RTC-WEB work. This memo discusses use of RTP in the context of the RTC-Web
It discusses important factors of RTP to consider by other parts of activity. It discusses important features of RTP that need to be
the solution, it also discusses which RTP profile to support and considered by other parts of the RTC-Web framework, describes which
which RTP extensions that should be supported. RTP profile to use in this environment, and outlines what RTP
extensions should be supported.
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 September 8, 2011. This Internet-Draft will expire on December 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements from RTP . . . . . . . . . . . . . . . . . . . . 3 1.1. Expected Topologies . . . . . . . . . . . . . . . . . . . 3
2.1. RTP Session Multiplexing . . . . . . . . . . . . . . . . . 4 2. Requirements from RTP . . . . . . . . . . . . . . . . . . . . 6
2.2. Signalling for RTP sessions . . . . . . . . . . . . . . . 6 2.1. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6
2.3. (Lack of) Signalling for Payload Format Changes . . . . . 7 2.2. Signalling for RTP sessions . . . . . . . . . . . . . . . 8
3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. (Lack of) Signalling for Payload Format Changes . . . . . 9
4. RTP and RTCP Guidelines . . . . . . . . . . . . . . . . . . . 7 3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. RTP Optimizations . . . . . . . . . . . . . . . . . . . . . . 8 4. RTP and RTCP Guidelines . . . . . . . . . . . . . . . . . . . 10
5.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 8 5. RTP Optimizations . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 8 5.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 11
5.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 8 5.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11
5.4. CNAME generation . . . . . . . . . . . . . . . . . . . . . 9 5.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 11
6. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12
6.1. RTP Conferencing Extensions . . . . . . . . . . . . . . . 9 6. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. RTCP Feedback Message: Full Intra Request . . . . . . 10 6.1. RTP Conferencing Extensions . . . . . . . . . . . . . . . 12
6.1.2. RTCP Feedback Message: Picture Loss Indicator . . . . 10 6.1.1. RTCP Feedback Message: Full Intra Request . . . . . . 13
6.1.2. RTCP Feedback Message: Picture Loss Indicator . . . . 13
6.1.3. RTCP Feedback Message: Temporary Maximum Media 6.1.3. RTCP Feedback Message: Temporary Maximum Media
Stream Bit Rate Request . . . . . . . . . . . . . . . 10 Stream Bit Rate Request . . . . . . . . . . . . . . . 14
6.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 11 6.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 14
6.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 11 6.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 15
7. Improving RTP Transport Robustness . . . . . . . . . . . . . . 12 7. Improving RTP Transport Robustness . . . . . . . . . . . . . . 15
7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 12 7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 15
7.2. Forward Error Correction . . . . . . . . . . . . . . . . . 12 7.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 15
8. RTP Rate Control and Media Adaptation . . . . . . . . . . . . 12 8. RTP Rate Control and Media Adaptation . . . . . . . . . . . . 16
9. RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 13 9. RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document discusses RTP in the context of RTC-WEB. This include This memo discusses the Real-time Transport Protocol (RTP) [RFC3551]
RTP's requirement on underlying transport, for example when it comes in the context of the RTC-Web activity. The work in the IETF Audio/
to provide multiplexing. It discusses which RTP profile that should Video Transport Working Group, and it's successors, has been about
be supported and what RTP extensions that should be supported. The providing building blocks for real-time multimedia transport, and has
importance of congestion control and media adaptation is also not specified who should use which building blocks. The selection of
discussed. This document is intended as a starting point for
discussing RTP features in RTC-WEB.
The work in the AVT WG has all been about providing building blocks
and not specify who should use which building blocks. Selection of
building blocks and functionalities can really only be done in the building blocks and functionalities can really only be done in the
context of some application(s). RTC-WEB will greatly benefit in context of some application, for example RTC-Web. We have selected a
interoperability if a reasonable set of RTP functionalities and set of RTP features and extensions that are suitable for a number of
extensions are selected. For RTC-WEB we have selected RTP extensions applications that fits the RTC-Web context. Thus applications such
that are suitable for a number of applications that fits the context. as VoIP, audio and video conferencing, and on-demand multimedia
Thus applications such as VoIP, audio and video conferencing, and on- streaming are considered. Applications that rely on IP multicast
demand multi-media streaming are considered. Applications that rely have not been considered likely to be applicable to RTC-Web, thus
on multicast transport has not been considered likely to be extensions related to multicast have been excluded. We believe that
applicable to RTC-WEB, thus extensions related to multicast have been RTC-Web will greatly benefit in interoperability if a reasonable set
excluded. of RTP functionalities and extensions are selected. This memo is
intended as a starting point for discussion of those features in the
RTC-Web framework.
The document is structured into different topics. For each topic one This memo is structured into different topics. For each topic, one
or several recommendations from the authors are done. When it comes or several recommendations from the authors are done. When it comes
to extensions or need for implementation support we use three levels to the importance of extensions, or the need for implementation
to indicate the importance for it to be included in an RTC-WEB support, we use three requirement levels to indicate the importance
specification. We see it as likely that everything that is included of the feature to the RTC-Web specification:
is in fact mandated to be implemented.
REQUIRED: Absolutely needed functionality to make the solution work REQUIRED: Functionality that is absolutely needed to make the RTC-
well. Also functionality of low complexity that provide high Web solution work well, or functionality of low complexity that
value has also been categorized as required. provides high value.
RECOMMENDED: Should be included as its brings significant benefit, RECOMMENDED: Should be included as its brings significant benefit,
but the solution can potentially work without it. but the solution can potentially work without it.
OPTIONAL: Something that is useful in some cases, but not always a OPTIONAL: Something that is useful in some cases, but not always a
benefit. benefit.
When this documents discusses RTP it always include RTCP unless When this memo discusses RTP, it includes the RTP Control Protocol
explicitly stated otherwise. This as RTCP is a fundamental and (RTCP) unless explicitly stated otherwise. RTCP is a fundamental and
integral part of the protocol. integral part of the RTP protocol, and is REQUIRED to be implemented.
2. Requirements from RTP 1.1. Expected Topologies
This section discusses some requirements RTP/RTCP [RFC3550] puts its As RTC-Web is focused on peer to peer connections established from
underlying transport, the signalling etc. clients in web browsers the following topologies further discussed in
RTP Topologies [RFC5117] are primarily considered. The topologies
are depicted and briefly explaind here for ease of the reader.
2.1. RTP Session Multiplexing +---+ +---+
| A |<------->| B |
+---+ +---+
RTP has three fundamental points of multiplexing. The first one is Figure 1: Point to Point
the RTP session, which is used to separate media of different kind or
purpose. Such as Audio and Video, or the document camera and the
speaker camera in video conference. This multiplexing point does not
have an identifier within the RTP protocol, instead it relies on the
lower layer to separate the different RTP session. Thus the most
common RTP session separation is different UDP port numbers, but also
IP address or other identifiers maybe used to achieve this
separation. The second multiplexing point is the SSRC that separates
different sources of media within a single RTP session. The third is
the RTP Payload type, which identifies how the media from a
particular source is encoded.
These multiplexing points area fundamental part of the design of RTP The point to point topology (Figure 1) is going to be very common in
and is discussed in Section 5.2 of [RFC3550]. From that list the any single user to single user applications.
ones that are directly related to the importance of the RTP session
as concept are 4 and 5 (from RFC 3550):
"4. An RTP mixer would not be able to combine interleaved streams of +---+ +---+
incompatible media into one stream." | A |<---->| B |
+---+ +---+
^ ^
\ /
\ /
v v
+---+
| C |
+---+
"5. Carrying multiple media in one RTP session precludes: the use of Figure 2: Multi-unicast
different network paths or network resource allocations if
appropriate; reception of a subset of the media if desired, for
example just audio if video would exceed the available bandwidth;
and receiver implementations that use separate processes for the
different media, whereas using separate RTP sessions permits
either single- or multiple-process implementations."
Point 4, has to do with media of different kind or purpose. The For small multiparty sessions it is practical enough to create RTP
processing that can happen in an RTP mixer, translator or in an end- sessions by letting every participant send individual unicast RTP/UDP
point is dependent on the purpose and media type of the stream. Thus flows to each of the other participants. This is called multi-
there is an importance of separating such streams from each other. unicast and is unfortunately not discussed in the RTP Topologies
This could of course be achieved by other methods, like tagging SSRC [RFC5117]. This topology has the benefit of not requiring central
values with their purpose, however there are reasons why this was not nodes. On the downside is that it increase the used bandwidth by
chosen. First of all it is not the simple solution, as this require requiring one copy of the media streams for each participant part of
additional signalling, and possibly synchronization between session the same session beyond the sender itself. Thus this is limited to
peers. In addition there is the issue point 5 raises. scenarios with few end-points unless the media is very low bandwidth.
Point 5 has to do with enabling quality of service or traffic It needs to be noted that if this topology is to be supported by the
engineering between the media flows in different RTP sessions. By RTC-Web framework it needs to be possible to connect one RTP session
using different transport layer ports, QoS mechanism that are capable to multiple established peer to peer flows that are individually
of operating on the 5-tuple (Source address, port, destination established.
address, port, and protocol) can be used without modification on RTP.
Due to these design principle implementors of various services or +---+ +------------+ +---+
applications using RTP has commonly not violated this model. If one | A |<---->| |<---->| B |
choses to violate it today one fails to achieve interoperability with +---+ | | +---+
a number of existing services, applications and implementations. | Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Lets assume one overloads multiple RTP sessions into one by tagging Figure 3: RTP Mixer with Only Unicast Paths
the SSRC to belong to different purposes. If one would gateway that An RTP mixer (Figure 3) is a centralized point that selects or mixes
design into a legacy system, then there would be a significant issue content in a conference to optimize the RTP session so that each end-
with SSRC collision. This as the legacy system would not know about point only needs connect to one entity, the mixer. The mixer also
the need to avoid using the same SSRC in the different RTP sessions. reduces the bit-rate needs as the media sent from the mixer to the
end-point can be optimized in different ways. These optimizations
include methods like only chosing media from the currently most
active speaker or mixing together audio so that only one audio stream
is required in stead of 3 in the depicted scenario. The downside of
the mixer is that someone is required to provide the actual mixer.
There are also various RTP mechanism that has the potential for +---+ +------------+ +---+
issues if one don't have a clear separation of RTP sessions: | A |<---->| |<---->| B |
+---+ | | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 4: RTP Translator (Relay) with Only Unicast Paths
If one wants a less complex central node it is possible to use an
relay (called an Transport Translator) (Figure 4) that takes on the
role of forwarding the media to the other end-points but doesn't
perform any media processing. It simply forwards the media from all
other to all the other. Thus one endpoint A will only need to send a
media once to the relay, but it will still receive 3 RTP streams with
the media if B, C and D all currently transmitts.
+------------+
| |
+---+ | | +---+
| A |<---->| Translator |<---->| B |
+---+ | | +---+
| |
+------------+
Figure 5: Translator towards Legacy end-point
To support legacy end-point (B) that don't fulfill the requiremetns
of RTC-Web it is possible to insert a Translator (Figure 5) that
takes on the role to ensure that from A's perspective B looks like a
fully compliant end-point. Thus it is the combination of the
Translator and B that looks like the end-point B. The intention is
that the presence of the translator is transparant to A, however it
is not certain that is possible. Thus this case is include so that
it can be discussed if any mechanism specified to be used for RTC-Web
results in such issues and how to handle them.
2. Requirements from RTP
This section discusses some requirements RTP and RTCP [RFC3550] place
on their underlying transport protocol, the signalling channel, etc.
2.1. RTP Multiplexing Points
There are three fundamental points of multiplexing within the RTP
framework:
Use of separate RTP Sessions: The first, and the most important,
multiplexing point is the RTP session. This multiplexing point
does not have an identifier within the RTP protocol itself, but
instead relies on the lower layer to separate the different RTP
sessions. This is most often done by separating different RTP
sessions onto different UDP ports, or by sending to different IP
multicast addresses. The distinguishing feature of an RTP session
is that it has a separate SSRC identifier space; a single RTP
session can span multiple transport connections provided packets
are gatewayed such that participants are known to each other.
Different RTP sessions are used to separate different types of
media within a multimedia session. For example, audio and video
flows are sent on separate RTP sessions.
Multiplexing using the SSRC within an RTP session: The second
multiplexing point is the SSRC that separates different sources of
media within a single RTP session. An example might be different
participants in a multiparty teleconference, or different camera
views of a presentation. In most cases, each participant within
an RTP session has a single SSRC, although this may change over
time if collisions are detected. However, in some more complex
scenarios participants may generate multiple media streams of the
same type simultaneously (e.g., if they have two cameras, and so
send two video streams at once) and so will have more than one
SSRC in use at once. The RTCP CNAME can be used to distinguish
between a single participant using two SSRC values (where the RTCP
CNAME will be the same for each SSRC), and two participants (who
will have different RTCP CNAMEs).
Multiplexing using the Payload Type within an RTP session: If
different media encodings of the same type are to be used at
different times within an RTP session, for example a single
participant that can switch between two different audio codecs,
the payload type is used to identify how the media from that
particular source is encoded. When changing media formats within
an RTP Session, the SSRC of the sender remains unchanged, but the
RTP Payload Type changes to indicate the change in media format.
These multiplexing points area fundamental part of the design of RTP
and are discussed in Section 5.2 of [RFC3550]. Of special importance
is the need to separate different RTP sessions using a multiplexing
mechanism at some lower layer than RTP, rather than trying to combine
several RTP sessions into one lower layer flow.
The processing that can happen in an RTP mixer, translator or in an
end-point is dependent on the purpose and media type of the stream,
as determined by the RTP session on which it arrives. Hence, it is
important to separate such RTP session from each other. This could
of course be achieved by other methods, like tagging SSRC values with
their purpose (this is not defined in any known specification), but
there are reasons why this method isn't defined. First of all it is
not the simple solution, as this require additional signalling, and
possibly synchronization between session peers. In addition,
combining RTP sessions into a single lower-layer flow complicates
quality of service and traffic engineering between the media flows in
different RTP sessions. By using different transport layer ports,
QoS mechanism that are capable of operating on the 5-tuple (Source
address, port, destination address, port, and protocol) can be used
without modification on RTP.
There are also various other RTP mechanism that become problematic if
one doesn't have a clear separation of RTP sessions:
Scalabilty: RTP was built with media scalability in consideration. Scalabilty: RTP was built with media scalability in consideration.
The simplest way of achieving separation between different The simplest way of achieving separation between different
scalability layers are placing them in different RTP sessions, and scalability layers are placing them in different RTP sessions, and
using the same SSRC and CNAME in each session to bind them using the same SSRC and CNAME in each session to bind them
together. This is most commonly done in multicast, and not together. This is most commonly done in multicast, and not
particular applicable to RTC-WEB, but gatewaying of such a session particular applicable to RTC-Web, but gatewaying of such a session
would then require more alterations and likely stateful would then require more alterations and likely stateful
translation. translation.
RTP Retransmission in Session Multiplexing mode: RTP Retransmission RTP Retransmission in Session Multiplexing mode: RTP Retransmission
[RFC4588] does have a mode for session multiplexing. This would [RFC4588] does have a mode for session multiplexing. This would
not be the main mode used in RTC-WEB, but for interoperability and not be the main mode used in RTC-Web, but for interoperability and
reduced cost in translation support for different RTP Sessions are reduced cost in translation support for different RTP Sessions are
required. required.
Forward Error Correction: The "An RTP Payload Format for Generic Forward Error Correction: The "An RTP Payload Format for Generic
Forward Error Correction" [RFC2733] and its update [RFC5109] can Forward Error Correction" [RFC2733] and its update [RFC5109] can
only be used on media formats that produce RTP packets that are only be used on media formats that produce RTP packets that are
smaller than half the MTU if the FEC flow and media flow being smaller than half the MTU if the FEC flow and media flow being
protected are to be sent in the same RTP session, this is due to protected are to be sent in the same RTP session, this is due to
"RTP Payload for Redundant Audio Data" [RFC2198]. This is because "RTP Payload for Redundant Audio Data" [RFC2198]. This is because
the SSRC value of the original flow is recovered from the FEC the SSRC value of the original flow is recovered from the FEC
skipping to change at page 6, line 10 skipping to change at page 8, line 21
is of suitable for conversational audio, but clearly not useful for is of suitable for conversational audio, but clearly not useful for
Video. This has three impacts, either one get unusable reports if Video. This has three impacts, either one get unusable reports if
they are generated for streams where there are little purpose. This they are generated for streams where there are little purpose. This
is maybe less likely for the VoIP report, but for example the more is maybe less likely for the VoIP report, but for example the more
detailed media agnostic reports it may occur. It otherwise makes the detailed media agnostic reports it may occur. It otherwise makes the
implementation of RTCP more complex as the SSRC purpose tagging needs implementation of RTCP more complex as the SSRC purpose tagging needs
not only to be one the media side, but also on the RTCP reporting. not only to be one the media side, but also on the RTCP reporting.
Also the RTCP reporting interval and transmission scheduling will be Also the RTCP reporting interval and transmission scheduling will be
affected. affected.
Due to these design principle implementors of various services or
applications using RTP have not commonly violated this model. If one
choses to violate it today, one fails to achieve interoperability
with a number of existing services, applications and implementations.
As a conclusion not ensuring that RTP sessions are used for its As a conclusion not ensuring that RTP sessions are used for its
intended purpose as a multiplexing point does violate the RTP design intended purpose as a multiplexing point does violate the RTP design
philosophy. It prevents the usage of certain RTP extensions. It philosophy. It prevents the use of certain RTP extensions. It will
will require additional extensions to function and will significantly require additional extensions to function and will significantly
increase the complexity of the implementation. At the same time it increase the complexity of the implementation. At the same time it
will significantly reduce the interoperability with current will significantly reduce the interoperability with current
implementations. implementations. Thus the authors considered it REQUIRED that RTP
sessions are multiplexed using a mechanism outside of RTP. The
RECOMMENDED mechanism to accomplish that would be to use unique UDP
flows. If the WG comes to a consensus that due to NAT/Firewall
traversal aspects would be greately simplified with a single flow
between peers and accept that flow based QoS can only be done on the
aggreage of all RTP sessions then the authors RECOMMEND that some
type of multiplexing layer is inserted between UDP flow and the RTP/
RTCP header to separate the RTP sessions.
2.2. Signalling for RTP sessions 2.2. Signalling for RTP sessions
RTP is built with the assumption of an external to RTP/RTCP RTP is built with the assumption of an external to RTP/RTCP
signalling channel to configure the RTP sessions and its functions. signalling channel to configure the RTP sessions and its functions.
The basic configuration of an RTP session consists of the following The basic configuration of an RTP session consists of the following
parameters: parameters:
RTP Profile: The name of the RTP profile to be used in session. The RTP Profile: The name of the RTP profile to be used in session. The
RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate
on basic level, as can their secure variants RTP/SAVP [RFC3711] on basic level, as can their secure variants RTP/SAVP [RFC3711]
and RTP/SAVPF [RFC5124]. The secure variants of the profiles do and RTP/SAVPF [RFC5124]. The secure variants of the profiles do
not directly interoperate with the non-secure variants, due to the not directly interoperate with the non-secure variants, due to the
presence of additional header fields. presence of additional header fields in addition to any
cryptographic transoformation of the packet content.
Transport Information: Source and destination address(s) and ports Transport Information: Source and destination address(s) and ports
for RTP and RTCP must be signalled for each RTP session. If RTP for RTP and RTCP must be signalled for each RTP session. If RTP
and RTCP multiplexing [RFC5761] is to be used, such that a single and RTCP multiplexing [RFC5761] is to be used, such that a single
port is used for RTP and RTCP flows, this must be signalled. port is used for RTP and RTCP flows, this must be signalled.
RTP Payload Types and Media formats: The mapping between media type RTP Payload Types, media formats, and media format parameters: The
names (and hence the RTP payload formats to be used) and the RTP mapping between media type names (and hence the RTP payload
payload type numbers must be signalled. Each media type may also formats to be used) and the RTP payload type numbers must be
have a number of media type parameters that must also be signalled signalled. Each media type may also have a number of media type
to configure the codec and RTP payload format (the "a=fmtp:" line parameters that must also be signalled to configure the codec and
from SDP). RTP payload format (the "a=fmtp:" line from SDP).
Support for exchanging RTCP Bandwidth values to the end-points will RTP Extensions: The RTP extensions one intendeds to use needs to be
be necessary, as described in "Session Description Protocol (SDP) agreed on, including any parameters for that extension. In some
Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" case just to avoid spending bit-rate on features that the other
[RFC3556], or something semantically equivalent. This also ensures end-point will ignore. But for certain mechanisms there is
that the end-points have a common view of the RTCP bandwidth, this is requirement for this to happen as interoperability failure
important as too different view of the bandwidths may lead to failure otherwise happens.
to interoperate.
RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the
end-points will be necessary, as described in "Session Description
Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)
Bandwidth" [RFC3556], or something semantically equivalent. This
also ensures that the end-points have a common view of the RTCP
bandwidth, this is important as too different view of the
bandwidths may lead to failure to interoperate.
These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the
offer/answer model, but does require all the necessary parameters to
be negotiated somehow, and provided to the RTP implementation.
2.3. (Lack of) Signalling for Payload Format Changes 2.3. (Lack of) Signalling for Payload Format Changes
As discussed in Section 2.2, the mapping between media type name, and As discussed in Section 2.2, the mapping between media type name, and
its associated RTP payload format, and the RTP payload type number to its associated RTP payload format, and the RTP payload type number to
be used for that format must be signalled as part of the session be used for that format must be signalled as part of the session
setup. An endpoint may signal support for multiple media formats, or setup. An endpoint may signal support for multiple media formats, or
multiple configurations of a single format, each using a different multiple configurations of a single format, each using a different
RTP payload type number. If multiple formats are signalled by an RTP payload type number. If multiple formats are signalled by an
endpoint, that endpoint must be prepared to receive data encoded in endpoint, that endpoint is REQUIRED to be prepared to receive data
any of those formats at any time. RTP does not require advance encoded in any of those formats at any time. RTP does not require
signalling for changes between formats that were signalled as part of advance signalling for changes between formats that were signalled
the session setup. This is necessary for rapid rate adaptation. during the session setup. This is needed for rapid rate adaptation.
3. RTP Profile 3. RTP Profile
The RTP profile REQUIRED to implement is "Extended Secure RTP Profile The "Extended Secure RTP Profile for Real-time Transport Control
for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to
SAVPF)" [RFC5124]. Which will mean implicit support for AVPF be implemented. This builds on the basic RTP/AVP profile [RFC3551],
[RFC4585], AVP [RFC3551] and SAVP [RFC3711]. the RTP/AVPF feedback profile [RFC4585], and the secure RTP/SAVP
profile [RFC3711].
The AVPF part of SAVPF is required to get the improved RTCP timer The RTP/AVPF part of RTP/SAVPF is required to get the improved RTCP
model, that allows more flexible transmission of RTCP packets as timer model, that allows more flexible transmission of RTCP packets
response to events, rather than strictly according to bandwidth. in response to events, rather than strictly according to bandwidth.
This also saves RTCP bandwidth and will commonly only utilize the This also saves RTCP bandwidth and will commonly only utilize the
full amount when there is a lot of events to send feedback on. full amount when there is a lot of events on which to send feedback.
This functionality is needed to make use of the RTP conferencing
extensions discussed in Section 6.1.
The S part of SAVPF is for support of SRTP. This provides media The RTP/SAVP part of RTP/SAVPF is for support for Secure RTP (SRTP)
encryption, integrity protection, replay protection and a limited [RFC3711]. This provides media encryption, integrity protection,
form of source authentication. It does not contain a specific keying replay protection and a limited form of source authentication. It
mechanism. So that and the set of security transforms will be does not contain a specific keying mechanism, so that, and the set of
required to be selected. It is possible that a security mechanism security transforms, will be required to be chosen. It is possible
operating on a lower layer than RTP can be used instead and that that a security mechanism operating on a lower layer than RTP can be
should be evaluated. However, the reasons for the design of SRTP used instead and that should be evaluated. However, the reasons for
should be taken into consideration in that discussion. the design of SRTP should be taken into consideration in that
discussion.
4. RTP and RTCP Guidelines 4. RTP and RTCP Guidelines
RTP and RTCP are two flexible and extensible protocols that allow, on RTP and RTCP are two flexible and extensible protocols that allow, on
the one hand, choosing from a variety of building blocks and the one hand, choosing from a variety of building blocks and
combining those to meet application needs, and on the other hand, combining those to meet application needs, and on the other hand,
create extensions where existing mechanisms are not sufficient: from create extensions where existing mechanisms are not sufficient: from
new payload formats to RTP extension headers to additional RTCP new payload formats to RTP extension headers to additional RTCP
control packets. control packets.
skipping to change at page 8, line 16 skipping to change at page 11, line 13
and Guidelines for Extending the RTP Control Protocol [RFC5968]. and Guidelines for Extending the RTP Control Protocol [RFC5968].
5. RTP Optimizations 5. RTP Optimizations
This section discusses some optimizations that makes RTP/RTCP work This section discusses some optimizations that makes RTP/RTCP work
better and more efficient and therefore are considered. better and more efficient and therefore are considered.
5.1. RTP and RTCP Multiplexing 5.1. RTP and RTCP Multiplexing
Historically, RTP and RTCP have been run on separate UDP ports. With Historically, RTP and RTCP have been run on separate UDP ports. With
the increased use of Network Address Port Translation (NAPT) this has the increased use of Network Address/Port Translation (NAPT) this has
become problematic, since maintaining multiple NAT bindings can be become problematic, since maintaining multiple NAT bindings can be
costly. It also complicates firewall administration, since multiple costly. It also complicates firewall administration, since multiple
ports must be opened to allow RTP traffic. To reduce these costs and ports must be opened to allow RTP traffic. To reduce these costs and
session setup times, support for multiplexing RTP data packets and session setup times, support for multiplexing RTP data packets and
RTCP control packets on a single port [RFC5761] is REQUIRED. RTCP control packets on a single port [RFC5761] is REQUIRED.
Supporting this specification is generally a simplification in code,
since it relaxes the tests in [RFC3550].
Note that the use of RTP and RTCP multiplexed on a single port Note that the use of RTP and RTCP multiplexed on a single port
ensures that there is occasional traffic sent on that port, even if ensures that there is occasional traffic sent on that port, even if
there is no active media traffic. This may be useful to keep-alive there is no active media traffic. This may be useful to keep-alive
NAT bindings. NAT bindings.
5.2. Reduced Size RTCP 5.2. Reduced Size RTCP
RTCP packets are usually sent as compound RTCP packets; and RFC 3550 RTCP packets are usually sent as compound RTCP packets; and RFC 3550
demands that those compound packets always start with an SR or RR demands that those compound packets always start with an SR or RR
skipping to change at page 8, line 43 skipping to change at page 11, line 42
these general statistics are not needed in every packet and these general statistics are not needed in every packet and
unnecessarily increase the mean RTCP packet size and thus limit the unnecessarily increase the mean RTCP packet size and thus limit the
frequency at which RTCP packets can be sent within the RTCP bandwidth frequency at which RTCP packets can be sent within the RTCP bandwidth
share. share.
RFC5506 "Support for Reduced-Size Real-Time Transport Control RFC5506 "Support for Reduced-Size Real-Time Transport Control
Protocol (RTCP): Opportunities and Consequences" [RFC5506] specifies Protocol (RTCP): Opportunities and Consequences" [RFC5506] specifies
how to reduce the mean RTCP message and allow for more frequent how to reduce the mean RTCP message and allow for more frequent
feedback. Frequent feedback, in turn, is essential to make real-time feedback. Frequent feedback, in turn, is essential to make real-time
application quickly aware of changing network conditions and allow application quickly aware of changing network conditions and allow
them to adapt their transmission and encoding behavior. them to adapt their transmission and encoding behavior. Supporting
this specification is generally a simplification in code, since it
relaxes the tests in [RFC3550].
Support for RFC5506 is REQUIRED. Support for RFC5506 is REQUIRED.
5.3. Symmetric RTP/RTCP 5.3. Symmetric RTP/RTCP
RTP entities choose the RTP and RTCP transport addresses, i.e., IP RTP entities choose the RTP and RTCP transport addresses, i.e., IP
addresses and port numbers, to receive packets on and bind their addresses and port numbers, to receive packets on and bind their
respective sockets to those. When sending RTP packets, however, they respective sockets to those. When sending RTP packets, however, they
may use a different IP address or port number for RTP, RTCP, or both; may use a different IP address or port number for RTP, RTCP, or both;
e.g., when using a different socket instance for sending and for e.g., when using a different socket instance for sending and for
receiving. Symmetric RTP/RTCP requires that the IP address and port receiving. Symmetric RTP/RTCP requires that the IP address and port
number for sending and receiving RTP/RTCP packets are identical. number for sending and receiving RTP/RTCP packets are identical.
The reasons for using symmetric RTP is primarily to avoid issues with
NAT and Firewalls by ensuring that the flow is actually bi-
directional and thus kept alive and registred as flow the intended
recipient actually wants. In addition it saves resources in the form
of ports at the end-points, but also in the network as NAT mappings
or firewall state is not unnecessary bloated. Also the number of QoS
state are reduced.
Using Symmetric RTP and RTCP [RFC4961] is REQURIED. Using Symmetric RTP and RTCP [RFC4961] is REQURIED.
5.4. CNAME generation 5.4. Generation of the RTCP Canonical Name (CNAME)
The RTCP Canonical Name (CNAME) provides a persistent transport-level The RTCP Canonical Name (CNAME) provides a persistent transport-level
identifier for an RTP endpoint. While the Synchronization Source identifier for an RTP endpoint. While the Synchronization Source
(SSRC) identifier for an RTP endpoint may change if a collision is (SSRC) identifier for an RTP endpoint may change if a collision is
detected, or when the RTP application is restarted, it's RTCP CNAME detected, or when the RTP application is restarted, it's RTCP CNAME
is meant to stay unchanged, so that RTP endpoints can be uniquely is meant to stay unchanged, so that RTP endpoints can be uniquely
identified and associated with their RTP media streams. For proper identified and associated with their RTP media streams. For proper
functionality, RTCP CNAMEs should be unique within the participants functionality, RTCP CNAMEs should be unique within the participants
of an RTP session. of an RTP session.
The RTP specification [RFC3550] includes guidelines for choosing a The RTP specification [RFC3550] includes guidelines for choosing a
unique RTP CNAME, but these are not sufficient in the presence of NAT unique RTP CNAME, but these are not sufficient in the presence of NAT
devices. In addition, some may find long-term persistent identifiers devices. In addition, some may find long-term persistent identifiers
problematic from a privacy viewpoint. Accordingly, support for problematic from a privacy viewpoint. Accordingly, support for
generating the RTP CNAME as specified in "Guidelines for Choosing RTP generating the RTP CNAME as specified in "Guidelines for Choosing RTP
Control Protocol (RTCP) Canonical Names (CNAMEs)" Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is
[I-D.ietf-avt-rtp-cnames] is RECOMMENDED, since this addresses both RECOMMENDED, since this addresses both concerns.
concerns.
6. RTP Extensions 6. RTP Extensions
There are a number of RTP extensions that could be very useful in the There are a number of RTP extensions that could be very useful in the
RTC-WEB context. One set is related to conferencing, others are more RTC-Web context. One set is related to conferencing, others are more
generic in nature. generic in nature.
6.1. RTP Conferencing Extensions 6.1. RTP Conferencing Extensions
RTP is inherently defined for group communications, originally RTP is inherently defined for group communications, whether using IP
assuming the availability of IP multicast. In today's practice, multicast, multi-unicast, or based on a centralised server. In
however, overlay-based conferencing dominates, typically using one or today's practice, however, overlay-based conferencing dominates,
a few so-called conference bridges or servers to connect endpoints in typically using one or a few so-called conference bridges or servers
a star or flat tree topology. Quite diverse conferencing topologies to connect endpoints in a star or flat tree topology. Quite diverse
can be created using the basic elements of RTP mixers and translators conferencing topologies can be created using the basic elements of
as defined in RFC 3550. RTP mixers and translators as defined in RFC 3550.
An number of conferencing topologies are defined in [RFC5117] out of An number of conferencing topologies are defined in [RFC5117] out of
the which the following ones are the more common (and most likely in the which the following ones are the more common (and most likely in
practice workable) ones: practice workable) ones:
1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117, section 1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117, section
3.3) 3.3)
2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4) 2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4)
3) Point to Multipoint Using a Video Switching MCU (RFC 5117, section 3) Point to Multipoint Using a Video Switching MCU (RFC 5117, section
3.5) 3.5)
4) Point to Multipoint Using Content Modifying MCUs (RFC 5117, 4) Point to Multipoint Using Content Modifying MCUs (RFC 5117,
section 3.6) section 3.6)
We note that 3 and 4 are not well utilizing the functions of RTP and
in some cases even violates the RTP specifications. Thus we
recommend that one focus on 1 and 2.
RTP protocol extensions to be used with conferencing are included RTP protocol extensions to be used with conferencing are included
because they are important in the context of centralized because they are important in the context of centralized
conferencing, where one RTP Mixer (Conference Focus) receives a conferencing, where one RTP Mixer (Conference Focus) receives a
participants media streams and distribute them to the other participants media streams and distribute them to the other
participants. These messages are defined in AVPF [RFC4585] or in participants. These messages are defined in the Extended RTP Profile
"Codec Control Messages in the RTP Audio-Visual Profile with Feedback for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
(AVPF)" [RFC5104]. AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio-
Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully
usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124].
6.1.1. RTCP Feedback Message: Full Intra Request 6.1.1. RTCP Feedback Message: Full Intra Request
The Full Intra Request is defined in Section 3.51 and 4.3.1 of The Full Intra Request is defined in Sections 3.5.1 and 4.3.1 of CCM
[RFC5104]. It is used to have the mixer request from the currently [RFC5104]. It is used to have the mixer request from the currently
distributed session participants a new Intra picture. This is used distributed session participants a new Intra picture. This is used
when switching between sources to ensure that the receivers can when switching between sources to ensure that the receivers can
decode the video or other predicted media encoding with long decode the video or other predicted media encoding with long
prediction chains. It is RECOMMENDED that this feedback message is prediction chains. It is RECOMMENDED that this feedback message is
supported. supported.
6.1.2. RTCP Feedback Message: Picture Loss Indicator 6.1.2. RTCP Feedback Message: Picture Loss Indicator
The Picture Loss Indicator is defined in Section 6.3.1 of [RFC4585]. The Picture Loss Indicator is defined in Section 6.3.1 of AVPF
It is used by a receiver to tell the encoder that it lost the decoder [RFC4585]. It is used by a receiver to tell the encoder that it lost
context and would like to have it repaired somehow. This is the decoder context and would like to have it repaired somehow. This
semantically different from the the Full Intra Request above. It is is semantically different from the Full Intra Request above. It is
RECOMMENDED that this feedback message is supported. RECOMMENDED that this feedback message is supported as a loss
tolerance mechanism.
6.1.3. RTCP Feedback Message: Temporary Maximum Media Stream Bit Rate 6.1.3. RTCP Feedback Message: Temporary Maximum Media Stream Bit Rate
Request Request
This feedback message is defined in Section 3.5.4 and 4.2.1 in This feedback message is defined in Section 3.5.4 and 4.2.1 in CCM
[RFC5104]. This message and its notification message is used by a [RFC5104]. This message and its notification message is used by a
media receiver, to inform the sending party that there is a current media receiver, to inform the sending party that there is a current
limitation on the amount of bandwidth available to this receiver. limitation on the amount of bandwidth available to this receiver.
This can be for various reasons, and can for example be used by an This can be for various reasons, and can for example be used by an
RTP mixer to limit the media sender being forwarded by the mixer RTP mixer to limit the media sender being forwarded by the mixer
(without doing media transcoding) to fit the bottlenecks existing (without doing media transcoding) to fit the bottlenecks existing
towards the other session participants. It is RECOMMENDED that this towards the other session participants. It is RECOMMENDED that this
feedback message is supported. feedback message is supported.
6.2. RTP Header Extensions 6.2. RTP Header Extensions
skipping to change at page 12, line 31 skipping to change at page 15, line 46
Payload Format" [RFC4588] is RECOMMENDED. Payload Format" [RFC4588] is RECOMMENDED.
The retransmission scheme in RTP allows flexible application of The retransmission scheme in RTP allows flexible application of
retransmissions. Only selected missing packets can be requested by retransmissions. Only selected missing packets can be requested by
the receiver. It also allows for the sender to prioritize between the receiver. It also allows for the sender to prioritize between
missing packets based on senders knowledge about their content. missing packets based on senders knowledge about their content.
Compared to TCP, RTP retransmission also allows one to give up on a Compared to TCP, RTP retransmission also allows one to give up on a
packet that despite retransmission(s) still has not been received packet that despite retransmission(s) still has not been received
within a time window. within a time window.
7.2. Forward Error Correction 7.2. Forward Error Correction (FEC)
Support of some type of FEC scheme to combat packet loss is Support of some type of FEC to combat the effects of packet loss is
beneficial, but is application dependent and also claimed to be beneficial, but is heavily application dependent. However, some FEC
mostly encumbered. For further discussion. mechanisms are encumbered.
(tbd: add further discussion here)
8. RTP Rate Control and Media Adaptation 8. RTP Rate Control and Media Adaptation
It is REQUIRED to have an RTP Rate Control mechanism using Media It is REQUIRED to have an RTP Rate Control mechanism using Media
adaptation to ensure that the generated RTP flows are network adaptation to ensure that the generated RTP flows are network
friendly. friendly, and maintain the user experience in the presence of network
problems.
The biggest issue is that there are no standardized and ready to use The biggest issue is that there are no standardized and ready to use
mechanism that can simply be included in RTC-WEB. Thus there will be mechanism that can simply be included in RTC-Web. Thus there will be
need for the IETF to produce such a specification. A potential need for the IETF to produce such a specification. A potential
starting point for defining a solution is "RTP with TCP Friendly Rate starting point for defining a solution is "RTP with TCP Friendly Rate
Control"[rtp-tfrc]. Control"[rtp-tfrc].
9. RTP Performance Monitoring 9. RTP Performance Monitoring
RTCP does contains a basic set of RTP flow monitoring points like RTCP does contains a basic set of RTP flow monitoring points like
packet loss and jitter. There exist a number of extensions that packet loss and jitter. There exist a number of extensions that
could be included in the set to be supported. However, in most cases could be included in the set to be supported. However, in most cases
which RTP monitoring that is needed depends on the application, which which RTP monitoring that is needed depends on the application, which
makes it difficult to select which to include when the set of makes it difficult to select which to include when the set of
applications is very large. applications is very large.
10. IANA Considerations 10. IANA Considerations
This document makes no request of IANA. This memo makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
11. Security Considerations 11. Security Considerations
RTP and its various extensions each have their own security RTP and its various extensions each have their own security
considerations. These should be taken into account when considering considerations. These should be taken into account when considering
the security properties of the complete suite. We currently don't the security properties of the complete suite. We currently don't
think this suite creates any additional security issues or think this suite creates any additional security issues or
properties. The usage of SRTP will provide protection or mitigation properties. The use of SRTP will provide protection or mitigation
against all the fundamental issues by offering confidentiality, against all the fundamental issues by offering confidentiality,
integrity and partial source authentication. We don't discuss the integrity and partial source authentication. We don't discuss the
key-management aspect of SRTP in this document, that needs to be done key-management aspect of SRTP in this memo, that needs to be done
taking the RTC-WEB communication model into account. taking the RTC-Web communication model into account.
In the context of RTC-WEB the actual security properties required In the context of RTC-Web the actual security properties required
from RTP are currently not fully understood. Until security goals from RTP are currently not fully understood. Until security goals
and requirements are specified it will be difficult to determine what and requirements are specified it will be difficult to determine what
security features in addition to SRTP and a suitable key-management, security features in addition to SRTP and a suitable key-management,
if any, that are needed. if any, that are needed.
12. Acknowledgements 12. Acknowledgements
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-avt-rtp-cnames]
Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-ietf-avt-rtp-cnames-05 (work in
progress), January 2011.
[I-D.ietf-avtext-client-to-mixer-audio-level] [I-D.ietf-avtext-client-to-mixer-audio-level]
Lennox, J., Ivov, E., and E. Marocco, "A Real-Time Lennox, J., Ivov, E., and E. Marocco, "A Real-Time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", Mixer Audio Level Indication",
draft-ietf-avtext-client-to-mixer-audio-level-00 (work in draft-ietf-avtext-client-to-mixer-audio-level-00 (work in
progress), February 2011. progress), February 2011.
[I-D.ietf-avtext-mixer-to-client-audio-level] [I-D.ietf-avtext-mixer-to-client-audio-level]
Ivov, E., Marocco, E., and J. Lennox, "A Real-Time Ivov, E., Marocco, E., and J. Lennox, "A Real-Time
Transport Protocol (RTP) Header Extension for Mixer-to- Transport Protocol (RTP) Header Extension for Mixer-to-
skipping to change at page 15, line 44 skipping to change at page 19, line 8
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011.
13.2. Informative References 13.2. Informative References
[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.
[rtp-tfrc] [rtp-tfrc]
Gharai, L., "RTP with TCP Friendly Rate Control Gharai, L., "RTP with TCP Friendly Rate Control
(draft-gharai-avtcore-rtp-tfrc-00)", March 2011. (draft-gharai-avtcore-rtp-tfrc-00)", March 2011.
 End of changes. 61 change blocks. 
202 lines changed or deleted 357 lines changed or added

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