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)