Hmm… I don’t understand the difference between mattermost and calls in your graph - do you mean the separate processes (mattermost as the core application, the integrated webserver and calls being the plugin)? If so, yes, this is correct.
The clients need to directly connect to the server where the Calls plugin is running via udp/8443 and they need to continue to connect to the mattermost server as they always did.
If your nginx reverse proxy is located on a different server than the mattermost application server, you will probably need to create a new domain name for the connection to the calls plugin (or you need to set the ICEHostOverride to the public IP which gets routed to the calls plugin on this server).
Right now I assume that mattermost.yourdomain.com points to the nginx reverse proxy block in your diagram and that this is a separte computing instance which then forwards to another computing instance where the mattermost application server and the calls plugin are running.
Most likeley, this second computing instance does not have a dedicated public IP, so you can now either set one up and point it to this instance and only allow udp/8443 on the public IP so the calls plugin can be reached from your clients or you can set up a port forwarding (not using nginx, but iptables) on your nginx reverse proxy instance which then forwards udp/8443 on the public interface to the internal IP of your mattermost computing instance.
Hope I explained that well, if not, let me know where I need to rephrase 