A remote desktop session is fundamentally different from a normal remFREE job.
Inventory can take a moment.
A script can take several seconds.
Remote mouse movement cannot.
Interactive support depends on low latency.
That requirement is why remFREE uses WebRTC for the remote-session media path.
Why screenshots are not enough
remFREE supports screenshot capture as a useful management feature.
But screenshots are individual images.
Trying to build full remote control by repeatedly taking screenshots would create a poor interactive experience.
The process would look something like:
capture image
|
v
upload image
|
v
display image
|
v
repeat
That model introduces unnecessary delay and bandwidth overhead.
Remote control instead needs a continuous media stream.
WebRTC
WebRTC is a technology designed for real-time communication between endpoints and browsers.
It provides mechanisms intended for interactive media rather than traditional request-and-response web traffic.
For remFREE, that makes it a strong fit for remote desktop video.
The remote-session path
Conceptually:
Managed Desktop
|
| screen capture
v
Session Helper
|
| VP8 video
v
WebRTC
|
v
Technician Browser
The exact endpoint capture method can vary by operating system, but the browser-side experience can remain consistent.
Why VP8?
remFREE uses VP8 for remote-session video.
VP8 is useful because it provides:
- broad browser support
- mature WebRTC compatibility
- real-time encoding characteristics
- reasonable compression
- no requirement for a browser plugin
This makes it practical for browser-based remote assistance.
Video and input are different things
Remote control contains at least two major flows.
The first is visual:
Endpoint screen → browser
The second is control:
Browser input → endpoint
Keyboard and mouse actions do not need to be embedded into the video itself.
They travel through the remote-session control path and are interpreted by the endpoint-side provider.
This separation allows the video stream and the control stream to be optimized for different requirements.
Mouse responsiveness
Mouse movement is especially sensitive to latency.
A remote-control implementation must avoid creating an unnecessary backlog of pointer events.
If the browser produces movement events faster than the endpoint can consume them, the system must avoid turning yesterday's mouse position into tomorrow's problem.
That is why remote-input implementations may use techniques such as:
- coalescing movement
- throttling unnecessary events
- tracking the newest pointer state
- avoiding excessive logging in high-frequency paths
Remote input is an interactive stream, not an audit log of every physical pixel crossed by the pointer.
WebRTC and the management channel are separate
An endpoint can be healthy in remFREE while a remote-control session fails.
That is because the normal management path and the media path have different requirements.
For example:
HTTPS / WSS works
|
+---- inventory works
+---- jobs work
+---- heartbeat works
WebRTC problem
|
+---- remote video may fail
This distinction is extremely useful when troubleshooting.
Network considerations
WebRTC behavior can be influenced by:
- firewall policy
- NAT
- UDP restrictions
- browser configuration
- enterprise security policy
Normal access to https://rmm.remfree.com does not automatically prove that every possible WebRTC path is available.
Why browser-based remote support?
Using the browser as the technician interface reduces the need to distribute a separate technician viewer.
The browser already provides:
- rendering
- input events
- WebRTC
- authentication context
- cross-platform access
That allows the remFREE web application to remain the technician's primary workspace.
Different operating systems, one support experience
Windows and Linux require different mechanisms for screen capture and input injection.
remFREE isolates those differences behind endpoint-side providers and helpers.
The goal is:
one remFREE remote session model
while still respecting:
different operating-system security models
That distinction is important to the long-term cross-platform design.