Pourquoi mon serveur Turn ne fonctionne pas?

Question

Je peux me connecter dans n'importe quelle situation en utilisant appr.tc serveurs de glace (google turn servers). mais je ne peux pas me connecter avec mon propre serveur de tour. J'ai fait configurer mon propre serveur de tour par coturn project. J'utilise l'API libjingle_peerconnection de google pour créer un Android Application qui peut effectuer video call.

Quand je lance le serveur tour:

<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: saladem.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> 

Quand je l'appelle de pair A à B:

IP d'un pair est 192.68.7.3 !!! Pourquoi?

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

Quand je l'appelle de B peer to peer:

Je ne vois pas ses pairs après les lignes de royaume !! Pourquoi?

<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 <saladem.com> user <>: incoming packet BINDING processed, success 
188: session 001000000000000001: realm <saladem.com> user <>: incoming packet message processed, error 401: Unauthorized 
188: session 001000000000000001: realm <saladem.com> user <>: incoming packet BINDING processed, success 
188: session 001000000000000001: realm <saladem.com> user <>: incoming packet message processed, error 401: Unauthorized 
188: IPv4. Local relay addr: 137.74.35.124:57827 
188: session 001000000000000001: new, realm=<saladem.com>, username=<heydari>, lifetime=600 
188: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet ALLOCATE processed, success 
188: IPv4. tcp or tls connected to: 5.112.222.14:1496 
188: session 000000000000000001: realm <saladem.com> user <>: incoming packet message processed, error 401: Unauthorized 
188: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet ALLOCATE processed, success 
189: session 000000000000000001: realm <saladem.com> user <>: incoming packet message processed, error 401: Unauthorized 
189: IPv4. Local relay addr: 137.74.35.124:52856 
189: session 000000000000000001: new, realm=<saladem.com>, username=<heydari>, lifetime=600 
189: session 000000000000000001: realm <saladem.com> user <heydari>: incoming packet ALLOCATE processed, success 
189: session 000000000000000001: realm <saladem.com> user <heydari>: incoming packet ALLOCATE processed, success 
198: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
199: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
209: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
209: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
219: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
219: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
229: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
229: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
239: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
239: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
249: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
249: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
260: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
260: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet BINDING processed, success 
267: session 001000000000000001: refreshed, realm=<saladem.com>, username=<heydari>, lifetime=0 
267: session 001000000000000001: realm <saladem.com> user <heydari>: incoming packet REFRESH processed, success 
267: session 000000000000000001: refreshed, realm=<saladem.com>, username=<heydari>, lifetime=0 
267: session 000000000000000001: realm <saladem.com> user <heydari>: incoming packet REFRESH processed, success 

</pre> 

Je ne peux pas établir de connexion pairs successfull. Où est le problème?

Lorsque j'utilise les serveurs appr.tc, je peux appeler de et vers chaque homologue, donc je pense que mon application est correcte.

Answer 1

Remplacer le domaine à 137.74.35.124 cela devrait fonctionner, je suis optimiste à Ur serveur coturn est sur ip public même que 137.74.35.124.

Answer 2

Vous utilisez WebRTC. La récupération des candidats relais dans WebRTC fonctionne uniquement avec les informations d'identification. Vous devez ajouter la configuration suivante à turnserver.config.

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

Utilisez turn:137.74.35.124:3478 cinque utilisateur et mot de passe guestsomepassword. Vous pouvez le tester ici: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Si les tests montrent des candidats relais collectés mais que la connexion échoue toujours dans vos homologues, il se peut que vous manquiez le mappage ip externe interne dans le fichier de configuration. C'est à dire. votre serveur de tour est derrière un NAT. Ajouter:

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

à votre turnserver.config.

Il y a une discussion sur la façon de configurer le serveur pour WebRTC utiliser ici: https://github.com/coturn/coturn/wiki/turnserver