A General Mechanism for RTP Header Extensions
RFC 5285

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 15

Network Working Group                                          D. Singer
Request for Comments: 5285                                   Apple, Inc.
Category: Standards Track                                    H. Desineni
                                                                Qualcomm
                                                               July 2008

             A General Mechanism for RTP Header Extensions

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document provides a general mechanism to use the header
   extension feature of RTP (the Real-Time Transport Protocol).  It
   provides the option to use a small number of small extensions in each
   RTP packet, where the universe of possible extensions is large and
   registration is de-centralized.  The actual extensions in use in a
   session are signaled in the setup information for that session.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  2
   3.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  2
   4.  Packet Design  . . . . . . . . . . . . . . . . . . . . . . . .  3
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     4.2.  One-Byte Header  . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  Two-Byte Header  . . . . . . . . . . . . . . . . . . . . .  6
   5.  SDP Signaling Design . . . . . . . . . . . . . . . . . . . . .  7
   6.  Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Identifier Space for IANA to Manage  . . . . . . . . . . . 13
     9.2.  Registration of the SDP extmap Attribute . . . . . . . . . 14
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 15

Singer & Desineni           Standards Track                     [Page 1]
RFC 5285                 RTP Header Extensions                 July 2008

1.  Introduction

   The RTP specification [RFC3550] provides a capability to extend the
   RTP header.  It defines the header extension format and rules for its
   use in Section 5.3.1.  The existing header extension method permits
   at most one extension per RTP packet, identified by a 16-bit
   identifier and a 16-bit length field specifying the length of the
   header extension in 32-bit words.

   This mechanism has two conspicuous drawbacks.  First, it permits only
   one header extension in a single RTP packet.  Second, the
   specification gives no guidance as to how the 16-bit header extension
   identifiers are allocated to avoid collisions.

   This specification removes the first drawback by defining a backward-
   compatible and extensible means to carry multiple header extension
   elements in a single RTP packet.  It removes the second drawback by
   defining that these extension elements are named by URIs, defining an
   IANA registry for extension elements defined in IETF specifications,
   and a Session Description Protocol (SDP) method for mapping between
   the naming URIs and the identifier values carried in the RTP packets.

   This header extension applies to RTP/AVP (the Audio/Visual Profile)
   and its extensions.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Design Goals

   The goal of this design is to provide a simple mechanism whereby
   multiple identified extensions can be used in RTP packets, without
   the need for formal registration of those extensions but nonetheless
   avoiding collision.

   This mechanism provides an alternative to the practice of burying
   associated metadata into the media format bit stream.  This has often
   been done in media data sent over fixed-bandwidth channels.  Once
   this is done, a decoder for the specific media format is required to
   extract the metadata.  Also, depending on the media format, the
   metadata may need to be added at the time of encoding the media so
   that the bit-rate required for the metadata is taken into account.
   But the metadata may not be known at that time.  Inserting metadata
   at a later time can require a decode and re-encode to meet bit-rate
   requirements.

Singer & Desineni           Standards Track                     [Page 2]