VA-10: WebRTC data-channel tunnel upgrade #55
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/VA-10-webrtc-datachannel"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
WebRTC data-channel tunnel upgrade (VA-10, Phase 5). The browser may offer to upgrade a relayed-WebSocket tunnel to a WebRTC data channel for lower-latency KVM traffic; the agent is the answerer. Falls back to the WebSocket when WebRTC is unavailable.
What changed
vervain-agent-rtccrate wrappingwebrtc-rs: thectrlChannel:102938signalling envelope (offer/answer/webrtc0/1/2), anRtcUpgradeanswerer (offer SDP in, answer SDP out with candidates bundled non-trickle, data-channel transport + open/failure signals), and ICE config decoding. Multicast-DNS host-candidate obfuscation is disabled so the agent advertises real host IPs.webrtc-rspeers over localhost: data-channel establishment (AC#1), bidirectional frame flow (AC#2), and fall-back-on-no-connect (AC#3).host::tunnel::run_desktop(+host::tunnel_rtc): on a browserofferthe desktop tunnel negotiates, answers, runs the webrtc0/1/2 switchover, and routes KVM tile frames onto the data channel once open (inbound input read from it too). Control frames stay on the WS; the WS is the fallback.webrtcconfigcontrol-channel action (server side: matching vervain-server PR).Dependency
webrtc-rsis heavyweight (~50 transitive crates) but the only pure-Rust WebRTC stack. It builds on the pinned 1.94 toolchain and cross-compiles clean forx86_64-pc-windows-gnu, so the CI Windows parity check stays green.Validation
oci-build/check.Dockerfile: fmt, clippy --deny warnings, build, full test suite (incl. the rtc loopback tests), and the Windows cross-check all pass. The live browser/NAT path is type-checked here; end-to-end needs a real server + browser.Refs VA-10.