vicidial.org

Hello,

Vicidial 6.0.2
1-Database 16X Intel Xeon 16GB Ram
3-Dialers - 16X Intel Xeon 4GB Ram

We are having an issue on inbound calls where sometimes an inbound call will somehow initiate a 3-way conference with 4 agents at the same time. So the customer gets 4 agents at once. While we like to take care of the customer, this is going overboard a little. The exact scenario is on an anonymous inbound call with all of the agents on IAX2 Zoiper Web Phone. I have already determined that each phone was on a different IP address and using a unique session id. Here is a screenshot of the real-time.



Any ideas on how to prevent this?

I've only ever seen this when the database is running slow.

Hmm, the internal network is gigabit. The db server is 16way Intel Xeon with 16GB RAM on SAS mirrored hard drives. Also, has been running about 97% idle.

Is it possible that a bunch of IAX2 phones with the wrong configurations could cause this?

I changed the inbound queue functions to turn on No Delay Call Routing and it seems to have solved the issue at least for now.

I have never used IAX2 phones but it sounds plausible. I am unfamiliar with the 'No Delay Call Routing' but if you're running a cluster and you're having to route inbound calls between telephoney servers this does use IAX2. So It might be related.

No Delay Call Routing is not fixing the issue. Still getting 3-way calls with multiple agents and 1 customer. We switched the agent phones to SIP to see if that would fix the issue but it has not helped. Are there any other things we can try to fix this issue?

Thank you,
Bill

You may also have network issues. How is your Layer 3 networking setup?

I don't think it is a network issue. We have been operating on the same gear for a few years now. I discovered a little more about the issue by doing some test calls and watching the logs, etc. This only occurs when one or more agents are on a dead call and have not gone to dispo yet. It doesn't actually pull anyone in to a 3-way call, it just reports it that way in the real-time log.

I've personally built about a dozen clusters for production and many, many more for test. I haven't seen this issue before version 6 and asterisk 1.8. I suspect it has to do with some of the changes in Asterisk. Either way, we know not to worry about it.

Good to know, it does sound like this belongs on the bug tracker though.