Offer/Answer Considerations for G723 Annex A and G729 Annex B
draft-ietf-mmusic-sdp-g723-g729-06

[Ballot comment]
The abstract would read better (IMHO) if you used the same terminology as in the title of the draft:

  This document provides the offer/answer considerations for the G723
  Annex A and the G729, G729D and G729E Annex B parameter
  when the value of the Annex A or Annex B parameter does not match in
  the Session Description protocol (SDP) offer and answer.

It's good to see this work happening—thanks for doing it!

[Ballot comment]
-- Section 3 --

This came at me from out of the blue when I read it.  What does it have to do with Annex A or Annex B?  You talk about comfort noise frames in here, without any other mention of them in the document.  What is Section 3 here for?

-- Sections 3.1 and 3.2 --

This is purely an editorial point -- I think you're saying, technically, what you need to say -- but I find these two sections to be rather convoluted.  I think, for example, this specifies the same thing, more clearly and concisely:

NEW (Section 3.1)
When a G723 offer or answer lacks an "annexa" parameter, "annexa=yes" is implied.

When a G723 offer and its corresponding answer both specify or imply "annexa=yes", then G723 is negotiated with "annexa=yes".

Otherwise ("annexa=no" is specified in either or both of the offer and answer), then G723 is negotiated with "annexa=no"
END

Is there really a reason for the rest of the wordiness, which I think actually comes across as confusing?

[Ballot comment]

- I think a reference to RFC 6562 in the security
considerations would be useful.

- Based on 6562, I also wondered if it'd really be
better for the defaults to be turned around from
missing==yes to missing==no? Even if that's not
feasible, were it desirable, it'd be worth noting.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mmusic-sdp-g723-g729-04, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  RFC4856 describes the annexa parameter for G723 and the annexb
  parameter for G729, G729D and G729E. However, the specification does
  not describe the offerer and answerer behavior when the value of the
  annexa or annexb parameter does not match in the Session Description
  protocol(SDP) offer and answer.  This document provides the offer/
  answer considerations for these parameters and updates RFC4856.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/ballot/


No IPR declarations have been submitted directly on this I-D.