Sending Multiple Types of Media in a Single RTP Session
RFC 8860

Document Type RFC - Proposed Standard (January 2021; No errata)
Updates RFC 3550, RFC 3551
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
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
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


   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

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
   ( 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
   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