ScreenMeet Enterprise Deployment Guide

ScreenMeet Enterprise Deployment Guide

The following best practices are recommended for deploying ScreenMeet on enterprise networks and devices.

HTTP Forward Proxies

If you use an HTTP forward proxy in your environment, we strongly recommend configuring your network to allow traffic to *.screenmeet.com to egress directly and bypass the proxy. While ScreenMeet can work with Forward Proxies on Windows Operating systems, this is not recommended. Using a forward proxy will degrade performance in several ways: In some cases, if the forward Proxy doesn’t support WebSockets, it can cause total connection failure. In other cases, it will force WebRTC to connect over TCP instead of UDP, which is a sub-optimal protocol for real-time video and audio. It will also cause hair-pinning of the traffic through the proxy and will add more latency and jitter to the connection.

Virtual Private Networks (VPN)

If your remote workers use a VPN to connect to your enterprise network, we recommend configuring your VPN in a “split-tunnel” configuration, allowing traffic to *.screenmeet.com to egress to the internet directly rather than through the VPN. If screenmeet traffic is being routed through the VPN, it will cause connectivity and performance degradation by creating traffic hair-pinning, choosing sub-optimal server regions, and other complications that may arise from how VPN traffic is processed and egress.

TLS/SSL Inspection (decryption)

If your company deploys a network security solution that decrypts TLS traffic, we recommend adding an exception for traffic from/to *.screenmeet.com. While ScreenMeet support can function while TLS inspection is active, we use certificate pinning in our client software, so users will generally see a warning that the session is “not secure” whenever connecting to a session. Please note that ScreenMeet Beam (unattended) will NOT connect if TLS inspection is enabled on your network - this is an intentional implementation decision for bolstering connection security.

AV / Binary Blockers

If you use a binary blocker (eg, Carbon Black), you will need to white-list the ScreenMeet binaries. On Windows, it is ScreenMeetSupport.exe as well as a bundled dll file called webrtcnative-x64.dll and ScreenMeetSupport.app on MacOS.

macOS Entitlements

ScreenMeet requires permissions to “Record Screen” and “Accessibility” to enable screen sharing and remote control. While the user will be prompted for these permissions on 1st use of ScreenMeet, they will need to have admin permissions to the device to grant these entitlements. For the best user experience, we recommend distributing a profile with your MDM solution that will grant these entitlements automatically and improve the end-user experience.

Firewalls

Allow UDP and TCP traffic for *.screenmeet.com. For more details, please see 

https://docs.screenmeet.com/docs/firewall-white-list.

Data Integration / egress IP’s

For customers that receive data from ScreenMeet in their CRM or Webhook integrations, please see the list of ScreenMeet’s egress IP addresses. API requests targeting your CRM or Webhook destination will originate from these IP’s:

https://docs.screenmeet.com/docs/api-egress-ip-ranges

WebRTC Troubleshooting Tool

The tool below may be run on production-based machines in order to validate that ScreenMeet services will work properly. If the tool fails on a machine, it is likely that one of the categories above is responsible for the failed test. 

https://integration.screenmeet.com/webrtctest/index.html