Please help me
matrix config:
turn_uris: [«turn:chat.trinissoft.com:3478?transport=tcp»,»turn:chat.trinissoft.com:3478?transport=udp»]
turn_shared_secret: «W85lGGbslu9iHFeUHdH3NfoLp3voXKo8lI7RoUidOV3wiJmk7aZ3mylONrprWK3M»
turn_user_lifetime: «86400000»
turn_allow_guests: True
error:
session 001000000000000001: realm <chat.trinissoft.com> user : incoming packet message processed, error 401: Unauthorized
8: handle_udp_packet: New UDP endpoint: local addr 5.189.144.69:5349, remote addr 80.78.65.91:61203
8: session 001000000000000002: realm <chat.trinissoft.com> user <>: incoming packet BINDING processed, success
8: session 001000000000000002: realm <chat.trinissoft.com> user <>: incoming packet message processed, error 401: Unauthorized
8: ERROR: check_stun_auth: Cannot find credentials of user
8: session 001000000000000002: realm <chat.trinissoft.com> user : incoming packet message processed, error 401: Unauthorized
error 401: Unauthorized5: session 001000000000000001: realm <chat.trinissoft.com> user <>: incoming packet BINDING processed, success
5: session 001000000000000001: realm <chat.trinissoft.com> user <>: incoming packet message processed, error 401: Unauthorized
65: session 001000000000000001: closed (2nd stage), user realm <chat.trinissoft.com> origin <>, local 5.189.144.69:5349, remote 80.78.65.91:61196, reason: allocation watchdog determined stale session state
68: session 001000000000000002: closed (2nd stage), user realm <chat.trinissoft.com> origin <>, local 5.189.144.69:5349, remote 80.78.65.91:61203, reason: allocation watchdog determined stale session state
listening-port=3478
tls-listening-port=5349
listening-ip=5.189.144.69
verbose
lt-cred-mech
user=juli:mypassword
use-auth-secret
static-auth-secret=W85lGGbslu9iHFeUHdH3NfoLp3voXKo8lI7RoUidOV3wiJmk7aZ3mylONrprWK3M
server-name=chat.trinissoft.com
realm=chat.trinissoft.com
cert=/etc/letsencrypt/live/chat.trinissoft.com/fullchain.pem
pkey=/etc/letsencrypt/live/chat.trinissoft.com/privkey.pem
#no-stdout-log
#log-file=/var/log/turnserver/turn.log
#simple-log
#pidfile=»/var/run/turnserver/turnserver.pid»
mobility
no-tlsv1
no-tlsv1_1
Andrew O
unread,
Mar 7, 2015, 12:49:09 AM3/7/15
to turn-server-project…@googlegroups.com
hi everyone,
i’ve just installed a coturn server on Ubuntu via the latest debian package.
The server starts up and listens fine, however I’m having trouble connecting to it as a stun/turn client.
The error that I’m getting repeatedly within the logs is:
94: read_client_connection:4457:start
94: read_client_connection: data.buffer=0x7f2208000a0c, data.len=128
94: session 130000000000000002: new, realm=<dev.mydomain.com>, username=<kurento>, lifetime=600
94: session 130000000000000002: realm <dev.mydomain.com> user <kurento>: incoming packet ALLOCATE processed, success
94: write_client_connection:4243:start
94: write_client_connection: prepare to write to s 0x7f2208025f10
94: write_client_connection:4263:end
94: read_client_connection:4563:end
94: udp_server_input_handler:620:start
94: read_client_connection:4457:start
94: read_client_connection: data.buffer=0x7f2208000a0c, data.len=60
94: session 130000000000000001: realm <dev.mydomain.com> user <>: incoming packet message processed, error 401: Unauthorised
what I’ve done as part of setup:
- i’ve configured a standard user with a password via turnadmin
- i can see that network connectivity is correct — there’s a single NAT in place between the client and the server
- I’m starting this as a daemon with the following arguments (via /etc/init.d/coturn):
DAEMON_ARGS=»-c /etc/turnserver.conf -f -o -a -v -r dev.mydomain.com —user=kurento:mypassword —no-stdout-log —external-ip $
Any ideas why i’m getting the unauthorised error?
Note: i’ve seen the posts about a single unauthorised error being normal, however i’m getting them consistently with no further access.
Note2: IP addresses, domains, and passwords have been changed for the extract above.
thanks in advance
Andrew
Oleg Moskalenko
unread,
Mar 7, 2015, 1:27:30 AM3/7/15
to Andrew O, turn-server-project…@googlegroups.com
If you getting multiple 401 errors then that means that your client does not provide correct credentials to the server.
Sent from my iPhone
Jordi Herms
unread,
Aug 1, 2015, 10:11:40 AM8/1/15
to TURN Server (Open-Source project)
Andrew did you solve this problem? I’m getting also a lot of 401 errors
thanks
jordi
El divendres, 6 març de 2015 22:49:09 UTC+1, Andrew O va escriure:
Oleg Moskalenko
unread,
Aug 1, 2015, 10:34:07 AM8/1/15
to Jordi Herms, TURN Server (Open-Source project)
401 errors when the server is still able to authenticate the users is
a normal situation.
401 errors when the server is not authenticating the users means that
the users credentials are set incorrectly or the client is providng
wrong credentials.
Alvaro Gil
unread,
Aug 30, 2016, 3:50:11 PM8/30/16
to TURN Server (Open-Source project), azo…@gmail.com
Hi Oleg,
Can you explain a little more why 401 are a normal situation?
I am noticing 401 responses lack of <username>, I wonder who/what is generating those requests.
Also in my logs I have these two lines, it is ok to say to say that first line bind the client but second deny access for all requests from that client, so that should not be a security issue?
221: session 000000000000000002: realm <myrealm.com> user <>: incoming packet BINDING processed, success
221: session 000000000000000002: realm <myrealm.com> user <>: incoming packet message processed, error 401: Unauthorized
Finally, this line is the one that worries me most…
229: session 000000000000000002: closed (2nd stage), user <myuser> realm <myrealm.com> origin <>, local 172.30.0.219:3478, remote 186.54.16.216:51932, reason: allocation timeout
That line comes after ALLOCATE, CREATE_PERMISSION and REFRESH processed, success.
Can you explain me what does it mean exactly?
Thank you very much for your work and help!
Oleg Moskalenko
unread,
Aug 31, 2016, 8:21:38 AM8/31/16
to Alvaro Gil, TURN Server (Open-Source project), Andrew Olson
Alvaro Gil
unread,
Sep 1, 2016, 4:02:20 PM9/1/16
to Oleg Moskalenko, TURN Server (Open-Source project), Andrew Olson
Ramya Raj
unread,
Dec 27, 2018, 2:16:19 PM12/27/18
to TURN Server (Open-Source project)
Hi Alvaro
Did you solved that? I’m also facing the same problem.
Thanks
RAMYA
manikanta nandam
unread,
Jan 7, 2019, 4:59:03 PM1/7/19
to TURN Server (Open-Source project)
Hi,
For me initially i am getting unauthenticated error, when i disconnect call and recall again then my call is getting connected and Incoming packet message processed is successful.
Anyone got the solution.
4: handle_udp_packet: New UDP endpoint: local addr 142.93.217.231:3478, remote addr 106.51.36.182:61354
4: session 001000000000000001: realm <someRealm> user <>: incoming packet BINDING processed, success
4: session 001000000000000001: realm <someRealm> user <>: incoming packet message processed, error 401: Unauthorized
4: handle_udp_packet: New UDP endpoint: local addr 142.93.217.231:3478, remote addr 106.51.36.182:53525
4: session 000000000000000001: realm <someRealm> user <>: incoming packet BINDING processed, success
4: session 000000000000000001: realm <someRealm> user <>: incoming packet message processed, error 401: Unauthorized
4: session 001000000000000001: realm <someRealm> user <>: incoming packet BINDING processed, success
4: session 000000000000000001: realm <someRealm> user <>: incoming packet BINDING processed, success
4: IPv4. Local relay addr: 142.93.217.231:54581
4: session 000000000000000001: new, realm=<someRealm>, username=<test>, lifetime=600
4: session 000000000000000001: realm <someRealm> user <test>: incoming packet ALLOCATE processed, success
4: IPv4. Local relay addr: 142.93.217.231:60565
4: session 001000000000000001: new, realm=<someRealm>, username=<test>, lifetime=600
4: session 001000000000000001: realm <someRealm> user <test>: incoming packet ALLOCATE processed, success
4: session 000000000000000001: realm <someRealm> user <test>: incoming packet ALLOCATE processed, success
4: session 001000000000000001: realm <someRealm> user <test>: incoming packet ALLOCATE processed, success
14: session 000000000000000001: realm <someRealm> user <test>: incoming packet BINDING processed, success
Я пытаюсь настроить сервер COTURN для моего приложения на основе WebRTC. Однако я застрял с парой сообщений об ошибках, которые я не в состоянии понять, и не могу найти никакой помощи на них в интернете.
Вот некоторые подробности о приложении:
-
Два пользователя входят в приложение, и один из них может поделиться своим экраном с другим-таким образом, поток идет только в одном направлении
-
Я могу заставить приложение работать в интрасети и на некоторых наружные сети. Поэтому я уверен, что приложение отлично работает везде, где достаточно режима оглушения.
-
Для некоторых сетей кандидаты на оглушение постоянно терпят неудачу, поэтому мне нужно получить сервер поворота для ретрансляции потока.
Я собрал некоторые журналы сервера с сервера, на случай, если кто-то сможет определить проблему на их основе:
handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59942
handle_turn_command: STUN method 0x1 ignored
handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59944
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
IPv4. Local relay addr: <IP Address>:64306
session 128000000000000096: new, realm=<server URL>, username=<username>, lifetime=600
session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
IPv4. Local relay addr: <IP Address>:65384
session 128000000000000097: new, realm=<server URL>, username=<username>, lifetime=600
session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: refreshed, realm=<server URL>, username=<username>, lifetime=0
session 128000000000000096: realm <server URL> user <username>: incoming packet REFRESH processed, success
session 128000000000000097: refreshed, realm=<server URL>, username=<username>, lifetime=0
session 128000000000000097: realm <server URL> user <username>: incoming packet REFRESH processed, success
session 128000000000000096: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59942, reason: allocation timeout
session 128000000000000096: delete: realm=<server URL>, username=<username>
session 128000000000000097: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59944, reason: allocation timeout
session 128000000000000097: delete: realm=<server URL>, username=<username>
Вот как мой turnserver.conf файл выглядит так:
listening-port=3478
#tls-listening-port=443
realm=subdomain.domain.com
server-name=subdomain.domain.com
lt-cred-mech
userdb=/etc/turnserdb.conf
cert=/home/ubuntu/certificate.crt
pkey=/home/ubuntu/qc.key
pkey-pwd=L1ght!t
no-stdout-log
Verbose
Я есть особое беспокойство вызывают следующие моменты:
-
Должен ли я предполагать, что, поскольку мой код работает с сервером STUN, он будет работать и срабочим сервером TURN? Следовательно, ошибка означает, что проблема с сервером поворота?
-
Я вижу пару ошибок, указывающих на «тайм-аут выделения». Означает ли это, что вы ссылаетесь на любое выделение оперативной памяти / процессора / сети, которое может быть недостаточным?
-
В некоторых запросах часть имени пользователя пуста »вместо», и за ним следует ‘401 несанкционированный’, в то время как я трижды проверил конфигурации RTCPeerConnection — они действительно содержат имя пользователя и пароль.
-
Кроме журналов выше, я видел, что «438 неправильных nonce» приходили довольно часто. Я немного поискал об этом, но это не похоже на то, что я могу контролировать через JS. Связано ли это с какими-либо конфигурациями серверов?
Спасибо! Ценю вашу помощь.
Я пытаюсь настроить сервер COTURN для своего приложения на основе WebRTC. Однако я застрял с парой сообщений об ошибках, которые я не могу понять, и не могу найти по ним помощь в Интернете.
Вот некоторые подробности о приложении:
-
Два пользователя входят в приложение, и один из них может делиться своим экраном с другим — поэтому поток идет только в одном направлении.
-
Я могу заставить приложение работать в интрасети и в некоторых внешних сетях. Поэтому я уверен, что приложение работает нормально там, где достаточно режима STUN.
-
В некоторых сетях кандидаты STUN постоянно терпят неудачу, поэтому мне нужно получить сервер TURN для ретрансляции потока.
Я собрал некоторые серверные журналы с сервера на случай, если кто-нибудь сможет определить проблему на их основе:
handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59942
handle_turn_command: STUN method 0x1 ignored
handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59944
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
IPv4. Local relay addr: <IP Address>:64306
session 128000000000000096: new, realm=<server URL>, username=<username>, lifetime=600
session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
IPv4. Local relay addr: <IP Address>:65384
session 128000000000000097: new, realm=<server URL>, username=<username>, lifetime=600
session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: refreshed, realm=<server URL>, username=<username>, lifetime=0
session 128000000000000096: realm <server URL> user <username>: incoming packet REFRESH processed, success
session 128000000000000097: refreshed, realm=<server URL>, username=<username>, lifetime=0
session 128000000000000097: realm <server URL> user <username>: incoming packet REFRESH processed, success
session 128000000000000096: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59942, reason: allocation timeout
session 128000000000000096: delete: realm=<server URL>, username=<username>
session 128000000000000097: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59944, reason: allocation timeout
session 128000000000000097: delete: realm=<server URL>, username=<username>
Вот как выглядит мой файл turnserver.conf :
listening-port=3478
#tls-listening-port=443
realm=subdomain.domain.com
server-name=subdomain.domain.com
lt-cred-mech
userdb=/etc/turnserdb.conf
cert=/home/ubuntu/certificate.crt
pkey=/home/ubuntu/qc.key
pkey-pwd=L1ght!t
no-stdout-log
Verbose
Я особенно обеспокоен следующими моментами:
-
Должен ли я предполагать, что, поскольку мой код работает с сервером STUN, он также будет работать с работающим сервером TURN? Следовательно, ошибка означает, что проблема с сервером TURN?
-
Я вижу пару ошибок, указывающих «Время ожидания распределения». Относится ли это к какому-либо распределению ОЗУ / ЦП / сети, которое может быть недостаточным?
-
Некоторые запросы содержат пустую часть имени пользователя «<>», а не «», и за ней следует «401 Unauthorized», хотя я трижды проверил конфигурации RTCPeerConnection — они действительно содержат имя пользователя и пароль.
-
Помимо журналов, приведенных выше, я также часто видел, как «438 Wrong nonce». Я искал немного об этом, но это не похоже на то, что я могу контролировать через JS. Это связано с какими-либо конфигурациями сервера?
Спасибо! Ценю твою помощь.
I’m trying to configure a coturn server for my webRTC application. I’ve hit a wall though after several days trying to get this to work. I do know that my webRTC node.js application is working with a turnserver. As I’ve acquired some free turnserver but they keep crashing and I will need my own anyway.
This is my log when I start coturn.
==== Show him the instruments, Practical Frost: ====
0: TLS supported
0: DTLS supported
0: DTLS 1.2 supported
0: TURN/STUN ALPN supported
0: Third-party authorization (oAuth) supported
0: GCM (AEAD) supported
0: OpenSSL compile-time version: OpenSSL 1.0.2g-fips 1 Mar 2016
0:
0: SQLite supported, default database location is /var/lib/turn/turndb
0: Redis supported
0: PostgreSQL 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: /etc/turnserver.conf
0: Listener address to use: 192.168.206.115
0: Relay address to use: 192.168.206.115
ERROR: Cannot open log file for writing: /var/log/turnserver/turn_2017-08-07.log
0: log file opened: /var/log/turn_28860_2017-08-07.log
0: Config file found: /etc/turnserver.conf
0: Domain name:
0: Default realm: external.ip
0: SSL23: Certificate file found: /etc/keys/crt.pem
0: SSL23: Private key file found: /etc/keys/key.pem
0: TLS1.0: Certificate file found: /etc/keys/crt.pem
0: TLS1.0: Private key file found: /etc/keys/key.pem
0: TLS1.1: Certificate file found: /etc/keys/crt.pem
0: TLS1.1: Private key file found: /etc/keys/key.pem
0: TLS1.2: Certificate file found: /etc/keys/crt.pem
0: TLS1.2: Private key file found: /etc/keys/key.pem
0: TLS cipher suite: DEFAULT
0: DTLS1.2: Certificate file found: /etc/keys/crt.pem
0: DTLS1.2: Private key file found: /etc/keys/key.pem
0: DTLS: Certificate file found: /etc/keys/crt.pem
0: DTLS: Private key file found: /etc/keys/key.pem
0: DTLS cipher suite: DEFAULT
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided
0: Wait for relay ports initialization...
0: relay 192.168.206.115 initialization...
0: relay 192.168.206.115 initialization done
0: Relay ports initialization done
0: IO method (general relay thread): epoll (with changelist)
1: turn server id=1 created
1: IPv4. TLS/SCTP listener opened on : 192.168.206.115:80
1: IPv4. TLS/TCP listener opened on : 192.168.206.115:80
1: IPv4. TLS/SCTP listener opened on : 192.168.206.115:443
1: IPv4. TLS/TCP listener opened on : 192.168.206.115:443
1: IO method (general relay thread): epoll (with changelist)
1: turn server id=0 created
1: IPv4. DTLS/UDP listener opened on: 192.168.206.115:80
1: IPv4. DTLS/UDP listener opened on: 192.168.206.115:443
1: Total General servers: 2
1: IPv4. TLS/TCP listener opened on : 192.168.206.115:80
1: IPv4. TLS/TCP listener opened on : 192.168.206.115:443
1: IO method (admin thread): epoll (with changelist)
1: ERROR: Cannot create CLI listener
1: IO method (auth thread): epoll (with changelist)
1: IO method (auth thread): epoll (with changelist)
1: SQLite DB connection success: /var/lib/turn/turndb
40: IPv4. tcp or tls connected to: 192.168.204.7:56282
40: read_client_connection: HTTP request: GET / HTTP/1.1
Host: 192.168.204.116
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
And here is my log when I try to use the server with my application. (Changed the external ip value)
170: IPv4. tcp or tls connected to: 192.168.204.7:56296
170: IPv4. tcp or tls connected to: 192.168.204.7:56298
170: IPv4. tcp or tls connected to: 192.168.204.7:56297
170: IPv4. tcp or tls connected to: 192.168.204.7:56299
170: session 001000000000000002: realm <83.external.ip> user <>: incoming packet message processed, error 401: Unauthorized
170: IPv4. Local relay addr: 192.168.206.115:58700
170: session 001000000000000002: new, realm=<83.external.ip>, username=<karl>, lifetime=3600
170: session 001000000000000002: realm <83.external.ip> user <karl>: incoming packet ALLOCATE processed, success
170: session 000000000000000005: realm <83.external.ip> user <>: incoming packet message processed, error 401: Unauthorized
170: IPv4. Local relay addr: 192.168.206.115:58433
170: session 000000000000000005: new, realm=<83.external.ip>, username=<karl>, lifetime=3600
170: session 000000000000000005: realm <83.external.ip> user <karl>: incoming packet ALLOCATE processed, success
170: session 001000000000000002: refreshed, realm=<83.external.ip>, username=<karl>, lifetime=0
170: session 001000000000000002: realm <83.external.ip> user <karl>: incoming packet REFRESH processed, success
170: session 001000000000000002: TCP socket closed remotely 192.168.204.7:56296
170: session 001000000000000002: closed (2nd stage), user <karl> realm <83.external.ip> origin <>, local 192.168.206.115:80, remote 192.168.204.7:56296, reason: TCP connection closed by client (callback)
170: session 001000000000000002: delete: realm=<83.external.ip>, username=<karl>
170: session 000000000000000005: TCP socket closed remotely 192.168.204.7:56297
170: session 000000000000000005: closed (2nd stage), user <karl> realm <83.external.ip> origin <>, local 192.168.206.115:80, remote 192.168.204.7:56297, reason: TCP connection closed by client (callback)
170: session 000000000000000005: delete: realm=<83.external.ip>, username=<karl>
170: session 001000000000000003: realm <83.external.ip> user <>: incoming packet message processed, error 401: Unauthorized
170: IPv4. Local relay addr: 192.168.206.115:51149
170: session 001000000000000003: new, realm=<83.external.ip>, username=<karl>, lifetime=3600
170: session 001000000000000003: realm <83.external.ip> user <karl>: incoming packet ALLOCATE processed, success
170: session 001000000000000003: peer 192.168.43.161 lifetime updated: 300
170: session 001000000000000003: realm <83.external.ip> user <karl>: incoming packet CREATE_PERMISSION processed, success
170: session 000000000000000006: realm <83.external.ip> user <>: incoming packet message processed, error 401: Unauthorized
170: IPv4. Local relay addr: 192.168.206.115:62354
170: session 000000000000000006: new, realm=<83.external.ip>, username=<karl>, lifetime=3600
170: session 000000000000000006: realm <83.external.ip> user <karl>: incoming packet ALLOCATE processed, success
170: session 001000000000000003: peer 77.218.243.167 lifetime updated: 300
170: session 001000000000000003: realm <83.external.ip> user <karl>: incoming packet CREATE_PERMISSION processed, success
I am unfortunately not awesome with networks. As I’m sitting behind a few firewalls, maybe that is the problem why this is not working but I have no clue. It is hard for me to see if its my configuration or a firewall problem.
This is my .config file.
# Run as TURN server only, all STUN requests will be ignored.
no-stun
verbose
# Specify listening port. Change to 80 or 443 to go around some strict NATs.
listening-port=80
tls-listening-port=443
# Specify listening IP, if not set then Coturn listens on all system IPs.
listening-ip=192.168.206.115
relay-ip=192.168.206.115
external-ip=83.external.ip
# These lines enable support for WebRTC
fingerprint
lt-cred-mech
realm=83.external.ip
# Authentication method
#use-auth-secret
#static-auth-secret=your-auth-secret
cert=/etc/keys/crt.pem
pkey=/etc/keys/key.pem
#total-quota=100000000
# Total bytes-per-second bandwidth the TURN server is allowed to allocate
# for the sessions, combined (input and output network streams are treated separately).
#bps-capacity=100000
#max-bps=100000000000
# This line provides extra security.
stale-nonce
log-file=/var/log/turnserver/turn.log
no-loopback-peers
no-multicast-peers
I’ve tried several different configurations without any success. If you have any input at all with the configuration, please tell as anything will be helpful. There’s a lack of working coturns out there.
I’ve got a user in turnuserdb.conf
karl:123
but if I turn on use-auth-secret etc I still get
17: ERROR: check_stun_auth: Cannot find credentials of user <karl>
in my logs.
Thanks in advance.