feat(desktop): browser WebRTC data channel with Direct/Relayed transport #73

Merged
Claude-Run merged 1 commit from feat/VAPP-63-desktop-webrtc-data-channel into main 2026-07-01 03:13:51 +02:00
Member

The desktop pane routed the KVM stream purely over vervain-server's relay WebSocket, so a session could never report a direct peer-to-peer path even though the agent already speaks the answerer half of a WebRTC upgrade (vervain-agent-rtc: signalling.rs, tests.rs) and MeshCentral's agent-redir-ws documents the browser offerer half.

Add the browser (offerer) side. Enable the web-sys Rtc* features under the wasm32 target and, on rendezvous, build an RtcPeerConnection, create the "DataChannel", generate a non-trickle offer (ICE candidates bundled in the SDP, sent once gathering completes), apply the agent's answer, and drive the webrtc0/webrtc1/webrtc2 switchover so the desktop binary stream (inbound tiles and outbound input) moves onto the peer-to-peer channel once it opens. All signalling rides the existing 102938 ctrlChannel text-frame convention, so the SPA keeps one control-frame convention.

Introduce a Transport that routes binary frames over the data channel when active and falls back to the WebSocket per frame on a channel-send error; signalling always stays on the WebSocket, matching the agent. Expose an is_direct signal from DesktopPane (shown as a Direct/Relayed badge in the ribbon) that the wasm driver flips true while frames flow over the channel and back to false on channel close or ICE failure, which the VAPP-51 connection-quality indicator consumes.

ICE uses an empty configuration (host candidates only), mirroring the agent's default IceConfig; server-provided STUN/TURN for NAT traversal needs a server-side config channel the relay tunnel does not expose yet and is left to a follow-up rather than hardcoding STUN servers.

The classification (parse_control), framing (offer_frame/switchover_frame), and switchover sequencing (Switchover) are factored out of the wasm driver as pure, host-tested logic, matching the ReorderBuffer/map_axis pattern.

#VAPP-63

The desktop pane routed the KVM stream purely over vervain-server's relay WebSocket, so a session could never report a direct peer-to-peer path even though the agent already speaks the answerer half of a WebRTC upgrade (vervain-agent-rtc: signalling.rs, tests.rs) and MeshCentral's agent-redir-ws documents the browser offerer half. Add the browser (offerer) side. Enable the web-sys Rtc* features under the wasm32 target and, on rendezvous, build an RtcPeerConnection, create the "DataChannel", generate a non-trickle offer (ICE candidates bundled in the SDP, sent once gathering completes), apply the agent's answer, and drive the webrtc0/webrtc1/webrtc2 switchover so the desktop binary stream (inbound tiles and outbound input) moves onto the peer-to-peer channel once it opens. All signalling rides the existing 102938 ctrlChannel text-frame convention, so the SPA keeps one control-frame convention. Introduce a Transport that routes binary frames over the data channel when active and falls back to the WebSocket per frame on a channel-send error; signalling always stays on the WebSocket, matching the agent. Expose an is_direct signal from DesktopPane (shown as a Direct/Relayed badge in the ribbon) that the wasm driver flips true while frames flow over the channel and back to false on channel close or ICE failure, which the VAPP-51 connection-quality indicator consumes. ICE uses an empty configuration (host candidates only), mirroring the agent's default IceConfig; server-provided STUN/TURN for NAT traversal needs a server-side config channel the relay tunnel does not expose yet and is left to a follow-up rather than hardcoding STUN servers. The classification (parse_control), framing (offer_frame/switchover_frame), and switchover sequencing (Switchover) are factored out of the wasm driver as pure, host-tested logic, matching the ReorderBuffer/map_axis pattern. #VAPP-63
feat(desktop): browser WebRTC data channel with Direct/Relayed transport
All checks were successful
Check / fmt + clippy + build + tests (pull_request) Successful in 51s
Create release / Create release from merged PR (pull_request) Has been skipped
591d812437
The desktop pane routed the KVM stream purely over vervain-server's relay WebSocket, so a session could never report a direct peer-to-peer path even though the agent already speaks the answerer half of a WebRTC upgrade (vervain-agent-rtc: signalling.rs, tests.rs) and MeshCentral's agent-redir-ws documents the browser offerer half.

Add the browser (offerer) side. Enable the web-sys Rtc* features under the wasm32 target and, on rendezvous, build an RtcPeerConnection, create the "DataChannel", generate a non-trickle offer (ICE candidates bundled in the SDP, sent once gathering completes), apply the agent's answer, and drive the webrtc0/webrtc1/webrtc2 switchover so the desktop binary stream (inbound tiles and outbound input) moves onto the peer-to-peer channel once it opens. All signalling rides the existing 102938 ctrlChannel text-frame convention, so the SPA keeps one control-frame convention.

Introduce a Transport that routes binary frames over the data channel when active and falls back to the WebSocket per frame on a channel-send error; signalling always stays on the WebSocket, matching the agent. Expose an is_direct signal from DesktopPane (shown as a Direct/Relayed badge in the ribbon) that the wasm driver flips true while frames flow over the channel and back to false on channel close or ICE failure, which the VAPP-51 connection-quality indicator consumes.

ICE uses an empty configuration (host candidates only), mirroring the agent's default IceConfig; server-provided STUN/TURN for NAT traversal needs a server-side config channel the relay tunnel does not expose yet and is left to a follow-up rather than hardcoding STUN servers.

The classification (parse_control), framing (offer_frame/switchover_frame), and switchover sequencing (Switchover) are factored out of the wasm driver as pure, host-tested logic, matching the ReorderBuffer/map_axis pattern.

#VAPP-63
David deleted branch feat/VAPP-63-desktop-webrtc-data-channel 2026-07-01 03:25:12 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/vervain-apps!73
No description provided.