Our Video Consultation feature is generally used for calls between clinicians and patients.

Patients will typically make calls on their personal devices using a mobile internet or domestic home broadband network connection. We find it's only in exceptional cases that firewall configuration changes would need to be made on the patient side. We generally recommend, in the rare case that a patient experiences network connectivity issues, that asking them to use a mobile internet connection is the best solution versus debugging/configuring their home firewall.

Clinician side network connectivity issues are also rare but more likely to occur than patient side due to enterprise firewalls being more stringent.

We recommend the following minimum requirements:

For best results we recommend the following:

We recommend testing a clinicians network connectivity by making a call between a device attached to the same network they would use and a device attached to a known good network connection (e.g. a mobile internet connection).
​
You can use the Network tab in the developer tooling for your browser to identify any requests that are being blocked.

Organisations we work with have kindly shared product specific configuration they have found useful. See the sections below for configuring Smoothwall, SonicWall and more. Please do share configuration tips for other products using our support chat below and we will include in this article.
​
​​Contact us for further support with firewall configuration.

The Video Consultation feature is built on the industry standard WebRTC protocol.
​
At the start of a video call, the clients negotiate how they will communicate with each other. They will either communicating directly or through a relayed connection using a TURN server. This maximises video quality whilst supporting a range of network situations, including hospital sites where it is more likely direct communication from client to client would not be permitted.
​
Opening port 443 for outbound TCP and UDP traffic is recommend to allow the direct mode of operation which can improve video quality however is not required.

For sites using Smoothwall Web Filter, we recommend the following configuration:

For sites using SonicWALL, we've found some organisations have had to disable the "App Control" feature. We will update this article if we learn about a more fine grained way to achieve.

For sites using Sophos UTM, we've found some organisations have had to use a combination of configuring HTTP/HTTPS filtering with exceptions for the traffic described above and then bypassing Sophos UTM for the WebSocket traffic.
​
Through working with organisations to configure their firewalls, we've learnt that Sophos UTM does not support filtering of WebSocket traffic at the moment. If you have more context on this, please contact us and we will share with other organisations by updating this article.
​
We've seen sites configure Proxy Auto Configuration (Sophos UTM > Web Protection > Filtering Options > Misc > Proxy Auto Configuration) to send WebSocket traffic direct to a Cisco Firepower configured with an outbound application rule to allow STUN.

For example, one site has kindly shared their configuration:

Some people have asked us whether they can route call traffic so it doesn't go over VPN. The IP addresses involved in a WebRTC call are dynamic, so you can't use IP based QoS rules, unfortunately.

However, we are recommending to use investigate other methods to detect WebRTC traffic (i.e. using Layer 7 rules rather than Layer 4 rules).

We've actively learning and would be grateful for feedback about approaches that have worked!

​