Receiving data before transports are constructed

[steveanton]

Once gather() and start() have been called on the RTCIceTransport, it will begin to establish connections. What happens if application data is received on the selected connection before a transport has been connected to it (e.g., via an RTCQuicTransport or RTCDtlsTransport constructor)?

The simplest option would be to drop the packets.

Alternatively, the ICE transport could buffer a small amount of incoming data (e.g., enough for a QUIC handshake).

[aboba]

Prior to calling start(), the RTCIceTransport can receive connectivity checks but won't be able to respond since the role has not been determined yet.

After calling start(), the RTCIceTransport responds to incoming connectivity checks, and can also send outgoing checks. Once it responds successfully to an incoming connectivity check, the remote peer can start QUIC or DTLS negotiation (e.g. as a result of calling start(remoteParameters)).

Both of these issues can be addressed with a small buffer. One case in which this might be useful is forking (e.g. the local peer constructed a RTCDtlsTransport or RTCQuicTransport, but not one for the fork receiving the incoming data).