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

It appears that there is a problem with having an IceGatherer respond to connectivity checks.

RFC 5245 Section 7.1.2.2 states:

7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING

The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING
attribute in the request if it is in the controlling role. The
content of either attribute MUST be the tie-breaker that was
determined in Section 5.2. These attributes are defined fully in
Section 19.1.

The problem is that an IceGatherer does not know its role, and so it cannot determine if there is a role conflict so as to correctly behave as specified in RFC 5245 Section 7.1.3.1:

7.1.3.1. Failure Cases

If the STUN transaction generates a 487 (Role Conflict) error
response, the agent checks whether it included the ICE-CONTROLLED or
ICE-CONTROLLING attribute in the Binding request. If the request
contained the ICE-CONTROLLED attribute, the agent MUST switch to the
controlling role if it has not already done so. If the request
contained the ICE-CONTROLLING attribute, the agent MUST switch to the
controlled role if it has not already done so. Once it has switched,
the agent MUST enqueue the candidate pair whose check generated the
487 into the triggered check queue. The state of that pair is set to
Waiting. When the triggered check is sent, it will contain an ICE-
CONTROLLING or ICE-CONTROLLED attribute reflecting its new role.
Note, however, that the tie-breaker value MUST NOT be reselected.

Therefore, if an IceGatherer can responds to incoming connectivity checks, the result could be an undetected role conflict.