Subject: RFC 4352

From: Alfred Hönes <[email-masked]>
Date: Tue, 7 Feb 2006 17:30:19 +0100 (MEZ)

Hello,
I'd like to report a few issues I've found reading the
recently published RFC 4352 (AMR-WB+ over RTP) authored
by you.

(1)  [typo in formula]

In Section 4.3.2.3 of RFC 4352, the first formula line on page 18,

      TS(i) = TS(i-1) + (DISi + 1) * frame duration,    2 < i < n

inadvertently excludes the cases i=2 and i=n, which thus remain
unspecified.
The text should say:

      TS(i) = TS(i-1) + (DISi + 1) * frame duration,    2 <= i <= n

(2)  [clarification]

The 'Example Algorithm' in Section 4.5.1, on page 27, in the
second half of Step 1, says:

   Return recovered timestamps as
   x(n) = t0 + n*L1 and associated ISF equal to isf0,
   for 0 < n < (t1 - t0)/L0
   goto End

IMHO, the "n*L1" in the second line above comes surprisingly and
should better be replaced by "n*L0" for the sake of consistency.
("L1" is not strictly wrong in that place: from the applicable
preconditions, it can be derived that L1 == L0 whenever the
above lines of pseudocode get executed.  But using "L0" instead
of "L1" would certainly enhance the readability because the
intrinsically related value of isf0 appears in the same line,
and in the next line the corresponding division is performed
by L0 as well.)
Furthermore, the intended structure of the above code fragment
could perhaps be better visualized by reversing the order of the
lines with the loop control statement and the body of the loop,
and make use of indentation for the latter.
To sum up, I propose this enhanced version:

   for 0 < n < (t1 - t0)/L0
      Return recovered timestamps as
      x(n) = t0 + n*L0 and associated ISF equal to isf0
   goto End

(3)  [clash in terminology]

In Section 7.2, on page 32, the itemized list presented starts
with:

   -  The media type ("audio") is used in SDP "m=" as the media name.

   -  The media type (payload format name) is used in SDP "a=rtpmap" as
      the encoding name.  [...]

Obviously, the second appearance of 'media type' does not refer
to the 'media type ("audio")' from the first line, but to what
usually is referred to by the term 'media subtype'.
Therefore, the above text should better say:

   -  The media type ("audio") is used in SDP "m=" as the media name.

   -  The media subtype (payload format name) is used in SDP "a=rtpmap"
      as the encoding name.  [...]

(4)  [appropriate wording]

Within the second paragraph on page 33, Section 7.2.1 of RFC 4352
says:
                                            [...]  As any receiver will
      be capable of receiving stereo frame type and perform local mixing
      within the AMR-WB+ decoder, there is normally only one reason to
      restrict to mono only: to avoid spending bit-rate on data that are
      not utilized if the front-end is only capable of mono.

It apparently should better have 'stereo frame type' replaced by
'stereo frame types', saying (with line wrapping re-adjusted to RFC
formatting rules):
                                               v
                                                   As any receiver will
|     be capable of receiving stereo frame types and perform local
      mixing within the AMR-WB+ decoder, there is normally only one
      reason to restrict to mono only: to avoid spending bit-rate on
      data that are not utilized if the front-end is only capable of
      mono.

IMHO, it would be appropriate to make the knowledge of these issues
available to other readers of the RFC, by posting of an Errata Note
to the RFC Editor's web site.
If you prefer to submit an Author's Errata Note, please make use
of the material presented above.  Otherwise, if you agree, I will
reformat it (stripping expanatory text) and submit it directly.

Additionally, I have found a few minor 'language/grammar' flaws not
mentioned above.  The details might be of interest to you should
ever an update of that RFC be intended.  Please let me know if you
are interested in getting these details for internal notice now.

BTW: I have sent today another message to the author of RFC 4348,
pointing to issues resulting from text apparently being borrowed
from RFC 4352 without proper adaptation to the particularities
of the VMR-WB RTP payload.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 9 Feb 2006 21:13:46 +0100 (MEZ)

After discussion with the authors of RFC 4352 -- the referenced
 messages have been CC'ed to you --, ...

At Tue, 07 Feb 2006 18:16:06 +0100, Magnus Westerlund wrote:
> Hi Alfred,
> 
> Thanks for the feedback, all your raised issues seems correctly
> identified and corrected. I agree that these should be included
> in an RFC errata. If you are willing to write that up we very
> much appreciate it.
>
> [...]
> 
> Please, do that.

... I hereby submit a consolidated version of the proposed
Errata Note for RFC 4352.

----------  snip  ----------

(1)

should say:

(2)

The 'Example Algorithm' in Section 4.5.1, on page 27, in the second
half of Step 1, says:

This pseudocode fragment should say:

   for 0 < n < (t1 - t0)/L0

(3)

In Section 7.2, on page 32, the second item of the unnumbered list
says:

It should say:

(4)

It should say:
      be capable of receiving stereo frame types and perform local

----------  snip  ----------

Best regards,
  Alfred Hönes.

--