2

I have two clients communicating over webrtc. (Client A writen in js, Client B in Python with aiortc). Now it happens that Client A wants to connect from a mobile Network thus it requires a turn-relay connection.

I have already setup a turn server which seems to do his job. But only approx 50% of the connections succeed now. I already found out when they succeed and when they fail:

SDP relay information in case of success:
Offer Client A

a=candidate:3 2 UDP 92217086 172.31.16.8 59986 typ relay raddr 172.31.16.8 rport 59986

Response Client B

a=candidate:11 1 UDP 92086015 172.31.16.8 49910 typ relay raddr 172.31.16.8 rport 49910

SDP relay information in case of failure:
Offer Client A

a=candidate:7 1 UDP 92151551 172.31.16.8 49871 typ relay raddr 172.31.16.8 rport 49871

Response Client B

a=candidate:5820bb1602563a80c76891a80be14933 1 udp 16777215 18.185.84.96 53279 typ relay raddr 172.31.1.103 rport 49244

The important difference is the IP address shown in the Response from Client B, in the successfull scenario it is the IP adress of the net in which Client B is, in the failing scenario it is the IP address of the turnserver (18.185.84.96).

Actually I do not understand why it sometimes gives the IP of the turnserver and the other times not, and what it means that the IP address of the turnserver is not possible to use...

Anyone any ideas, on where to start looking for the issue?

Tanja Bayer
  • 711
  • 5
  • 13
  • 1
    does configuring the TURN server with a public IP change the results? Does the success case still work when iceTransportPolicy to 'relay' in the JS RTCPeerConnection constructor? Does success/failure depend on who sends the offer? – Philipp Hancke Jan 28 '20 at 06:28

1 Answers1

1

It seems like our turn server was missconfigured.
I can not tell what was misconfigured, because sadly I have no access to the configuration of the turn server.
But I tested by deploying some turn servers on my local machine and they behaved similar when they where not correctly configured. By looking into the logs of thos turn servers I saw 401 Unauthorized popping up all the time. So I changed the configuration, until the authorization was working. With this config we deployed a new server which is now working.

Some words on the configuration for people also having troubles with that on the first run, those are the configurations we put into /etc/turnserver.conf and passed it when starting the server with turnserver -v -c /etc/turnserver.conf:

listening-port=<port>
alt-listening-port=<port>
listening-ip=<listening-ip>
external-ip=<external-ip>
realm=<realm>
fingerprint
lt-cred-mech
user=<user:pw>

bofore coming to that configuration we made some errors, maybe they are obious to experienced people but they were not to us:

  1. we had the use-auth-secret in the config file, this should not be enabled when using user
  2. we had the issue that the turn server was usable in firefox but not in chrome or others, (not possible to gather relay candidates), this was do to realm not beeing configured in the config
Tanja Bayer
  • 711
  • 5
  • 13