RFC Errata
Found 5 records.
Status: Verified (1)
RFC 5404, "RTP Payload Format for G.719", January 2009
Source of RFC: avt (rai)
Errata ID: 3245
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ravi Kumar
Date Reported: 2012-06-04
Verifier Name: Robert Sparks
Date Verified: 2012-06-07
Section 7.1 says:
7.1. Media Type Definition
int-delay:
int-delay = "int-delay:" source-delay *("," source-delay)
source-delay = SSRC ":" delay-value
SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format
delay-value = 1*5DIGIT ; The delay value in milliseconds
Example: int-delay=ABCD1234:1000,4321DCB:640
NOTE: No white space allowed in the parameter before the end of
all the value pairs
It should say:
int-delay = "int-delay=" source-delay *("," source-delay)
source-delay = SSRC ":" delay-value
SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format
delay-value = 1*5DIGIT ; The delay value in milliseconds
Example: int-delay=ABCD1234:1000,4321DCB:640
NOTE: No white space allowed in the parameter before the end of
all the value pairs
Notes:
int-delay ABNF does not match example mention in RFC.
"int-delay:" need to change to "int-delay="
7.2. Mapping to SDP
o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type parameter string as a
semicolon-separated list of parameter=value pairs.
As per section 7.2 int-delay parameter should be part of a=fmtp line and it should have parameter as parameter=value pair.
But as per ABNF it should be int-delay:<value>
Also example mentions that int-delay=<value>
Status: Held for Document Update (4)
RFC 5404, "RTP Payload Format for G.719", January 2009
Source of RFC: avt (rai)
Errata ID: 1668
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings
Section 5.6.2, pg.13 says:
[...]. Although
| the G.719 is robust and thus tolerant to a high random frame erasure
rate, it would have difficulties handling consecutive frame losses at
startup. Thus, some special implementation considerations are
described.
It should say:
[...]. Although
| the G.719 decoder is robust and thus tolerant to a high random frame
erasure rate, it would have difficulties handling consecutive frame
losses at startup. Thus, some special implementation considerations
are described.
Notes:
Rationale: Word omission; "decoder" inserted after "the G.719".
Errata ID: 1669
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings
Date Held: 2009-01-28
Section 7.1, pg.18 says:
CBR: Constant Bitrate (CBR) indicates the exact codec bitrate in
bits per second (not including the overhead from packetization,
RTP header, or lower layers) that the codec MUST use. "CBR" is to
be used when the dynamic rate cannot be supported (one case is,
e.g., gateway to H.320). "CBR" is mostly used for gateways to
| circuit switch networks. Therefore, the "CBR" is the rate not
including any FEC as specified in Section 4.3.1. If FEC is to be
| used, the "b=" parameter MUST be used to allow the extra bitrate
needed to send the redundant information. [...]
It should say:
CBR: Constant Bitrate (CBR) indicates the exact codec bitrate in
bits per second (not including the overhead from packetization,
RTP header, or lower layers) that the codec MUST use. "CBR" is to
be used when the dynamic rate cannot be supported (one case is,
e.g., gateway to H.320). "CBR" is mostly used for gateways to
| circuit switched networks. Therefore, the "CBR" is the rate not
including any FEC as specified in Section 4.3.1. If FEC is to be
| used, the "b=" SDP parameter MUST be used to allow the extra
bitrate needed to send the redundant information. [...]
Notes:
Rationale:
a) Typo; s/circuit switch/circuit switched/
b) In the context of the discussion of media type parameters,
also using the unqualified term "parameter" for an SDP parameter
is rather confusing; for clarity, "SDP" needs to be inserted.
Additional note from authors of RFC ...
This text should probably not talk about SDP
parameters at all, but rather the need for external functionality that
indicates the actual bitrate of the RTP session as due to the
FEC/Redundancy the CBR value is not a good indicator of the total bitrate.
Errata ID: 1670
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings
Section 7.2.1, pg.21 says:
<< on top of page 21 >>
[...]. The answerer is
recommended to include in its answer an "int-delay" parameter
to declare what the property is for the stream it is going to
| send. The answer is expected to be capable of selecting a
valid parameter value that is between zero and the declared
maximum number of slots in the de-interleaving buffer.
It should say:
[...]. The answerer is
recommended to include in its answer an "int-delay" parameter
to declare what the property is for the stream it is going to
| send. The answerer is expected to be capable of selecting a
valid parameter value that is between zero and the declared
maximum number of slots in the de-interleaving buffer.
Notes:
Rationale: Confusing typo; s/answer/answerer/
Errata ID: 1754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Magnus Westerlund
Date Reported: 2009-04-03
Held for Document Update by: Cullen Jennings
Section 12.1 says:
[ITU-T-G719] ITU-T, "Specification : ITU-T G.719 extension for 20
kHz fullband audio", April 2008.
It should say:
[ITU-T-G719] ITU-T, "Specification: ITU-T G.719 Low-complexity, full-band audio coding for high-quality, conversational applications", June 2008.
Notes:
Steven Botzko informed me that the Reference title is not correct, nor is the publication date for the G.719 reference. However, there should be little issues with finding the correct reference based on Recommendation number.