I've problems to establish a WebRTC connection when firefox is involved and a TURN server is needed. The reason is reproducable with this test tool: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Try the following stun server configuration:
URI: turn:numb.viagenie.ca
username: l1787875@mvrht.com
password: test
In chrome there appears relay candidates. In firefox there are missing. But why?
Result in Chrome 56.0.2924.87 (64-bit):
Time Component Type Foundation Protocol Address Port Priority
0.002 1 host 2969322736 udp 192.168.178.29 58537 126 | 30 | 255
0.002 1 host 1665573758 udp 2001::34ad:4890:3ce5:1be4:aa2b:d831 58538 126 | 10 | 255
0.002 2 host 2969322736 udp 192.168.178.29 58539 126 | 30 | 254
0.003 2 host 1665573758 udp 2001::34ad:4890:3ce5:1be4:aa2b:d831 58540 126 | 10 | 254
0.544 1 srflx 842163049 udp 85.212.39.206 58537 100 | 30 | 255
0.553 2 srflx 842163049 udp 85.212.39.206 58539 100 | 30 | 254
0.658 1 relay 3433799847 udp 66.228.45.110 57491 2 | 30 | 255
0.677 2 relay 3433799847 udp 66.228.45.110 57492 2 | 30 | 254
0.678 Done
Result in Firefox 51.0.1 (32-Bit):
Time Component Type Foundation Protocol Address Port Priority
0.008 1 host 0 UDP 192.168.178.29 52762 126 | 32512 | 255
0.009 1 host 3 UDP 2001:0:9d38:6abd:82d:1d5a:aa2b:d831 52763 126 | 32256 | 255
0.009 2 host 0 UDP 192.168.178.29 52764 126 | 32512 | 254
0.009 2 host 3 UDP 2001:0:9d38:6abd:82d:1d5a:aa2b:d831 52765 126 | 32256 | 254
11.234 Not reachable?
When I tested it the TURN server responds with 486 "Allocation Quota Reached". Since now I don't get relay candidates with either Chrome or Firefox I guess your TURN provider has disabled the credentials you posted here. If you can reproduce it I would recommend to take a look at about:webrtc in Firefox. It should have some log messages indicating what is going wrong. If you see something suspicious in the log it might be a bug worth filling on bugzilla.mozilla.org.
Update: I was able to reproduce the problem. Its a bug in Firefox TURN client. I created this bug tracking issue for it https://bugzilla.mozilla.org/show_bug.cgi?id=1338384
Update 2: The bug has been fixed in Firefox 54. The long explanation is that coturn includes a bandwidth attribute in its reply messages to Firefox. This bandwidth attribute has never been officially standardized. And the range in which that bandwidth attribute resides demands that if a client does not understand this attribute it is considered a parsing failure. Except that the expired draft for the bandwidth attribute specifically says it is optional to understand the meaning of the bandwidth attribute. So a poor spec attempt + a server which implemented things which were never officially speced + a client which didn't understand the result.