Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Description of RTCIceTransport.start method #607

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

Description of RTCIceTransport.start method #607

lgrahl opened this issue Oct 11, 2016 · 11 comments
Assignees
Labels

Comments

@lgrahl
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

lgrahl commented Oct 18, 2016

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.

@robin-raymond
Copy link
Contributor

robin-raymond commented Oct 26, 2016

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
Copy link
Contributor Author

lgrahl commented Oct 26, 2016

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
Copy link
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
Copy link
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
Copy link
Contributor

robin-raymond commented Oct 26, 2016

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
Copy link
Contributor Author

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
Copy link
Contributor

aboba commented Oct 28, 2016

@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
Copy link
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
Copy link
Contributor

PR merged. Resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants