openclaw - 💡(How to fix) Fix Bug: Realtime voice bridge fails on outbound calls — status callback race overwrites <Connect><Stream> TwiML [1 participants]

Bug: Realtime voice bridge fails on outbound calls — status callback race condition overwrites <Connect><Stream> TwiML

Description

When making outbound calls with realtime.enabled = true, the OpenAI Realtime voice bridge consistently fails with "WebSocket was closed before the connection was established". The root cause is a race condition between the status callback (regular path) and the TwiML-fetch callback (realtime path).

Environment

• OpenClaw version: 2026.4.15
• Provider: Twilio
• Realtime provider: OpenAI (gpt-4o-realtime-preview)
• streaming.enabled: false
• realtime.enabled: true
• Webhook via Cloudflare Tunnel

Steps to Reproduce

1. Configure voice-call plugin with realtime.enabled = true and streaming.enabled = false
2. Initiate an outbound call via the voice_call tool (mode: conversation)
3. Call connects and Twilio sends webhooks

Expected Behavior

• The TwiML-fetch callback returns <Connect><Stream url="wss://..."> via the realtime shortcircuit
• Twilio connects the media stream WebSocket
• OpenAI Realtime bridge connects and handles the call

Actual Behavior

The call fails every time with this error:

[voice-call] realtime voice error: WebSocket was closed before the connection was established
[voice-call] Failed to connect realtime bridge: Error: WebSocket was closed before the connection was established
    at WebSocket.close (.../ws/lib/websocket.js:300:7)
    at OpenAIRealtimeVoiceBridge.close (.../realtime-voice-provider-*.js:119:12)
    at WebSocket.<anonymous> (.../realtime-handler-*.js:110:39)

Root Cause Analysis

When Twilio initiates an outbound call, two webhook callbacks arrive nearly simultaneously:

The race condition:

1. TwiML-fetch correctly returns <Connect><Stream url="wss://..."> via the realtime shortcircuit. Twilio begins connecting the media stream WebSocket.
2. Status callback goes through the regular path. processEvent registers the call as call.answered, which triggers maybeSpeakInitialMessageOnAnswered → speakInitialMessage → playTts.
3. In playTts (Twilio provider), since no legacy media stream is active (streaming.enabled = false), it falls back to Twilio REST API: POST /Calls/<sid>.json with <Say><Gather> TwiML.
4. This REST API call overwrites the in-progress <Connect><Stream> TwiML. Twilio tears down the media stream WebSocket and sends a stop event.
5. The stop event triggers bridge.close() on the OpenAI Realtime bridge, which is still mid-connect (~1-2s handshake). This throws "WebSocket was closed before the connection was established".

Log evidence (consistent across all 3 observed failures):

:57.619  Status callback (type=status, in-progress) → REGULAR path
:57.628  Starting max duration timer (call registered)
:57.630  Speaking initial message (mode: conversation)
:57.635  WARN: Using TwiML <Say> fallback
:57.642  TwiML-fetch (type=undefined) → REALTIME TwiML returned
:58.185  Starting max duration timer AGAIN (realtime handler also registers)
:58.194  ERROR: WebSocket was closed before established

Suggested Fix

When realtime mode is active for a call, the status callback's processEvent should either:

1. Skip call registration when the call is already being handled by the realtime handler, OR
2. Skip speakInitialMessage when realtime mode is active (the realtime handler's handleCall → onReady → triggerGreeting handles the greeting independently), OR
3. Guard playTts to never issue a REST API TwiML update when a realtime stream is active or pending for that call

Option 2 or 3 seems safest — it preserves status event processing for logging/state tracking while preventing the destructive TwiML overwrite.

Additional Context

• The shouldDeferConversationInitialMessageUntilStreamConnect check in the call manager only returns true when streaming.enabled = true, which doesn't apply to realtime.enabled calls.
• The OpenAI API key and Realtime WebSocket connection are verified working independently — standalone connection tests succeed in ~1.4s.
• Twilio's WebSocket upgrade through Cloudflare Tunnel is also verified working (HTTP/1.1 upgrade returns 101/401 as expected).