This article explains how to forward camera and microphone input — Real-Time Audio and Video (RTAV) — from the end user's device to the remote host through a Thinfinity Workspace RDP session. Enabling multimedia redirection turns a Workspace session into a fully collaborative environment, capable of running Microsoft Teams, Zoom, Google Meet, and any other application that depends on local camera or microphone access.
RTAV configuration spans three layers: the remote host, the user's local device, and the Thinfinity Workspace portal. Skipping any of them — particularly the certificate requirements on the portal — will cause the camera or microphone to fail silently with no clear error message in the browser.
| Product | Thinfinity Workspace |
| Versions | 7.0.1.102 and later (including v8) |
| Protocol | RDP (RTAV is not supported on VNC or native protocols) |
| Audience | Workspace administrators, system engineers |
Before starting, confirm that the following are in place:
The configuration on the remote host depends on the operating system. Follow the section that matches your environment.
If the remote host is a Windows Server, install the Remote Desktop Services role:
If the remote host is a Windows 10 or 11 client, enable Remote Desktop instead:
Windows privacy controls block camera and microphone access at the OS level. These settings must be enabled on both the end user's device and the remote host. Skipping either side results in a session where the user appears to grant access but no audio or video is captured.
After the OS-level permissions are in place, the browser also has its own permission layer. The example below uses Google Chrome — Edge follows the same flow and Firefox is similar. Repeat on both the end user's device and the remote host.
With the host and the operating system permissions in place, enable Remote Sound on the Access Profile. This is the step that turns on the RTAV channel within the Workspace session.
A self-signed certificate is not enough.
Browsers only grant camera and microphone permissions on what they consider a secure context — that means HTTPS with a certificate that the browser actually trusts. If the user sees any "Not secure" or "Your connection is not private" warning when opening the portal, RTAV will fail silently regardless of every other step in this guide.
For RTAV to work, the Thinfinity Workspace Server certificate must meet all three of the following:
- Issued by a trusted Certificate Authority. Either a publicly trusted CA (Let's Encrypt, DigiCert, Sectigo, etc.) or an internal/enterprise CA whose root certificate is already installed as Trusted Root on every client device that will connect.
- Subject Alternative Name (SAN) matches the DNS name users actually type. A certificate for
workspace.example.comwill not work for users who connect viahttps://192.168.1.10or via a different hostname. Verify the Workspace binding hostname matches the certificate exactly.- Currently valid. Not expired, not revoked, and within the validity window. Expired certificates trigger the same browser warning and the same silent RTAV failure.
Self-signed certificates are acceptable only for development or proof-of-concept environments where the same certificate is manually trusted on every test device. They are not viable for production RTAV deployments.
The first time a user connects after this change, the browsers on both sides may prompt for camera and microphone permission. Once granted, refresh the page for the change to take effect. The end user's camera and microphone are now available inside the remote session.
After applying every step, validate end-to-end with the following sequence:
| Symptom | Most likely cause | What to check |
|---|---|---|
| Browser never prompts for camera or microphone permission | Portal is not served over a trusted-HTTPS connection (secure context) | Inspect the certificate against the three rules in Certificate requirements |
| Camera works but microphone does not (or vice-versa) | OS-level privacy setting is off on one side | Verify Camera and Microphone privacy settings on both end user and remote host |
| Video stutters or quality is very low | H.264 is not enabled, or network bandwidth is insufficient | Confirm H.264 is enabled in the Access Profile; test bandwidth from the end user to the gateway |
| Permission prompt appears but device shows as unavailable in the remote session | Remote Sound is not enabled on the Access Profile, or the host does not have the RDS role | Re-check RDP Settings → Resources → Enable Remote Sound; confirm RDS role is installed |
| Worked on first connection, fails on subsequent ones | Browser permission was revoked or session cached an old state | Reset the site permission in browser settings and refresh the portal |