Offer/Answer Considerations for G723 Annex A and G729 Annex B
draft-ietf-mmusic-sdp-g723-g729-06
Yes
(Gonzalo Camarillo)
(Richard Barnes)
No Objection
(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)
(Spencer Dawkins)
(Stewart Bryant)
Note: This ballot was opened for revision 05 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
(for -05)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(for -05)
Unknown
Ted Lemon Former IESG member
Yes
Yes
(2014-02-19 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-02-17 for -05)
Unknown
-- 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 IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -05)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -05)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-17 for -05)
Unknown
- 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 IESG member
No Objection
No Objection
(for -05)
Unknown