RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010

Note: This RFC has been obsoleted by RFC 8445, RFC 8839

Note: This RFC has been updated by RFC 6336

Source of RFC: mmusic (rai)

Errata ID: 2338
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Reif, Frank
Date Reported: 2010-07-20
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 15.1 says:

extension-att-name    = byte-string    ;from RFC 4566

It should say:

extension-att-name    = token    ;from RFC 4566

Notes:

"extension-att-name" may contain the SP (0x20) as defined for "byte-string" in RFC 4566.
The 'SP' character cannot be allowed within "extension-att-name" as it is also used as delimiter between "extension-att-name" and "extension-att-value".

Errata ID: 3149
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Marc Petit-huguenin
Date Reported: 2012-03-07
Verifier Name: Robert Sparks
Date Verified: 2012-04-13

Section 21.1.4 says:

Type of Attribute: session-level

It should say:

Type of Attribute: media-level

Notes:

Section 15.3 clearly says that "ice-mismatch" is media-level:

'"ice-mismatch" is a media-level
attribute only, and when present in an answer, indicates that the
offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute.'

Section Section 6.1 also implies that "ice-mismatch" is media-level:

"In some cases, the answer may omit a=candidate attributes for the
media streams, and instead include an a=ice-mismatch attribute for
one or more of the media streams in the SDP."

Status: Held for Document Update (1)

RFC 5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010

Note: This RFC has been obsoleted by RFC 8445, RFC 8839

Note: This RFC has been updated by RFC 6336

Source of RFC: mmusic (rai)

Errata ID: 3107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: N V S Kaushik
Date Reported: 2012-02-05
Held for Document Update by: Robert Sparks

Section Appendix B.6 says:

However, the check from agent R has not yet 
generated a response, and agent R receives the updated offer 
(message 7) before getting the response (message 9).  

It should say:

However, the check from agent R has not yet 
received a response, and agent R receives the updated offer 
(message 7) before getting the response (message 9).  

Notes:

Here, Agent R (ideally Agent B as per the figure 11) has generated the request, so it must receive the response. The original text may give a meaning that Agent R has to generate a response.

Status: Rejected (2)

RFC 5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010

Note: This RFC has been obsoleted by RFC 8445, RFC 8839

Note: This RFC has been updated by RFC 6336

Source of RFC: mmusic (rai)

Errata ID: 3619
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Ashish Kundu
Date Reported: 2013-05-13
Rejected by: Gonzalo Camarillo
Date Rejected: 2013-05-15

Section Section 4, 5 says:

Missed candidate pair in ICE standard

It should say:

Scenario: X is caller, Z is callee. X is behind a non-full-cone 
(such as symmetric) NAT, Z is behind a full-cone NAT. 

ICE standard: Section 2.1 of RFC5245 describes the addresses that 
are collected as candidate addresses: (local address, server-reflexive 
address, TURN relay address).  For X: (X:x, X1:x1, Yx:yx), and for Z: 
(Z:z, Z1:z1, Yz:yz). 

Missed candidate pair in ICE standard: 
1. X:x sends a connection check message to the Z1:z1 (as part of the 
process in Section 2.2 of the standard) 
2. Since X is behind a non-full cone NAT such a symmetric one, NAT of 
X maps X:x to X2:x2, sends the message to Z1:z1
3. Z is behind a full-cone NAT, so packets received at Z1:z1 address 
is forwarded to Z:z by the NAT

Since X is behind a non-full cone NAT such a symmetric one and Z is 
behind a full-cone NAT, connection from X:x to Z1:z1 would be via a 
server-reflexive address X2:x2 of X, which is not a candidate address 
for X as specified by ICE. X2:x2 should be a candidate address of X, 
which however can only be determine when X sends a message to Z. The 
pair (X2:x2, Z1:z1) provides a direct connection option between X and Y.

Conditions on which X2:x2 is a valid candidate address:
1. One of the peers (Z) is behind a full-cone NAT, else step 3 above 
does not succeed.
2. X2:x2 is unique, i.e., different from X1:x1 (already covered by 
Section 2.1) if and only if one of the peers is  behind a non-full-cone 
NAT.

So I think there should be two stages in the candidate collection process:
A: Section 2.1 -- candidate addresses independent of the other clients
B: collection of the candidate pairs with respect to the peer, such as 
X2:x2 and Z2:z2, if any. 

B consists of the following steps including 1, 2, and 3:
4. Z:z determines if X2:x2 from which it received the message is a 
different address than in the candidate set of X.
5. If 4 is true, then send an OK message to X2:x2 that it received the
message with X2:x2 XOR-encoded.
6. X:x receives the OK message in 4, then X:x determines X2:x2 as its 
new candidate address.

If X:x decides to establish the connection via X2:x2, it sends ACK 
message to Z2:z2.

Notes:

This feedback for improvement of ICE candidate gathering and decision process was sent to Dr. Rosenberg on Nov 09, 2012. However, since I have not received any response from him over my next two followups and this e-mail, I thought it should be reported via this method.

This is not an error mesage, but a method to improve the candidate gathering and decision process of ICE.
--VERIFIER NOTES--

Errata ID: 3952
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Suresh Tummala
Date Reported: 2014-04-04
Rejected by: Richard Barnes
Date Rejected: 2014-04-09

Section 15.1 says:

priority = 1*10DIGIT

Notes:

priority = 1*10DIGIT

Here the maximum value it can hold is "9999999999"(ten-nines)(priority is of maximum length 10 DIGIT as per grammar in sec 15.1).

The number of bits required to hold the maximum value(ten-nines) is 34. Which requires a "double" value instead of integer of 32 bit.

Can i know why the priority is maximum of 10 DIGIT length? If possible we may decrease to 9 DIGIT, so that the value will be fit into integer of 32bit.

-- VERIFIER NOTES --
The limitation to 2^32-1 is made clear elsewhere in the text. The ABNF does not need to enforce this constraint

Report New Errata



Advanced Search