Is it possible to restrict nextcloud to VPN but to invite external users for a call over a coturn/hpc backend

Hi community,
in the past few days I read through the forums about the talk / Turn and hpc topic. I have set myself up a running coturn/signalling hpc backend in the cloud with public facing IP with the help of this neat script:
GitHub - sunweaver/nextcloud-high-performance-backend-setup. I do reach the hpc/coturn server and entering the domain /secret values inside administration console appears to be succesful.
Here comes the caveat:
I want to set this up for a small company where the nextcloud instance is only available internally or over vpn. So I thought the turn server would be a great solution to allow video calls to externals. When trying to add a guest the generated link shows the internal address of nextcloud, which is not accessible from public…
So my question now:
Is it possible to use nextcloud talk in this scenario? Can the externals not just connect to the public turn/hpc server without knowing anything about the cloud behind?

Hey, just to give you an update what I acheived so far:
I tested the hpc/coturn server with a test nextcloud instance exposed to public and everything works fine, no errors in log. I reread the config files of the spreed-signaling server and noticed that the backend needs to be specified always.
I tried the allowall=true setting with secret specified and I can create rooms in the first place but receive then the error:

ClientException Client error: POST https://hpc1.example.com/standalone-signaling/api/v1/room/cc8o9bas` resulted in a 403 Forbidden response: Authentication check failed`

php error : stream_socket_client(): Unable to connect to ssl://hpc1.example.com:443 (Connection refused) at /var/www/html/custom_apps/spreed/lib/Service/CertificateService.php#107

The logs of the signalling server look like this:

May 22 19:29:23 testdebian-8gb-fsn1-1 nextcloud-spreed-signaling-server[811]: client.go:283: Client from [IPAddress] has RTT of 25 ms (25.29448ms)
May 22 19:29:23 testdebian-8gb-fsn1-1 nextcloud-spreed-signaling-server[811]: capabilities.go:151: Capabilities expired for https://cloud.int.example.com/ocs/v2.php/cloud/capabilities>
May 22 19:29:32 testdebian-8gb-fsn1-1 nextcloud-spreed-signaling-server[811]: capabilities.go:248: Could not get capabilities for https://cloud.int.example.com/ocs/v2.php/apps/spree

Would a signaling proxy solve this problem?
Are there any ideas?
Apreciate any help Thanks