RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec
RFC 4352

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

(Allison Mankin) Yes

(Brian Carpenter) No Objection

Comment (2005-04-25 for -)
No email
send info
Editing needed as per Mary Barnes' review:

 Summary: 
-------- 
The draft should be ready for publication as a proposed standard (with
the caveat that I am not an AMR-WB+ codec expert) with the correction
of some editorial nits (and one suggestion for normative wording in
section 4.4). 

Editorial comments: 
------------------ 
- Abstract: expand AMR. 

- Footing: authors - "et. al." should be "et al." 

- Section 1.1: I would suggest putting the word "codec" in parenthesis
  for the terms AMR, AMR-WB and AMR-WB+. The phrase "codec" is
  sometimes used along with the abbreviation when the term is used in
  the body of the document, thus "codec" in the Glossary for the term
  is redundant, although there are times when "codec" is implied. 

 - Section 3.1, 1st paragraph, 1st sentence: expand GSM and 3G (or at
   least include in the glossary).  

- Section 3.1, 11th paragraph, last sentence, page 6: change "...but
  provided higher fidelity..." to "...but provides higher
  fidelity..." 

- Section 3.6.1, last paragraph, page 10: Expand RTCP and it would
  likely be useful to include a reference to [9].  

 - Section 3.6.2, 1st paragraph, 1st sentence: "...frames be
   encapsulated..." should be "...frames to be encapsulated..." 

- Section 4, 1st paragraph, last sentence: "...all frames types."
  should be "...all frame types." or "...all types of frames." 

- Section 4.3.2.3, 1st paragraph, 5th sentence: "First, sum of the
  frame durations..." should be "First, the sum of the frame
  durations..." 

- Section 4.3.2.3, paragraph after the "TS(1)" equation, last
  sentence, page 18: "...the same way is for the first group." should
  be "...the same way as for the first group." 

- Section 4.3.2.4, 2nd paragraph, last sentence: should be reworded from: 
" Thus also frames of type 0-9 will have a derived TFI, which is ignored." 
to: 
" Thus, frames of type 0-9 will also have a derived TFI which is ignored." 

- Section 4.3.2.5, 1st paragraph, 1st sentence: would read much more clearly if changed from: 
"If receiving a ToC entry with a FT value not defined, the whole 
 packet SHALL be discarded." 
to: 
" If a ToC entry with an undefined FT value is received, the whole 
 packet SHALL be discarded." 

- Section 4.3.2.5, 3rd paragraph, 1st sentence: change " ... the TOC
  entry represent independently of ..." to "... the TOC entry
  represents, independent of ..." 

 - Section 4.4. 1st paragraph, last sentence. "...actual memory
   requirement..." should be either "...actual memory requirements..."
   OR " ...an actual memory requirement...". 

 - Section 4.4, 3rd paragraph, last sentence. "This problem also arise
   when..." should be "This problem also arises when..." 

- Section 4.4, 4th paragraph, first sentence. Propose to reword from: 
" Although the AMR-WB+ is robust and thus tolerant to high random 
 frame erasure rate, it would have difficulties to handle consecutive 
 frame loss at startup." 
to: 
" Although the AMR-WB+ is robust and thus tolerant to a high random 
 frame erasure rate, it would have difficulties handling consecutive 
 frame losses at startup." 

- Section 4.4, 4th paragraph, third sentence. Should this not be
  normative wording (i.e. "MAY only" or "SHOULD only" rather than "can
  only"), particularly given that the following sentence is normative
  and the two points are listed as special implementation
  considerations? 

- Section 4.4, 5th paragraph, 1st sentence: "...in worst case..."
  should be "...in the worst case..."  

- Section 6.1, 2nd paragraph, 1st sentence: "...can have negative
  impact..." should be "...can have a negative impact..." 

- Section 7.1 page 31, 1st sentence: "...may need to be appropriate
  encoded..." should be "...may need to be appropriately encoded..."

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2005-04-21 for -)
No email
send info
Same question as in the vmr-wb doc applies here.

(Sam Hartman) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection