Section 3.3.2: ICE re-start #166

Closed
aboba opened this Issue Dec 8, 2014 · 5 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Dec 8, 2014

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 aboba added the 1.1 label Dec 8, 2014
@aboba
Contributor
aboba commented Dec 8, 2014

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
juberti commented Dec 12, 2014

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
Contributor
aboba commented Jan 5, 2015

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.

@robin-raymond robin-raymond pushed a commit that referenced this issue Jan 22, 2015
Robin Raymond Updated Section 8.3 to reflect proposed matching rules, reflecting:
#48

Update to the Statistics API, reflecting:
#85

Update on 'automatic' use of scalable video coding, as noted in:
#156

Update to the H.264 parameters, as noted in:
#158

Update to the 'Big Picture', as noted in:
#159

Added support for maxptime, as noted in:
#160

Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in:
#161

Update to RTCRtpUnhandledEvent as noted in:
#163

Added support for RTCIceGatherer.state as noted in:
#164

Revised the text relating to RTCIceTransport.start() as noted in:
#166

Added text relating to DTLS interoperability with WebRTC 1.0, as noted in:
#167

Revised the text relating to RTCDtlsTransport.start() as noted in:
#168

Clarified handling of incoming connectivity checks by the RTCIceGatherer as noted in:
#170

Added a reference to the ICE consent specification, as noted in:
#171
a927ecf
@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 notifications@github.com 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
Contributor
aboba commented Jan 6, 2016

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.

@aboba aboba closed this Jan 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment