Skip to main content

RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
draft-ietf-avt-rtp-amr-bis-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    avt mailing list <avt@ietf.org>, 
    avt chair <avt-chairs@tools.ietf.org>
Subject: Protocol Action: 'RTP Payload Format and File Storage 
         Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate 
         Wideband (AMR-WB) Audio Codecs' to Proposed Standard 

The IESG has approved the following document:

- 'RTP Payload Format and File Storage Format for the Adaptive Multi-Rate 
   (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs '
   <draft-ietf-avt-rtp-amr-bis-07.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-bis-07.txt

Ballot Text

* Technical Summary

This document specifies a real-time transport protocol (RTP) payload
format to be used for Adaptive Multi-Rate (AMR) and Adaptive
Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload
format is designed to be able to interoperate with existing AMR and
AMR-WB transport formats on non-IP networks. In addition, a file
format is specified for transport of AMR and AMR-WB speech data in
storage mode applications such as email. Two separate media type
registrations are included, one for AMR and one for AMR-WB,
specifying use of both the RTP payload format and the storage
format. This document obsoletes RFC 3267.


* Working Group Summary

This is an update to RFC 3267, to properly define offer/answer 
behavior and to clarify various other details in light of 
implementation experience. It was not controversial.

* Protocol Quality

This is an update to a very widely implemented RTP payload format, 
incorporating a series of clarifications in the light of 
implementation experience. The media type review occurred in July 
2006, with no objections. Harikishan Desineni provided working group 
last call comments.

Note to RFC Editor 

OLD:

    CMR (4 bits): Indicates a codec mode request sent to the speech
       encoder at the site of the receiver of this payload.  The value
       of the CMR field is set to the frame type index of the
       corresponding speech mode being requested.  The frame type index
       may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for
       AMR-WB, as defined in Table 1a in [4].  CMR value 15 indicates
       that no mode request is present, and other values are for future
       use.

NEW:

    CMR (4 bits): Indicates a codec mode request sent to the speech
       encoder at the site of the receiver of this payload.  The value
       of the CMR field is set to the frame type index of the
       corresponding speech mode being requested.  The frame type index
       may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for
       AMR-WB, as defined in Table 1a in [4].  CMR value 15 indicates
       that no mode request is present, and other values are for future
+      use. A CMR value that is not a speech mode or NO_DATA SHALL NOT
+      be sent and if received it SHALL be ignored.

DELETE (First paragraph on page 17):

    If receiving a payload with a CMR value that is not a speech mode or
    NO_DATA, the CMR MUST be ignored by the receiver.

Section 4.5:
OLD:

    No operating mode of the payload format is mandatory to implement.
    The requirements of the application using the payload format should
    be used to determine what to implement.  To achieve basic
    interoperability an implementation SHOULD at least implement both
    bandwidth-efficient and octet-aligned modes for a single audio
    channel.  The other operating modes: interleaving, robust sorting,
    and frame-wise CRC in both single and multi-channel, are OPTIONAL to
    implement.

NEW:

    No operating mode of the payload format is mandatory to implement.
    The requirements of the application using the payload format should
    be used to determine what to implement.  To achieve basic
    interoperability an implementation SHOULD at least implement both
    bandwidth-efficient and octet-aligned modes for a single audio
    channel.  The other operating modes: interleaving, robust sorting,
    and frame-wise CRC in both single and multi-channel, are OPTIONAL to
    implement. Any specification that utilize this RTP payload format
    SHOULD specify at least one payload format mode as mandatory to
    implement.


IESG Note
 (none)

IANA Note
 (none)

RFC Editor Note