Section 3.3.2: ICE re-start

[aboba]

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:

1. 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?
2. What happens to the IceTransport when .start is called again with a new IceGatherer? Does it go back to the "connecting" state and out of the "completed" state?

[aboba]

Here is the recommended change to 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."

[juberti]

When start() is called again, I don't think we want to transition to the new state - we're still connected, so we should probably just go back to the connected state.

If a new ICEGatherer is supplied, we want to flush the existing local candidates, get a new ufrag/pwd, and then transition from the existing candidate pair to a new candidate pair with new local candidates.

If a new ICEGatherer is not supplied, we want to reuse the existing local candidates, use the same local ufrag/pwd, but it's not clear whether we need to transition from the existing candidate pair to a new candidate pair. I think we need to understand how this "lite restart" would work.

[aboba]

Here is the proposed text for Section 3.3.2:

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, RTCIceTransportState transitions to the "connected" state, all remote candidates are flushed, and addRemoteCandidates or setRemoteCandidates must be called to add the remote candidates back or replace them.

If a newly constructed RTCIceGatherer object is 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 with RTCIceGathererState of "completed" is passed as an argument to start(), the existing (unpruned) local candidates are reused and the ICE ufrag/password remains unchanged. However, other aspects of the behavior in this case are not currently defined.

[pthatcherg]

I thought the local ufrag/pwd was tied to the RTCIceGatherer. Wouldn't
that mean that if I call IceTranpsort.start(iceGatherer1) and then
IceTranpsort.start(iceGatherer2),
it would use the ICE ufrag/pwd of iceGatherer2? The text you just sent
says "remain unchanged", implying it would use the ICE ufrag/pwd of
iceGatherer1.

The rest sounds good to me (the idea of "lite restart" when the passed-in
gatherer is already completed).

On Mon, Jan 5, 2015 at 11:34 AM, aboba [email protected] wrote:

Here is the proposed text for Section 3.3.2:

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,
RTCIceTransportState transitions to the "connected" state, all remote
candidates are flushed, and addRemoteCandidates or setRemoteCandidates must
be called to add the remote candidates back or replace them.

If a newly constructed RTCIceGatherer object is 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 with RTCIceGathererState of
"completed" is passed as an argument to start(), the existing (unpruned)
local candidates are reused and the ICE ufrag/password remains unchanged.
However, other aspects of the behavior in this case are not currently
defined.

—
Reply to this email directly or view it on GitHub
#166 (comment).

[aboba]

Here is the current text in the document:

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. For example, if gatherer.component has a value different from iceTransport.component, throw an InvalidParameters exception. If state or gatherer.state is "closed", throw an InvalidStateError exception. When start() is called again, RTCIceTransportState transitions to the "connected" state, all remote candidates are flushed, and addRemoteCandidate() or setRemoteCandidates() must be called to add the remote candidates back or replace them.

If a newly constructed RTCIceGatherer object is passed as an argument when start() is called again, an ICE restart as defined in [RFC5245] Section 9.2.1.1 occurs. Since start() does not change the username fragment and password of gatherer, if start() is called again with the same value of gatherer, the existing local candidates are reused and the ICE username fragment and password remains unchanged. However, other aspects of the behavior are not currently defined.

As noted in [RFC5245] Section 7.1.2.3, an incoming connectivity check utilizes the local/remote username fragment and the local password, whereas an outgoing connectivity check utilizes the local/remote username fragment and the remote password. Since start() provides role information, as well as the remote username fragment and password, once start() is called an RTCIceTransport object can respond to incoming connectivity checks based on its configured role, as well as initiating connectivity checks.