Not clear when responding PeerConnection reaches iceconnectionstate = completed

[alvestrand]

Current spec text on RTCIceConnectionState enum:

completed The ICE Agent has finished gathering and checking and found a connection for all components. Open issue: it is not clear how the non controlling ICE side knows it is in the state.

It turns out that at least in Chrome, the last transition seems not to happen, so this is a problem for implementors too.

[juberti]

When using regular nomination, receipt of USE-CANDIDATE indicates completion. When using aggressive nomination, you need to set a 3 second timer from when you go into the connected state (https://tools.ietf.org/html/rfc5245#section-8.3.1).

[fluffy]

I think this is all covered in ICE so not clear to me we need to add anything

[alvestrand]

Closing with resolution "no change needed, RFC 5245 section 8.3.1 covers this".

[dontcallmedom]

I think the issue should be re-opened until the "open issue" text in the description of "completed" in the spec is removed (ideally replaced with a reference to RFC 5245 section 8.3.1 :)

[alvestrand]

Agreeed, the "open issue" needs to go.

[aboba]

The controlled side should enter the "completed" state once it has received a "candidates complete" signal from the controlling side, and has provided this information to the API. The specification should indicate how this works.

Since Section 4.3.2.3 says it is not possible to pass a null RTCIceCandidate to addIceCandidate(), it cannot be done that way.

JSEP Sections 5.2.2 and 5.3.2 state (for Offers and Answers):

  If candidate gathering for the section has completed, an "a=end-of-candidates" attribute MUST be     
  added, as described in [I-D.ietf-mmusic-trickle-ice], Section 9.3.

Given this, does the controlled side reach the "completed" state once an an a=end-of-candidates line is provided to setRemoteDescription()?

[stefhak]

Using a=end-of-candidates to trigger going to "completed" would mean that for applications that use Trickle and that do no SDP exchanges after the initial setup "completed" is never reached. Is that an issue worth considering?

[alvestrand]

See Justin's April 30 comment. This doesn't refer to any SDP exchange or end-of-candidates, just stuff that happens with ICE candidates on the wire (where the browser sees it, not the app).

Note that this bug refers to ICEConnectionState enum's "completed", nothing else.

Closing, since the "Issue:" was removed on July 31.

[stefhak]

@juberti I can't really read out the following from RC5245 - could you give pointers?: "When using regular nomination, receipt of USE-CANDIDATE indicates completion. When using aggressive nomination, you need to set a 3 second timer from when you go into the connected state (https://tools.ietf.org/html/rfc5245#section-8.3.1)."