When the tests in dom/media/tests/mochitest/test_peerConnection_* are executed on Mac OSX with the OS firewall turned on only a few STUN Binding Requests get send, as the user is normally to slow to click the "Accept" button in the firewall pop-up before the transmission times out. Even though no STUN responses, DTLS packets or media has been exchanged between the two ports in this case the mochitest still reports a "Pass" for all the tests! Note: test_dataChannel_* do not seem to be affected. Either because they retransmit, or because the primary audio channel does not get used by these test any how and ICE for the data channel starts a later point in time. Attaching log files for test_peerConnection_basicAudioVideo.html

Comment on attachment 8349053 [details] [diff] [review] This adds ICE connection check on both ends of PeerConnection tests Note: this implementation uses polling with an interval, but it works. I'm planing on opening a separate ticket for an implementation which utilizes oniceconnectionstatechange.

Comment on attachment 8349053 [details] [diff] [review] This adds ICE connection check on both ends of PeerConnection tests Review of attachment 8349053 [details] [diff] [review]: ----------------------------------------------------------------- Please change this to at least check for a known-bad ice state so you can fail fast when that happens. Also consider using an event model for ice state validation rather than a polling model. ::: dom/media/tests/mochitest/pc.js @@ +1335,5 @@ > + }, > + > + /** > + * Polls the ICE connection state on an interval base and > + * reports success or failure (=timeout). Polling is a rather inelegant way of taking care of this check. Also, with the current structure, the only way a failure is detected is by timing out, even when information that the connection has failed is available. I think you really want to re-write this in terms of the PC "iceconnectionstatechange" event. Basically: register an event handler for that event. If it transitions to connected, continue the tests. If it transitions to failed, disconnected, or closed, then register a failure. Don't worry about timeouts here; the mochi test framework takes care of them for us.

Thanks for the feedback. I decided to work on a better implementation in bug 951892 and use this ticket as an umbrella for a collection of problems around the mochitests.