RFC Errata
Found 1 record.
Status: Verified (1)
RFC 4352, "RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec", January 2006
Source of RFC: avt (rai)
Errata ID: 114
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-07
(1)
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
should say:
TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 <= i <= n
(2)
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
This pseudocode fragment should say:
for 0 < n < (t1 - t0)/L0
Return recovered timestamps as
x(n) = t0 + n*L0 and associated ISF equal to isf0
goto End
(3)
In Section 7.2, on page 32, the second item of the unnumbered list
says:
- The media type (payload format name) is used in SDP "a=rtpmap" as
the encoding name. [...]
It should say:
- The media subtype (payload format name) is used in SDP "a=rtpmap"
as the encoding name. [...]
(4)
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 should say:
[...] 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.
Notes:
from pending
