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

My suggestion would be to respond to the ice checks, record the information
about the ice check to be passed to IceTransport, and buffer the DTLS
handshakes to be passed to the DtlsTransport. This is going to be tricky to
implement no matter what we do, but I think this corresponds to the
behavior in current implementations.

_____________
Roman Shpount

On Thu, Jan 29, 2015 at 9:44 AM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> 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)."
>