@Vapi @Vapi Support Bot I’m running into an issue with Vapi squads. When the user speaks during a call, the audio is clearly present in the call recording, but nothing shows up in the transcription. Because of this, the call ends due to silence timeout, even though the user was actually speaking. Call IDs: 1) 019cf557-aa53-7000-8cc0-4e47acea8618 2) 019cf56a-eebf-7000-8618-6ba294aa7400 Any guidance or suggestions would be greatly appreciated.

Suggestion: Check your squad's transcriber configuration in the Vapi dashboard and try switching to a more accurate transcriber model. - Go to Dashboard → Observe → Call Logs - Select the affected call and review the transcript and transcriber settings - If needed, update your assistant config to use a different transcriber, for example:

json
"transcriber": {
  "provider": "deepgram",
  "model": "flux-general-en"
}

This step often resolves issues where recordings exist but transcripts are empty ([Vapi Debugging Guide](https://docs.vapi.ai/debugging)). Source: - [Vapi Debugging Guide](https://docs.vapi.ai/debugging)

I have tested with different transcribers, the issue still persists. This is a multilingual squad and I am usign deepgram Nova3

If you’re already using Deepgram Nova-3 with a multilingual squad and still getting recordings without transcripts, it could be related to the language detection or audio channel configuration rather than the model itself. I’d suggest checking the transcriber settings in the call logs again to confirm the language configuration and input audio format. If everything looks correct and the issue persists across models, it may be worth raising it with Vapi support since it could be a squad/transcriber bug. If you want, we could also review the config together and troubleshoot it live.

Message marked as helpful by @Diana precious! 🎉

Hi, Your squad has a

recordingConsentPlan

with

type: 'stay-on-line'

configured on one of the assistants. This consent type mutes audio from reaching the STT stream during the consent waiting period - but in squad calls, there's a bug where this persists throughout the entire call, including after assistant swaps. So Deepgram never receives audio for transcription, triggering the silence timeout. The reason you can hear the user in the recording is that the recorder pulls audio from the transport layer directly, upstream of where the consent muting happens. Fix - pick one: 1. Remove

compliancePlan.recordingConsentPlan

from all squad member assistants 2. Switch to

type: 'verbal'

instead of

type: 'stay-on-line'

if you still need consent handling 3. Move the consent message into the first assistant's greeting without using the formal

recordingConsentPlan

feature Option 1 is the quickest fix if consent handling isn't critical for your use case. We've flagged this as a bug internally. Let us know if you need help updating the assistant config! Best, Vapi Support

This is an enterprise feature. I dont need consent handling

Hi, To remove the consent plan, don't set

type: "null"

- just omit the

recordingConsentPlan

field entirely from your PATCH request:

{
  "compliancePlan": null
}

Or simply don't include

compliancePlan

in the payload at all. The API only accepts

"stay-on-line"

or

"verbal"

as valid types, which is why you're getting the Bad Request error. Since you also mentioned this is a multilingual squad and the issue persists with different transcribers, there may be a second problem: when assistants swap, the STT stream is recreated with the new assistant's transcriber config. If squad members have different

transcriber.language

settings, the new transcriber may not match the language the customer is speaking. To fix this, either use the same language across all squad members, or enable auto-detection:

{
  "transcriber": {
    "provider": "deepgram",
    "model": "nova-3",
    "detectLanguage": true
  }
}

Best, Vapi Support

The squad is set up as follows: There is an initial agent that asks the caller which language-specific agent they would like to be transferred to (English, German, or French). After the caller responds, the initial agent hands off the call to the chosen language-specific assistant. The transcription issue occurs in the initial agent, not in the language-specific agents. The initial agent repeatedly asks the caller which language they want, although the caller’s voice is captured in audio, it is not being transcribed. Is this a provider related Issue? I am using Deepgram Nova3 (multi-lingual) in inital agent.

To resolve the transcription issue, remove the

recordingConsentPlan

from your initial agent's configuration. In your API request, either omit the

recordingConsentPlan

field or set the entire

compliancePlan

to `null`:

json
{
  "compliancePlan": null
}

This will disable consent muting and allow the STT stream to function normally in your squad setup. Reference: [Vapi Recording Consent Plan Documentation](https://docs.vapi.ai/security-and-privacy/recording-consent-plan) Source: - [Vapi Recording Consent Plan Documentation](https://docs.vapi.ai/security-and-privacy/recording-consent-plan)

I have done this already, didn' t resolve the issue

Can you let me know the adjustment you’ve made ?

They advised me to omit compliancePlan.recordingConsentPlan, but it was already omitted since this is an enterprise feature. I also set the compliancePlan:null. Additionally, the transcription issue only occurs with the initial agent and does not affect the downstream agents. The handoff is not smooth. While the caller’s audio is captured, it is not transcribed, which causes the initial agent to repeatedly ask the same question "Which language-specific agent would you like to transfer to?" https://cdn.discordapp.com/attachments/1483007168943755316/1484082559389270088/image.png?ex=69bcef17&is=69bb9d97&hm=7f4437ee63a7ab1b5d4bb6147bba2c08ecb39efca747685bdb0aa5eafddf8001&

since the audio quality is a bit low, i would suggest allowing the use of keypad entry for languages so that the transcriber doesnt have to do much of the heavy lifting of deciphering the audio. for example, "for francais, press 1.... etc."