Subject: Protocol Action: RTP payload format for MPEG-4 Audio/Visual streams to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 22 Nov 2000 11:22:30 -0500

The IESG has approved the Internet-Draft 'RTP payload format for MPEG-4
Audio/Visual streams' <draft-ietf-avt-rtp-mpeg4-es-05.txt> as a
Proposed Standard.  This document is the product of the Audio/Video
Transport Working Group.  The IESG contact persons are Allison Mankin
and Scott Bradner.

Technical Summary

   This specification describes RTP payload formats for carrying MPEG-4
   Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems.
   It is aimed for applications (such as H.323 terminals and "mbone"
   conferencing tools) that do not require the stream control
   functionality of MPEG-4 Systems, and that therefore want payloads
   consisting of MPEG-4 Elementary Streams (ES).  The AVT Working Group is
   also developing candidate RTP payload formats for applications using
   MPEG-4 Systems, that would wish to transmit a payload of the MPEG-4 Systems
   Sync Layer (SL).  The SL work is going on in parallel.  The ES payload
   in this specification does not depend on any aspects of the work on SL.

   MPEG-4 Audio is a new kind of audio standard that integrates many
   different types of audio coding tools.  For the RTP payload for
   ES, the specification limits the bitstream to be producted by the
   MPEG-4 Low-overhead Audio Transport Multiplex (LATM) tool.  LATM
   carries data about each payload in a way that means RTP packets
   need not also carry an audio-specific header.

   For the purpose of directly mapping MPEG-4 Audio-LATM and Visual
   elementary streams onto RTP packets, the document specifies the use
   of RTP header fields for each type, fragmentation rules for them,
   MIME type registrations, and SDP information and parameters.

Working Group Summary

   The Working Group gave consensus to advance the specification,
   after resolution of a number of debated points.  The consensus
   was not unanimous, but rough consensus was obtained that the
   final draft was technically solid and suitable for implementation
   and use by applications needing MPEG-4 elementary streams,
   and in particular, by H.323 terminals.

   During IETF Last Call, the Moving Picture Experts Group
   (and some of its individual members) gave a position that
   a single specification was desirable for both ES and SL
   MPEG-4 payloads.  This is contradictory to the Application
   Layer Framing (ALF) design principle of RTP, and had also
   been previously resolved by the AVT WG in favor of separate
   development and standard payload-type signalling (as
   defined by RFC 2736, the Guidelines for Writers of RTP
   Payload Format Specifications BCP).

Protocol Quality

  The specification was reviewed for the IESG by Allison Mankin.

Note to RFC Editor:

Please replace the definition of cpresent.

From:
     cpresent: this parameter indicates whether audio payload configuration
     data has been multiplexed into an RTP payload (see section 4.1). If
     not specified, the default value is 1.

To:
     cpresent: a boolean parameter indicates whether audio payload
     configuration data has been multiplexed into an RTP payload (see
     section 4.1). A 0 indicates the configuration data has not been
     multiplexed into an RTP payload, a 1 indicates that it has. The
     default if the parameter is omitted is 1.

Also, please make the following changes:

Note 1.

In Section 5.3, MIME type registration of MPEG-4 Audio

Replace this text ->
     cpresent: this parameter indicates whether audio payload configuration
     data has been multiplexed into an RTP payload (see section 4.1). If
     not specified, the default value is 1.

With this clarifying replacement text ->
     cpresent: a boolean parameter indicates whether audio payload
     configuration data has been multiplexed into an RTP payload (see
     section 4.1). A 0 indicates the configuration data has not been
     multiplexed into an RTP payload, a 1 indicates that it has. The
     default if the parameter is omitted is 1.

Note 2.

Also in Section 5.3

Replace this text ->
   Optional parameters:
     profile-level-id: a decimal representation of MPEG-4 Audio Profile
     Level indication value defined in ISO/IEC 14496-1 [10].

With this replacement text ->
   Optional parameters:
     profile-level-id: a decimal representation of MPEG-4 Audio Profile
     Level indication value defined in ISO/IEC 14496-1 ([6] and its
     amendments).
Note 3.
Replace Section 7, References in its entirety with the following ->

   1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
     RFC 2026, October 1996.

   2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual
     objects - Part2: Visual".

   3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual
     objects - Part3: Audio".

   4 ISO/IEC 14496-2:1999/Amd 1:2000, "Information technology - Coding of
     audio-visual objects - Part 2: Visual, Amendment 1: Visual extensions".

   5 ISO/IEC 14496-3:1999/Amd 1:2000, "Information technology - Coding of
     audio-visual objects - Part3: Audio, Amendment 1: Audio extensions".

   6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-visual
     objects - Part1: Systems".

   7 Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997

   8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A Transport
     Protocol for Real Time Applications",  RFC 1889, Internet Engineering
     Task Force, January 1996.

   9 ISO/IEC 14496-2:1999/Cor 1:2000, "Information technology - Coding of
     audio-visual objects - Part2: Visual, Technical corrigendum 1".