Offer/Answer Considerations for G723 Annex A and G729 Annex B
RFC 7261

Note: This ballot was opened for revision 05 and is now closed.

(Gonzalo Camarillo; former steering group member) Yes

Yes ( for -05)
No email
send info

(Richard Barnes; former steering group member) Yes

Yes ( for -05)
No email
send info

(Ted Lemon; former steering group member) Yes

Yes (2014-02-19 for -05)
No email
send info
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!

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2014-02-17 for -05)
No email
send info
-- 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?

(Benoît Claise; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-02-17 for -05)
No email
send info
- 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.

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -05)
No email
send info