[Bug]: stun/turn credential problems

[volga629-1]

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?

= 6

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

• I have checked the FAQ for my issue

Considerations for XMPP users

• I have checked if my issue can be solved with Considerations for XMPP users and Considerations for XMPP server admins

XEP-Check

• I have checked that at least XEP-198, XEP-0280, XEP-0352, XEP-0357, XEP-0313 and XEP-0163 are activated on my server and shown as 'green' under Settings --> Account--> (i) in advanced settings

Notifications-Menu

• I have checked that all checkmarks are present under Settings --> Notifications

[tmolitor-stud-tu]

Please show us the following:

• ejabberd_stun-Listener
• mod_stun_disco-Config
• The actual loglines showing the error you mentioned (you can strip off ip addresses etc.)

[volga629-1]

Here 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 [email protected]/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]

[weiss]

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.)

[volga629-1]

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

[volga629-1]

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.

[tmolitor-stud-tu]

Add each other as contact (contact details --> press the "add contact" button)

[volga629-1]

Is this right place ?

[volga629-1]

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]

[weiss]

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?

[FriedrichAltheide]

@volga629-1 And have you configured turn for IPv6 as well?

[volga629-1]

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.

[weiss]

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?

[volga629-1]

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]

[weiss]

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:

1. The address/port isn't reachable for any peer due to server-side networking/routing/firewall issues.
2. The address/port wasn't reachable for that specific peer due to either missing IPv4 connectivity. Some mobile networks tunnel IPv4 through IPv6, which depending on the details may fail for TURN despite working for other services.
3. The address/port wasn't reachable for that specific peer due to UDP (maybe only on high ports) being filtered.

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).