Re: Issue 170: Response to connectivity checks prior to calling iceTransport.start()?

Robin pointed out a potential consequence of Option 2. 

Since responding to the remote peer makes it think it is connected, if the remote peer has constructed a DtlsTransport from the IceTransport sending the check, it may initiate DTLS negotiation over the IceTransport.

If IceTransport.start() has not yet been called on the local peer, not only can the local peer not initiate its own connectivity checks, but now DTLS packets are arriving that cannot be delivered to a DtlsTransport even if one had been constructed. 

This is because prior to calling IceTransport.start(), there is no association between the IceGatherer and IceTransport, and therefore the right DtlsTransport cannot be easily determined. 

This problem would not arise with Option 4. 


Peter Thatcher said: 

"Would it make sense to rephrase this question as the following?

How do we want to deal with the case where ICE connectivity checks may
arrive before signalling (because the remote side calls
IceTransport.start() before you get their IceParameters)?


Options seem to be:
1.  Discard the check.
2.  Send back an ICE connectivity response from the IceGatherer.
3.  Buffer the check and send a response when IceTransport.start() is
called.
4.  Add some kind of IceTransport.listen(IceGatherer) which puts an
IceTransport into a "responder" state without going in to the full
"checking" state.

I'm not sure I like any of the options.

#1 seems sub-optimal. We'd be throwing away information.
#2 seems risky, since the remote side thinks its connected to something,
even though it isn't.
#3 seems tricky to implement right, and adds some unnecessary delay.
#4 adds complexity to the API and requires more effort from JS to get the
right behavior.  Although, it would give a natural way to do ice lite.

It seems like we're stuck between requiring the JS to give us more
information (that it wants a IceTransport to repond to pings before an the
remote parameters are available) and doing something tricky (either sending
responses from the gatherer or buffering the checks)."

Received on Thursday, 29 January 2015 14:44:40 UTC