draft-perkins-rtcweb-rtp-usage-01.txt   draft-perkins-rtcweb-rtp-usage-02.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: Standards Track M. Westerlund
Expires: December 7, 2011 Ericsson Expires: January 12, 2012 Ericsson
J. Ott J. Ott
Aalto University Aalto University
June 5, 2011 July 11, 2011
RTP Requirements for RTC-Web RTP Requirements for RTC-Web
draft-perkins-rtcweb-rtp-usage-01 draft-perkins-rtcweb-rtp-usage-02
Abstract Abstract
This memo discusses use of RTP in the context of the RTC-Web This memo discusses use of RTP in the context of the RTC-Web
activity. It discusses important features of RTP that need to be activity. It discusses important features of RTP that need to be
considered by other parts of the RTC-Web framework, describes which considered by other parts of the RTC-Web framework, describes which
RTP profile to use in this environment, and outlines what RTP RTP profile to use in this environment, and outlines what RTP
extensions should be supported. extensions should be supported.
This document is a candidate to become a work item of the RTCWEB
working group as <WORKING GROUP DRAFT "MEDIA TRANSPORTS">.
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 December 7, 2011. This Internet-Draft will expire on January 12, 2012.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Expected Topologies . . . . . . . . . . . . . . . . . . . 3 1.1. Expected Topologies . . . . . . . . . . . . . . . . . . . 4
2. Requirements from RTP . . . . . . . . . . . . . . . . . . . . 6 2. Requirements from RTP . . . . . . . . . . . . . . . . . . . . 7
2.1. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6 2.1. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 7
2.2. Signalling for RTP sessions . . . . . . . . . . . . . . . 8 2.2. RTP Session Multiplexing . . . . . . . . . . . . . . . . . 8
2.3. (Lack of) Signalling for Payload Format Changes . . . . . 9 2.2.1. Why RTP Sessions Should be Demultiplexed by the
3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 10 Transport . . . . . . . . . . . . . . . . . . . . . . 8
4. RTP and RTCP Guidelines . . . . . . . . . . . . . . . . . . . 10 2.2.2. Arguments for a single transport flow . . . . . . . . 12
5. RTP Optimizations . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 11 2.3. Signalling for RTP sessions . . . . . . . . . . . . . . . 15
5.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11 2.4. (Lack of) Signalling for Payload Format Changes . . . . . 16
5.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 11 3. RTP Session Multiplexing . . . . . . . . . . . . . . . . . . . 16
5.4. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12 3.1. DCCP Based Solution . . . . . . . . . . . . . . . . . . . 17
6. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. SHIM layer . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. RTP Conferencing Extensions . . . . . . . . . . . . . . . 12 3.3. RTP Internal Multiplexing . . . . . . . . . . . . . . . . 20
6.1.1. RTCP Feedback Message: Full Intra Request . . . . . . 13 3.3.1. Issues with SSRC RTP Multiplexing . . . . . . . . . . 21
6.1.2. RTCP Feedback Message: Picture Loss Indicator . . . . 13 3.3.2. Executing on this Proposal . . . . . . . . . . . . . . 22
6.1.3. RTCP Feedback Message: Temporary Maximum Media 3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23
Stream Bit Rate Request . . . . . . . . . . . . . . . 14 4. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 14 5. RTP and RTCP Guidelines . . . . . . . . . . . . . . . . . . . 24
6.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 15 6. RTP Optimisations . . . . . . . . . . . . . . . . . . . . . . 24
7. Improving RTP Transport Robustness . . . . . . . . . . . . . . 15 6.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 24
7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 15 6.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 25
7.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 15 6.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 25
8. RTP Rate Control and Media Adaptation . . . . . . . . . . . . 16 6.4. Generation of the RTCP Canonical Name (CNAME) . . . . . . 25
9. RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 16 7. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. RTP Conferencing Extensions . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1.1. RTCP Feedback Message: Full Intra Request . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.2. RTCP Feedback Message: Picture Loss Indicator . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.3. RTCP Feedback Message: Temporary Maximum Media
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 Stream Bit Rate Request . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 28
7.4. Client to Mixer Audio Level . . . . . . . . . . . . . . . 28
7.5. Mixer to Client Audio Level . . . . . . . . . . . . . . . 29
8. Improving RTP Transport Robustness . . . . . . . . . . . . . . 29
8.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 29
8.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 31
8.2.1. Basic Redundancy . . . . . . . . . . . . . . . . . . . 31
8.2.2. Block Based . . . . . . . . . . . . . . . . . . . . . 32
8.2.3. Recommendations for FEC . . . . . . . . . . . . . . . 33
9. RTP Rate Control and Media Adaptation . . . . . . . . . . . . 33
10. RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This memo discusses the Real-time Transport Protocol (RTP) [RFC3551] This memo discusses the Real-time Transport Protocol (RTP) [RFC3550]
in the context of the RTC-Web activity. The work in the IETF Audio/ in the context of the RTC-Web activity. The work in the IETF Audio/
Video Transport Working Group, and it's successors, has been about Video Transport Working Group, and it's successors, has been about
providing building blocks for real-time multimedia transport, and has providing building blocks for real-time multimedia transport, and has
not specified who should use which building blocks. The selection of not specified who should use which building blocks. The 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, for example RTC-Web. We have selected a context of some application, for example RTC-Web. We have selected a
set of RTP features and extensions that are suitable for a number of set of RTP features and extensions that are suitable for a number of
applications that fits the RTC-Web context. Thus applications such applications that fit the RTC-Web context. Thus, applications such
as VoIP, audio and video conferencing, and on-demand multimedia as VoIP, audio and video conferencing, and on-demand multimedia
streaming are considered. Applications that rely on IP multicast streaming are considered. Applications that rely on IP multicast
have not been considered likely to be applicable to RTC-Web, thus have not been considered likely to be applicable to RTC-Web, thus
extensions related to multicast have been excluded. We believe that extensions related to multicast have been excluded. We believe that
RTC-Web will greatly benefit in interoperability if a reasonable set RTC-Web will greatly benefit in interoperability if a reasonable set
of RTP functionalities and extensions are selected. This memo is of RTP functionalities and extensions are selected. This memo is
intended as a starting point for discussion of those features in the intended as a starting point for discussion of those features in the
RTC-Web framework. RTC-Web framework.
This memo 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 given. When it comes
to the importance of extensions, or the need for implementation to the importance of extensions, or the need for implementation
support, we use three requirement levels to indicate the importance support, we use three requirement levels to indicate the importance
of the feature to the RTC-Web specification: of the feature to the RTC-Web specification:
REQUIRED: Functionality that is absolutely needed to make the RTC- REQUIRED: Functionality that is absolutely needed to make the RTC-
Web solution work well, or functionality of low complexity that Web solution work well, or functionality of low complexity that
provides high value. 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.
skipping to change at page 3, line 50 skipping to change at page 4, line 50
When this memo discusses RTP, it includes the RTP Control Protocol When this memo discusses RTP, it includes the RTP Control Protocol
(RTCP) unless explicitly stated otherwise. RTCP is a fundamental and (RTCP) unless explicitly stated otherwise. RTCP is a fundamental and
integral part of the RTP protocol, and is REQUIRED to be implemented. integral part of the RTP protocol, and is REQUIRED to be implemented.
1.1. Expected Topologies 1.1. Expected Topologies
As RTC-Web is focused on peer to peer connections established from As RTC-Web is focused on peer to peer connections established from
clients in web browsers the following topologies further discussed in clients in web browsers the following topologies further discussed in
RTP Topologies [RFC5117] are primarily considered. The topologies RTP Topologies [RFC5117] are primarily considered. The topologies
are depicted and briefly explaind here for ease of the reader. are depicted and briefly explained here for ease of the reader.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Figure 1: Point to Point
The point to point topology (Figure 1) is going to be very common in The point to point topology (Figure 1) is going to be very common in
any single user to single user applications. any single user to single user applications.
skipping to change at page 4, line 32 skipping to change at page 5, line 32
| C | | C |
+---+ +---+
Figure 2: Multi-unicast Figure 2: Multi-unicast
For small multiparty sessions it is practical enough to create RTP For small multiparty sessions it is practical enough to create RTP
sessions by letting every participant send individual unicast RTP/UDP sessions by letting every participant send individual unicast RTP/UDP
flows to each of the other participants. This is called multi- flows to each of the other participants. This is called multi-
unicast and is unfortunately not discussed in the RTP Topologies unicast and is unfortunately not discussed in the RTP Topologies
[RFC5117]. This topology has the benefit of not requiring central [RFC5117]. This topology has the benefit of not requiring central
nodes. On the downside is that it increase the used bandwidth by nodes. The downside is that it increases the used bandwidth at each
requiring one copy of the media streams for each participant part of sender by requiring one copy of the media streams for each
the same session beyond the sender itself. Thus this is limited to participant that are part of the same session beyond the sender
scenarios with few end-points unless the media is very low bandwidth. itself. Thus this is limited to scenarios with few end-points unless
the media is very low bandwidth.
It needs to be noted that if this topology is to be supported by the It needs to be noted that, if this topology is to be supported by the
RTC-Web framework it needs to be possible to connect one RTP session RTC-Web framework, it needs to be possible to connect one RTP session
to multiple established peer to peer flows that are individually to multiple established peer to peer flows that are individually
established. established.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 3: RTP Mixer with Only Unicast Paths Figure 3: RTP Mixer with Only Unicast Paths
An RTP mixer (Figure 3) is a centralized point that selects or mixes An RTP mixer (Figure 3) is a centralised point that selects or mixes
content in a conference to optimize the RTP session so that each end- content in a conference to optimise the RTP session so that each end-
point only needs connect to one entity, the mixer. The mixer also point only needs connect to one entity, the mixer. The mixer also
reduces the bit-rate needs as the media sent from the mixer to the reduces the bit-rate needs as the media sent from the mixer to the
end-point can be optimized in different ways. These optimizations end-point can be optimised in different ways. These optimisations
include methods like only chosing media from the currently most include methods like only choosing media from the currently most
active speaker or mixing together audio so that only one audio stream 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 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. the mixer is that someone is required to provide the actual mixer.
+---+ +------------+ +---+ +---+ +------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Translator | | Translator |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +------------+ +---+ +---+ +------------+ +---+
Figure 4: RTP Translator (Relay) with Only Unicast Paths Figure 4: RTP Translator (Relay) with Only Unicast Paths
If one wants a less complex central node it is possible to use an 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 relay (called an Transport Translator) (Figure 4) that takes on the
role of forwarding the media to the other end-points but doesn't role of forwarding the media to the other end-points but doesn't
perform any media processing. It simply forwards the media from all 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 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 media once to the relay, but it will still receive 3 RTP streams with
the media if B, C and D all currently transmitts. the media if B, C and D all currently transmits.
+------------+ +------------+
| | | |
+---+ | | +---+ +---+ | | +---+
| A |<---->| Translator |<---->| B | | A |<---->| Translator |<---->| B |
+---+ | | +---+ +---+ | | +---+
| | | |
+------------+ +------------+
Figure 5: Translator towards Legacy end-point Figure 5: Translator towards Legacy end-point
To support legacy end-point (B) that don't fulfill the requiremetns To support legacy end-point (B) that don't fulfil the requirements of
of RTC-Web it is possible to insert a Translator (Figure 5) that RTC-Web it is possible to insert a Translator (Figure 5) that takes
takes on the role to ensure that from A's perspective B looks like a on the role to ensure that from A's perspective B looks like a fully
fully compliant end-point. Thus it is the combination of the compliant end-point. Thus it is the combination of the Translator
Translator and B that looks like the end-point B. The intention is and B that looks like the end-point B. The intention is that the
that the presence of the translator is transparant to A, however it presence of the translator is transparent to A, however it is not
is not certain that is possible. Thus this case is include so that certain that is possible. Thus this case is include so that it can
it can be discussed if any mechanism specified to be used for RTC-Web be discussed if any mechanism specified to be used for RTC-Web
results in such issues and how to handle them. results in such issues and how to handle them.
2. Requirements from RTP 2. Requirements from RTP
This section discusses some requirements RTP and RTCP [RFC3550] place This section discusses some requirements RTP and RTCP [RFC3550] place
on their underlying transport protocol, the signalling channel, etc. on their underlying transport protocol, the signalling channel, etc.
2.1. RTP Multiplexing Points 2.1. RTP Multiplexing Points
There are three fundamental points of multiplexing within the RTP There are three fundamental points of multiplexing within the RTP
skipping to change at page 6, line 27 skipping to change at page 7, line 27
does not have an identifier within the RTP protocol itself, but does not have an identifier within the RTP protocol itself, but
instead relies on the lower layer to separate the different RTP instead relies on the lower layer to separate the different RTP
sessions. This is most often done by separating different RTP sessions. This is most often done by separating different RTP
sessions onto different UDP ports, or by sending to different IP sessions onto different UDP ports, or by sending to different IP
multicast addresses. The distinguishing feature of an RTP session multicast addresses. The distinguishing feature of an RTP session
is that it has a separate SSRC identifier space; a single RTP is that it has a separate SSRC identifier space; a single RTP
session can span multiple transport connections provided packets session can span multiple transport connections provided packets
are gatewayed such that participants are known to each other. are gatewayed such that participants are known to each other.
Different RTP sessions are used to separate different types of Different RTP sessions are used to separate different types of
media within a multimedia session. For example, audio and video media within a multimedia session. For example, audio and video
flows are sent on separate RTP sessions. flows are sent on separate RTP sessions. But also completely
different usages of the same media type, e.g. video of the
presenter and the slide video, benefits from being separated.
Multiplexing using the SSRC within an RTP session: The second Multiplexing using the SSRC within an RTP session: The second
multiplexing point is the SSRC that separates different sources of multiplexing point is the SSRC that separates different sources of
media within a single RTP session. An example might be different media within a single RTP session. An example might be different
participants in a multiparty teleconference, or different camera participants in a multiparty teleconference, or different camera
views of a presentation. In most cases, each participant within views of a presentation. In most cases, each participant within
an RTP session has a single SSRC, although this may change over an RTP session has a single SSRC, although this may change over
time if collisions are detected. However, in some more complex time if collisions are detected. However, in some more complex
scenarios participants may generate multiple media streams of the scenarios participants may generate multiple media streams of the
same type simultaneously (e.g., if they have two cameras, and so 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 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 SSRC in use at once. The RTCP CNAME can be used to distinguish
between a single participant using two SSRC values (where the RTCP between a single participant using two SSRC values (where the RTCP
CNAME will be the same for each SSRC), and two participants (who CNAME will be the same for each SSRC), and two participants (who
will have different RTCP CNAMEs). will have different RTCP CNAMEs).
Multiplexing using the Payload Type within an RTP session: If Multiplexing using the Payload Type within an RTP session: If
different media encodings of the same type are to be used at different media encodings of the same media type (audio, video,
different times within an RTP session, for example a single text, etc) are to be used at different times within an RTP
participant that can switch between two different audio codecs, session, for example a single participant that can switch between
the payload type is used to identify how the media from that two different audio codecs, the payload type is used to identify
particular source is encoded. When changing media formats within how the media from that particular source is encoded. When
an RTP Session, the SSRC of the sender remains unchanged, but the changing media formats within an RTP Session, the SSRC of the
RTP Payload Type changes to indicate the change in media format. 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 These multiplexing points area fundamental part of the design of RTP
and are discussed in Section 5.2 of [RFC3550]. Of special importance and are discussed in Section 5.2 of [RFC3550]. Of special importance
is the need to separate different RTP sessions using a multiplexing is the need to separate different RTP sessions using a multiplexing
mechanism at some lower layer than RTP, rather than trying to combine mechanism at some lower layer than RTP, rather than trying to combine
several RTP sessions into one lower layer flow. several RTP sessions implicitly into one lower layer flow. This will
be further discussed in the next section.
The processing that can happen in an RTP mixer, translator or in an 2.2. RTP Session Multiplexing
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 In today's network with prolific use of Network Address Translators
one doesn't have a clear separation of RTP sessions: (NAT) and Firewalls (FW), there is a desire to reduce the number of
transport layer ports used by an real-time media application using
RTP. This has led some to suggest multiplexing two or more RTP
sessions on a single transport layer flow, using either the Payload
Type or SSRC to demultiplex the sessions, in violation of the rules
outlined above. It is not the first time some people look at RTP and
question the need for using RTP sessions for different media types,
and even more the potential need to separate different media streams
of the same type into different session due to their different
purposes. Section 5.2 of [RFC3550] outlines some of those problems;
we elaborate on that discussion, and on other problems that occurs if
one violates this part of the RTP design and architecture.
Scalabilty: RTP was built with media scalability in consideration. 2.2.1. Why RTP Sessions Should be Demultiplexed by the Transport
As discussed in Section 5.2 of [RFC3550], multiplexing several RTP
sessions (e.g., audio and video) onto a single transport layer flow
introduces the following problems:
Payload Identification: If two RTP sessions of the same type are
multiplexed onto a single transport layer flow using the same SSRC
but relying on the Payload Type to distinguish the session, and
one were to change encodings and thus acquire a different RTP
payload type, there would be no general way of identifying which
stream had changed encodings. This can be avoided by partitioning
the SSRC space between the two sessions, but that causes other
problems as discussed below.
Timing and Sequence Number Space: An RTP SSRC is defined to identify
a single timing and sequence number space. Interleaving multiple
payload types would require different timing spaces if the media
clock rates differ and would require different sequence number
spaces to tell which payload type suffered packet loss. Using
multiple clock rates in a single RTP session is problematic, as
discussed in [I-D.ietf-avtext-multiple-clock-rates]. This can be
avoided by partitioning the SSRC space between the two sessions,
but that causes other problems as discussed below.
RTCP Reception Reports: RTCP sender reports and receiver reports can
only describe one timing and sequence number space per SSRC, and
do not carry a payload type field. Multiplexing sessions based on
the payload type breaks RTCP. This can be avoided by partitioning
the SSRC space between the two sessions, but that causes other
problems as discussed below.
RTP Mixers: Multiplexing RTP sessions of incompatible media type
(e.g., audio and video) onto a single transport layer flow breaks
the operation of RTP mixers, since they are unable to combine the
flows together.
RTP Translators: Multiplexing RTP sessions of incompatible media
type (e.g., audio and video) onto a single transport layer flow
breaks the operation of RTP some types of RTP translator, for
example media transcoders, which rely on the RTP requirement that
all media are of the same type.
Quality of Service: Carrying multiple media in one RTP session
precludes the use of different network paths or network resource
allocations that are flow based if appropriate. It also makes
reception of a subset of the media, for example just audio if
video would exceed the available bandwidth, difficult without the
use of an RTP translator within the network to filter out the
unwanted media which unless they are trusted devices (and included
in the key-exchange). This is difficult to combine with media
security functions.
Separate Endpoints: Multiplexing several sessions into one transport
layer flow prevents use of a distributed endpoint implementation,
where audio and video are rendered by different processes and/or
systems.
We do note that some of the above issues are resolved as long as
there is explicit separation of the RTP sessions when transported
over the same lower layer transport, for example by inserting a
multiplexing layer in between the lower transport and the RTP/RTCP
headers. But a number of the above issue are not resolved by this.
In the RTCWEB context, i.e. web browsers running on various end-
points it might appear unlikely that flow based QoS is available on
the end-points that will support RTCWEB. The authors don't disagree
that it is unlikely for the common case of users in their home-
network or at WiFi hotspots will have flow-based QoS available.
However, if one considers enterprise users, especially using intranet
applications, the availability and desire to use QoS is not
implausible. There are also web users who use networks that are more
resource-constrained than wired networks and WIFI networks, for
example cellular network. The current access network QoS mechanism
for user traffic in cellular technology from 3GPP are flow based.
RTP's design hasn't been changed, although session multiplexing
related topics have been discussed at various points of RTP's 20 year
history. The fact is that numerous RTP mechanism and extensions have
been defined assuming that one can perform session multiplexing when
needed. Mechanism that has been identified as problematic if one
doesn't do session separation are:
Scalability: 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 is 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 particularly applicable to RTC-Web, but gatewaying of such a
would then require more alterations and likely stateful session 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. beneficial.
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
packets SSRC field. So for anything that desires to use these packets SSRC field. So for anything that desires to use these
format with RTP payloads that are close to MTU needs to put the format with RTP payloads that are close to MTU needs to put the
FEC data in a separate RTP session compared to the original FEC data in a separate RTP session compared to the original
transmissions. transmissions. The usage of this type of FEC data has not been
decided on in RTCWEB.
RTCP behavior also becomes a factor in why overloading RTP sessions SSRC Allocation and Collision: The SSRC identifier is a random 32-
is problematic. The extension mechanisms used in RTCP depends on the bit number that is required to be globally unique within an RTP
media streams. For example the Extended RTCP report block for VoIP session, and that is reallocated to a new random value if an SSRC
is of suitable for conversational audio, but clearly not useful for collision occurs between participants. If two or more RTP
Video. This has three impacts, either one get unusable reports if sessions share a transport layer flow, there is no guarantee that
they are generated for streams where there are little purpose. This their choice of SSRC values will be distinct, and there is no way
is maybe less likely for the VoIP report, but for example the more in standard RTP to signal which SSRC values are used by which RTP
detailed media agnostic reports it may occur. It otherwise makes the session. RTP is explicitly a group-based communication protocol,
implementation of RTCP more complex as the SSRC purpose tagging needs and new participants can join an RTP session at any time; these
not only to be one the media side, but also on the RTCP reporting. new participants may chose SSRC values that conflict with the SSRC
Also the RTCP reporting interval and transmission scheduling will be values used in any of the multiplexed RTP sessions. This problem
affected. can be avoided by partitioning the SSRC space, and signalling how
the space is to be subdivided, but this is not backwards
compatible with any existing RTP system. In addition, subdividing
the SSRC space makes it difficult to gateway between multiplexed
RTP sessions and standard RTP sessions: the standard sessions may
use parts of the SSRC space reserved in the multiplexed RTP
sessions, requiring the gateway to rewrite RTCP packets, as well
as the SSRC and CSRC list in RTP data packets. Rewriting RTCP is
a difficult task, especially when one considers extensions such as
RTCP XR.
Due to these design principle implementors of various services or Conflicting RTCP Report Types: The extension mechanisms used in RTCP
applications using RTP have not commonly violated this model. If one depend on separation of RTP sessions for different media types.
choses to violate it today, one fails to achieve interoperability For example, the RTCP Extended Report block for VoIP is suitable
with a number of existing services, applications and implementations. for conversational audio, but clearly not useful for Video. This
may cause unusable or unwanted reports to be generated for some
streams, wasting capacity and confusing monitoring systems. While
this is problem may be unlikely for VoIP reports, it may be an
issue for the more detailed media agnostic reports which are
sometimes be used for different media types. Also, this makes the
implementation of RTCP more complex, since partitioning the SSRC
space by media type needs not only to be one the media processing
side, but also on the RTCP reporting
As a conclusion not ensuring that RTP sessions are used for its RTCP Reporting and Scheduling: The RTCP reporting interval and its
intended purpose as a multiplexing point does violate the RTP design packet scheduling will be affected if several RTP sessions are
philosophy. It prevents the use of certain RTP extensions. It will multiplexed onto the same transport layer flow. The reporting
require additional extensions to function and will significantly interval is determined by the session bandwidth, and the reporting
increase the complexity of the implementation. At the same time it interval chosen for a high-rate video session will be different to
will significantly reduce the interoperability with current the interval chosen by a low-rate VoIP session. If such sessions
implementations. Thus the authors considered it REQUIRED that RTP are multiplexed, then participants in one session will see the
sessions are multiplexed using a mechanism outside of RTP. The SSRC values of the other session. This will cause them to
RECOMMENDED mechanism to accomplish that would be to use unique UDP overestimate the number of participants in the session by a factor
flows. If the WG comes to a consensus that due to NAT/Firewall of two, thus doubling their RTCP reporting interval, and making
traversal aspects would be greately simplified with a single flow their feedback less timely. In the worst case, when an RTP
between peers and accept that flow based QoS can only be done on the session with very low RTCP bandwidth is multiplexed with an RTP
aggreage of all RTP sessions then the authors RECOMMEND that some session with high RTCP bandwidth, this may cause repeated RTCP
type of multiplexing layer is inserted between UDP flow and the RTP/ timer reconsideration, leading to the members of the low bandwidth
RTCP header to separate the RTP sessions. session timing out. Participants in an RTP session configured
with high bandwidth (and short RTCP reporting interval) will see
RTCP reports from participants in the low bandwidth session much
less often than expected, potentially causing them to repeatedly
timeout and re-create state for those participants. The split of
RTCP bandwidth between senders and receivers (where at least 25%
of the RTCP bandwidth is allocated to senders) will be disrupted
if a session with few senders (e.g., a VoIP session) is
multiplexed with a session with many senders (e.g., a video
session). These issues can be resolved if the partition of the
SSRC is signalled, but this is not backwards compatible with any
existing RTP system. The partition would require re-implementing
large part of the RTCP processing to take the individual sessions
into account.
2.2. Signalling for RTP sessions Sampling Group Membership: The mechanism defined in RFC2762 to
sample the group membership, allowing participants to keep less
state, assumes a single flat 32-bit SSRC space, and breaks if the
SSRC space is shared between several RTP sessions.
As can be seen, the requirement that separate RTP sessions are
carried in separate transport-layer flows is fundamental to the
design of RTP. Due to this design principle, implementors of various
services or applications using RTP have not commonly violated this
model, and have separated RTP sessions onto different transport layer
flows. After 15 years of deployment of RTP in its current form, any
move to change this assumption must carefully consider the backwards
compatibility problems that this will cause. In particular, since
widespread use of multiplexed RTP sessions in RTC-Web will almost
certainly cause their use in other scenarios, the discussion
regarding compatibility must be wider than just whether multiplexing
works for the extremely limited subset of RTP use cases currently
being considered in the RTC-Web group. Any such multiplexing
extension to RTP must therefore be developed by the AVTCORE working
group, since it has much broader applicability and scope than RTC-
Web.
2.2.2. Arguments for a single transport flow
The arguments the authors are aware of for why it is desirable to use
a single underlying transport (e.g., UDP) flow for all media, rather
than one flow for each type of media are the following:
End-Point Port Consumption: A given IP address only has 16-bits of
available port space per transport protocol for any consumer of
ports that exists on the machine. This is normally never an issue
for a end-user machine. It can become an issue for servers that
has large number of simultaneous flows. However, in RTCWEB where
we will use authenticated STUN requests a server can serve
multiple end-point from the same local port, and use the whole
5-tuple (source and destination address, source and destination
port, protocol) as identifier of flows. Thus, in theory, the
minimal number of media server ports needed are the maximum number
of simultaneous RTP sessions a single end-point may use, when in
practice implementation probably benefit from using more.
NAT State: If an end-point is behind a NAT each flow it generates to
an external address will result in state on that NAT. That state
is a limited resource, either from memory or processing stand-
point in home or SOHO NATs, or for large scale NATs serving many
internal end-points, the available ports run-out. We see this
primarily as a problem for larger centralised NATs where end-point
independent mapping do require each flow mapping to use one port
for the external IP address, thus affecting the the maximum
aggregation of internal users per external IP address. However,
we would like to point out that a RTCWEB session with audio and
video are likely using 2 or 3 UDP flows. This can be contrasted
with that certain web applications that can result that 100+ TCP
flows are opened to various servers. Sure they are recovered more
quickly due to the explicit session teardown when no longer need,
at the same time more web sites may be simultaneously communicated
in various browser tabs. So the question is if the UDP mapping
space is as heavily used as the TCP mapping space, and that TCP
will continue to be the limiting factor for the amount of internal
users a particular NAT can support.
NAT Traversal taking additional time: When doing NAT/FW traversal it
takes additional time to open additional ports. And it takes time
in a phase of communication between accepting to communicate and
the media path being established which is a fairly critical. The
best case scenario for how much extra time it can take following
the specified ICE procedures are. 1.5*RTT +
Ta*(Additional_Flows-1), where Ta is the pacing timer, which ICE
specifies to be no smaller than 20 ms. That assumes a message in
one direction, and then an immediate triggered check back. This
as ICE first finds one candidate pair that works prior to
establish multiple flows. Thus, there is no extra time until one
has found a working candidate pair, from that is only the time it
takes to in parallel establish the additional flows which in most
case are 1 or 2 more additional flows.
NAT Traversal Failure Rate: In cases when one needs more than a
single flow to be established through the NAT there is some risk
that one succeed in establishing the first flow but fails with one
or more of the additional flows. The risk that this happens are
hard to quantify. However, that risk should be fairly low as one
has just prior successfully established one flow from the same
interfaces. Thus only rare events as NAT resource overload, or
selecting particular port numbers that are filtered etc, should be
reasons for failure.
2.2.3. Summary
As we have noted in the preceding sections, implicit multiplexing of
multiple RTP sessions onto a single transport flow raises a large
number of backwards compatibility issues. It has been argued that
these issues are either not important, since the RTP features
disrupted are not of interest to the current set of RTC-Web use
cases, or can be solved by somehow explicitly dividing the SSRC space
into different regions for different RTP sessions. We believe the
first argument is short-sighted: those RTP features may not be
important today, but the successful deployment of simple RTC-Web
applications will generate interest to try more advanced scenarios,
which may well need those features. Partitioning the SSRC space to
separate RTP sessions results in new set of issues, where the biggest
from our point of view is that it effectively creates a new variant
of the RTP protocol, which is incompatible with standard RTP. Having
two different variants of the core functionality of RTP will make it
much more difficult to develop future protocol extensions, and the
new variant will likely also have different set of extensions that
work. In addition the two versions aren't directly interoperable,
and will force anyone that want to interconnect the two version to
deploy (complex) gateways. It also reduces the common user base and
interest in maintaining and developing either version.
On the other hand, we are sympathetic to the argument that using a
single transport flow does save some time in setup processing, it
will save some resources on NATs and FWs that are in between the end-
points communicating, it may have somewhat higher success rate of
session establishment.
Thus the authors considered it REQUIRED that RTP sessions are
multiplexed using an explicit mechanism outside RTP. We strongly
RECOMMENDED that the mechanism used to accomplish this multiplexing
is to use unique UDP flows for each RTP session, based on simplicity
and interoperability. However, we can accept a WG consensus that
using a single transport layer flow between peers is the default, and
that also the fallback of using separate UDP flows are supported,
under one constraint: that the RTP sessions are explicitly
multiplexed in such a way existing mechanism or extensions to RTP are
not prevented to work, and that the solution does not result in that
an alternative variant of RTP is created (i.e., it must not disrupt
RTCP processing, and the RTP semantics). In this later case we
RECOMMEND that some type of multiplexing layer is inserted between
UDP flow and the RTP/RTCP headers to separate the RTP sessions, since
removing this shim-layer and gatewaying to standard RTP sessions is
simpler than trying to separate RTP sessions that are multiplexed
together to gateway them to standard RTP sessions. We discuss
possible multiplexing layers in Section 3.
2.3. 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 in addition to any presence of additional header fields in addition to any
cryptographic transoformation of the packet content. cryptographic transformation 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, media formats, and media format parameters: The RTP Payload Types, media formats, and media format parameters: The
mapping between media type names (and hence the RTP payload mapping between media type names (and hence the RTP payload
formats to be used) and the RTP payload type numbers must be formats to be used) and the RTP payload type numbers must be
signalled. Each media type may also have a number of media type signalled. Each media type may also have a number of media type
parameters that must also be signalled to configure the codec and parameters that must also be signalled to configure the codec and
RTP payload format (the "a=fmtp:" line from SDP). RTP payload format (the "a=fmtp:" line from SDP).
RTP Extensions: The RTP extensions one intendeds to use needs to be RTP Extensions: The RTP extensions one intends to use need to be
agreed on, including any parameters for that extension. In some agreed upon, including any parameters for each respective
case just to avoid spending bit-rate on features that the other extension. At the very least, this will help avoiding using
end-point will ignore. But for certain mechanisms there is bandwidth for features that the other end-point will ignore. But
requirement for this to happen as interoperability failure for certain mechanisms there is requirement for this to happen as
otherwise happens. interoperability failure otherwise happens.
RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the
end-points will be necessary, as described in "Session Description end-points will be necessary, as described in "Session Description
Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)
Bandwidth" [RFC3556], or something semantically equivalent. This Bandwidth" [RFC3556], or something semantically equivalent. This
also ensures that the end-points have a common view of the RTCP also ensures that the end-points have a common view of the RTCP
bandwidth, this is important as too different view of the bandwidth, this is important as too different view of the
bandwidths may lead to failure to interoperate. bandwidths may lead to failure to interoperate.
These parameters are often expressed in SDP messages conveyed within These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the an offer/answer exchange. RTP does not depend on SDP or on the
offer/answer model, but does require all the necessary parameters to offer/answer model, but does require all the necessary parameters to
be negotiated somehow, and provided to the RTP implementation. be agreed somehow, and provided to the RTP implementation. We note
that in RTCWEB context it will depend on the signalling model and API
how these parameters need to be configured but they will be need to
either set in the API or explicitly signalled between the peers.
2.3. (Lack of) Signalling for Payload Format Changes 2.4. (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.3, 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 is REQUIRED to be prepared to receive data endpoint, that endpoint is REQUIRED to be prepared to receive data
encoded in any of those formats at any time. RTP does not require encoded in any of those formats at any time. RTP does not require
advance signalling for changes between formats that were signalled advance signalling for changes between formats that were signalled
during the session setup. This is needed for rapid rate adaptation. during the session setup. This is needed for rapid rate adaptation.
3. RTP Profile 3. RTP Session Multiplexing
This section explores a few different possible solutions for how to
achieve explicit multiplexing between RTP sessions and possible other
UDP based flows, such as STUN and protocols carrying application
data. But before diving into the proposals we should consider a bit
what requirements we can derive from the previous discussion and the
intended goals.
General Requirements for this multiplexing solution as we understand
them are:
On top of a single flow: To get the full set of benefits of reducing
the number of transport flows between two peers one should be able
to multiplex all peer traffic from one application instance over a
single transport flow.
On top of UDP: The primary transport protocol that meets real-time
requirements and has reasonable NAT/FW traversal properties are
UDP. So the solution are REQUIRED to work over this.
Fallback Protocol: If UDP fails to traverse the NAT/FW including
using TURN when available a fallback option has been discussed.
This would be WebSocket [I-D.ietf-hybi-thewebsocketprotocol] or
over HTTP(S) [RFC2616]. Over HTTP one likely need to consider the
media stream as parts of a unknown length binary object and thus
provide framing and multiplexing between what would be sent as
individual IP packets. WebSocket provides framing, but here
multiplexing is needed.
Protocols to Multiplex: The protocols that need to be multiplexed
over this lower layer transport are:
1. STUN [RFC5389] or something similar to enable the ICE-like
connectivity checks [RFC5245] to be performed.
2. RTP Sessions: One or more for each media type (audio and
video) that the application desires to setup. For example we
may need more than one RTP session to allow easy separation of
video streams showing the person speaking and a slide video
stream. There has also been proposal for supporting
simulcasting to enable non-transcoding centralised
conferencing.
3. DTLS-SRTP or ZRTP are two proposals for how to do key-
management for SRTP. Both are in-band key-management schemes
that will be sent on the same flow as SRTP will be sent as
soon as the key-management has completed. Thus they must also
successfully be multiplexed. In addition there is a question
if each RTP session needs its own keying context, then also
the different DTLS handshakes needs to be separated.
4. Protocols for non-RTP media data. Such protocols provide a
datagram service to the application that is congestion
controlled and secured. The exact protocol is not yet
decided. For securing this DTLS is a likely candidate,
however the order of the protocols are not clear. If it is
foo over DTLS or DTLS over foo is yet to be decided.
5. Reliable Data transmission protocol. There has been some
interest for a reliable data transport between the peer. It
is uncertain if this is going to be defined from the start,
later or not at all.
Please keep these general requirements in mind when we look at some
possible solutions.
3.1. DCCP Based Solution
The most reasonable approach is to use DCCP as common multiplexing
layer, at least for RTP and non-RTP data and use DCCP's function for
congestion control in both cases. This would result in a stack
picture that looks like this:
+-------------+------+
| Media | FOO |
+------+------+ | +
| SRTP | DTLS | DTLS |
+------+------+------+------+
| STUN | DCCP |
+------+--------------------+
| UDP |
+---------------------------+
RTP and Data on top of DCCP
STUN and DCCP can be demultiplexed simply as long as the DCCP source
port are in the range 16384-65535. The great benefit of this
solution is that it can support large number of parallel explicitly
multiplexed datagram flows. Another great benefit is a common place
for congestion control implementation for both RTP and non-RTP data.
It also provides a negotiation mechanism for transport features,
including congestion control algorithms, enabling future development
of this layer.
The above leaves out the question of a reliable transport solution.
This can be done in two major ways as far as we can see. Either
build reliability extensions on top of DCCP or put a protocol in
parallel with STUN and DCCP. The downside with the latter is that we
again end up in a situation where we have several protocols that can
occur in the outer UDP payload requiring implicit demultiplexing
based on actual data, rather than on a field. As DCCP has a
negotiation mechanism for both what service that uses DCCP and DCCP
options and features both becomes viable methods for defining
reliability extensions.
Note: that the main reason not also putting STUN on top of DCCP is
the fact that DCCP do require a handshake on transport parameters
when establishing a new flow. Thus performing that negotiation prior
to doing verification of connection increase both the amount of data
that will be transmitted to a not yet consenting peer and the the
increased delay.
3.2. SHIM layer
A very straightforward design would be adding a one or two byte shim
layer on top of the transport payload prior to the actual multiplexed
protocols. This allows both for static assignment of shim code-
points like for STUN and for dynamically agreed on usages, either
explicitly through signalling or implicitly by application context.
+-------------+------+
| Media | DTLS |
+------+------+------+------+
| STUN | SRTP | DTLS | FOO |
+------+------+------+------+
| SHIM |
+---------------------------+
| UDP |
+---------------------------+
Using a SHIM layer on top of UDP
The Internet Draft "RTC-Web Non-Media Data Transport Requirements"
[I-D.cbran-rtcweb-data] dismisses the idea of a generic SHIM layer
for a number of reasons:
Breaking interoperability with existing inspection gear: The authors
of [I-D.cbran-rtcweb-data] point out the need for recognising the
specific SSRC for recognising the special magic cookie. A device
upgraded to perform this kind of a matching could also be modified
to inspect a SHIM layer. Assuming that a SHIM layer will be
introduced in the IETF anyway, it appears more beneficial to have
a single upgrade to networking gear capable of supporting a set of
protocols than defining application-specific extensions.
Adding complexity through another muxing layer: Removing an extra
fixed size header is trivial. In contrast to SSRC-based
demultiplexing, this could even be easily supported by the
operating system. It should also be noted that both SSRC-based
and SHIM layer-based demultiplexing require all media streams to
terminate within the same application process and hence similar
application-internal mechanisms to forward media data to the
correct media engine for processing. It is thus hard to see the
"adding complexity" reasoning.
Increase packet overhead further: A reasonably designed SHIM layer
would only add a few bytes of overhead. Given that the entire
discussion is motivated by audio/video calls and video packets
would dominate a media stream both in number and in size, the
relative overhead is minimal and the point appear moot.
Shim is a mistake which cannot be undone later: One can argue the
same for overloading the SSRC identifier space. SHIM layers have
repeatedly been discussed in the IETF because new protocols, such
as DCCP and SCTP, face deployment problems in the real-world
Internet as they use previously unknown IP protocol numbers. The
only issue is that the IETF has not yet decided on a (common) SHIM
layer. And if the shim layer is explicitly signalled and there
exist fallback solution to using separate UDP flows, then it can
in fact be undone.
A shim layer has low overhead combined with explicitness and great
flexibility on what to put on top. In addition to definition of the
shim itself some signalling will needed, either explicit or implicit
depending on how the signalling model and the API. The signalling
needs to assign meaning to what a particular multiplexing code-point
means in the particular underlying transport flow.
Although a reliable protocol isn't included in the above example it
can easily be included and be anything that can put in a UDP payload
such as TCP, RMT based, home grown. Thus ensuring maximum
flexibility to add additional protocols on top of the single UDP
flow.
3.3. RTP Internal Multiplexing
The main point with RTP internal multiplexing is to enable
multiplexing RTP sessions without adding any extra layer between the
RTP header and the lower transport, e.g. single UDP flow, that things
are multiplex on. Rosenberg [I-D.rosenberg-rtcweb-rtpmux] suggests
one method for RTP Internal Multiplexing. In addition to this there
are suggestion in "RTC-Web Non-Media Data Transport Requirements"
[I-D.cbran-rtcweb-data] to multiplex also the non-RTP data on the
same level using implicit identification of data packets that
separate them from DTLS-SRTP packets, RTP/RTCP packets and STUN
packets. This results in a stack picture that looks like this:
+-------------+------+
| Media | DTLS |
+------+------+------+------+
| STUN | SRTP | DTLS | FOO |
+------+------+------+------+
| UDP |
+---------------------------+
RTP Internal Multiplexing
Where Foo is the protocol suggested by "RTC-Web Non-Media Data
Transport Requirements" [I-D.cbran-rtcweb-data].
These proposals rely on the idea that a receiver can look at a number
of the bytes of the UDP payload to identify the type of packet. So
assuming DTLS-SRTP key management and a datagram non-RTP data
transport we have at least four protocols to separate. If one have
successfully identified the protocol as (S)RTP then one looks at the
SSRC field to find out media type and stream IDs.
There are a number of issues with the current proposals which we will
raise below. We also discuss what is going to be needed to drive
this work.
3.3.1. Issues with SSRC RTP Multiplexing
The first argument against this design is that it further
proliferates this bad design of implicit packet identification that
started with STUN. And instead of trying to break out of this
pattern we appear to pile on more protocols that is supposed to
identified despite that all these protocols actually have protocol
fields that have a purpose in these overlapping bytes that we attempt
to perform identification in. At some point a protocol extension in
either of the protocols will result in a collision breaking the
demultiplexing mechanism.
Secondly, the design restricts RTCWEB to a subset of RTP
functionality. By redefining the SSRC field this creates in practice
an alternative RTP protocol that can't fully interoperate with RTP as
currently defined. The inclusion of a magic word that allows Deep
Packet Inspection and other interpreters to commonly identify the
versions correctly is a clear admission to this fact, even if not
state explicitly in the text. This new version is forever prevented
from using any of the features that has been identified as not being
compatible with this design. In addition it either forces future RTP
extensions to take this severe limitation in into account or create
additional extensions that are not compatible. Forking the RTP
protocol into two versions is really not desirable.
Thirdly, a significantly limited size stream ID field requires
someone to manage and ensure that unique stream IDs are used by each
end-point. This would not be an issue if the only use case ever
would be communication between two end-points. However, we at this
point have use cases and requirements for centralised conferencing
scenarios. Even a basic star scenario requires extra complexities as
the central node needs to be able to force the node that aren't at
the centre to use the IDs that the central node dictates. This usage
then becomes much more complex at the very moment someone attempts to
interconnect two stars. This is in fact likely to happen when one
needs either scalability or geographical optimisation. With
geographical optimisation I mean one entity in Asia and one in Africa
that performs media mixing or transport relaying to reduce the delay
and traffic load. In addition to the centralised conferencing usage,
it looks plausible that RTCWEB could allow for an ad-hoc conferencing
mesh. Without a central point beyond the web server, only the web
server could ensure the uniqueness requirements. All of the above
cases is easily handled by regular RTP without any control at all.
Showing that this proposal brings extra complexities.
Fourth, if any legacy interoperation is considered one should be
aware that it occurs that the same SSRC value is used in different
RTP session in the same communication session. Commonly for
providing quick association of media streams in the different
sessions, sometime due to implementation choices, and sometime due to
that an extension requires this, like the session mode of RTP
retransmission [RFC4588].
Fifth, there is a need to support more than a single session context
per media type. As shown in "RTP Multiple Stream Sessions and
Simulcast" [I-D.westerlund-avtcore-multistream-and-simulcast] there
are clear benefits in using multiple RTP sessions for separating
intent with different media streams. This is already occurring in
video conferencing to separate main video (e.g. active speaker) from
alternative video (e.g. non-active speaker, audience) and document or
slide video streams. We will not deny that the web server could
track the flows and their purpose through other mechanisms and
signalling channels. However, it complicates any interop with legacy
and forces more functionality and additional APIs into any gateway
function.
3.3.2. Executing on this Proposal
If RTCWEB WG decides that despite the issues associated with RTP
internal multiplexing wants to pursue this approach the WG needs to
be aware that this WG doesn't have the right to redefine RTP
semantics. The IETF has an active WG chartered for maintaining and
extending RTP in the AVTCORE WG, and proposal for change needs to be
handled in that WG. This means that all RTCWEB WG can do for the RTP
multiplexing part is to provide requirements to AVTCORE. The WG
participants would then be encouraged to engage in proposing and be
proponents for the work in the AVTCORE WG.
Considering that not only RTCWEB is has voiced the need for a
multiplexing solution and that this likely have significant impact on
RTP for the future, any proposal for a solution needs to be generally
applicable. For example most of the arguments dismissed in
"Multiplexing of Real-Time Transport Protocol (RTP) Traffic for
Browser based Real-Time Communications (RTC)"
[I-D.rosenberg-rtcweb-rtpmux] as not being applicable for RTCWEB will
need to be reconsidered in the light of more general applications.
So some requirements on this solution are from the authors of this
draft:
1. Possible to multiplex more than a single RTP session of the same
media type.
2. Be possible to use all relevant RTP/RTCP extensions and RTP
payload formats.
3. Be possible to use a particular SSRC value in more than a single
RTP session simultaneously.
4. Be possible to interconnect through a gateway the RTP sessions
that are multiplexed on a single transport flow back to using
multiple transport flows to a legacy end-point otherwise
supporting the applications RTP configuration. This should
preferably done with minimal state, especially avoid per SSRC
state.
3.4. Conclusion
Looking at these proposals we authors are clearly in favour of a shim
layer unless DCCP is being selected anyway as datagram or media
transport protocol which in case one should strongly consider having
both data and media over the same protocol to enable that it is used
as multiplexing layer.
We don't see RTP internal as a realistic contender for the first
phase of RTCWEB specifications. It has documented issues. The only
way forward for the WG is to develop requirements for what RTCWEB
needs and share these with AVTCORE. If there are proponents for
driving a solution, they take the design of a generalised protocol in
AVTCORE that takes into consideration the existing specification. It
might find a suitable solution, it may not. When this is done we
might have something stable to start deploying in two years from now
or the WG has decided to drop the work as non feasible.
4. RTP Profile
The "Extended Secure RTP Profile for Real-time Transport Control The "Extended Secure RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to
be implemented. This builds on the basic RTP/AVP profile [RFC3551], be implemented. This builds on the basic RTP/AVP profile [RFC3551],
the RTP/AVPF feedback profile [RFC4585], and the secure RTP/SAVP the RTP/AVPF feedback profile [RFC4585], and the secure RTP/SAVP
profile [RFC3711]. profile [RFC3711].
The RTP/AVPF part of RTP/SAVPF is required to get the improved RTCP The RTP/AVPF part of RTP/SAVPF is required to get the improved RTCP
timer model, that allows more flexible transmission of RTCP packets timer model, that allows more flexible transmission of RTCP packets
in 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 use the full
full amount when there is a lot of events on which to send feedback. amount when there is a lot of events on which to send feedback. This
This functionality is needed to make use of the RTP conferencing functionality is needed to make use of the RTP conferencing
extensions discussed in Section 6.1. extensions discussed in Section 7.1.
The RTP/SAVP part of RTP/SAVPF is for support for Secure RTP (SRTP) The RTP/SAVP part of RTP/SAVPF is for support for Secure RTP (SRTP)
[RFC3711]. This provides media encryption, integrity protection, [RFC3711]. This provides media encryption, integrity protection,
replay protection and a limited form of source authentication. It replay protection and a limited form of source authentication. It
does not contain a specific keying mechanism, so that, and the set of does not contain a specific keying mechanism, so that, and the set of
security transforms, will be required to be chosen. It is possible security transforms, will be required to be chosen. It is possible
that a security mechanism operating on a lower layer than RTP can be that a security mechanism operating on a lower layer than RTP can be
used instead and that should be evaluated. However, the reasons for used instead and that should be evaluated. However, the reasons for
the design of SRTP should be taken into consideration in that the design of SRTP should be taken into consideration in that
discussion. discussion.
4. RTP and RTCP Guidelines 5. 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.
Different informational documents provide guidelines to the use and Different informational documents provide guidelines to the use and
particularly the extension of RTP and RTCP, including the following: particularly the extension of RTP and RTCP, including the following:
Guidelines for Writers of RTP Payload Format Specifications [RFC2736] Guidelines for Writers of RTP Payload Format Specifications [RFC2736]
and Guidelines for Extending the RTP Control Protocol [RFC5968]. and Guidelines for Extending the RTP Control Protocol [RFC5968].
5. RTP Optimizations 6. RTP Optimisations
This section discusses some optimizations that makes RTP/RTCP work This section discusses some optimisations 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 6.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, Supporting this specification is generally a simplification in code,
since it relaxes the tests in [RFC3550]. 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 6.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
packet. However, especially when using frequent feedback messages, packet. However, especially when using frequent feedback messages,
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. Supporting them to adapt their transmission and encoding behaviour.
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 6.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 The reasons for using symmetric RTP is primarily to avoid issues with
NAT and Firewalls by ensuring that the flow is actually bi- NAT and Firewalls by ensuring that the flow is actually bi-
directional and thus kept alive and registred as flow the intended directional and thus kept alive and registered as flow the intended
recipient actually wants. In addition it saves resources in the form 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 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 or firewall state is not unnecessary bloated. Also the number of QoS
state are reduced. state are reduced.
Using Symmetric RTP and RTCP [RFC4961] is REQURIED. Using Symmetric RTP and RTCP [RFC4961] is REQUIRED.
5.4. Generation of the RTCP Canonical Name (CNAME) 6.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 Synchronisation 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 among the participants of
of an RTP session. 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 a short-term persistent RTCP CNAMEs following method (b)
Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is as specified in Section 4.2 of "Guidelines for Choosing RTP Control
RECOMMENDED, since this addresses both concerns. Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is RECOMMENDED,
since this addresses both concerns.
6. RTP Extensions 7. 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 7.1. RTP Conferencing Extensions
RTP is inherently defined for group communications, whether using IP RTP is inherently defined for group communications, whether using IP
multicast, multi-unicast, or based on a centralised server. In multicast, multi-unicast, or based on a centralised server. In
today's practice, however, overlay-based conferencing dominates, today's practice, however, overlay-based conferencing dominates,
typically using one or a few so-called conference bridges or servers typically using one or a few so-called conference bridges or servers
to connect endpoints in a star or flat tree topology. Quite diverse to connect endpoints in a star or flat tree topology. Quite diverse
conferencing topologies can be created using the basic elements of conferencing topologies can be created using the basic elements of
RTP mixers and translators 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
skipping to change at page 13, line 22 skipping to change at page 26, line 46
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 We note that 3 and 4 are not well utilising the functions of RTP and
in some cases even violates the RTP specifications. Thus we in some cases even violates the RTP specifications. Thus we
recommend that one focus on 1 and 2. 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 centralised
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 the Extended RTP Profile participants. These messages are defined in the Extended RTP Profile
for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio-
Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully
usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124].
6.1.1. RTCP Feedback Message: Full Intra Request 7.1.1. RTCP Feedback Message: Full Intra Request
The Full Intra Request is defined in Sections 3.5.1 and 4.3.1 of CCM 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 a session
distributed session participants a new Intra picture. This is used participants a new Intra picture. This is used when switching
when switching between sources to ensure that the receivers can between sources to ensure that the receivers can decode the video or
decode the video or other predicted media encoding with long other predicted media encoding with long prediction chains. It is
prediction chains. It is RECOMMENDED that this feedback message is RECOMMENDED that this feedback message is supported.
supported.
6.1.2. RTCP Feedback Message: Picture Loss Indicator 7.1.2. RTCP Feedback Message: Picture Loss Indicator
The Picture Loss Indicator is defined in Section 6.3.1 of AVPF The Picture Loss Indicator is defined in Section 6.3.1 of AVPF
[RFC4585]. It is used by a receiver to tell the encoder that it lost [RFC4585]. It is used by a receiver to tell the encoder that it lost
the decoder context and would like to have it repaired somehow. This the decoder context and would like to have it repaired somehow. This
is semantically different from 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 as a loss RECOMMENDED that this feedback message is supported as a loss
tolerance mechanism. tolerance mechanism.
6.1.3. RTCP Feedback Message: Temporary Maximum Media Stream Bit Rate 7.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 CCM 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 7.2. RTP Header Extensions
The RTP specification [RFC3550] provides a capability to extend the The RTP specification [RFC3550] provides a capability to extend the
RTP header with in-band data, but the format and semantics of the RTP header with in-band data, but the format and semantics of the
extensions are poorly specified. Accordingly, if header extensions extensions are poorly specified. Accordingly, if header extensions
are to be used, it is REQUIRED that they be formatted and signalled are to be used, it is REQUIRED that they be formatted and signalled
according to the general mechanism of RTP header extensions defined according to the general mechanism of RTP header extensions defined
in [RFC5285]. in [RFC5285].
As noted in [RFC5285], the requirement from the RTP specification As noted in [RFC5285], the requirement from the RTP specification
that header extensions are "designed so that the header extension may that header extensions are "designed so that the header extension may
be ignored" [RFC3550] stands. To be specific, header extensions must be ignored" [RFC3550] stands. To be specific, header extensions must
only be used for data that can safely be ignored by the recipient only be used for data that can safely be ignored by the recipient
without affecting interoperability, and must not be used when the without affecting interoperability, and must not be used when the
presence of the extension has changed the form or nature of the rest presence of the extension has changed the form or nature of the rest
of the packet in a way that is not compatible with the way the stream of the packet in a way that is not compatible with the way the stream
is signaled (e.g., as defined by the payload type). Valid examples is signalled (e.g., as defined by the payload type). Valid examples
might include metadata that is additional to the usual RTP might include metadata that is additional to the usual RTP
information. information.
The RTP rapid synchronisation header extension is recommended, as The RTP rapid synchronisation header extension [RFC6051] is
discussed in Section 6.3. recommended, as discussed in Section 7.3 we also recommend the client
to mixer audio level [I-D.ietf-avtext-client-to-mixer-audio-level],
and consider the mixer to client audio level
[I-D.ietf-avtext-mixer-to-client-audio-level] as optional feature.
Currently no other header extensions are recommended. But we do Currently the other header extensions are not recommended to be
include a list of the available ones for consideration below: included at this time. But we do include a list of the available
ones for information below:
Transmission Time offsets: [RFC5450] defines a format for including Transmission Time offsets: [RFC5450] defines a format for including
an RTP timestamp offset of the actual transmission time of the RTP an RTP timestamp offset of the actual transmission time of the RTP
packet in relation to capture/display timestamp present in the RTP packet in relation to capture/display timestamp present in the RTP
header. This can be used to improve jitter determination and header. This can be used to improve jitter determination and
buffer management. buffer management.
Associating Time-Codes with RTP Streams: [RFC5484] defines how to Associating Time-Codes with RTP Streams: [RFC5484] defines how to
associate SMPTE times codes with the RTP streams. associate SMPTE times codes with the RTP streams.
Audio Levels indications: There is ongoing work to define RTP header 7.3. Rapid Synchronisation Extensions
extensions for providing audio levels both from a media sender to
an mixer [I-D.ietf-avtext-client-to-mixer-audio-level], and from a
mixer to a receiver[I-D.ietf-avtext-mixer-to-client-audio-level].
6.3. Rapid Synchronisation Extensions
Many RTP sessions require synchronisation between audio, video, and Many RTP sessions require synchronisation between audio, video, and
other content. This synchronisation is performed by receivers, using other content. This synchronisation is performed by receivers, using
information contained in RTCP SR packets, as described in the RTP information contained in RTCP SR packets, as described in the RTP
specification [RFC3550]. This basic mechanism can be slow, however, specification [RFC3550]. This basic mechanism can be slow, however,
so it is RECOMMENDED that the rapid RTP synchronisation extensions so it is RECOMMENDED that the rapid RTP synchronisation extensions
described in [RFC6051] be implemented. The rapid synchronisation described in [RFC6051] be implemented. The rapid synchronisation
extensions use the general RTP header extension mechanism [RFC5285], extensions use the general RTP header extension mechanism [RFC5285],
which requires signalling, but are otherwise backwards compatible. which requires signalling, but are otherwise backwards compatible.
7. Improving RTP Transport Robustness 7.4. Client to Mixer Audio Level
There are some tools that can robustify RTP flows against Packet loss The Client to Mixer Audio Level
and reduce the impact on media quality. However they all add extra [I-D.ietf-avtext-client-to-mixer-audio-level] is an RTP header
bits compared to a non-robustified stream. These extra bits needs to extension used by a client to inform a mixer about the level of audio
be considered and the aggregate bit-rate needs to be rate controlled. activity in the packet the header is attached to. This enables a
Thus robustification might require a lower base encoding quality but central node to make mixing or selection decisions without decoding
has the potential to give that quality with fewer errors in it. or detailed inspection of the payload. Thus reducing the needed
complexity in some types of central RTP nodes.
7.1. RTP Retransmission Assuming that the Client to Mixer Audio Level
[I-D.ietf-avtext-client-to-mixer-audio-level] is published as a
finished specification prior to RTCWEB's first RTP specification then
it is RECOMMENDED that this extension is included.
7.5. Mixer to Client Audio Level
The Mixer to Client Audio Level header extension
[I-D.ietf-avtext-mixer-to-client-audio-level] provides the client
with the audio level of the different sources mixed into a common mix
from the RTP mixer. Thus enabling a user interface to indicate the
relative activity level of a session participant, rather than just
being included or not based on the CSRC field. This is a pure
optimisations of non critical functions and thus optional
functionality.
Assuming that the Mixer to Client Audio Level
[I-D.ietf-avtext-client-to-mixer-audio-level] is published as a
finished specification prior to RTCWEB's first RTP specification then
it is OPTIONAL that this extension is included.
8. Improving RTP Transport Robustness
There are some tools that can make RTP flows robust against Packet
loss and reduce the impact on media quality. However they all add
extra bits compared to a non-robust stream. These extra bits needs
to be considered and the aggregate bit-rate needs to be rate
controlled. Thus improving robustness might require a lower base
encoding quality but has the potential to give that quality with
fewer errors in it.
8.1. RTP Retransmission
Support for RTP retransmission as defined by "RTP Retransmission Support for RTP retransmission as defined by "RTP Retransmission
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 prioritise 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 (FEC) "RTC-Web Media Transport Requirements" [I-D.cbran-rtcweb-data] raises
two issues that they think makes RTP Retransmission unsuitable for
RTCWEB. We here consider these issues and explain why they are in
fact not a reason to exclude RTP retransmission from the tool box
available to RTCWEB media sessions.
The additional latency added by [RFC4588] will exceed the latency
threshold for interactive voice and video: RTP Retransmission will
require at least one round trip time for a retransmission request
and repair packet to arrive. Thus the general suitability of
using retransmissions will depend on the actual network path
latency between the end-points. In many of the actual usages the
latency between two end-points will be low enough for RTP
retransmission to be effective. Interactive communication with
end-to-end delays of 400 ms still provide a fair quality. Even
removing half of that in end-point delays allows functional
retransmission between end-points on the continent. In addition
in some applications one may accept temporary delay spikes to
allow for retransmission of crucial codec information such an
parameter sets, intra picture etc, rather than getting no media at
all.
The undesirable increase in packet transmission at the point when
congestion occurs: Congestion loss will impact the rate controls
view of available bit-rate for transmission. When using
retransmission one will have to prioritise between performing
retransmissions and the quality one can achieve with ones
adaptable codecs. In many use cases one prefer error free or low
rates of error with reduced base quality over high degrees of
error at a higher base quality.
The RTCWEB end-point implementations will need to both select when to
enable RTP retransmissions based on API settings and measurements of
the actual round trip time. In addition for each NACK request that a
media sender receives it will need to make a prioritisation based on
the importance of the requested media, the probability that the
packet will reach the receiver in time for being usable, the
consumption of available bit-rate and the impact of the media quality
for new encodings.
To conclude, the issues raised are implementation concerns that an
implementation needs to take into consideration, they are not
arguments against including a highly versatile and efficient packet
loss repair mechanism.
8.2. Forward Error Correction (FEC)
Support of some type of FEC to combat the effects of packet loss is Support of some type of FEC to combat the effects of packet loss is
beneficial, but is heavily application dependent. However, some FEC beneficial, but is heavily application dependent. However, some FEC
mechanisms are encumbered. mechanisms are encumbered.
(tbd: add further discussion here) The main benefit from FEC is the relatively low additional delay
needed to protect against packet losses. The transmission of any
repair packets should preferably be done with a time delay that is
just larger than any loss events normally encountered. That way the
repair packet isn't also lost in the same event as the source data.
8. RTP Rate Control and Media Adaptation The amount of repair packets needed are also highly dynamically and
depends on two main factors, the amount and pattern of lost packets
to be recovered and the mechanism one use to derive repair data. The
later choice also effects the the additional delay required to both
encode the repair packets and in the receiver to be able to recover
the lost packet(s).
8.2.1. Basic Redundancy
The method for providing basic redundancy is to simply retransmit an
some time earlier sent packet. This is relatively simple in theory,
i.e. one saves any outgoing source (original) packet in a buffer
marked with a timestamp of actual transmission, some X ms later one
transmit this packet again. Where X is selected to be longer than
the common loss events. Thus any loss events shorter than X can be
recovered assuming that one doesn't get an another loss event before
all the packets lost in the first event has been received.
The downside of basic redundancy is the overhead. To provide each
packet with once chance of recovery, then the transmission rate
increases with 100% as one needs to send each packet twice. It is
possible to only redundantly send really important packets thus
reducing the overhead below 100% for some other trade-off is
overhead.
In addition the basic retransmission of the same packet using the
same SSRC in the same RTP session is not possible in RTP context.
The reason is that one would then destroy the RTCP reporting if one
sends the same packet twice with the same sequence number. Thus one
needs more elaborate mechanisms.
RTP Payload for Redundant Audio Data: This audio and text redundancy
format defined in [RFC2198] allows for multiple levels of
redundancy with different delay in their transmissions, as long as
the source plus payload parts to be redundantly transmitted
together fits into one MTU. This should work fine for most
interactive use cases as both the codec bit-rates and the framing
intervals normally allow for this requirement to hold. This
payload format also don't increase the packet rate, as original
data and redundant data are sent together. This format does not
allow perfect recovery, only recovery of information deemed
necessary for audio, for example the sequence number of the
original data is lost.
RTP Retransmission Format: The RTP Retransmission Payload format
[RFC4588] can be used to pro-actively send redundant packets using
either SSRC or session multiplexing. By using different SSRCs or
a different session for the redundant packets the RTCP receiver
reports will be correct. The retransmission payload format is
used to recover the packets original data thus enabling a perfect
recovery.
Duplication Grouping Semantics in the Session Description Protocol:
This [I-D.begen-mmusic-redundancy-grouping] is proposal for new
SDP signalling to indicate media stream duplication using
different RTP sessions, or different SSRCs to separate the source
and the redundant copy of the stream.
8.2.2. Block Based
Block based redundancy collects a number of source packets into a
data block for processing. The processing results in some number of
repair packets that is then transmitted to the other end allowing the
receiver to attempt to recover some number of lost packets in the
block. The benefit of block based approaches is the overhead which
can be lower than 100% and still recover one or more lost source
packet from the block. The optimal block codes allows for each
received repair packet to repair a single loss within the block.
Thus 3 repair packets that are received should allow for any set of 3
packets within the block to be recovered. In reality one commonly
don't reach this level of performance for any block sizes and number
of repair packets, and taking the computational complexity into
account there are even more trade-offs to make among the codes.
One result of the block based approach is the extra delay, as one
needs to collect enough data together before being able to calculate
the repair packets. In addition sufficient amount of the block needs
to be received prior to recovery. Thus additional delay are added on
both sending and receiving side to ensure possibility to recover any
packet within the block.
The redundancy overhead and the transmission pattern of source and
repair data can be altered from block to block, thus allowing a
adaptive process adjusting to meet the actual amount of loss seen on
the network path and reported in RTCP.
The alternatives that exist for block based FEC with RTP are the
following:
RTP Payload Format for Generic Forward Error Correction: This RTP
payload format [RFC5109] defines an XOR based recovery packet.
This is the simplest processing wise that an block based FEC
scheme can be. It also results in some limited properties, as
each repair packet can only repair a single loss. To handle
multiple close losses a scheme of hierarchical encodings are need.
Thus increasing the overhead significantly.
Forward Error Correction (FEC) Framework: This framework
[I-D.ietf-fecframe-framework] defines how not only RTP packets but
how arbitrary packet flows can be protected. Some solutions
produced or under development in FECFRAME WG are RTP specific.
There exist alternatives supporting block codes such as Reed-
Salomon and Raptor.
8.2.3. Recommendations for FEC
(tbd)
9. 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, and maintain the user experience in the presence of network friendly, and maintain the user experience in the presence of network
problems. problems.
The biggest issue is that there are no standardized and ready to use The biggest issue is that there are no standardised 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 10. 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 11. IANA Considerations
This memo 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 12. 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 use 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 memo, 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 13. Acknowledgements
13. References 14. References
13.1. Normative References 14.1. Normative References
[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-03 (work in
progress), February 2011. progress), July 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-
Client Audio Level Indication", Client Audio Level Indication",
draft-ietf-avtext-mixer-to-client-audio-level-00 (work in draft-ietf-avtext-mixer-to-client-audio-level-03 (work in
progress), February 2011. progress), July 2011.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format [I-D.ietf-avtext-multiple-clock-rates]
for Generic Forward Error Correction", RFC 2733, Petit-Huguenin, M., "Support for multiple clock rates in
December 1999. an RTP session", draft-ietf-avtext-multiple-clock-rates-00
(work in progress), June 2011.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, Payload Format Specifications", BCP 36, RFC 2736,
December 1999. December 1999.
[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, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
skipping to change at page 18, line 27 skipping to change at page 35, line 49
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[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.
[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, February 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009. RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
RFC 5484, March 2009. RFC 5484, March 2009.
[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.
[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
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 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011. (CNAMEs)", RFC 6222, April 2011.
13.2. Informative References 14.2. Informative References
[I-D.begen-mmusic-redundancy-grouping]
Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
Semantics in the Session Description Protocol",
draft-begen-mmusic-redundancy-grouping-01 (work in
progress), June 2011.
[I-D.cbran-rtcweb-data]
Bran, C. and C. Jennings, "RTC-Web Non-Media Data
Transport Requirements", draft-cbran-rtcweb-data-00 (work
in progress), July 2011.
[I-D.ietf-fecframe-framework]
Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework",
draft-ietf-fecframe-framework-15 (work in progress),
June 2011.
[I-D.ietf-hybi-thewebsocketprotocol]
Fette, I. and A. Melnikov, "The WebSocket protocol",
draft-ietf-hybi-thewebsocketprotocol-10 (work in
progress), July 2011.
[I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
Rescorla, E., and T. Terriberry, "Multiplexing of Real-
Time Transport Protocol (RTP) Traffic for Browser based
Real-Time Communications (RTC)",
draft-rosenberg-rtcweb-rtpmux-00 (work in progress),
July 2011.
[I-D.westerlund-avtcore-multistream-and-simulcast]
Westerlund, M. and B. Burman, "RTP Multiple Stream
Sessions and Simulcast",
draft-westerlund-avtcore-multistream-and-simulcast-00
(work in progress), July 2011.
[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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733,
December 1999.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010.
[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.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
 End of changes. 84 change blocks. 
216 lines changed or deleted 1076 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/