maureen.shaw1 | 2022-10-25 14:05:33 UTC | #1
How can you troubleshoot an inbound call that immediately drops to a new inbound flow? It came back as a system disconnectType. I can point the DID to a different callflow and it works so it doesn't seem to be the DID. I even changed the first task to play the same exact wav file as the working flow and it still drops with the triple beep immediately after I dial the DID. I am not sure how else to see why it is failing, as it fails without completing any of the actions in the flow. I did run developer tools and see that we are getting a 409 back on what looks like loading the prompts. I have compared the settings for the working and non-working script and the they are the same. The biggest difference is that the new flow is much larger (2500 tasks/menus) but I thought the max per flow was 10k. Any help is appreciated! Thanks!
"state": "terminated", "direction": "inbound", "disconnectType": "system",
jacobshaw | 2022-10-25 15:15:10 UTC | #2
Hi @maureen.shaw1
For this resource, POST /api/v2/architect/prompts, the 409 status code is associated with the "Conflict" message. Further, the error code for this response type is architect.prompt.already.exists, meaning a prompt with the specified name already exists. Maybe this helps.
maureen.shaw1 | 2022-10-26 06:00:22 UTC | #3
Thank you so much for your response Jacob! Turns out this was an error that was thrown when I was trying to change out prompts (to see if this would resolve my issue, since the call drops immediately). In looking at the packet capture, I see the BYE coming from maybe a switch? I am at a loss at this point. Thank you for any input!
jacobshaw | 2022-10-26 13:25:25 UTC | #4
A couple things to help find the failure point The Architect flow size indicator. By default it will display when the flow is 70% or more of it's maximum size. That should help determine if the flow is too large. See the article for a more throrough description.
Also the interaction details view shows the point of disconnect as well as the reason for disconnect. Here's the doc for Disconnect reasons
maureen.shaw1 | 2022-10-27 06:01:04 UTC | #5
Thank you! I was worried that it was too large, even though it was about 3000 elements, a lot of them are menus with some tasks. I did check the flow size indicator and it shows it is low: The disconnect reason shows as system in the interaction timeline and disconnects after exactly 1 second each time. Below is the party sending the BYE, which makes it seem like the switch/carrier maybe? I never get any call treatment, just a beep and the call drops each time. If I point the DID to a different script it works fine. Thank you for your help!
mod_sofia GENESYS-SIPSERVICE
jacobshaw | 2022-10-27 14:34:20 UTC | #6
I think opening a case with Care is going to be your best bet. They can look at customer-specific data (edge logs, etc.)
maureen.shaw1 | 2022-11-07 19:28:22 UTC | #7
Customer Care says that the script is most likely corrupt :( . I am working on rebuilding from scratch, as I don't know any other way around it. Thanks for your time and input jacobshaw!
system | 2022-12-08 19:28:34 UTC | #8
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 16872