Description of RTCIceTransport.start method

[lgrahl]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

@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]

@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.