Closed volga629-1 closed 2 months ago
Please show us the following:
ejabberd_stun
-Listenermod_stun_disco
-ConfigHere are information
-
port: 3478
transport: udp
module: ejabberd_stun
auth_realm: user
auth_type: user
use_turn: true
turn_min_port: 51000
turn_max_port: 54000
turn_ipv4_address: pubic ip
-
port: 5349
transport: tcp
module: ejabberd_stun
auth_realm: user
auth_type: user
tls: true
use_turn: true
turn_min_port: 51000
turn_max_port: 54000
ip: 10.18.130.29
turn_ipv4_address: public IP
mod_stun_disco:
access: local
offer_local_services: true
credentials_lifetime: 4
secret:
services:
-
host: disco.domain.com
port: 3478
type: stun
transport: udp
restricted: false
-
host: disco.domain.com
port: 3478
type: turn
transport: udp
restricted: true
-
host: disco.domain.com
port: 5349
type: turns
transport: tcp
restricted: true
Log
2024-07-08 14:15:29.758738-04:00 [info] <0.622.0>@mod_stun_disco:handle_call/3:332 Offering STUN/TURN services to user@domain.com/Monal-iOS.80f7d04b (cad8c3515d7e15f0)
2024-07-08 14:15:32.098645-04:00 [notice] <0.469.0>@stun:process/2:248 Failed long-term STUN/TURN authentication [UDP, session 86o7uy6bxfr7, user 1720462502:6d25cc055d7e15f0, client 129.222.194.45:34013]
2024-07-08 14:15:32.104233-04:00 [notice] <0.469.0>@stun:process/2:248 Failed long-term STUN/TURN authentication [UDP, session u11tt9xpu32o, user 1720462502:6d25cc055d7e15f0, client 129.222.194.45:13814]
2024-07-08 14:15:32.115034-04:00 [notice] <0.469.0>@stun:process/2:248 Failed long-term STUN/TURN authentication [UDP, session bqmh1pbbzk6v, user 1720462502:6d25cc055d7e15f0, client 129.222.194.45:43799]
2024-07-08 14:15:32.115194-04:00 [notice] <0.469.0>@stun:process/2:248 Failed long-term STUN/TURN authentication [UDP, session efcesl0tl7xu, user 1720462502:6d25cc055d7e15f0, client 129.222.194.45:37016]
credentials_lifetime: 4
Here you're telling ejabberd to invalidate the temporary TURN credentials 4 seconds after handing them out to the client. That's the culprit I guess.
I'd suggest sticking to the example configuration:
listen:
-
port: 3478
ip: "::"
transport: udp
module: ejabberd_stun
use_turn: true
## The server's public IPv4 address:
# turn_ipv4_address: "203.0.113.3"
modules:
mod_stun_disco: {}
The mod_stun_disco
options you're using are basically just needed to configure external TURN servers. And offering TLS will usually just add negotiation latency without serving an actual purpose, as clients will prefer UDP (to avoid additional A/V stream latency) and WebRTC streams are end-to-end encrypted anyway. (The only real use case is offering TURNS on port 443 for circumventing restrictive firewalls.)
I appleid suggested settings, but still authentication failure message present. Calls hit and miss sometimes one way , sometimes only audio.
[notice] <0.469.0>@stun:process/2:248 Failed long-term STUN/TURN authentication
I don't know if it related, but under contact --> Resources is empty. And when I try to place the call it says that "Missing call support" message.
Add each other as contact (contact details --> press the "add contact" button)
Is this right place ?
Ok I removed and added contacts and it display resources correctly right now, but call on LTE data failing right away. On LTE call call disconnects on log lines
2024-07-11 21:26:22.918027-04:00 [notice] <0.1111.0>@turn:wait_for_allocate/2:226 Creating TURN allocation (lifetime: 600 seconds) [UDP, session aynglo1k392q, user 1720783673:cad8c3515d7e15f0, client client_public_ip:7785, relay ejabberd_public_ip:52370]
That log line is fine (doesn't refer to a disconnection).
call on LTE data failing right away.
Do you get an error message?
And: Is the UDP port range (49152
–65535
) accessible on the configured turn_ipv4_address
?
@volga629-1 And have you configured turn for IPv6 as well?
Yes, no error and I checked firewall and turn ip configuration and they exactly as you described. In logs there are no error messages. There no IPv6 configured.
IPv6 is required to make STUN/TURN work for certain (mobile) networks, but if the log message you cited was indeed related to the failed call, then missing IPv6 is not the issue in this case.
The log message basically says that the TURN session was created by the client just fine. Next step would be the peer talking to the UDP port created for that relay (port 52370 according to your log message). Note that the "peer" may either be the contact's client or the contact's TURN server; if the contact is using your server as well, it would be your own TURN server, which would end up talking UDP to itself (I'm mentioning that because that specific case may go wrong even if other scenarios work, depending on your setup).
Do you see any additional messages if you grep the log for aynglo1k392q
?
That only messages I see
[~]# grep aynglo1k392q /opt/ejabberd/logs/ejabberd.log
2024-07-11 21:26:22.918027-04:00 [notice] <0.1111.0>@turn:wait_for_allocate/2:226 Creating TURN allocation (lifetime: 600 seconds) [UDP, session aynglo1k392q, user 1720783673:cad8c3515d7e15f0, client clinet_ip:7785, relay ejabberd_public_ip:52370]
2024-07-11 21:26:37.180117-04:00 [notice] <0.1111.0>@turn:terminate/3:489 Relayed 5 KiB (in 0 B / 0 packets, out 5568 B / 58 packets), duration: 14 seconds [UDP, session aynglo1k392q, user 1720783673:cad8c3515d7e15f0, client client_ip:7785, relay ejabberd_pubic_ip:52370]
Those messages poove that a TURN session was created and used by the client successfully, but that no incoming traffic was received from the peer on UDP port 52370. The server logs won't reveal why no traffic was received. Presumably, UDP port 52370 isn't accessible for the peer on the turn_ipv4_address
. All I can offer is guessing some possible causes:
Issue 2 and 3 should in practice be mitigated by the contact's client using TURN as well. Maybe that's not the case, or the contact is actually using the same TURN server as the client, which would lead to the TURN server talking UDP to itself (via the turn_ipv4_address
), and maybe the server-side networking setup just doesn't allow this special case (could happen if e.g. the TURN server is behind NAT).
This seems to be inactive and since this is a server configuration error, I'll close it now.
What Monal Release channel are you using?
AppStore
iOS system version (if applicable)
17.5.1
macOS system version (if applicable)
17.5.1
Monal version
6.4
Used XMPP server (domain)
networklab.ca
Which XMPP-Server software are you using?
ejabberd
XMPP Server Software Version
24.06
How many accounts are you using in Monal?
What happened?
For video audio calls ejabberd stun , turn after discovery is failing. Based on ejabberd logs authentication sent incorrectly and result call is failing.
Anything else?
I will submit logs soon
FAQ
Considerations for XMPP users
XEP-Check
Notifications-Menu