Hangup IAX Loop on Long Drop Call Seconds Queue

[geilt]

Is 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...

[mflorell]

Are you currently using the "--cu3way" flag on your ADMIN_keepalive_ALL.pl crontab entry on your dialers?

[geilt]

No we are not.

We are getting close to the issue now.

Basically, IP Relay is getting "Stuck" but not crashing or restarting on it's own.

It is happening only on one dialer and we have to force kill all 3 IP Relays so that it detect that it is off and then restarts them.

This is effecting music on hold, parks, transfers, and has been a huge headache for the pat 3 weeks.

The IP Relays just wont stay up without manual intervention and we have to "time" it right so we don't lose active working conferences.

It's almost like the ip_relays can't hit the "exit" command properly. This is why I was of the theory that the channels are remaining open when three ways are made and left. It could be causing unneeded load by keeping the channel thread open and overloading ip_relay?

[mflorell]

We've see this and other weird behavior on systems running on virtual machines before, yet more reasons not to run on VMs.