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-timeShow full document text