RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

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

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

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

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

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.

Report New Errata