Hangup IAX Loop on Long Drop Call Seconds Queue
Posted: Thu Dec 05, 2019 5:52 pmIs it possible to manually hangup a IAX Loop after an agent hits Hangup Transfer while in an Consultative Ingroup Queue with a very long drop call seconds set...
What we are noticing is an agent that is impatient, will hangup, the transfer and try again, which is worse for them as they are last in queue, but we had an ingroup with 10000 drop sec timeout and the channels were staying open...
Multiple Dead transfers would be received by the Verification Department, and SOMETIMES, not always, the audio drops. I have added a button in our system to catch the issue in action, but it was not helping because of this theory:
I think that when the agent hits hangup on the dead call, VICI itself (I think I have seen this in the code base for transfer commands) cleans up any open IAX Channels connected to that agent, of which each one of those channels would have been spawned from the same agent and ALL automatically killed including the one that has the client on the line which leads to a no audio issue where the agent and client can hear each other but the verifier and transferred loop as a one way audio issue between the channels due to the cleanup.
Am I making sense?
I have quiet extensive experience and knowledge perusing through the vicidial codebase and running multiple systems.
I mostly bother Matt on Twitter, but figure I start contributing here too...
What we are noticing is an agent that is impatient, will hangup, the transfer and try again, which is worse for them as they are last in queue, but we had an ingroup with 10000 drop sec timeout and the channels were staying open...
Multiple Dead transfers would be received by the Verification Department, and SOMETIMES, not always, the audio drops. I have added a button in our system to catch the issue in action, but it was not helping because of this theory:
I think that when the agent hits hangup on the dead call, VICI itself (I think I have seen this in the code base for transfer commands) cleans up any open IAX Channels connected to that agent, of which each one of those channels would have been spawned from the same agent and ALL automatically killed including the one that has the client on the line which leads to a no audio issue where the agent and client can hear each other but the verifier and transferred loop as a one way audio issue between the channels due to the cleanup.
Am I making sense?
I have quiet extensive experience and knowledge perusing through the vicidial codebase and running multiple systems.
I mostly bother Matt on Twitter, but figure I start contributing here too...