VitalPBX Connect: no way to provision TURN/ICE — app unusable where UDP/RTP is throttled (Egypt)

VitalPBX
1

Hello VitalPBX Support,

I run VitalPBX Community Edition and have purchased VitalPBX Connect device licenses, which I installed in my own customers phone. Several of those customers are in Egypt, where mobile carriers throttle VoIP media. VitalPBX Connect is currently unusable there without a VPN, and I have gathered enough data to isolate the cause to one missing capability on the client side.

I would like to know whether there is a supported way to provision TURN settings to the Connect client.

=== ENVIRONMENT ===
VitalPBX 4.5.4-1 (Community), Asterisk 20.21.0, Debian 12
On-premise, behind NAT, static public IP, single IPv4 address
Let’s Encrypt certificate covering pbx / sip / turn / app subdomains

=== THE PROBLEM, MEASURED ===
During a live call from an Egyptian mobile network, ‘pjsip show channelstats’ showed:

Internal leg (LAN extension) : 0% loss, both directions
Egypt leg, inbound to PBX : 322 lost / 169 received (~66% loss)
Egypt leg, outbound to client : 123 lost / 522 sent (~24% loss)

The call dropped after roughly 15 seconds. The internal leg being completely clean rules out any problem on my PBX, my LAN, or my configuration. This is packet policing applied to RTP on the carrier side. No codec survives 66% loss, so codec changes are not a workaround.

=== WHAT I HAVE ALREADY BUILT ===

  1. SIP signalling now runs over TLS on TCP/443, fronted by HAProxy using SNI routing so that sip / turn / app subdomains share the single public IP on port 443. Signalling passes through the Egyptian network without issue, which confirms that TLS/443 is not filtered.

  2. I deployed coturn with TURN over TLS, also reachable on TCP/443 via the same SNI router (turns:turn.example.ps:443?transport=tcp).

  3. I filled in the STUN/TURN fields under Settings > Technology Settings > RTP Settings. These values are correctly written to /etc/asterisk/vitalpbx/rtp__10-general.conf:

icesupport=yes
stunaddr=turn.example:3478
turnaddr=turn.example:443
turnusername=
turnpassword=

=== PROOF THAT THE TURN SERVER WORKS ===
Using a plain browser WebRTC client with iceTransportPolicy set to ‘relay’ and the exact same credentials entered in RTP Settings, the server successfully allocated relay candidates:

relay :20015 udp
relay :20500 udp

So the TURN server, the TLS termination, the SNI routing, the credentials, and the firewall are all confirmed working end to end from an external client.

=== WHAT DOES NOT WORK ===
VitalPBX Connect never sends an Allocate request. During repeated test calls from the app — after regenerating the QR code and re-provisioning the device from scratch — /var/log/turnserver.log shows zero sessions carrying the configured TURN username. The app’s media continues to go out as plain UDP RTP, which is exactly what is being throttled.

The app itself exposes no ICE/STUN/TURN settings in its UI. Decoding the provisioning QR shows a Cloud Softphone URI of the form csc::@VITALPBXCLOUD, so the configuration profile is fetched from the cloud rather than built on my PBX. I could not find any reference to iceEnabled, turnServer, stunServer or similar keys anywhere under /usr/share/vitalpbx, and the VPBXConnect PHP components (Model.php, RestClient.php) are ionCube-encoded, so I cannot inspect or extend them myself.

This suggests that the RTP Settings STUN/TURN fields apply only to Asterisk’s own ICE agent and are never propagated into the Acrobits client provisioning profile.

=== WHAT I AM ASKING ===

  1. Is there a supported way to push iceEnabled, turnServer, turnUsername and turnPassword (or the equivalent Acrobits keys) into the Cloud Softphone provisioning profile used by VitalPBX Connect?

  2. If not currently possible, is TURN provisioning on the roadmap? Media relay over TLS is the only reliable way to deliver working audio in countries that throttle VoIP, and this affects a large and growing market.

  3. In the meantime, would VitXi WebRTC give me client-side TURN control? WebRTC mandates ICE and TURN-over-TLS fallback, so it would solve this — but I would prefer to keep using the Connect licenses I have already purchased.

I am happy to provide packet captures, full channel statistics, or coturn logs, and to test any build or configuration you would like to try.

Thank you,