draft-ietf-rtcweb-rtp-usage-00.txt   draft-ietf-rtcweb-rtp-usage-01.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: March 17, 2012 Ericsson Expires: May 3, 2012 Ericsson
J. Ott J. Ott
Aalto University Aalto University
September 14, 2011 October 31, 2011
RTP Requirements for RTC-Web Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
draft-ietf-rtcweb-rtp-usage-00 draft-ietf-rtcweb-rtp-usage-01
Abstract Abstract
This memo discusses use of RTP in the context of the RTC-Web The Web Real-Time Communication (WebRTC) framework aims to provide
activity. It discusses important features of RTP that need to be support for direct interactive rich communication using audio, video,
considered by other parts of the RTC-Web framework, describes which collaboration, games, etc. between two peers' web-browsers. This
RTP profile to use in this environment, and outlines what RTP memo describes the media transport aspects of the WebRTC framework.
extensions should be supported. It specifies how the Real-time Transport Protocol (RTP) is used in
the WebRTC context, and gives requirements for which RTP features,
This document is a candidate to become a work item of the RTCWEB profiles, and extensions need to be supported.
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 March 17, 2012. This Internet-Draft will expire on May 3, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements from RTP . . . . . . . . . . . . . . . . . . . . 6 3. Media Transport in WebRTC . . . . . . . . . . . . . . . . . . 4
2.1. Signalling for RTP sessions . . . . . . . . . . . . . . . 6 3.1. Expected Topologies . . . . . . . . . . . . . . . . . . . 4
2.2. (Lack of) Signalling for Payload Format Changes . . . . . 7 3.2. Requirements from RTP . . . . . . . . . . . . . . . . . . 7
3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Signalling for RTP sessions . . . . . . . . . . . . . 7
4. RTP and RTCP Guidelines . . . . . . . . . . . . . . . . . . . 8 3.2.2. (Lack of) Signalling for Payload Format Changes . . . 8
5. RTP Optimisations . . . . . . . . . . . . . . . . . . . . . . 8 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 8
5.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 8 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 8 4.2. Choice of RTP Profile . . . . . . . . . . . . . . . . . . 9
5.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 9 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 10
5.4. Generation of the RTCP Canonical Name (CNAME) . . . . . . 9 4.4. RTP Session Multiplexing . . . . . . . . . . . . . . . . . 10
6. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 10 5. WebRTC Use of RTP: Optimisations . . . . . . . . . . . . . . . 10
6.1. RTP Conferencing Extensions . . . . . . . . . . . . . . . 10 5.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10
6.1.1. Full Intra Request . . . . . . . . . . . . . . . . . . 11 5.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11
6.1.2. Picture Loss Indication . . . . . . . . . . . . . . . 11 5.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 11
6.1.3. Slice Loss Indication . . . . . . . . . . . . . . . . 11 5.4. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12
6.1.4. Reference Picture Selection Indication . . . . . . . . 11 6. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12
6.1.5. Temporary Maximum Media Stream Bit Rate Request . . . 11 6.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12
6.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 12 6.1.1. Full Intra Request . . . . . . . . . . . . . . . . . . 13
6.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 13 6.1.2. Picture Loss Indication . . . . . . . . . . . . . . . 13
6.4. Client to Mixer Audio Level . . . . . . . . . . . . . . . 13 6.1.3. Slice Loss Indication . . . . . . . . . . . . . . . . 13
6.5. Mixer to Client Audio Level . . . . . . . . . . . . . . . 13 6.1.4. Reference Picture Selection Indication . . . . . . . . 14
7. Improving RTP Transport Robustness . . . . . . . . . . . . . . 13 6.1.5. Temporary Maximum Media Stream Bit Rate Request . . . 14
7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 14 6.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14
7.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 15 6.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 15
7.2.1. Basic Redundancy . . . . . . . . . . . . . . . . . . . 15 6.4. Mixer Audio Level Extensions . . . . . . . . . . . . . . . 15
7.2.2. Block Based . . . . . . . . . . . . . . . . . . . . . 16 6.4.1. Client to Mixer Audio Level . . . . . . . . . . . . . 15
7.2.3. Recommendations for FEC . . . . . . . . . . . . . . . 17 6.4.2. Mixer to Client Audio Level . . . . . . . . . . . . . 15
8. RTP Rate Control and Media Adaptation . . . . . . . . . . . . 17 7. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16
9. RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 18 7.1. Retransmission . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.2.1. Basic Redundancy . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7.2.2. Block Based FEC . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2.3. Recommendations for FEC . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.1. Rate Control Requirements . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. RTCP Limiations . . . . . . . . . . . . . . . . . . . . . 21
8.3. Legacy Interop Limitations . . . . . . . . . . . . . . . . 22
9. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This memo discusses the Real-time Transport Protocol (RTP) [RFC3550] The Real-time Transport Protocol (RTP) [RFC3550] was designed to
in the context of the RTC-Web activity. The work in the IETF Audio/ provide a framework for delivery of audio and video teleconferencing
Video Transport Working Group, and it's successors, has been about data and other real-time media applications. This memo describes how
providing building blocks for real-time multimedia transport, and has RTP is to be used in the context of the Web Real-Time Communication
not specified who should use which building blocks. The selection of (WebRTC) framework, a new activity that aims to provide support for
building blocks and functionalities can really only be done in the direct, interactive, and rich communication using audio, video,
context of some application, for example RTC-Web. We have selected a collaboration, games, etc. between two peers' web-browsers.
set of RTP features and extensions that are suitable for a number of
applications that fit the RTC-Web context. Thus, applications such Previous work in the IETF Audio/Video Transport Working Group, and
as VoIP, audio and video conferencing, and on-demand multimedia it's successors, has been about providing a framework for real-time
streaming are considered. Applications that rely on IP multicast multimedia transport, but has not specified how the pieces of this
have not been considered likely to be applicable to RTC-Web, thus framework should be combined. This is because the choice of building
extensions related to multicast have been excluded. We believe that blocks and protocol features can really only be done in the context
RTC-Web will greatly benefit in interoperability if a reasonable set of some application. This memo proposes a set of RTP features and
of RTP functionalities and extensions are selected. This memo is extensions to be implemented by applications that fit within the
intended as a starting point for discussion of those features in the WebRTC application context. This includes applications such as voice
RTC-Web framework. over IP (VoIP), video teleconferencing, and on-demand multimedia
streaming, delivered in the context of the WebRTC browser-based
infrastructure.
2. Terminology
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 given. 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 WebRTC specification:
REQUIRED: Functionality that is absolutely needed to make the RTC- REQUIRED: Functionality that is absolutely needed to make the WebRTC
Web solution work well, or functionality of low complexity that 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.
OPTIONAL: Something that is useful in some cases, but not always a OPTIONAL: Something that is useful in some cases, but not always a
benefit. benefit.
When this memo discusses RTP, it includes the RTP Control Protocol 3. Media Transport in WebRTC
(RTCP) unless explicitly stated otherwise. RTCP is a fundamental and
integral part of the RTP protocol, and is REQUIRED to be implemented.
1.1. Expected Topologies 3.1. Expected Topologies
As RTC-Web is focused on peer to peer connections established from As WebRTC 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 explained 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
skipping to change at page 4, line 30 skipping to change at page 5, line 32
v v v v
+---+ +---+
| 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 (Figure 2), and is unfortunately not discussed in the RTP
[RFC5117]. This topology has the benefit of not requiring central Topologies [RFC5117]. This topology has the benefit of not requiring
nodes. The downside is that it increases the used bandwidth at each central nodes. The downside is that it increases the used bandwidth
sender by requiring one copy of the media streams for each at each sender by requiring one copy of the media streams for each
participant that are part of the same session beyond the sender participant that are part of the same session beyond the sender
itself. Thus this is limited to scenarios with few end-points unless itself. Thus this is limited to scenarios with few end-points unless
the media is very low bandwidth. the media is very low bandwidth.
It needs to be noted that, if this topology is to be supported by the This topology may be implemented as a single RTP session, spanning
RTC-Web framework, it needs to be possible to connect one RTP session multiple peer to peer transport layer connections, or as several
to multiple established peer to peer flows that are individually pairwise RTP sessions, one between each pair of peers. The later
established. approach simplifies rate adaptation, but reduces the effectiveness of
RTCP for debugging purposes, by limiting the ability to send third-
party RTCP reports.
+---+ +------------+ +---+ +---+ +------------+ +---+
| 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
skipping to change at page 5, line 44 skipping to change at page 7, line 6
| | | |
+---+ | | +---+ +---+ | | +---+
| 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 fulfil the requirements of To support legacy end-point (B) that don't fulfil the requirements of
RTC-Web it is possible to insert a Translator (Figure 5) that takes WebRTC it is possible to insert a Translator (Figure 5) that takes on
on the role to ensure that from A's perspective B looks like a fully the role to ensure that from A's perspective B looks like a fully
compliant end-point. Thus it is the combination of the Translator compliant end-point. Thus it is the combination of the Translator
and B that looks like the end-point B. The intention is that the and B that looks like the end-point B. The intention is that the
presence of the translator is transparent to A, however it is not presence of the translator is transparent to A, however it is not
certain that is possible. Thus this case is include so that it can certain that is possible. Thus this case is include so that it can
be discussed if any mechanism specified to be used for RTC-Web be discussed if any mechanism specified to be used for WebRTC results
results in such issues and how to handle them. in such issues and how to handle them.
2. Requirements from RTP 3.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. Signalling for RTP sessions 3.2.1. 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 transformation 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 (see
Section 5.1). If several RTP sessions are to be multiplexed onto
a single transport layer flow, this MUST also be signalled (see
Section 4.4).
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 intends to use need to be RTP Extensions: The RTP extensions one intends to use need to be
agreed upon, including any parameters for each respective agreed upon, including any parameters for each respective
skipping to change at page 7, line 11 skipping to change at page 8, line 28
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 agreed somehow, and provided to the RTP implementation. We note be agreed somehow, and provided to the RTP implementation. We note
that in RTCWEB context it will depend on the signalling model and API 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 how these parameters need to be configured but they will be need to
either set in the API or explicitly signalled between the peers. either set in the API or explicitly signalled between the peers.
2.2. (Lack of) Signalling for Payload Format Changes 3.2.2. (Lack of) Signalling for Payload Format Changes
As discussed in Section 2.1, the mapping between media type name, and As discussed in Section 3.2.1, the mapping between media type name,
its associated RTP payload format, and the RTP payload type number to and its associated RTP payload format, and the RTP payload type
be used for that format must be signalled as part of the session number to be used for that format must be signalled as part of the
setup. An endpoint may signal support for multiple media formats, or session setup. An endpoint may signal support for multiple media
multiple configurations of a single format, each using a different formats, or multiple configurations of a single format, each using a
RTP payload type number. If multiple formats are signalled by an different RTP payload type number. If multiple formats are signalled
endpoint, that endpoint is REQUIRED to be prepared to receive data by an endpoint, that endpoint is REQUIRED to be prepared to receive
encoded in any of those formats at any time. RTP does not require data encoded in any of those formats at any time (this is slightly
advance signalling for changes between formats that were signalled modified if several RTP sessions are multiplexed onto one transport
during the session setup. This is needed for rapid rate adaptation. layer connection, such that an endpoint must be prepared for a source
to switch between formats of the same media type at any time; see
Section 4.4). RTP does not require advance signalling for changes
between formats that were signalled during the session setup. This
is needed for rapid rate adaptation.
3. RTP Profile 4. WebRTC Use of RTP: Core Protocols
The "Extended Secure RTP Profile for Real-time Transport Control 4.1. RTP and RTCP
Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to
be implemented. This builds on the basic RTP/AVP profile [RFC3551], The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be
the RTP/AVPF feedback profile [RFC4585], and the secure RTP/SAVP implemented as the media transport protocol for WebRTC. RTP itself
profile [RFC3711]. comprises two parts: the RTP data transfer protocol, and the RTP
control protocol (RTCP). RTCP is a fundamental and integral part of
the RTP protocol, and is REQUIRED to be implemented.
RTP and RTCP are flexible and extensible protocols that allow, on the
one hand, choosing from a variety of building blocks and combining
those to meet application needs, but on the other hand, offer the
ability to create extensions where existing mechanisms are not
sufficient. This memo requires a number of RTP and RTCP extensions
that have been shown to be provide important functionality in the
WebRTC context be implemented. It is possible that future extensions
will be needed: several documents provide guidelines for the use and
extension of RTP and RTCP, including Guidelines for Writers of RTP
Payload Format Specifications [RFC2736] and Guidelines for Extending
the RTP Control Protocol [RFC5968], and should be consulted before
extending this memo.
4.2. Choice of RTP Profile
The complete specification of RTP for a particular application domain
requires the choice of an RTP Profile. For WebRTC use, the "Extended
Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-
Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to be implemented.
This builds on the basic RTP/AVP profile [RFC3551], the RTP/AVPF
feedback profile [RFC4585], and the secure RTP/SAVP 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 use the full This also saves RTCP bandwidth and will commonly only use the full
amount when there is a lot of events on which to send feedback. This amount when there is a lot of events on which to send feedback. 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 6.1. The improved RTCP timer model
defined by RTP/AVPF is backwards compatible with legacy systems that
implement only the RTP/AVP profile given some constraints on
parameter configuration such as RTCP banwidth and "trr-int".
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. A mandatory to implement media security mechanism
including keying must be required so that confidentialtiy, integrity
protection and source authentication of the media stream can be
provided when desired by the user.
4. RTP and RTCP Guidelines 4.3. Choice of RTP Payload Formats
RTP and RTCP are two flexible and extensible protocols that allow, on (tbd: say something about the choice of RTP Payload Format for
the one hand, choosing from a variety of building blocks and WebRTC. If there is a mandatory to implement set of codecs, this
combining those to meet application needs, and on the other hand, should reference them. In any case, it should reference a discussion
create extensions where existing mechanisms are not sufficient: from of signalling for the choice of codec, once that discussion reaches
new payload formats to RTP extension headers to additional RTCP closure.)
control packets.
Different informational documents provide guidelines to the use and 4.4. RTP Session Multiplexing
particularly the extension of RTP and RTCP, including the following:
Guidelines for Writers of RTP Payload Format Specifications [RFC2736]
and Guidelines for Extending the RTP Control Protocol [RFC5968].
5. RTP Optimisations An association amongst a set of participants communicating with RTP
is known as an RTP session. A participant may be involved in
multiple RTP sessions at the same time. In a multimedia session,
each medium has typically been carried in a separate RTP session with
its own RTCP packets (i.e., one RTP session for the audio, with a
separate RTP session running on a different transport connection for
the video; if SDP is used, this corresponds to one RTP session for
each "m=" line in the SDP). WebRTC implementations of RTP are
REQUIRED to implement support of multimedia sessions in this way, for
compatibility with legacy systems.
In today's networks, however, with the prolific use of Network
Address Translators (NAT) and Firewalls (FW), there is a desire to
reduce the number of transport layer ports used by real-time media
applications using RTP by combining multimedia traffic in a single
RTP session. (Details of how this is to be done are tbd, but see
[I-D.lennox-rtcweb-rtp-media-type-mux],
[I-D.holmberg-mmusic-sdp-bundle-negotiation] and
[I-D.westerlund-avtcore-multiplex-architecture].) WebRTC
implementations of RTP are REQUIRED to support multiplexing of
multimedia sessions onto a single RTP session according to (tbd). If
such RTP session multiplexing is to be used, this MUST be negotiated
during the signalling phase.
5. WebRTC Use of RTP: Optimisations
This section discusses some optimisations 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 5.1. RTP and RTCP Multiplexing
Historically, RTP and RTCP have been run on separate UDP ports. With Historically, RTP and RTCP have been run on separate UDP ports. With
the increased use of Network Address/Port Translation (NAPT) this has the increased use of Network Address/Port Translation (NAPT) this has
become problematic, since maintaining multiple NAT bindings can be become problematic, since maintaining multiple NAT bindings can be
costly. It also complicates firewall administration, since multiple costly. It also complicates firewall administration, since multiple
ports must be opened to allow RTP traffic. To reduce these costs and ports must be opened to allow RTP traffic. To reduce these costs and
session setup times, support for multiplexing RTP data packets and session setup times, support for multiplexing RTP data packets and
RTCP control packets on a single port [RFC5761] is REQUIRED. RTCP control packets on a single port [RFC5761] is REQUIRED.
Supporting this specification is generally a simplification in code, 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 and is recommend method for application level keep-
alives of RTP sessions [RFC6263].
5.2. Reduced Size RTCP 5.2. Reduced Size RTCP
RTCP packets are usually sent as compound RTCP packets; and RFC 3550 RTCP packets are usually sent as compound RTCP packets; and RFC 3550
demands that those compound packets always start with an SR or RR demands that those compound packets always start with an SR or RR
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.
skipping to change at page 10, line 5 skipping to change at page 12, line 27
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 a short-term persistent RTCP CNAMEs following method (b) generating a short-term persistent RTCP CNAMEs following method (b)
as specified in Section 4.2 of "Guidelines for Choosing RTP Control as specified in Section 4.2 of "Guidelines for Choosing RTP Control
Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is RECOMMENDED, Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is RECOMMENDED,
since this addresses both concerns. since this addresses both concerns.
6. RTP Extensions 6. WebRTC Use of 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 WebRTC context. One set is related to conferencing, others are more
generic in nature. generic in nature.
6.1. RTP Conferencing Extensions 6.1. Conferencing Extensions
RTP is inherently defined for group communications, whether using IP
multicast, multi-unicast, or based on a centralised server. In
today's practice, however, overlay-based conferencing dominates,
typically using one or a few so-called conference bridges or servers
to connect endpoints in a star or flat tree topology. Quite diverse
conferencing topologies can be created using the basic elements of
RTP mixers and translators as defined in RFC 3550.
An number of conferencing topologies are defined in [RFC5117] out of RTP is inherently a group communication protocol. Groups can be
the which the following ones are the more common (and most likely in implemented using a centralised server, multi-unicast, or IP
practice workable) ones: multicast. While IP multicast was popular in early deployments, in
today's practice, overlay-based conferencing dominates, typically
using one or more central servers to connect endpoints in a star or
flat tree topology. These central servers can be implemented in a
number of ways [RFC5117], of which the following are the most common:
1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117, section 1. RTP Translator (Relay) with Only Unicast Paths ([RFC5117],
3.3) section 3.3)
2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4) 2. RTP Mixer with Only Unicast Paths ([RFC5117], section 3.4)
3) Point to Multipoint Using a Video Switching MCU (RFC 5117, section 3. Point to Multipoint Using a Video Switching MCU ([RFC5117],
3.5) section 3.5)
4) Point to Multipoint Using Content Modifying MCUs (RFC 5117, 4. Point to Multipoint Using Content Modifying MCUs ([RFC5117],
section 3.6) section 3.6)
We note that 3 and 4 are not well utilising the functions of RTP and As discussed in [RFC5117] section 3.5, the use of a video switching
in some cases even violates the RTP specifications. Thus we MCU makes the use of RTCP for congestion control, or any type of
recommend that one focus on 1 and 2. quality reports, very problematic. Also, as discussed in [RFC5117]
section 3.6, the use of a content modifying MCU with RTCP termination
breaks RTP loop detection and removes the ability for receivers to
identify active senders. According only the first two options are
recommended.
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 centralised 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].
skipping to change at page 12, line 5 skipping to change at page 14, line 28
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 6.2. 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
skipping to change at page 12, line 31 skipping to change at page 15, line 5
is signalled (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 [RFC6051] is The RTP rapid synchronisation header extension [RFC6051] is
recommended, as discussed in Section 6.3 we also recommend the client recommended, as discussed in Section 6.3 we also recommend the client
to mixer audio level [I-D.ietf-avtext-client-to-mixer-audio-level], to mixer audio level [I-D.ietf-avtext-client-to-mixer-audio-level],
and consider the mixer to client audio level and consider the mixer to client audio level
[I-D.ietf-avtext-mixer-to-client-audio-level] as optional feature. [I-D.ietf-avtext-mixer-to-client-audio-level] as optional feature.
It is RECOMMENDED that the mechanism to encrypt header extensions It is REQUIRED that the mechanism to encrypt header extensions
[I-D.ietf-avtcore-srtp-encrypted-header-ext] is implemented when the [I-D.ietf-avtcore-srtp-encrypted-header-ext] is implemented when the
client-to-mixer and mixer-to-client audio level indications are in client-to-mixer or mixer-to-client audio level indications are in use
use in SRTP encrypted sessions, since the information contained in in SRTP encrypted sessions, since the information contained in these
these header extensions may be considered sensitive. header extensions may be considered sensitive.
Currently the other header extensions are not recommended to be
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
an RTP timestamp offset of the actual transmission time of the RTP
packet in relation to capture/display timestamp present in the RTP
header. This can be used to improve jitter determination and
buffer management.
Associating Time-Codes with RTP Streams: [RFC5484] defines how to
associate SMPTE times codes with the RTP streams.
6.3. Rapid Synchronisation Extensions 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.
6.4. Client to Mixer Audio Level 6.4. Mixer Audio Level Extensions
6.4.1. Client to Mixer Audio Level
The Client to Mixer Audio Level The Client to Mixer Audio Level
[I-D.ietf-avtext-client-to-mixer-audio-level] is an RTP header [I-D.ietf-avtext-client-to-mixer-audio-level] is an RTP header
extension used by a client to inform a mixer about the level of audio extension used by a client to inform a mixer about the level of audio
activity in the packet the header is attached to. This enables a activity in the packet the header is attached to. This enables a
central node to make mixing or selection decisions without decoding central node to make mixing or selection decisions without decoding
or detailed inspection of the payload. Thus reducing the needed or detailed inspection of the payload. Thus reducing the needed
complexity in some types of central RTP nodes. complexity in some types of central RTP nodes.
Assuming that the Client to Mixer Audio Level Assuming that the Client to Mixer Audio Level
[I-D.ietf-avtext-client-to-mixer-audio-level] is published as a [I-D.ietf-avtext-client-to-mixer-audio-level] is published as a
finished specification prior to RTCWEB's first RTP specification then finished specification prior to RTCWEB's first RTP specification then
it is RECOMMENDED that this extension is included. it is RECOMMENDED that this extension is included.
6.5. Mixer to Client Audio Level 6.4.2. Mixer to Client Audio Level
The Mixer to Client Audio Level header extension The Mixer to Client Audio Level header extension
[I-D.ietf-avtext-mixer-to-client-audio-level] provides the client [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 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 from the RTP mixer. Thus enabling a user interface to indicate the
relative activity level of a session participant, rather than just relative activity level of a session participant, rather than just
being included or not based on the CSRC field. This is a pure being included or not based on the CSRC field. This is a pure
optimisations of non critical functions and thus optional optimisations of non critical functions and thus optional
functionality. functionality.
Assuming that the Mixer to Client Audio Level Assuming that the Mixer to Client Audio Level
[I-D.ietf-avtext-client-to-mixer-audio-level] is published as a [I-D.ietf-avtext-client-to-mixer-audio-level] is published as a
finished specification prior to RTCWEB's first RTP specification then finished specification prior to RTCWEB's first RTP specification then
it is OPTIONAL that this extension is included. it is OPTIONAL that this extension is included.
7. Improving RTP Transport Robustness 7. WebRTC Use of RTP: Improving Transport Robustness
There are some tools that can make RTP flows robust against Packet There are some tools that can make RTP flows robust against Packet
loss and reduce the impact on media quality. However they all add loss and reduce the impact on media quality. However they all add
extra bits compared to a non-robust stream. These extra bits needs extra bits compared to a non-robust stream. These extra bits needs
to be considered and the aggregate bit-rate needs to be rate to be considered and the aggregate bit-rate needs to be rate
controlled. Thus improving robustness might require a lower base controlled. Thus improving robustness might require a lower base
encoding quality but has the potential to give that quality with encoding quality but has the potential to give that quality with
fewer errors in it. fewer errors in it.
7.1. RTP Retransmission 7.1. 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 prioritise 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.
"RTC-Web Media Transport Requirements" [I-D.cbran-rtcweb-data] raises "WebRTC Media Transport Requirements" [I-D.cbran-rtcweb-data] raises
two issues that they think makes RTP Retransmission unsuitable for two issues that they think makes RTP Retransmission unsuitable for
RTCWEB. We here consider these issues and explain why they are in RTCWEB. We here consider these issues and explain why they are in
fact not a reason to exclude RTP retransmission from the tool box fact not a reason to exclude RTP retransmission from the tool box
available to RTCWEB media sessions. available to RTCWEB media sessions.
The additional latency added by [RFC4588] will exceed the latency The additional latency added by [RFC4588] will exceed the latency
threshold for interactive voice and video: RTP Retransmission will threshold for interactive voice and video: RTP Retransmission will
require at least one round trip time for a retransmission request require at least one round trip time for a retransmission request
and repair packet to arrive. Thus the general suitability of and repair packet to arrive. Thus the general suitability of
using retransmissions will depend on the actual network path using retransmissions will depend on the actual network path
latency between the end-points. In many of the actual usages the latency between the end-points. In many of the actual usages the
latency between two end-points will be low enough for RTP latency between two end-points will be low enough for RTP
retransmission to be effective. Interactive communication with retransmission to be effective. Interactive communication with
end-to-end delays of 400 ms still provide a fair quality. Even end-to-end delays of 400 ms still provide a fair quality. Even
removing half of that in end-point delays allows functional removing half of that in end-point delays allows functional
retransmission between end-points on the continent. In addition retransmission between end-points on the same continent. In
in some applications one may accept temporary delay spikes to addition, some applications may accept temporary delay spikes to
allow for retransmission of crucial codec information such an allow for retransmission of crucial codec information such an
parameter sets, intra picture etc, rather than getting no media at parameter sets, intra picture etc, rather than getting no media at
all. all.
The undesirable increase in packet transmission at the point when The undesirable increase in packet transmission at the point when
congestion occurs: Congestion loss will impact the rate controls congestion occurs: Congestion loss will impact the rate controls
view of available bit-rate for transmission. When using view of available bit-rate for transmission. When using
retransmission one will have to prioritise between performing retransmission one will have to prioritise between performing
retransmissions and the quality one can achieve with ones retransmissions and the quality one can achieve with ones
adaptable codecs. In many use cases one prefer error free or low adaptable codecs. In many use cases one prefer error free or low
skipping to change at page 15, line 31 skipping to change at page 17, line 40
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.
The main benefit from FEC is the relatively low additional delay The main benefit from FEC is the relatively low additional delay
needed to protect against packet losses. The transmission of any needed to protect against packet losses. The transmission of any
repair packets should preferably be done with a time delay that is repair packets should preferably be done with a time delay that is
just larger than any loss events normally encountered. That way the 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. repair packet isn't also lost in the same event as the source data.
The amount of repair packets needed are also highly dynamically and The amount of repair packets needed varies depending on the amount
depends on two main factors, the amount and pattern of lost packets and pattern of packet loss to be recovered, and on the mechanism used
to be recovered and the mechanism one use to derive repair data. The to derive repair data. The later choice also effects the the
later choice also effects the the additional delay required to both additional delay required to both encode the repair packets and in
encode the repair packets and in the receiver to be able to recover the receiver to be able to recover the lost packet(s).
the lost packet(s).
7.2.1. Basic Redundancy 7.2.1. Basic Redundancy
The method for providing basic redundancy is to simply retransmit an The method for providing basic redundancy is to simply retransmit a
some time earlier sent packet. This is relatively simple in theory, some time earlier sent packet. This is relatively simple in theory,
i.e. one saves any outgoing source (original) packet in a buffer i.e. one saves any outgoing source (original) packet in a buffer
marked with a timestamp of actual transmission, some X ms later one marked with a timestamp of actual transmission, some X ms later one
transmit this packet again. Where X is selected to be longer than 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 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 recovered assuming that one doesn't get an another loss event before
all the packets lost in the first event has been received. all the packets lost in the first event has been received.
The downside of basic redundancy is the overhead. To provide each The downside of basic redundancy is the overhead. To provide each
packet with once chance of recovery, then the transmission rate packet with once chance of recovery, then the transmission rate
skipping to change at page 16, line 13 skipping to change at page 18, line 21
possible to only redundantly send really important packets thus possible to only redundantly send really important packets thus
reducing the overhead below 100% for some other trade-off is reducing the overhead below 100% for some other trade-off is
overhead. overhead.
In addition the basic retransmission of the same packet using the In addition the basic retransmission of the same packet using the
same SSRC in the same RTP session is not possible in RTP context. 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 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 sends the same packet twice with the same sequence number. Thus one
needs more elaborate mechanisms. needs more elaborate mechanisms.
RTP Payload Format Support: Some RTP payload format do support basic
redundancy within the RTP paylaod format itself. Examples are
AMR-WB [RFC4867] and G.719 [RFC5404].
RTP Payload for Redundant Audio Data: This audio and text redundancy RTP Payload for Redundant Audio Data: This audio and text redundancy
format defined in [RFC2198] allows for multiple levels of format defined in [RFC2198] allows for multiple levels of
redundancy with different delay in their transmissions, as long as redundancy with different delay in their transmissions, as long as
the source plus payload parts to be redundantly transmitted the source plus payload parts to be redundantly transmitted
together fits into one MTU. This should work fine for most together fits into one MTU. This should work fine for most
interactive use cases as both the codec bit-rates and the framing interactive audio and text use cases as both the codec bit-rates
intervals normally allow for this requirement to hold. This and the framing intervals normally allow for this requirement to
payload format also don't increase the packet rate, as original hold. This payload format also don't increase the packet rate, as
data and redundant data are sent together. This format does not original data and redundant data are sent together. This format
allow perfect recovery, only recovery of information deemed does not allow perfect recovery, only recovery of information
necessary for audio, for example the sequence number of the deemed necessary for audio, for example the sequence number of the
original data is lost. original data is lost.
RTP Retransmission Format: The RTP Retransmission Payload format RTP Retransmission Format: The RTP Retransmission Payload format
[RFC4588] can be used to pro-actively send redundant packets using [RFC4588] can be used to pro-actively send redundant packets using
either SSRC or session multiplexing. By using different SSRCs or either SSRC or session multiplexing. By using different SSRCs or
a different session for the redundant packets the RTCP receiver a different session for the redundant packets the RTCP receiver
reports will be correct. The retransmission payload format is reports will be correct. The retransmission payload format is
used to recover the packets original data thus enabling a perfect used to recover the packets original data thus enabling a perfect
recovery. recovery.
Duplication Grouping Semantics in the Session Description Protocol: Duplication Grouping Semantics in the Session Description Protocol:
This [I-D.begen-mmusic-redundancy-grouping] is proposal for new This [I-D.begen-mmusic-redundancy-grouping] is proposal for new
SDP signalling to indicate media stream duplication using SDP signalling to indicate media stream duplication using
different RTP sessions, or different SSRCs to separate the source different RTP sessions, or different SSRCs to separate the source
and the redundant copy of the stream. and the redundant copy of the stream.
7.2.2. Block Based 7.2.2. Block Based FEC
Block based redundancy collects a number of source packets into a Block based redundancy collects a number of source packets into a
data block for processing. The processing results in some number of data block for processing. The processing results in some number of
repair packets that is then transmitted to the other end allowing the repair packets that is then transmitted to the other end allowing the
receiver to attempt to recover some number of lost packets in the receiver to attempt to recover some number of lost packets in the
block. The benefit of block based approaches is the overhead which block. The benefit of block based approaches is the overhead which
can be lower than 100% and still recover one or more lost source can be lower than 100% and still recover one or more lost source
packet from the block. The optimal block codes allows for each packet from the block. The optimal block codes allows for each
received repair packet to repair a single loss within the block. 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 Thus 3 repair packets that are received should allow for any set of 3
skipping to change at page 17, line 42 skipping to change at page 20, line 9
[I-D.ietf-fecframe-framework] defines how not only RTP packets but [I-D.ietf-fecframe-framework] defines how not only RTP packets but
how arbitrary packet flows can be protected. Some solutions how arbitrary packet flows can be protected. Some solutions
produced or under development in FECFRAME WG are RTP specific. produced or under development in FECFRAME WG are RTP specific.
There exist alternatives supporting block codes such as Reed- There exist alternatives supporting block codes such as Reed-
Salomon and Raptor. Salomon and Raptor.
7.2.3. Recommendations for FEC 7.2.3. Recommendations for FEC
(tbd) (tbd)
8. RTP Rate Control and Media Adaptation 8. WebRTC Use of RTP: Rate Control and Media Adaptation
It is REQUIRED to have an RTP Rate Control mechanism using Media WebRTC will be used in very varied network environment with a
adaptation to ensure that the generated RTP flows are network hetrogenous set of link technologies, including wired and wireless,
friendly, and maintain the user experience in the presence of network interconnecting peers at different topological locations resulting in
problems. network paths with widely varying one way delays, bit-rate capacity,
load levels and traffic mixes. In addition individual end-points
will open one or more WebRTC sessions between one or more peers.
Each of these session may contain different mixes of media and data
flows. Assymetric usage of media bit-rates and number of media
streams is also to be expected. A single end-point may receive zero
to many simultanous media streams while itself transmitting one or
more streams.
The WebRTC application is very dependent from a quality perspective
on the media adapation working well so that an end-point doesn't
transmit significantly more than the path is capable of handling. If
it would, the result would be high levels of packet loss or delay
spikes causing media degradations.
WebRTC applications using more than a single media stream of any
media type or data flows has an additional concern. In this case the
different flows should try to avoid affecting each other negatively.
In addition in case there is a resource limiation, the available
resources needs to be shared. How to share them is something the
application should prioritize so that the limiation in quality or
capabilities are the ones that provide the least affect on the
application.
This hetrogenous situation results in a requirement to have
functionality that adapts to the available capacity and that competes
fairly with other network flows. If it would not compete fairly
enough WebRTC could be used as an attack method for starving out
other traffic on specific links as long as the attacker is able to
create traffic across a specific link. This is not far-fetched for a
web-service capable of attracting large number of end-points and use
the service, combined with BGP routing state a server could pick
client pairs to drive traffic to specific paths.
The above estalish a clear need based on several reasons why there
need to be a well working media adaptation mechanism. This mechanism
also have a number of requirements on what services it should provide
and what performance it needs to provide.
The biggest issue is that there are no standardised 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 WebRTC Thus there will be
need for the IETF to produce such a specification. A potential need for the IETF to produce such a specification. Therefore the
starting point for defining a solution is "RTP with TCP Friendly Rate suggested way forward is to specify requirements on any solution for
Control" [rtp-tfrc]. the media adaptation. These requirements is for now proposed to be
documented in this specification. In addition a proposed detailed
solution will be developed, but is expected to take longer time to
finalize than this document.
9. RTP Performance Monitoring 8.1. Rate Control Requirements
Note: This section does not yet have WG consensus.
This section provides a number of requirements on an media
adaptation/congestion control solution for WebRTC.
1. All WebRTC media streams MUST be congestion-controlled. (The
same requirement apply to data streams)
2. The congestion algorithms used MUST cause WebRTC streams to act
reasonably fairly with TCP and other congestion-controlled flows,
such as DCCP and TFRC, and other WebRTC flows. Note that WebRTC
involves multiple data flows which "normally" would be separately
congestion-controlled.
3. The congestion control mechanism MUST be possible to realize
between two indendently implemented WebRTC end-points.
4. The congestion control algorithm SHOULD attempt to minimize the
media-stream end-to-end delays between the participants, by
controlling bandwidth appropriately.
5. The congestion control SHOULD allow for prioritization and
shifting of banwidth between media flows. In other words, if one
flow on the same path as another has to adjust its bit-rate the
other flow can perform that adjustment instead, or divided
between the flows.
Thus it is REQUIRED to have an implementation of an RTP Rate Control
mechanism fulfilling the above requirements.
8.2. RTCP Limiations
Experience with the congestion control algorithms of TCP [RFC5681],
TFRC [RFC5348], and DCCP [RFC4341], [RFC4342], [RFC4828], has shown
that feedback on packet arrivals needs to be sent roughly once per
round trip time. We note that the capabilities of real-time media
traffic to adapt to changing path conditions may be less rapid than
for the elastic applications TCP was designed for, but frequent
feedback is still required to allow the congestion control algorithm
to track the path dynamics.
The total RTCP bandwidth is limited in its transmission rate to a
fraction of the RTP traffic (by default 5%). RTCP packets are larger
than, e.g., TCP ACKs (even when non-compound RTCP packets are used).
The media stream bit rate thus limits the maximum feedback rate as a
function of the mean RTCP packet size.
Interactive communication may not be able to afford waiting for
packet losses to occur to indicate congestion, because an increase in
playout delay due to queuing (most prominent in wireless networks)
may easily lead to packets being dropped due to late arrival at the
receiver. Therefore, more sophisticated cues may need to be reported
-- to be defined in a suitable congestion control framework as noted
above -- which, in turn, increase the report size again. For
example, different RTCP XR report blocks (jointly) provide the
necessary details to implement a variety of congestion control
algorithms, but the (compound) report size grows quickly.
In group communication, the share of RTCP bandwidth needs to be
shared by all group members, reducing the capacity and thus the
reporting frequency per node.
Example: assuming 512 kbit/s video yields 3200 bytes/s RTCP
bandwidth, split across two entities in a point-to-point session. An
endpoint could thus send a report of 100 bytes about every 70ms or
for every other frame in a 30 fps video.
8.3. Legacy Interop Limitations
Congestion control interoperability with most type of legacy devices,
even using an translator could be difficult. There are numerous
reasons for this:
No RTCP Support: There exist legacy implementations that does not
even implement RTCP at all. Thus no feedback at all is provided.
RTP/AVP Minimal RTCP Interval of 5s: RTP [RFC3550] under the RTP/AVP
profile specifies a recommended minimal fixed interval of 5
seconds. Sending RTCP report blocks as seldom as 5 seconds makes
it very difficult for a sender to use these reports and react to
any congestion event.
RTP/AVP Scaled Minimal Interval: If a legacy device uses the scaled
minimal RTCP compound interval, the "RECOMMENDED value for the
reduced minimum in seconds is 360 divided by the session bandwidth
in kilobits/second" ([RFC3550], section 6.2). The minimal
interval drops below a second, still several times the RTT in
almost all paths in the Internet, when the session bandwidht
becomes 360 kbps. A session bandwidth of 1 Mbps still has a
minimal interval of 360 ms. Thus, with the exception for rather
high bandwidth sessions, getting frequent enough RTCP Report
Blocks to report on the order of the RTT is very difficult as long
as the legacy device uses the RTP/AVP profile.
RTP/AVPF Supporting Legacy Device: If a legacy device supports RTP/
AVPF, then that enables negotation of important parameters for
frequent reporting, such as the "trr-int" parameter, and the
possibility that the end-point supports some useful feedback
format for congestion control purpose such as TMMBR [RFC5104].
It has been suggested on the RTCWEB mailing list that if
interoperating with really limited legacy devices an WebRTC end-point
may not send more than 64 kbps of media streams, to avoid it causing
massive congestion on most paths in the Internet when communicating
with a legacy node not providing sufficient feedback for effective
congestion control. This warrants further discussion as there is
clearly a number of link layers that don't even provide that amount
of bit-rate consistently, and that assumes no competing traffic.
9. WebRTC Use of 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.
Exposing some metrics in the WebRTC API should be considered allowing
the application to gather the measurements of interest. However,
security implications for the different data sets exposed will need
to be considered in this.
10. IANA Considerations 10. 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 11. Security Considerations
RTP and its various extensions each have their own security RTP and its various extensions each have their own security
considerations. These should be taken into account when considering considerations. These should be taken into account when considering
the security properties of the complete suite. We currently don't the security properties of the complete suite. We currently don't
think this suite creates any additional security issues or think this suite creates any additional security issues or
properties. The use of SRTP [RFC3711] will provide protection or properties. The use of SRTP [RFC3711] will provide protection or
mitigation against all the fundamental issues by offering mitigation against all the fundamental issues by offering
confidentiality, integrity and partial source authentication. The confidentiality, integrity and partial source authentication. A
guidelines in [I-D.ietf-avtcore-srtp-vbr-audio] apply when using mandatory to implement media security solution will be required to be
variable bit rate (VBR) audio codecs, for example Opus. picked. We currently don't discuss the key-management aspect of SRTP
in this memo, that needs to be done taking the WebRTC communication
model into account.
We don't discuss the key-management aspect of SRTP in this memo, that The guidelines in [I-D.ietf-avtcore-srtp-vbr-audio] apply when using
needs to be done taking the RTC-Web communication model into account. variable bit rate (VBR) audio codecs, for example Opus or the Mixer
audio level header extensions.
In the context of RTC-Web the actual security properties required Security considerations for the WebRTC work are discussed in
from RTP are currently not fully understood. Until security goals [I-D.ietf-rtcweb-security].
and requirements are specified it will be difficult to determine what
security features in addition to SRTP and a suitable key-management,
if any, that are needed.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Harald Alvestrand, Cary Bran, and
Cullen Jennings for valuable feedback.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.holmberg-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
Using Session Description Protocol (SDP) Port Numbers",
draft-holmberg-mmusic-sdp-bundle-negotiation-00 (work in
progress), October 2011.
[I-D.ietf-avtcore-srtp-encrypted-header-ext] [I-D.ietf-avtcore-srtp-encrypted-header-ext]
Lennox, J., "Encryption of Header Extensions in the Secure Lennox, J., "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", Real-Time Transport Protocol (SRTP)",
draft-ietf-avtcore-srtp-encrypted-header-ext-00 (work in draft-ietf-avtcore-srtp-encrypted-header-ext-00 (work in
progress), June 2011. progress), June 2011.
[I-D.ietf-avtcore-srtp-vbr-audio] [I-D.ietf-avtcore-srtp-vbr-audio]
Perkins, C. and J. Valin, "Guidelines for the use of Perkins, C. and J. Valin, "Guidelines for the use of
Variable Bit Rate Audio with Secure RTP", Variable Bit Rate Audio with Secure RTP",
draft-ietf-avtcore-srtp-vbr-audio-03 (work in progress), draft-ietf-avtcore-srtp-vbr-audio-03 (work in progress),
skipping to change at page 19, line 34 skipping to change at page 25, line 23
draft-ietf-avtext-client-to-mixer-audio-level-03 (work in draft-ietf-avtext-client-to-mixer-audio-level-03 (work in
progress), July 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-03 (work in draft-ietf-avtext-mixer-to-client-audio-level-03 (work in
progress), July 2011. progress), July 2011.
[I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-01 (work in progress),
October 2011.
[I-D.lennox-rtcweb-rtp-media-type-mux]
Lennox, J. and J. Rosenberg, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011.
[I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., and C. Perkins, "RTP
Multiplexing Architecture",
draft-westerlund-avtcore-multiplex-architecture-00 (work
in progress), October 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
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
skipping to change at page 20, line 32 skipping to change at page 26, line 39
[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.
[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
RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
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.
[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.
skipping to change at page 21, line 29 skipping to change at page 27, line 29
Watson, M., Begen, A., and V. Roca, "Forward Error Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", Correction (FEC) Framework",
draft-ietf-fecframe-framework-15 (work in progress), draft-ietf-fecframe-framework-15 (work in progress),
June 2011. June 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.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006.
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control
(TFRC): The Small-Packet (SP) Variant", RFC 4828,
April 2007.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.
[RFC5404] Westerlund, M. and I. Johansson, "RTP Payload Format for
G.719", RFC 5404, January 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[rtp-tfrc] [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Gharai, L., "RTP with TCP Friendly Rate Control Keeping Alive the NAT Mappings Associated with RTP / RTP
(draft-gharai-avtcore-rtp-tfrc-00)", March 2011. Control Protocol (RTCP) Flows", RFC 6263, June 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
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 69 change blocks. 
216 lines changed or deleted 485 lines changed or added

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