STUN binding request failing though IP and port are reachabe

1
votes

I am testing a WebRTC application that works perfectly well on hundreds of pairs of peers but fails on one specific peer (Matt below). Consider:

  • Alice : Peer on which WebRTC app works (laptop on a home network behind a NAT)
  • Bob : Peer on which WebRTC app works (Ubuntu server in a corporate network).
  • Matt : Peer on which WebRTC app does not work (Ubuntu server in a corporate network)
  • Server : An Ubuntu 18.04 EC2 instance I used for simulating STUN and TURN (more on this below)

The STUN and TURN servers used are:

stun:global.stun.twilio.com:3478
turn:global.turn.twilio.com:3478 (with credentials)

Issue
Alice and Bob perform WebRTC signalling and iceConnectionState becomes connected within 0.92s.

[0.074] onIceServers: [object Object],[object Object],[object Object],[object Object]
[0.081] createOffer
[0.161] onAnswer
[0.17] ICE STATE: new
[0.171] onTrack
[0.234] addIceCandidate
[0.235] addIceCandidate
[0.73] addIceCandidate
...
[0.928] ICE Connected

Now, Alice and Matt attempt signaling and iceConnectionState does not change to connected for up to 60s. If we wait till ~70s, the state changes to failed.

[0.143] onIceServers: [object Object],[object Object],[object Object],[object Object]
[0.147] createOffer
[0.399] onAnswer
[0.408] ICE STATE: new
[0.409] onTrack
[0.541] addIceCandidate
[0.541] addIceCandidate
...
[15.528] addIceCandidate
[76.77] ICE FAILURE: failed

Alice and Bob each attempt signaling using identical code / stack with 100 other peers, and, in each case, the peer connection was established and the iceConnectionState change to connected within 2-3 seconds.

We perform the following tests on Matt

Test 1: IP/port reachability
The following works:

telnet global.turn.twilio.com 3478

This confirms outgoing TCP traffic to port 3478 and the twilio servers is not blocked.

Test 2: UDP traffic
I created a simple netcat listener on Server as follows:

nc -ul 3478

Then Matt was able to send packets to this server as follows:

nc -u <SERVER_IP> 3478

This confirms outgoing UDP traffic to port 3478 is not blocked.

Test 3: Stuntman
Alice and Bob are both able perform stun binding successfully:

root@XXXX:/# stunclient --verbosity 9 global.stun.twilio.com 3478
Resolved global.stun.twilio.com to 54.244.51.6:0
config.fBehaviorTest = false
config.fFilteringTest = false
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 54.244.51.6:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 54.244.51.6:3478
Got response (76 bytes) from 54.244.51.6:3478 on interface 10.1.13.185:47172
Other address is 54.244.51.6:3479

Binding test: success
Local address: 10.1.13.185:47172
Mapped address: 50.209.172.197:47172

However, Matt fails the binding test:

root@YYYYY:/# stunclient --verbosity 9 --mode full global.stun.twilio.com 3478
Resolved global.stun.twilio.com to 34.203.250.156:0
config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 34.203.250.156:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 34.203.250.156:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 34.203.250.156:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Binding test: fail
Behavior test: fail
Filtering test: fail

The same test was performed with stunserver --primaryport 8085 on Server. The outcome was identical.

==================

Have the following questions regarding Matt:

  • If STUN server's IP and port are reachable and UDP traffic is not blocked, why is the stunclient request failing?
  • What does the IT administrator need to do to allow STUN requests? What should my ask be?
  • Why is the peer connection not being established through the TURN server? I can confirm the Twilio TURN server works. I'm seeing traffic from other peers on my Twilio account and the Trickle ICE test here succeeds as well. Isn't TURN supposed to relay traffic when STUN fails to find an external IP/port for a peer?

Thanks!

1
networkingwebrtcnatstunturn

1 Answers

0
votes

I have a WebRTC project that was having similar problems. A Peer on a ubuntu digital ocean was unable to connect. What I found was

I had to open up the ports on the digital ocean fire wall. these are the ports I had to enable

#+BEGIN_SRC
  107  ufw allow 49152:65535/udp
  108  ufw allow 3478/udp
  109  ufw allow 3478/tcp
#+END_SRC

Note you want both 3478 udp and tcp. In my case I was using the Coturn STUN/TRUN server and it was configured to run on this ports

    environment:
      - TURN_PORT_START=49152
      - TURN_PORT_END=65535

I think those are the default TURN range but not sure if turn:global.turn.twilio.com:3478 is the same

I would check that port range on the Matt peer

Maybe you might want to host your own TURN server to examine the connections that are happening there as well.