Skip to main content

Multi Codec RTP payload format

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Sergio Garcia Murillo , Youenn Fablet , Dr. Alex Gouaillard , Justin Uberti
Last updated 2022-01-12 (Latest revision 2021-07-11)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


RTP Media Chains usually rely on piping encoder output directly to packetizers. Media packetization formats often support a specific codec format and optimize RTP packets generation accordingly. With the development of Selective Forward Unit (SFU) solutions, RTP Media Chains used in WebRTC solutions are increasingly relying on application-specific transforms that sit between encoder and packetizer on one end and between depacketizer and decoder on the other end. These transforms are typically encrypting media content so that the media content is not readable from the SFU, for instance using [SFrame] or [WebRTCInsertableStreams]. In that context, RTP packetizers can no longer expect to use packetization formats that mandate media content to be in a specific codec format. This document provides a solution to that problem by describing a RTP packetization format that can be used for many media content, and how to negotiate use of this format. This document also describes a solution to allow SFUs to continue performing packet routing on top of this RTP packetization format.


Sergio Garcia Murillo
Youenn Fablet
Dr. Alex Gouaillard
Justin Uberti

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)