Jitsi with Turn and more than 2 participants

Hello specialists,

we have a Jitsi Instance on Ubuntu 20.04.1 LTS and a own turnserver.
P2P with blocked 10000 UDP works over the turnserver and port 443/TCP (see the log).
A third participant will come in the meeting and than we don’t have Audio and Video.
The test was with a PC (10000/UDP blocked), Mobilphone over LTE and a Laptop (10000/UDP blocked).
What is wrong?
I have no idea.

See the log:
101450: handle_udp_packet: New UDP endpoint: local addr <our_turnserver>:443, remote addr <PC_10000_blocked>:57594
101450: session 001000000000000241: realm <our_turnserver_fqdn> user <>: incoming packet BINDING processed, success
101450: session 001000000000000241: realm <our_turnserver_fqdn> user <>: incoming packet message processed, error 401: Unauthorized
101450: IPv4. Local relay addr: <our_turnserver>:64327
101450: session 001000000000000241: new, realm=<our_turnserver_fqdn>, username=<1606656599>, lifetime=600
101450: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet ALLOCATE processed, success
101450: IPv4. tcp or tls connected to: <PC_10000_blocked>:55724
101450: IPv4. tcp or tls connected to: <PC_10000_blocked>:55727
101454: handle_udp_packet: New UDP endpoint: local addr <our_turnserver>:443, remote addr <Mobilphone_LTE>:15502
101454: session 001000000000000242: realm <our_turnserver_fqdn> user <>: incoming packet message processed, error 401: Unauthorized
101454: session 001000000000000242: realm <our_turnserver_fqdn> user <>: incoming packet BINDING processed, success
101455: session 001000000000000242: realm <our_turnserver_fqdn> user <>: incoming packet message processed, error 401: Unauthorized
101455: session 001000000000000242: realm <our_turnserver_fqdn> user <>: incoming packet BINDING processed, success
101456: IPv4. Local relay addr: <our_turnserver>:55732
101456: session 001000000000000242: new, realm=<our_turnserver_fqdn>, username=<1606656562>, lifetime=600
101456: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet ALLOCATE processed, success
101456: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet ALLOCATE processed, success
101457: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet ALLOCATE processed, success
101457: IPv4. tcp or tls connected to: <Mobilphone_LTE>:15572
101457: IPv4. tcp or tls connected to: <Mobilphone_LTE>:15576
101457: session 001000000000000242: peer <PC_10000_blocked> lifetime updated: 300
101457: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CREATE_PERMISSION processed, success
101457: session 001000000000000242: peer <our_turnserver> lifetime updated: 300
101457: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CREATE_PERMISSION processed, success
101457: IPv4. tcp or tls connected to: <Mobilphone_LTE>:15577
101457: IPv4. tcp or tls connected to: <Mobilphone_LTE>:15578
101457: session 001000000000000242: peer <PC_10000_blocked> lifetime updated: 300
101457: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CREATE_PERMISSION processed, success
101457: session 001000000000000242: peer <our_turnserver> lifetime updated: 300
101457: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CREATE_PERMISSION processed, success
101458: session 001000000000000242: peer <PC_10000_blocked> lifetime updated: 300
101458: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CREATE_PERMISSION processed, success
101458: session 001000000000000242: peer <our_turnserver> lifetime updated: 300
101458: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CREATE_PERMISSION processed, success
101460: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet BINDING processed, success
101462: session 001000000000000241: peer 10.28.10.12 lifetime updated: 300
101462: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet CREATE_PERMISSION processed, success
101462: session 001000000000000241: peer 10.150.247.95 lifetime updated: 300
101462: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet CREATE_PERMISSION processed, success
101462: session 001000000000000241: peer <Mobilphone_LTE> lifetime updated: 300
101462: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet CREATE_PERMISSION processed, success
101462: session 001000000000000241: peer <our_turnserver> lifetime updated: 300
101462: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet CREATE_PERMISSION processed, success
101463: session 001000000000000242: peer <PC_10000_blocked> lifetime updated: 600
101463: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CHANNEL_BIND processed, success
101463: session 001000000000000242: peer <PC_10000_blocked> lifetime updated: 600
101463: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CHANNEL_BIND processed, success
101464: session 001000000000000242: peer <PC_10000_blocked> lifetime updated: 600
101464: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet CHANNEL_BIND processed, success
101465: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet BINDING processed, success
101470: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet BINDING processed, success
101472: session 001000000000000241: refreshed, realm=<our_turnserver_fqdn>, username=<1606656599>, lifetime=0
101472: session 001000000000000241: realm <our_turnserver_fqdn> user <1606656599>: incoming packet REFRESH processed, success
101472: session 000000000000000220: TCP socket closed remotely <PC_10000_blocked>:55724
101472: session 000000000000000220: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101472: session 000000000000000220: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101472: session 000000000000000220: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <PC_10000_blocked>:55724, reason: TCP connection closed by client (callback)
101473: session 001000000000000245: TCP socket closed remotely <Mobilphone_LTE>:15577
101473: session 001000000000000245: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101473: session 001000000000000245: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101473: session 001000000000000245: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <Mobilphone_LTE>:15577, reason: TCP connection closed by client (callback)
101473: session 001000000000000246: TCP socket closed remotely <Mobilphone_LTE>:15578
101473: session 001000000000000246: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101473: session 001000000000000246: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101473: session 001000000000000246: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <Mobilphone_LTE>:15578, reason: TCP connection closed by client (callback)
101473: session 001000000000000241: usage: realm=<our_turnserver_fqdn>, username=<1606656599>, rp=28, rb=3152, sp=14, sb=1616
101473: session 001000000000000241: peer usage: realm=<our_turnserver_fqdn>, username=<1606656599>, rp=24, rb=2240, sp=18, sb=1728
101473: session 001000000000000241: closed (2nd stage), user <1606656599> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <PC_10000_blocked>:57594, reason: allocation timeout
101473: session 001000000000000241: delete: realm=<our_turnserver_fqdn>, username=<1606656599>
101473: session 001000000000000241: peer 10.28.10.12 deleted
101473: session 001000000000000241: peer 10.150.247.95 deleted
101473: session 001000000000000241: peer <Mobilphone_LTE> deleted
101473: session 001000000000000241: peer <our_turnserver> deleted
101473: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31820
101473: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31821
101473: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31822
101473: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31823
101474: session 001000000000000242: refreshed, realm=<our_turnserver_fqdn>, username=<1606656562>, lifetime=0
101474: session 001000000000000242: realm <our_turnserver_fqdn> user <1606656562>: incoming packet REFRESH processed, success
101475: session 001000000000000242: usage: realm=<our_turnserver_fqdn>, username=<1606656562>, rp=319, rb=74057, sp=225, sb=16709
101475: session 001000000000000242: peer usage: realm=<our_turnserver_fqdn>, username=<1606656562>, rp=207, rb=13465, sp=301, sb=69620
101475: session 001000000000000242: closed (2nd stage), user <1606656562> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <Mobilphone_LTE>:15502, reason: allocation timeout
101475: session 001000000000000242: delete: realm=<our_turnserver_fqdn>, username=<1606656562>
101475: session 001000000000000242: peer <PC_10000_blocked> deleted
101475: session 001000000000000242: peer <our_turnserver> deleted
101480: session 000000000000000221: TCP socket closed remotely <PC_10000_blocked>:55727
101480: session 000000000000000221: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101480: session 000000000000000221: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101480: session 000000000000000221: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <PC_10000_blocked>:55727, reason: TCP connection closed by client (callback)
101487: session 001000000000000243: TCP socket closed remotely <Mobilphone_LTE>:15572
101487: session 001000000000000243: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101487: session 001000000000000243: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101487: session 001000000000000243: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <Mobilphone_LTE>:15572, reason: TCP connection closed by client (callback)
101487: session 001000000000000244: TCP socket closed remotely <Mobilphone_LTE>:15576
101487: session 001000000000000244: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101487: session 001000000000000244: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101487: session 001000000000000244: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <Mobilphone_LTE>:15576, reason: TCP connection closed by client (callback)
101491: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31829
101491: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31830
101491: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31831
101491: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31832
101509: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31833
101509: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31834
101509: IPv4. tcp or tls connected to: <Laptop_10000_blocked>:31835

Do you block 10000 and for the turnserver? Coturn should be able to contact jvb on port 10000 UDP

you could possibly get more understanding by reading these:

Port 10000/UDP is open.
USER@turn:/var/log/coturn$ sudo nc -uvv <IP_Jitsi_Server> 10000
Connection to <IP_Jitsi_Server> 10000 port [udp/*] succeeded!

And clients can connect to our Jtisi Server over port 10000/UDP.
Only more than 2 participants with blocked port 10000/UDP cannot connect

I tested to connect with 3 participants in a conference. Than i restarted our Turnserver. Nothing happens on the 3 participants. After restart from the turnserver no log entrys are in the turnserver.log.

Why do the participants don’t connect to the turnserver?
I have disconnected one participant. The conference broken and reconnect. After that i can see log entrys in the turnserver.log

you said that you can’t have a conference with 3 users. So if you had a conference with 3 users, they must have connected without port 10000 being blocked, right ? in this case, why do you expect to be something in the turnserver log ?

Hey gpatel-fr,
I expressed myself wrong.
The conference with 3 users don’t work (Port 10000/udp is blocked).
But on the turnserver.log i can see logentrys without a username:

101480: session 000000000000000221: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101480: session 000000000000000221: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <PC_10000_blocked>:55727, reason: TCP connection closed by client (callback)
101487: session 001000000000000243: TCP socket closed remotely <Mobilphone_LTE>:15572
101487: session 001000000000000243: usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101487: session 001000000000000243: peer usage: realm=<our_turnserver_fqdn>, username=<>, rp=0, rb=0, sp=0, sb=0
101487: session 001000000000000243: closed (2nd stage), user <> realm <our_turnserver_fqdn> origin <>, local <our_turnserver>:443, remote <Mobilphone_LTE>:15572, reason: TCP connection closed by client (callback)

When i restart the turnserver there are no logentrys.

your user connect to the coturn server but the coturn don’t seem to be able to connect to jvb (rp,rb,sp and sb = 0 <==> no data exchanged)
From what you show it’s not possible to find an explanation, I suggest that you read the posts I have pointed to you there should be sufficient information to get you to find the root cause.

ok, i make some tests with your posts.
The coturn server works with our bigbluebutton server.
So i think the configuration from the coturn server is ok.

when i make a test from one client with blocked outgoing port 10000/udp and 3 chrome tabs there is no audio or video. On webrtc-internals i can see iceservers turns:turn.my-domain.de 443?transport=tcp.

In the configurationfile /etc/prosody/conf.avail# nano public-ip.cfg.lua i have deactivate authentication. turncredentials is activate.

my coturn server is a separate server. the nginx is not configured at my jitsi installation.
What should i do?

In your place I’d take a look at the traffic between coturn and jvb with a network tool such as tcpdump or tshark. If there is none, your coturn server can’t still find the videobridge. You have to search for facts, I can’t do that for you.

ok, thanks.

the tcpdump from our turnserver

09:38:03.127136 IP 188.192.197.230.54067 > <our_turnserverip>.443: UDP, length 20
09:38:03.127329 IP <our_turnserverip>.443 > 188.192.197.230.54067: UDP, length 108
09:38:09.096897 IP 188.192.197.230.37288 > <our_turnserverip>.443: Flags [F.], seq 139520426, ack 2277366615, win 229, options [nop,nop,TS val 1399037867 ecr 2869636298], length 0
09:38:09.097110 IP <our_turnserverip>.443 > 188.192.197.230.37288: Flags [R.], seq 1, ack 1, win 506, options [nop,nop,TS val 2869655329 ecr 1399037867], length 0
09:38:10.328674 IP 188.192.197.230.54063 > <our_turnserverip>.443: UDP, length 112
09:38:10.328957 IP <our_turnserverip>.443 > 188.192.197.230.54063: UDP, length 92
09:38:11.168318 IP 188.192.197.230.37323 > <our_turnserverip>.443: Flags [S], seq 3703533922, win 29200, options [mss 1460,sackOK,TS val 1399038386 ecr 0,nop,wscale 7], length 0
09:38:11.168355 IP <our_turnserverip>.443 > 188.192.197.230.37323: Flags [S.], seq 4076020545, ack 3703533923, win 65160, options [mss 1460,sackOK,TS val 2869657400 ecr 1399038386,nop,wscale 7], length 0
09:38:11.186336 IP 188.192.197.230.37323 > <our_turnserverip>.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 1399038389 ecr 2869657400], length 0
09:38:11.186552 IP 188.192.197.230.37323 > <our_turnserverip>.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 1399038389 ecr 2869657400], length 517
09:38:11.186564 IP <our_turnserverip>.443 > 188.192.197.230.37323: Flags [.], ack 518, win 506, options [nop,nop,TS val 2869657418 ecr 1399038389], length 0
09:38:11.446637 IP 188.192.197.230.37326 > <our_turnserverip>.443: Flags [S], seq 1606381499, win 29200, options [mss 1460,sackOK,TS val 1399038455 ecr 0,nop,wscale 7], length 0
09:38:11.446664 IP <our_turnserverip>.443 > 188.192.197.230.37326: Flags [S.], seq 2671980583, ack 1606381500, win 65160, options [mss 1460,sackOK,TS val 2869657678 ecr 1399038455,nop,wscale 7], length 0
09:38:11.463270 IP 188.192.197.230.37326 > <our_turnserverip>.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 1399038459 ecr 2869657678], length 0
09:38:11.463419 IP 188.192.197.230.37326 > <our_turnserverip>.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 1399038459 ecr 2869657678], length 517
09:38:11.463431 IP <our_turnserverip>.443 > 188.192.197.230.37326: Flags [.], ack 518, win 506, options [nop,nop,TS val 2869657695 ecr 1399038459], length 0
09:38:11.874989 IP 188.192.197.230.37327 > <our_turnserverip>.443: Flags [S], seq 2183971762, win 29200, options [mss 1460,sackOK,TS val 1399038562 ecr 0,nop,wscale 7], length 0
09:38:11.875025 IP <our_turnserverip>.443 > 188.192.197.230.37327: Flags [S.], seq 1887970897, ack 2183971763, win 65160, options [mss 1460,sackOK,TS val 2869658107 ecr 1399038562,nop,wscale 7], length 0
09:38:11.892714 IP 188.192.197.230.37327 > <our_turnserverip>.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 1399038566 ecr 2869658107], length 0
09:38:11.898459 IP 188.192.197.230.37327 > <our_turnserverip>.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 1399038566 ecr 2869658107], length 517
09:38:11.898476 IP <our_turnserverip>.443 > 188.192.197.230.37327: Flags [.], ack 518, win 506, options [nop,nop,TS val 2869658130 ecr 1399038566], length 0
09:38:28.341084 IP 188.192.197.230.37323 > <our_turnserverip>.443: Flags [F.], seq 518, ack 1, win 229, options [nop,nop,TS val 1399042676 ecr 2869657418], length 0
09:38:28.341322 IP <our_turnserverip>.443 > 188.192.197.230.37323: Flags [R.], seq 1, ack 519, win 506, options [nop,nop,TS val 2869674573 ecr 1399042676], length 0
09:38:28.603556 IP 188.192.197.230.37326 > <our_turnserverip>.443: Flags [F.], seq 518, ack 1, win 229, options [nop,nop,TS val 1399042744 ecr 2869657695], length 0
09:38:28.603691 IP <our_turnserverip>.443 > 188.192.197.230.37326: Flags [R.], seq 1, ack 519, win 506, options [nop,nop,TS val 2869674835 ecr 1399042744], length 0
09:38:28.965137 IP 188.192.197.230.37327 > <our_turnserverip>.443: Flags [F.], seq 518, ack 1, win 229, options [nop,nop,TS val 1399042835 ecr 2869658130], length 0
09:38:28.965283 IP <our_turnserverip>.443 > 188.192.197.230.37327: Flags [R.], seq 1, ack 519, win 506, options [nop,nop,TS val 2869675197 ecr 1399042835], length 0
09:38:28.978248 IP 188.192.197.230.37336 > <our_turnserverip>.443: Flags [S], seq 2788245635, win 29200, options [mss 1460,sackOK,TS val 1399042837 ecr 0,nop,wscale 7], length 0
09:38:28.978281 IP <our_turnserverip>.443 > 188.192.197.230.37336: Flags [S.], seq 4031089439, ack 2788245636, win 65160, options [mss 1460,sackOK,TS val 2869675210 ecr 1399042837,nop,wscale 7], length 0
09:38:28.990962 IP 188.192.197.230.37336 > <our_turnserverip>.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 1399042842 ecr 2869675210], length 0
09:38:28.995707 IP 188.192.197.230.37336 > <our_turnserverip>.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 1399042842 ecr 2869675210], length 517
09:38:28.995723 IP <our_turnserverip>.443 > 188.192.197.230.37336: Flags [.], ack 518, win 506, options [nop,nop,TS val 2869675227 ecr 1399042842], length 0
09:38:29.242339 IP 188.192.197.230.37338 > <our_turnserverip>.443: Flags [S], seq 619466846, win 29200, options [mss 1460,sackOK,TS val 1399042902 ecr 0,nop,wscale 7], length 0
09:38:29.242369 IP <our_turnserverip>.443 > 188.192.197.230.37338: Flags [S.], seq 715110237, ack 619466847, win 65160, options [mss 1460,sackOK,TS val 2869675474 ecr 1399042902,nop,wscale 7], length 0
09:38:29.255864 IP 188.192.197.230.37338 > <our_turnserverip>.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 1399042908 ecr 2869675474], length 0
09:38:29.260645 IP 188.192.197.230.37338 > <our_turnserverip>.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 1399042908 ecr 2869675474], length 517
09:38:29.260662 IP <our_turnserverip>.443 > 188.192.197.230.37338: Flags [.], ack 518, win 506, options [nop,nop,TS val 2869675492 ecr 1399042908], length 0
09:38:29.441184 IP 188.192.197.230.37340 > <our_turnserverip>.443: Flags [S], seq 3459520757, win 29200, options [mss 1460,sackOK,TS val 1399042953 ecr 0,nop,wscale 7], length 0
09:38:29.441217 IP <our_turnserverip>.443 > 188.192.197.230.37340: Flags [S.], seq 1909446240, ack 3459520758, win 65160, options [mss 1460,sackOK,TS val 2869675673 ecr 1399042953,nop,wscale 7], length 0
09:38:29.451049 IP 188.192.197.230.37340 > <our_turnserverip>.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 1399042957 ecr 2869675673], length 0
09:38:29.456191 IP 188.192.197.230.37340 > <our_turnserverip>.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 1399042957 ecr 2869675673], length 517
09:38:29.456206 IP <our_turnserverip>.443 > 188.192.197.230.37340: Flags [.], ack 518, win 506, options [nop,nop,TS val 2869675688 ecr 1399042957], length 0

There is no port 10000.
On the jitsi server is also no port 10000 from ingoing.

ufw status turnserver

Status: active

To Action From


22/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
443/udp ALLOW Anywhere
10000/udp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
443/udp (v6) ALLOW Anywhere (v6)
10000/udp (v6) ALLOW Anywhere (v6)

Where i can look what is wrong?

as this is from a cable provider, I take it that’s the address from your workstation ? So there is no traffic at all between turnserver and jitsi.
The coturn configuration is being dumped by default in the log at start, or you can get it from the ‘pc’ command of telnet interface if you have set it up as I cited in my post. Hmm, did you post your coturn config file ? I don’t think so; but the ‘realm’ is an interesting line, if you take its value and on the coturn server try to ping this value, and try the nc trick with the this value, does it succeed ? If you don’t know what it is, here is the thing:

(server)
sudo systemctl stop jitsi-videobridge2
nc -l 10000 -u
(workstation)
echo "123" | nc -u (your public address) 10000

here the ‘workstation’ is the coturn server of course and the ‘public address’ is the realm value.

YOU ARE MY HERO!!!

it works!
The problem was the permission of the private key file.
I changed it to 644 and after restart it works!
Thank you!