Closes #79118.

Summary

• Wire processParsedEvents (the generic webhook event path used by providers without OpenClaw streaming integration — Telnyx and Plivo today) to fire handleInboundResponse after a final call.speech event for inbound or conversation-mode calls, mirroring the path that already runs for Twilio Media Streams in the onTranscript callback. Gated on manager.processEvent actually appending a user transcript entry so replays and turn-token mismatches stay idempotent.
• Expose a small public CallManager.hasTranscriptWaiter(callId) so the webhook layer can avoid double-firing when a programmatic turn-aware flow (e.g. continueCall) is already lined up to consume the transcript.
• Lookup tolerates both event.callId shapes: the manager UUID (outbound calls carry it via client_state) and the providerCallId fallback (inbound Telnyx calls don't echo client_state, so the normalized event's callId is the call control ID).

Why

Reported in #79118: on Telnyx (and any provider whose final user transcripts arrive through OpenClaw's generic webhook event path rather than a media-stream onTranscript callback), inbound calls answer, the greeting plays, the user transcript is captured to the call record, and then nothing — the bot never speaks again. The call sits in listening until the caller hangs up. Note that Telnyx and Plivo are streaming-capable carriers; OpenClaw's plugin just doesn't wire up streaming integration for them today (see #79324 for the in-flight Telnyx streaming work).

Root cause is a single missing call-site. handleInboundResponse had exactly one invocation, gated behind the Twilio Media Streams onTranscript callback (webhook.ts:391). The generic webhook call.speech handler in manager/events.ts:238 records the transcript and transitions to listening but never invokes the auto-response. Provider webhook events flow through processParsedEvents → manager.processEvent, missing the auto-response handoff entirely.

The fix is the smallest viable change: a peek at waiter state before manager.processEvent (which clears the waiter), then fire handleInboundResponse afterward when no programmatic flow is waiting and the call is inbound or in conversation mode. Path-1 (Twilio Media Streams) is intentionally untouched — no behavior change for streaming providers.

Real Behavior Proof

• Behavior or issue addressed: Telnyx inbound calls (and any provider whose final user transcripts arrive through OpenClaw's generic webhook event path rather than a media-stream onTranscript callback) answer and play the configured greeting, capture the user's final speech transcript to the call record, but the bot never replies — processParsedEvents only forwards the event to the manager and never invokes handleInboundResponse. This PR mirrors the Twilio media-stream auto-response handoff into the webhook event path, gated on actual transcript persistence to preserve manager replay/dedupe semantics. Telnyx and Plivo are streaming-capable carriers; OpenClaw's plugin just doesn't wire up streaming integration for them today (feat(voice-call): add Telnyx realtime media streams #79324 is the in-flight Telnyx streaming work).

• Real environment tested: Linux home server running OpenClaw 2026.5.7 gateway with @openclaw/[email protected] plugin, configured for provider Telnyx (Call Control v2). Regulated DE DID, BNetzA-cleared, Telnyx number status active. Inbound webhook served at 127.0.0.1:3334/voice/webhook and exposed publicly via Cloudflare Tunnel with full Telnyx signature verification active (TELNYX_PUBLIC_KEY). Inbound policy allowlist, German inboundGreeting, per-number responseSystemPrompt, streaming.enabled: false, realtime.enabled: false. Because npm only ships the bundled plugin, the source-equivalent fix was applied as a small local patch to the dist/runtime-entry-*.js chunk file carrying the exact same processParsedEvents logic this PR adds.

• Exact steps or command run after this patch:

  1. Apply the source-equivalent patch to ~/.openclaw/npm/node_modules/@openclaw/voice-call/dist/runtime-entry-*.js (idempotent shell tool, refuses to apply if upstream pattern shifts).
  2. systemctl --user restart openclaw-gateway.service.
  3. Dial the DID from the allowlisted mobile.
  4. Wait for the German greeting, then speak in English.
  5. Continue a multi-turn conversation; hang up.

• Evidence after fix: redacted runtime logs from journalctl --user -u openclaw-gateway.service after the test call. The [voice-call] Auto-responding to inbound call … line is the exact log statement that never appears on current main for the generic webhook event path; with the patch it appears once per final user transcript and the bot's reply is rendered through Telnyx-hosted TTS and audible to the caller.

  [voice-call] Inbound call accepted: +49***REDACTED*** is in allowlist
  [voice-call] Created inbound call record: c7be1d4a-…-… from +49***REDACTED***
  [voice-call] Speaking initial message for call c7be1d4a-…-… (mode: conversation)
  [voice-call] Auto-responding to inbound call c7be1d4a-…-…: "hi which Step are you using"
  [voice-call] Auto-responding to inbound call c7be1d4a-…-…: " and is this um 5 and 5 through the API or through a subscription"
  

  Persisted multi-turn call record copied live from ~/.openclaw/voice-calls/calls.jsonl (redacted, four user turns each followed by a bot reply):

  {
    "callId": "9df40ff1…",
    "provider": "telnyx",
    "direction": "inbound",
    "state": "completed",
    "from": "+49***REDACTED***",
    "to": "+49***REDACTED***",
    "endReason": "completed",
    "transcript": [
      { "speaker": "bot",  "text": "Hallo, was kann ich für dich tun?",                       "isFinal": true },
      { "speaker": "user", "text": "hello how are you",                                        "isFinal": true },
      { "speaker": "bot",  "text": "I'm good, thanks. How can I help you today?",             "isFinal": true },
      { "speaker": "user", "text": " right now",                                               "isFinal": true },
      { "speaker": "bot",  "text": "What would you like me to do right now?",                  "isFinal": true },
      { "speaker": "user", "text": " I want you to tell me which large language model are you","isFinal": true },
      { "speaker": "bot",  "text": "I'm running on OpenAI GPT 5.5 right now, inside OpenClaw.","isFinal": true },
      { "speaker": "user", "text": " okay thank you bye bye",                                  "isFinal": true },
      { "speaker": "bot",  "text": "You're welcome. Bye!",                                     "isFinal": true }
    ]
  }

  Before the fix, only the first two transcript entries existed (the bot greeting and one user turn) and endReason came from the caller hanging up after silence rather than from the bot saying goodbye.

• Observed result after fix: caller heard each bot reply audibly through the call. Multi-turn conversation worked end-to-end. Conversation ended naturally (caller said "okay thank you bye bye" → bot replied → caller hung up). No regressions observed in outbound calling or any other voice-call flow on the same gateway during the test session.

• What was not tested:

  • Plivo (the other provider currently using the generic webhook event path). The same processParsedEvents code path covers it and the fix is provider-agnostic, but I don't have a Plivo number to dial.
  • Twilio Media Streams (path-1) regression. The diff makes no behavioral change to that path, but I don't have a Twilio number to dial either. Unit coverage in webhook.test.ts > VoiceCallWebhookServer media stream auto-response continues to pass.
  • Live race between an active transcriptWaiter and a webhook transcript event. Covered by the unit test "does not fire handleInboundResponse when a transcript waiter is pending" but not exercised live.

Verification

• pnpm test extensions/voice-call/src/webhook.test.ts — 38/38 pass (34 pre-existing + 4 new under the webhook event path auto-response (#79118) describe block)
• pnpm test extensions/voice-call/src/manager/events.test.ts extensions/voice-call/src/manager.closed-loop.test.ts extensions/voice-call/src/providers/telnyx.test.ts — all pass
• Whole voice-call extension test run (44 files, 377 tests) — all pass; no regressions
• pnpm check:changed — exit 0 (typecheck extensions, typecheck extension tests, lint extensions via oxlint, runtime sidecar loader guard, runtime import cycles, duplicate scan target coverage)

Notes

• AI-assisted: PR drafted with Claude (Opus 4.7); fix logic, tests, and the live-call validation above are mine.
• I am the original reporter of [voice-call] Telnyx inbound calls answer and greet, but bot never replies — auto-response loop missing for webhook call.speech path #79118; the live call setup that produced the proof above is the same setup described in the issue body.