Custom TTS normally returns valid raw PCM and works successfully. When the custom-voice primary is deliberately made unavailable, the call ends instead of using voice.fallbackPlan.voices.

Reproduction: create a WebSocket call with a custom-voice primary endpoint that returns HTTP 503. Include fallbackPlan with voices [{"provider":"vapi","voiceId":"Elliot"}]. The call ends with "Request failed with status code 503", with no spoken fallback. Repeat with [{"provider":"openai","voiceId":"shimmer","model":"tts-1"}]: same result. Both backup voices speak successfully when used directly as the primary. An unavailable primary hostname also ends with getaddrinfo ENOTFOUND rather than activating fallback.

The fallbackPlan is present in the saved voice configuration and in the isolated per-call override. The normal assistant configuration was preserved during testing. Silent audio frames were not counted as successful recovery.

Expected: switch to the configured working backup and continue the call, as described in https://docs.vapi.ai/voice-fallback-plan and https://docs.vapi.ai/customization/custom-voices/custom-tts.

Please confirm whether fallback from custom-voice supports initial synthesis failures on WebSocket/browser calls, which error types trigger recovery, and whether additional configuration is required. Test-call IDs are available through a private support channel.