Why my turn server doesn't work?
Asked Answered
A

3

6

I can connect in any situation when using appr.tc ice servers (google turn servers). but i can't connect with my own turn server. I did config my own turn server by coturn project.

I'm using google's libjingle_peerconnection api to create an Android Application that can perform video call.

When i run turn server:

<pre>
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Coturn-4.5.0.5 'dan Eider'
0: 
Max number of open files/sockets allowed for this process: 4096
0: 
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 2000 (approximately)
0: 

==== Show him the instruments, Practical Frost: ====

0: TLS supported
0: DTLS supported
0: DTLS 1.2 is not supported
0: TURN/STUN ALPN is not supported
0: Third-party authorization (oAuth) supported
0: GCM (AEAD) supported
0: OpenSSL compile-time version: OpenSSL 1.0.1e-fips 11 Feb 2013 (0x1000105f)
0: 
0: SQLite is not supported
0: Redis is not supported
0: PostgreSQL is not supported
0: MySQL supported
0: MongoDB is not supported
0: 
0: Default Net Engine version: 3 (UDP thread per CPU core)

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

0: Config file found: /usr/local/etc/turnserver.conf
0: Config file found: /usr/local/etc/turnserver.conf
0: Domain name: 
0: Default realm: myserver.com
0: 
CONFIGURATION ALERT: you specified long-term user accounts, (-u option) 
    but you did not specify the long-term credentials option
    (-a or --lt-cred-mech option).
    I am turning --lt-cred-mech ON for you, but double-check your configuration.
0: WARNING: cannot find certificate file: turn_server_cert.pem (1)
0: WARNING: cannot start TLS and DTLS listeners because certificate file is not set properly
0: WARNING: cannot find private key file: turn_server_pkey.pem (1)
0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly
0: NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED
0: ===========Discovering listener addresses: =========
0: Listener address to use: 127.0.0.1
0: Listener address to use: 137.74.35.124
0: Listener address to use: ::1
0: =====================================================
0: Total: 1 'real' addresses discovered
0: =====================================================
0: NO EXPLICIT RELAY ADDRESS(ES) ARE CONFIGURED
0: ===========Discovering relay addresses: =============
0: Relay address to use: 137.74.35.124
0: Relay address to use: ::1
0: =====================================================
0: Total: 2 relay addresses discovered
0: =====================================================
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: Wait for relay ports initialization...
0:   relay 137.74.35.124 initialization...
0:   relay 137.74.35.124 initialization done
0:   relay ::1 initialization...
0:   relay ::1 initialization done
0: Relay ports initialization done
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=0 created
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=1 created
0: IPv4. TCP listener opened on : 127.0.0.1:3478
0: IPv4. TCP listener opened on : 127.0.0.1:3479
0: IPv4. TCP listener opened on : 137.74.35.124:3478
0: IPv4. TCP listener opened on : 137.74.35.124:3479
0: IPv6. TCP listener opened on : ::1:3478
0: IPv6. TCP listener opened on : ::1:3479
0: IPv4. TCP listener opened on : 127.0.0.1:3478
0: IPv4. TCP listener opened on : 127.0.0.1:3479
0: IPv4. TCP listener opened on : 137.74.35.124:3478
0: IPv4. TCP listener opened on : 137.74.35.124:3479
0: IPv6. TCP listener opened on : ::1:3478
0: IPv6. TCP listener opened on : ::1:3479
0: IPv4. UDP listener opened on: 127.0.0.1:3478
0: IPv4. UDP listener opened on: 127.0.0.1:3479
0: IPv4. UDP listener opened on: 137.74.35.124:3478
0: IPv4. UDP listener opened on: 137.74.35.124:3479
0: IPv6. UDP listener opened on: ::1:3478
0: IPv6. UDP listener opened on: ::1:3479
0: Total General servers: 2
0: IO method (auth thread): epoll (with changelist)
0: IO method (auth thread): epoll (with changelist)
0: IO method (admin thread): epoll (with changelist)
0: IPv4. CLI listener opened on : 127.0.0.1:5766
</pre>

When i call from peer A to B :

IP of a peer is 192.68.7.3 !!! Why?

<pre>
58: IPv4. tcp or tls connected to: 5.112.222.14:1358
58: session 001000000000000001: realm <myserver.com> user <>: incoming packet message processed, error 401: Unauthorized
58: session 001000000000000001: realm <myserver.com> user <>: incoming packet message processed, error 401: Unauthorized
58: IPv4. Local relay addr: 137.74.35.124:51937
58: session 001000000000000001: new, realm=<myserver.com>, username=<heydari>, lifetime=600
58: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet ALLOCATE processed, success
58: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet ALLOCATE processed, success
69: session 001000000000000001: peer 192.168.7.3 lifetime updated: 300
69: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet CREATE_PERMISSION processed, success
69: session 001000000000000001: peer 192.168.7.3 lifetime updated: 300
69: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet CREATE_PERMISSION processed, success
69: session 001000000000000001: peer 109.110.172.36 lifetime updated: 300
69: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet CREATE_PERMISSION processed, success
69: session 001000000000000001: peer 109.110.172.36 lifetime updated: 300
69: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet CREATE_PERMISSION processed, success
186: session 001000000000000001: refreshed, realm=<myserver.com>, username=<heydari>, lifetime=0
186: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet REFRESH processed, success
</pre>

When i call from peer B to peer A :

I don't see peers after realm lines !! why?

<pre>
188: handle_udp_packet: New UDP endpoint: local addr 137.74.35.124:3478, remote addr 5.112.222.14:1164
188: session 001000000000000001: realm <myserver.com> user <>: incoming packet BINDING processed, success
188: session 001000000000000001: realm <myserver.com> user <>: incoming packet message processed, error 401: Unauthorized
188: session 001000000000000001: realm <myserver.com> user <>: incoming packet BINDING processed, success
188: session 001000000000000001: realm <myserver.com> user <>: incoming packet message processed, error 401: Unauthorized
188: IPv4. Local relay addr: 137.74.35.124:57827
188: session 001000000000000001: new, realm=<myserver.com>, username=<heydari>, lifetime=600
188: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet ALLOCATE processed, success
188: IPv4. tcp or tls connected to: 5.112.222.14:1496
188: session 000000000000000001: realm <myserver.com> user <>: incoming packet message processed, error 401: Unauthorized
188: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet ALLOCATE processed, success
189: session 000000000000000001: realm <myserver.com> user <>: incoming packet message processed, error 401: Unauthorized
189: IPv4. Local relay addr: 137.74.35.124:52856
189: session 000000000000000001: new, realm=<myserver.com>, username=<heydari>, lifetime=600
189: session 000000000000000001: realm <myserver.com> user <heydari>: incoming packet ALLOCATE processed, success
189: session 000000000000000001: realm <myserver.com> user <heydari>: incoming packet ALLOCATE processed, success
198: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
199: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
209: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
209: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
219: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
219: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
229: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
229: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
239: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
239: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
249: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
249: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
260: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
260: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet BINDING processed, success
267: session 001000000000000001: refreshed, realm=<myserver.com>, username=<heydari>, lifetime=0
267: session 001000000000000001: realm <myserver.com> user <heydari>: incoming packet REFRESH processed, success
267: session 000000000000000001: refreshed, realm=<myserver.com>, username=<heydari>, lifetime=0
267: session 000000000000000001: realm <myserver.com> user <heydari>: incoming packet REFRESH processed, success

</pre>

I Can't establish successfull connection peers. Where is the problem?

When I use appr.tc turn servers I can call from and to each peers so i think my application is ok.

Abrade answered 9/7, 2017 at 12:48 Comment(0)
A
9

You are using WebRTC. Relay candidate harvesting in WebRTC only works with credentials. You should add the following configuration to turnserver.config.

 listening-ip=137.74.35.124
 fingerprint
 lt-cred-mech
 user=guest:somepassword
 realm=saladem.com

Use turn:137.74.35.124:3478 whith user guest and password somepassword. You can test it here: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

If the tests show relay candidates harvested but the connection still fails in your peers, then it can be that you are missing the external-internal ip mapping in the config file. I.e. your turn server is behind a NAT. Add:

external-ip=[your-external-ip]/[your-internal-ip]

to your turnserver.config.

There is a discussion on how to configurate the server for WebRTC use here: https://github.com/coturn/coturn/wiki/turnserver

Aleedis answered 21/9, 2017 at 20:33 Comment(0)
U
1

Replace the domain to 137.74.35.124 it should work, I am hopeful to Ur coturn server is on public ip same as 137.74.35.124.

Untouched answered 10/7, 2017 at 12:46 Comment(2)
Yes you are right. I'm using turn:137.74.35.124:transport=udp and turn:137.74.35.124:transport=tcp but it doesn't workAbrade
My suggestion to you is change the domain in your turnserver.conf to your public IP ie 137.74.35.124 and also if installed on any web service then plz fill the appropriate mapping file in turnserver.conf .It will be better if u can share ur conf file else its hard to debugUntouched
M
0

In my case, I was getting CREATE_PERMISSION 403: Forbidden IPerror and I was not being able to connect to peer outside my network. The answer here absolutely helped me. I was setting only the public ip for external-ip in turnserver.conf. I set it as / and it worked. something like below:

external-ip=13.some.thing.229/172.some.thing.else

Monkish answered 20/4, 2021 at 14:9 Comment(1)
are you running your turn server on docker?Colloquialism

© 2022 - 2024 — McMap. All rights reserved.