Call recipient can't hear the assistant after squa...
# support
k
I have a squad set up that has 2 assistants - the first one navigates the IVR, and a second one that talks to the human representative once the first one is able to get through the IVR. I'm running into an issue where the human representative cannot hear the second assistant at all, and I'm not able to replicate the issue. The only suspicion I have is that the recipient has a PSTN number, whereas I'm testing locally with mobile numbers. Do you have any guidance on what may be wrong and what I can fix here?
v
You can continue this conversation by mentioning me in the message.
@kev3522 It's great that you're using a squad setup with multiple assistants for different stages of the call. The issue you're facing with the human representative not being able to hear the second assistant could be due to a few different factors. Here are some steps you can take to troubleshoot and resolve the issue: 1. **Check Volume Levels**: Ensure that the volume levels for the second assistant are set correctly and are not muted or too low. 2. **Audio Routing**: Verify that the audio from the second assistant is being correctly routed to the call once the IVR navigation is complete. 3. **PSTN Compatibility**: There might be compatibility issues with PSTN (Public Switched Telephone Network) numbers. Test the call with a PSTN number to see if the problem persists. 4. **Codec Issues**: Sometimes, the codec used for VoIP calls might not be compatible with PSTN systems. Check if the codecs used are supported by PSTN. 5. **Network Quality**: Poor network quality or latency can affect the audio transmission. Test the call quality and network conditions. 6. **Logs and Monitoring**: Review logs for any errors or warnings during the transition from the first to the second assistant. Monitoring tools can help identify if the audio stream is being sent and received properly. 7. **Test with Different Devices**: Try testing with different devices and carriers to rule out device-specific or carrier-specific issues. 8. **Contact Support**: If you've gone through these steps and still face issues, it might be best to contact support for more in-depth troubleshooting. If you need further assistance or would like to proceed with any specific checks or tests, please let me know, and I'll be happy to help you further.
k
1, 2, and 5 do not appear to be issues since it works totally fine against mobile numbers. 4 doesn't seem to be a problem because the codec is PCMU. 3 is probably it, but I don't have access to a PSTN number at the moment and looking to get one.
@User the support bot doesn't seem to be working - would you be able to help out? thanks 🙏
I suspect I need to set up SIP trunking, so I followed https://relieved-yuzu-73a.notion.site/SIP-Outbound-Guide-997d66df35284295b7149fc10c82f3e8 but the outbound calls are failing. checked twilio error logs and I'm seeing "SIP: Invalid phone number" the "To" field looks like
<sip:1650*******@****.pstn.twilio.com>;transport=udp
when it should look like
<sip:+1650*******@****.pstn.twilio.com>;transport=udp
I'm using the javascript sdk like so to create the call:
Copy code
const vapiCall = await client.calls.create({
  ...
  customer: {
    number: "+1650*******",
    numberE164CheckEnabled: false,
  }
})
despite the
+
being there in
customer.number
, it seems to always get stripped before it lands on Twilio. maybe a bug wherever Vapi makes the Twilio call?
here's a call id if helpful:
f2ceb397-a9ab-41fc-b5b0-86f9120427d9
@Shubham Bajaj this is fairly urgent for us, please let me know if you could help out! 🙏
s
@kev3522 available for a quick call?
k
yep!
s
@User let's hope over the stage.
k
@Shubham Bajaj thanks for your help earlier! I have one last question - outbound calls with the SIP trunked number end with the reason "Phone call provider clos...". I assume this refers to
phone-call-provider-closed-websocket: The connection with the call provider was unexpectedly closed.
from https://docs.vapi.ai/calls/call-ended-reason is this an expected side effect with the SIP trunk in place? or is it a separate problem?
some call IDs:
7012a004-08a0-4c6e-99b6-4876772de567
,
499093a0-188c-4c4b-acd2-1720a9fb4648
s
@kev3522 When the user hangs up, the SIP gateway sends a cancellation signal, which we register as "phone-call-provider-closed-websocket". Technically, we should rename this event to "customer-ended-call", but that needs to be fixed later. Good to Ignore.
k
perfect, thank you