Repository navigation
feat: governed realtime media membrane #2166
Description
Activity
- addedstate:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage
on Jul 7, 2026 @sandl99 are you able to get media working by adding a target endpoint and using
tls:skipto allow traffic to pass through un-inspected? I'd like to just know if the proxy will pass this traffic currently.As far as adding new
protocol: media|grpctypes, we are unlikely to support that. This is a great candidate for using middleware: #1738 - so you could develop a small service that analyzes payloads and annotate allow/deny semantics that will trigger the OpenShell Proxy to take action.What is the concrete MVP you would want to build here? Can we start with one of Parakeet, Magpie, etc and a small governance surface area? If the MVP requirements can be narrowed down we can work with you on using the upcoming middleware feature.
- addedquestionFurther information is requestedFurther information is requestedand removedstate:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage
on Jul 10, 2026 Adding replies from Voice team on your ask @johntmyers
tested on OpenShell 0.0.72 (the version latest NemoClaw pins), with streaming gRPC (local ASR NIM + a cloud gRPC server) and WebSockets.Q1 — yes, both items work through the proxy today, without enforcement:
• gRPC over HTTP/2: streaming gRPC works end-to-end — verified both local (StreamingRecognize to a local ASR NIM) and cloud (server-streaming to a gRPC server). Plaintext gRPC rides plain L4 passthrough; TLS gRPC works via a raw-passthrough endpoint (access: full + tls: skip) — an existing OpenShell policy option that NemoClaw's built-in WhatsApp channel already relies on. (On the default TLS path the proxy MITM-terminates and drops h2 ALPN → HTTP/1.1, which breaks gRPC, so TLS gRPC just needs the raw-passthrough policy.)
• Streaming WebSocket (text + binary): works over L4 — sustained bidirectional streaming, both frame types. Deny-by-default correctly blocks until the endpoint is allowed.
• Everything we tested is TCP-based (gRPC/HTTP2 + WebSocket). WebRTC (UDP) can't terminate inside the sandbox — it can give a better real-time experience on lossy networks, but it isn't required here: a WebSocket audio path is enough to unblock the in-sandbox POC.→ So yes @San Dang — it works; the in-sandbox voice POC is unblocked on the transport side.2 — practical policies to enforce in a media WS stream once the upgrade lands:
today protocol: websocket only covers the handshake + WEBSOCKET_TEXT frames — there's no rule type for binary frames, and no L7 for gRPC. Practical examples:
• gate binary frames (and direction) while still validating the interleaved JSON control frames (e.g. OpenAI Realtime / Twilio Media Streams config messages)
• for gRPC: an HTTP/2-aware method/:path allowlist
(plus, as defense-in-depth on an opaque binary channel: volume / rate / duration caps)
This maps directly to the middleware "parse the protocol → signal allow/deny", you mentioned earlier.@Dharmendra Choudhary (SW-TEGRA) for the POC on Nemoclaw community we have two paths from here:
(1) fully in-sandbox — swap the browser leg WebRTC→WebSocket, STT/TTS via gRPC to NIMs inside;
(2) hybrid — keep UI+Talker+WebRTC on the host (preserve WebRTC UX), and let the in-sandbox OpenClaw voice-call use gRPC to the NIMs.@johntmyers @pimlock I noticed that #2027 was merged as a middleware feature.
I reviewed the current implementation and want to confirm the intended path for gRPC. The current middleware contract exposes EvaluateHttpRequest for buffered HTTP/1.x requests. HTTP/2 is not inspected, TLS termination advertises only http/1.1, and tls: skip relays encrypted traffic without middleware evaluation or credential injection.Do we have any plan for HTTP/2 middleware in near timeline to unblock us ?
Reacted by Piotr MlocekThis issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
- addedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Aug 3, 2026
Problem Statement
Related: NVIDIA/NemoClaw#6207.
VoiceClaw referencces
P0: OpenShell needs a governed realtime media path for audio streams.
OpenShell 0.0.72 can relay WebSocket binary bytes, but only the WebSocket upgrade and text messages have policy semantics today. WebRTC/TURN-style media is also outside the current TCP CONNECT proxy model.
VoiceClaw needs realtime audio without turning the sandbox boundary into an opaque raw socket escape. Media must remain deny-by-default, auditable, rate-limited, and bound to declared destinations and sessions.
Who will use this
voice-calland Talk sessions.Concrete protocol evidence
RivaSpeechRecognition/Recognizeand bidirectionalStreamingRecognize./v1/realtime?intent=transcription, using JSON events with base64 audio./v1/audio/synthesizeand/v1/audio/synthesize_online.RivaSpeechSynthesis/Synthesizeand server-streamingSynthesizeOnline./v1/realtime?intent=synthesize, using JSON events.Proposed Design
Add a governed media protocol surface to OpenShell.
This could be a new
protocol: media, or staged support through:WEBSOCKET_BINARYfor realtime audio over WebSocket.protocol: grpcfor streaming gRPC.The media policy should include:
Alternatives Considered
Agent Investigation
../openclawVoice Call code. Carrier and provider paths use WebSocket media streams; some providers use JSON events with base64 audio and some use binary audio frames.protocol: websocketgoverns upgrade and client text frames; binary WebSocket frames are relayed but not policy-governed.protocol: grpcis not currently listed as an L7 protocol.Sources:
Acceptance Criteria
Non-Goals
Checklist