User's Block is getting broken
# support
a
We erased the first message because the user's blocks were broken and we have the problem that people are hanging up because the assistant is not speaking. In other cases, we inserted "hello" as the first message and if the user spoke through the first message, then the blocks were broken again. This is the call id: a1f04608-8641-4f11-9a96-bf97a954504e
v
message has been deleted
@Andres Cardozo I understand that you're experiencing issues with the assistant's messages during calls, leading to either broken blocks or users hanging up due to the assistant not speaking. To address this, we need to review the clientMessages configuration for the assistant and ensure that the messages are set up correctly to engage the users without causing interruptions or silence that could lead to hang-ups. Could you please provide more details on how you would like the assistant to behave during the calls? Specifically, what messages should be sent and at what points during the interaction? This information will help us to adjust the settings accordingly and resolve the issue you're facing.
You can continue this conversation by mentioning me in the message.
a
It only happens when I send an outbound call. The user is speaking but the orange block appears broken. Eventually, the call ends because of the silence time-out. Here is an example https://cdn.discordapp.com/attachments/1316852392209154048/1325460935015530637/image.png?ex=677bdf30&is=677a8db0&hm=4496860c6d2362f05f47995c6142ea8809e8747650f70b7550a4b7bcd2930f19&
s
@Andres Cardozo Apology for the late response. Blocks are not yet ready for production or development use, so you'll need to use the assistant for now.
a
Those are not blocks. I meant the users audio is getting blocked
This is happening with normal assistants
@Shubham Bajaj
s
@Andres Cardozo I apologize for any misunderstanding regarding blocks. Could you please share a recent call ID? We only keep logs for approximately one month, so I need a recent ID to investigate what's causing the user audio to be blocked. While I can access call recordings, they may not be as helpful in diagnosing this specific issue. I'm also aware of your other ticket and will look into that as well. Started At
2024-12-12 18:03:29.387+00
https://cdn.discordapp.com/attachments/1316852392209154048/1326902068971175986/Screenshot_2025-01-09_at_18.37.01.png?ex=67811d59&is=677fcbd9&hm=169c2820dcb2b802290998c5d2252bf853c5105e21650733d7462cbfb2ad855d&
@Andres Cardozo Looking at the previous thread PCAP data, we noticed there was a significant delay (about 27 seconds) from your end in responding to our INVITE request. While the PCAP shows timestamps going up to 42 seconds, you'll only hear 15 seconds of audio in the call recording (42 minus 27). This is because the call audio didn't actually connect until that 27-second mark. So any conversation that happened before the connection was established won't be captured in the recording.
a
Hello @Shubham Bajaj, here is a couple of call ids with the same problem: 1. 00cb0885-b69c-4a95-b630-5ca3cb0b8ce0 2. 5f074463-ebe6-489c-a10e-92863552906e 3. 07de8529-b00a-489c-bbd8-591b17dbf8ad
s
Call Recording: https://storage.vapi.ai/5f074463-ebe6-489c-a10e-92863552906e-1736429720238-80398839-542b-48b8-9ad4-780f55ce20fc-mono.wav @Andres Cardozo The call recording is still only 10 seconds long. However, looking at the PCAP file, it took 44 seconds to respond to the SIP invite, which caused the user's audio to be lost. You will need to check with your telephony provider about this delay. I am sharing the PCAP file for your reference. Call Id: 5f074463-ebe6-489c-a10e-92863552906e https://cdn.discordapp.com/attachments/1316852392209154048/1327587173800611872/Screenshot_2025-01-11_at_16.05.42.png?ex=67839b67&is=678249e7&hm=77f9fc2c89ad871c6cfb495b004f9dc68b484c191c25b13afdc63423034ec0a7& https://cdn.discordapp.com/attachments/1316852392209154048/1327587174023172157/Jambonz_Call_ID_46f94911.pcap?ex=67839b67&is=678249e7&hm=2a165d38ba6529d1537372b1b0cf889d94fea602838a2f0c1d27a62ed898d50d&
a
aThank you very much Shubham! We will check it right now to confirm it is in fact a problem in our end