On the answerer side, when the offerer (controlling ICE agent) sends a STUN check that causes ICE to transition to connected, we fire events that cause the DTLS handshake to start, and then send the response. This means that the Client Hello arrives before the STUN response, causing it to be dropped (because ICE isn't connected yet). The retransmission happens a full second later, delaying the flow of media significantly. Fixing this will not only allow our tests to run faster, but will also improve user experience somewhat.

/r/4443 - Bug 1137932: Unwind the stack before starting the DTLS handshake. Pull down this commit: hg pull review -r d505249a669520931f59b0f9bcaf772b19fe3b2e

Comment on attachment 8570744 [details] MozReview Request: bz://1137932/bwc This is one possible approach for fixing this bug. The other approach is sending the STUN response before firing the ready callback, which is currently not possible because the ready callback can return an error code that determines whether the STUN response is a 200 or not. In order to do this, we'd either need to do away with this behavior entirely, or we would need to have two ready callbacks, the first of which can fail, and the second of which can not. This would be a bit more invasive.

Seeing some persistent infra build bustage on that try push. Let's see if a rebase clears that up: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9799aed03755