Description of RTCIceTransport.start method #607

Closed
lgrahl opened this Issue Oct 11, 2016 · 11 comments

Projects

None yet

3 participants

@lgrahl
lgrahl commented Oct 11, 2016

I have a few questions regarding the RTCIceTransport.start method:

When start() is called again, RTCIceTransportState transitions to the connected state

What if the current state is new, checking or failed? connected wouldn't make sense then, right?

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.

OK. But what is supposed to happen in case start() is called for the first time and the RTCIceGatherer instance is different to the one the RTCIceTransport instance has been created with?

@lgrahl
lgrahl commented Oct 11, 2016

Another thing:

[...] Since start() provides role information, as well as [...]

But role is optional. What is supposed to happen if it's not set?

@lgrahl
lgrahl commented Oct 18, 2016 edited

I guess the ICE transport instance should assume controlling as its role and the ICE protocol takes care of the rest? If that is how it's intended, this should be mentioned in the start method description.

@aboba aboba added a commit that referenced this issue Oct 25, 2016
@aboba aboba Description of RTCIceTransport.start method
Fix for Issue #607
a3dca94
@aboba aboba self-assigned this Oct 25, 2016
@robin-raymond
Contributor
robin-raymond commented Oct 26, 2016 edited

start rules?

  1. First time called, gather is the same, local candidates are maintained, start pairing with remote candidates, transport go into checking
  2. First time called, gather is changed from constructor, flush local candidates, flush candidate pairs, take new gatherer's candidates and pair with remote candidates, transport go into checking
  3. Called again, gatherer is changed, remote ufrag/password kept, local candidates are flush, all pairs are flush, start pairing new gathered local candidates with existing remote candidates, transport go back into checking
  4. Called again, gather is same, remote ufrag/password changed, local candidates are kept, all remote candidates are flushed, all pairs are flush, transport goes back into checking
  5. Called again, gather and remote ufrag/pasword changed, local candidates are flush, remote candidates are flushed, all pairs are flushed, gather goes back to checking
  6. Called again, gather and remote ufrag/password same. Noop.
  7. Role changed from last start call - exception is thrown.
@lgrahl
lgrahl commented Oct 26, 2016 edited

Called again, gather and remote ufrag/password same. Noop.

So, in order to be able to gather new interfaces added since the first gathering call, I will have to create a new ICE gatherer. Is this intended?

@robin-raymond
Contributor

@lgrahl no, new local interfaces should be announced by the gatherer without needing to call gather again, that's automatic because gatherer can go from completed to gathering whenever new interfaces come online.

@robin-raymond
Contributor

small correct to rules, go to disconnected state when all remote candidates are flushed, because there are no possible pairs to check (yet).

@robin-raymond
Contributor
robin-raymond commented Oct 26, 2016 edited

correction (again), maybe it should be new as the new state is when we have no remote candidates (yet), so maybe new state makes more sense. The trouble is the state diagram does not allow going back to new, so maybe it does need to be disconnected.

@lgrahl
lgrahl commented Oct 26, 2016

new local interfaces should be announced by the gatherer without needing to call gather again

It would help to add this to the RTCIceGatherer description as well.

I understand that it's a bit hard to add all this information to a simple state diagram. Furthermore, it's probably even harder to extract this information from the state diagram. So, maybe it would be more helpful to simply write down the rules above?

@aboba
Contributor
aboba commented Oct 28, 2016 edited

@robin-raymond The current RTCIceTransportState description says that the disconnected state can only be reached if there is at least one remote candidate. So it seems to me that when remoteParameters changes, but before remote candidates are added, the state has to transition to new. This is not an issue for the RTCIceTransportState transition diagram since new can be reached from any state except closed.

@aboba
Contributor
aboba commented Oct 28, 2016

@lgrahl The description of the complete state in RTCIceGathererState says:

Events such as adding, updating or removing an interface, or adding, changing or removing a TURN server will cause the state to go back to gathering before re-entering complete once all candidate changes are finalized.

@aboba aboba removed the PR exists label Oct 28, 2016
@robin-raymond
Contributor

PR merged. Resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment