remFREE provides browser-based remote control without requiring administrators to expose a traditional inbound remote-administration service directly on every managed endpoint.
Remote control is built from several cooperating parts of the remFREE architecture.
Starting a remote session
A technician opens a managed device in remFREE and requests a remote-control session.
The request is coordinated through the normal authenticated remFREE application.
The managed endpoint participates through the installed remFREE agent and its platform-specific remote-session components.
The video path
Remote desktop video uses WebRTC.
WebRTC was designed for low-latency real-time communication and is supported directly by modern browsers.
That makes it much better suited to an interactive remote desktop than repeatedly requesting individual screenshots over ordinary HTTP.
VP8 video encoding
remFREE uses VP8 as a practical video codec for remote-session media.
VP8 provides:
- broad browser support
- mature WebRTC compatibility
- efficient real-time encoding
- a strong fit for interactive screen video
The goal is responsive remote support, not archival video recording.
Keyboard and mouse input
Remote input travels separately from the video stream.
The browser captures supported keyboard and pointer activity and sends those actions through the remote-session communication path.
The endpoint then translates those actions into operating-system-specific input.
Why operating systems need different implementations
Windows and Linux do not expose their graphical desktops in the same way.
Their security models, display systems, session boundaries, and input mechanisms are different.
For that reason, remFREE keeps the server-side remote-control workflow platform-neutral while endpoint-side providers deal with the operating-system-specific details.
This makes it possible for remFREE to maintain one remote-support model without pretending every operating system behaves identically.
Windows session boundaries
Windows services do not normally operate inside the same interactive desktop session as the logged-in user.
remFREE therefore uses a user-session helper architecture for remote-control functions that need access to the interactive desktop.
This keeps the Windows service responsible for service-level work while the helper handles actions that belong inside the user's graphical session.
Linux graphical sessions
Linux remote control depends on the active graphical environment.
X11 and Wayland use different security and display models.
This means Linux capture and input behavior can vary depending on:
- the desktop environment
- the display server
- the active session
- available permissions
- the input provider being used
remFREE treats these differences as platform capabilities rather than attempting to hide them.
Security and auditing
Remote control is a privileged administrative action.
Access should depend on:
- authenticated remFREE users
- tenant membership
- role permissions
- device ownership
- supported endpoint capabilities
Remote-session activity should also remain visible in the platform's operational and audit history.
When normal management works but remote control does not
An endpoint can be online and still have a remote-control-specific problem.
That can happen because normal agent traffic and real-time media traffic have different requirements.
Investigate:
- WebRTC restrictions
- browser permissions
- endpoint graphical-session availability
- endpoint helper status
- firewall policy
- NAT behavior
- UDP policy
Normal device connectivity proves that the management channel works.
It does not automatically prove that the entire remote-media path is available.