Add doc section on how to run in a private network

docs/getting_started.md

@@ -13,7 +13,7 @@
 
 > **_Note:_** The following steps are targeting Ubuntu based systems but they should be easily adaptable to other Linux distributions with none to mininimal changes.
 
-As first step you should download the latest official `calls-offloader` version which can be found at https://github.com/mattermost/calls-offloader/releases:
+As first step you should download the latest official `calls-offloader` version which can be found at <https://github.com/mattermost/calls-offloader/releases>:
 
 ```
 wget https://github.com/mattermost/calls-offloader/releases/download/vx.x.x/calls-offloader-linux-amd64
@@ -31,7 +31,7 @@ Create a new system user to own and run the service:
 sudo useradd --system --user-group mattermost
 ```
 
-It's important that the user running the `calls-offloader` binary is part of the *docker* group as the service requires access to the docker API to run jobs:
+It's important that the user running the `calls-offloader` binary is part of the _docker_ group as the service requires access to the docker API to run jobs:
 
 ```
 sudo usermod -a -G docker mattermost
@@ -51,7 +51,7 @@ sudo chmod +x /usr/local/bin/calls-offloader
 
 ## Running
 
-To start the service you can create and enable the following *systemd* file:
+To start the service you can create and enable the following _systemd_ file:
 
 ```
 sudo touch /lib/systemd/system/calls-offloader.service
@@ -76,7 +76,8 @@ WantedBy=multi-user.target
 ```
 
 > **_Note:_** By default the service starts even if no configuration file is provided. In such case default values are used. In the service file above we are overriding a config setting through environment variables:
->    - `api.security.allow_self_registration` We set this to `true` so that clients (Mattermost instances) can automatically self register and authenticate to the service without manually having to create accounts. This is fine as long as the service is running in an internal/private network.
+>
+> - `api.security.allow_self_registration` We set this to `true` so that clients (Mattermost instances) can automatically self register and authenticate to the service without manually having to create accounts. This is fine as long as the service is running in an internal/private network.
 
 Load the service file:
 
@@ -105,5 +106,14 @@ Configuration for the service is fully documented in-place through the [`config.
 The last step is to configure the calls side to use the service. This is done via the **System Console > Plugins > Calls > Job service URL** setting, which in this example will be set to `http://localhost:4545`.
 
 > **_Note:_**
+>
 > 1. The client will self-register the first time it connects to the service and store the authentication key in the database. If no client ID is explicitly provided, the diagnostic ID of the Mattermost installation will be used.
 > 2. The service URL supports credentials in the form `http://clientID:authKey@hostname`. Alternatively these can be passed through environment overrides to the Mattermost server, namely `MM_CALLS_JOB_SERVICE_CLIENT_ID` and `MM_CALLS_JOB_SERVICE_AUTH_KEY`.
+
+## Running in a private network
+
+When the Mattermost deployment is running in a private network, additional configuration may be necessary for the jobs spawned by the `calls-offloader` service to reach the Mattermost side.
+
+In such cases, it’s possible to override the site URL used by jobs to connect by setting (on the Mattermost service) the `MM_CALLS_RECORDER_SITE_URL` or `MM_CALLS_TRANSCRIBER_SITE_URL` environment variables respectively.
+
+Additionally, it may necessary to add the internal site URL to the exception list in the [`ServiceSettings.AllowCorsFrom`](https://docs.mattermost.com/configure/integrations-configuration-settings.html#enable-cross-origin-requests-from) Mattermost server setting.