Some customers use Aircall through a Remote Desktop environment, such as Azure Virtual Desktop or similar technologies, where users log into a remote machine to complete daily activities.
This article explains the common problems that can occur when running Aircall in such environments, the likely causes, and recommended solutions.
Symptoms
When using Aircall through a Remote Desktop or Virtual Machine setup, you may experience the following issues:
- Outbound calls fail or experience significant latency
- Inbound calls are not received when the Aircall app runs on a Virtual Machine
Cause
A Remote Desktop or Virtual Machine introduces additional network and audio transmission layers that can negatively impact Aircall’s performance.
Because Aircall requires a stable, high-quality network connection, routing data and audio through a Remote Desktop client increases the chances of latency, jitter, and packet loss. This additional overhead can cause both outbound and inbound call instability.
Solution
For optimal performance, Aircall should be installed and used directly on the local (thin) client, not on a Virtual Machine or within a Remote Desktop environment.
Important: Aircall does not recommend using Remote Desktop or Virtual Machine setups for running the Aircall app. The best practice is to deploy and use the app locally on each user’s device. For more information, visit our article Device & Headset Recommendations
If a Remote Desktop setup must be used, ensure the following:
- You have a high-speed, stable, and reliable internet connection between the local client and the remote server at all times.
- You perform network and quality tests to confirm consistent low latency and packet stability.
If you are experiencing call quality or connectivity issues:
- Test without the Remote Desktop layer to identify whether the problem is related to the virtual environment.
- If issues persist after removing the Remote Desktop connection, please check our articles about Audio, call quality & network.
Tip: Testing Aircall locally (outside of a Remote Desktop environment) can quickly help isolate whether the issue is caused by network conditions or the virtual machine setup itself.