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

Previously on the list we have discussed potential issues that can result by having an IceGatherer respond to connectivity checks.  Since an IceGatherer has no "role" it cannot detect role conflicts and this could cause a problem.

Prohibiting any response to an incoming connectivity check until iceTransport.start() is called seems likely to impact performance, so that is not a great solution.

There is also the issue that once a response to a connectivity check is sent, incoming DTLS negotiation packets can arrive and this could lead to the DTLS negotiation being completed (and even incoming media!) even dtlsTransport.start() hasn't been called yet, so that the remote fingerprint hasn't been verified.  I would note that before receiver.receive is called, receiver.kind is not defined, so that the receiver cannot be wired up to an <audio> tag yet.  So with all of this, things can get a bit messy which could result in lost packets/delays/poor performance.

Peter has suggested that it would be helpful for an IceTransport to be automatically set up on receipt of an incoming connectivity check, so that it can be wired up to a DtlsTransport.

Since there is a lot to talk about relating to this issue (and related ones), it would be good to reserve some time during the upcoming ORTC CG meeting to go over it.