2

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?

JT2809
  • 324
  • 1
  • 5
  • 16
  • Can you list the candidates you are seeing? I see no relay candidates even in Chrome. E.g. Under *ICE options*, if I set *IceTransports value:* to *relay* I see zero candidates. – jib Feb 08 '17 at 21:07
  • You're right. I've edited the question. – JT2809 Feb 09 '17 at 12:11

3 Answers3

3

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.

Nils Ohlmeier
  • 1,061
  • 7
  • 8
  • Looks the quota is not exceeded any more and I see the following error message on about:webrtc (I'll have a look at this later today): Unrecognized attribute: 0x0010 STUN-CLIENT(relay(IP4:10.252.27.46:50759/UDP|numb.viagenie.ca:3478)::TURN): Received response; processing STUN-CLIENT(relay(IP4:10.252.27.46:50759/UDP|numb.viagenie.ca:3478)::TURN): Error processing response: Operation rejected, stun error code 0. ICE(PC:1486673561857884 (id=2147488911 url=https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)): Message does not correspond to any registered stun ctx – Nils Ohlmeier Feb 09 '17 at 20:54
  • Ok, my WebRTC know-how is limited, but it seems not to be an issue with my application code. Theoretical great, but is there a solution on server or client side to get it running? I had also tried a docker image with coTurn. Same issue. – JT2809 Feb 13 '17 at 11:34
  • No it's not a issue in your application code. The problem is that coturn sends adds an attribute to its messages which Firefox was not able to handle properly. The problem has been fixed in Firefox 54 (which is Firefox Nightly right now). I don't know if you can somehow configure coturn to not send the bandwidth attribute. – Nils Ohlmeier Feb 14 '17 at 17:24
  • same problem here with ios webrtc native, after check log i found if (!config || config->relays.empty()) { // No relay ports specified in this config. sequence_flags |= PORTALLOCATOR_DISABLE_RELAY; } Can someone help? im using google stun – famfamfam Jul 08 '20 at 09:54
  • A STUN server will not give you relay candidates, because it is not a TURN server. Only TURN servers give our relay candidates. – Nils Ohlmeier Jul 09 '20 at 19:54
0

For those who got to this question and no answer helped, my issue was that Firefox (tested on v. 92) doesn't support turn server which has no credentials set. I was always getting only host type candidates.

I was getting following errors in about:webrtc

short term auth failed
Error processing response: Operation rejected, stun error code 0.
Message does not correspond to any registered stun

Set coturn config:

lt-cred-mech
user=yourUser:yourPassword
realm=domain.com

Also set the name/password in your client app and you should get relay/srflx as well now.

Marax
  • 314
  • 3
  • 8
-1

Turn needs realm for its authentication process.

For some reason firefox appends an empty realm if it can't find one but chrome and edge don't append any default realm. Since chrome and edge are not appending any realm your TURN server will not be able to authenticate. If you capture packets using wireshark you'll see that its flooded with "Authentication failed" for stun protocol.

The fix is to provide a realm in your TURN server configuration. Otherwise you'll see no relay candidates in chrome and edge as their is no authenticated turn server.

So open your TURN server config and add below line.

realm : <any-string>
Prakhar Shukla
  • 3
  • 1
  • 7