Menu
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.
218
The TURN server receives the peer UDP datagram, checks the permissions and if they are valid, forwards it to the client. This process gets around even symmetric NATs because both the client and peer can at least talk to the TURN server, which has allocated a relay IP address for communication.
webrtc peer to peer chat without signaling servera turn server is never used. since no signaling server is used the negotiation has to be done manually. that means a so called "offer" has to be copied from the initiator to the responder. and the "answer" has to be copied from the responder to the initiator.
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
58
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.
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
