Issue 166: Section 3.3.2: ICE re-start

Currently the text on RTCIceTransport.start states:

"The first time start is called candidate connectivity checks are started and the ICE transport attempts to connect to the remote RTCIceTransport... If start is called again, an ICE restart occurs, all remote candidates are flushed, and addRemoteCandidates or setRemoteCandidates must be called to add the remote candidates back or replace them."

This raises several questions:

In an ICE restart as defined in RFC 5245, the ICE ufrag/password is changed and candidates are re-gathered. This would imply constructing a new RTCIceGatherer object to use when calling RTCIceTransport.start again. What happens if an existing RTCIceGatherer is used when calling start again?

What happens to the IceTransport state when .start is called again with a new IceGatherer? 

Here are some proposed changes to clarify the text: 

"start
The first time start() is called, candidate connectivity checks are started and the ICE transport attempts to connect to the remote RTCIceTransport. If start() is called with invalid parameters, throw an InvalidParameters exception. When start() is called again, the RTCIceTransport transitions to the "new" state, all remote candidates are flushed, and addRemoteCandidates or setRemoteCandidates must be called to add the remote candidates back or replace them.

If an RTCIceGatherer object is constructed and passed as an argument when start() is called again, an ICE restart as defined in [RFC5245] Section 9.2.1.1 occurs. If an RTCIceGatherer object in the "sleeping" state is passed as an argument to start(), throw an InvalidParameters exception."

Received on Monday, 8 December 2014 18:28:15 UTC