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

[Ballot comment]
Section 4.3.1., paragraph 3:
>    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.

  Add the usual statement of "don't send and ignore on receive" for
  "other values", i.e., 9-4.

Editing nits emailed to authors, chairs and shepherds offlist.

[Ballot comment]
Section 4.3.1., paragraph 3:
>    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.

  Add the usual statement of "don't send and ignore on receive" for
  "other values", i.e., 9-4.

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following changes
in the "RTP PARAMETERS" registry located at
http://www.iana.org/assignments/rtp-parameters
table: "RTP Payload Format MIME types
Old:
audio AMR 8000 [RFC3267]
audio AMR-WB 16000 [RFC3267]

New:
audio AMR 8000 [RFC-avt-rtp-amr-bis][RFC3267]
audio AMR-WB 16000 [RFC-avt-rtp-amr-bis][RFC3267]

We understand the above to be the only IANA Actions for this document.

State Change Notice email list have been change to avt-chairs@tools.ietf.org, qxie1@email.mot.com, Johan.Sjoberg@ericsson.com, fluffy@cisco.com, ari.lakaniemi@nokia.com, magnus.westerlund@ericsson.com from avt-chairs@tools.ietf.org, qxie1@email.mot.com,  Johan.Sjoberg@ericsson.com, fluffy@cisco.com, ari.lakaniemi@nokia.com, magnus.westerlund@ericsson.com

State Change Notice email list have been change to avt-chairs@tools.ietf.org, qxie1@email.mot.com,  Johan.Sjoberg@ericsson.com, fluffy@cisco.com, ari.lakaniemi@nokia.com, magnus.westerlund@ericsson.com from avt-chairs@tools.ietf.org, qxie1@email.mot.com,  Johan.Sjoberg@ericsson.com,  fluffy@cisco.com, ari.lakaniemi@nokia.com, magnus.westerlund@ericsson.com

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has had adequate review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus. This is a minor update to an existing,
widely implemented, specification.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes (idnits reports minor formatting issues that the RFC Editor will
trivially fix).

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where
the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. The only normative reference to an i-d is
to 3555bis, which is in IETF last call now.


1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* 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
behaviour 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.