Sending Multiple Types of Media in a Single RTP Session
RFC 8860
| Document | Type | RFC - Proposed Standard (January 2021; No errata) | |
|---|---|---|---|
| Authors | Magnus Westerlund , Colin Perkins , Jonathan Lennox | ||
| Last updated | 2021-01-18 | ||
| Replaces | draft-westerlund-avtcore-multi-media-rtp-session | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Roni Even | ||
| Shepherd write-up | Show (last changed 2015-10-08) | ||
| IESG | IESG state | RFC 8860 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Ben Campbell | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions | ||
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 8860 Ericsson
Updates: 3550, 3551 C. Perkins
Category: Standards Track University of Glasgow
ISSN: 2070-1721 J. Lennox
8x8 / Jitsi
January 2021
Sending Multiple Types of Media in a Single RTP Session
Abstract
This document specifies how an RTP session can contain RTP streams
with media from multiple media types such as audio, video, and text.
This has been restricted by the RTP specifications (RFCs 3550 and
3551), and thus this document updates RFCs 3550 and 3551 to enable
this behaviour for applications that satisfy the applicability for
using multiple media types in a single RTP session.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8860.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Terminology
3. Background and Motivation
4. Applicability
5. Using Multiple Media Types in a Single RTP Session
5.1. Allowing Multiple Media Types in an RTP Session
5.2. Demultiplexing Media Types within an RTP Session
5.3. Per-SSRC Media Type Restrictions
5.4. RTCP Considerations
6. Extension Considerations
6.1. RTP Retransmission Payload Format
6.2. RTP Payload Format for Generic FEC
6.3. RTP Payload Format for Redundant Audio
7. Signalling
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
The Real-time Transport Protocol [RFC3550] was designed to use
separate RTP sessions to transport different types of media. This
implies that different transport-layer flows are used for different
RTP streams. For example, a video conferencing application might
send audio and video traffic RTP flows on separate UDP ports. With
increased use of network address/port translation, firewalls, and
other middleboxes, it is, however, becoming difficult to establish
multiple transport-layer flows between endpoints. Hence, there is
pressure to reduce the number of concurrent transport flows used by
RTP applications.
This memo updates [RFC3550] and [RFC3551] to allow multiple media
types to be sent in a single RTP session in certain cases, thereby
reducing the number of transport-layer flows that are needed. It
makes no changes to RTP behaviour when using multiple RTP streams
containing media of the same type (e.g., multiple audio streams or
multiple video streams) in a single RTP session. However, [RFC8108]
provides important clarifications to RTP behaviour in that case.
This memo is structured as follows. Section 2 defines terminology.
Section 3 further describes the background to, and motivation for,
this memo; Section 4 describes the scenarios where this memo is
applicable. Section 5 discusses issues arising from the base RTP and
RTP Control Protocol (RTCP) specifications [RFC3550] [RFC3551] when
using multiple types of media in a single RTP session, while
Section 6 considers the impact of RTP extensions. We discuss
signalling in Section 7. Finally, security considerations are
discussed in Section 8.
2. Terminology
The terms "encoded stream", "endpoint", "media source", "RTP
session", and "RTP stream" are used as defined in [RFC7656]. We also
define the following terms:
Media Type: The general type of media data used by a real-time
Show full document text