Maximum number of agents on a server

[lyxn2011]

Hello,

What is the maximum number of agents that vicidial code can handle on a server?

I have followed the scratch install doc to install the server. In the 'vicidial_conferences' table I can see that only 249 conferences (8600051- 8600299) are created. Also in the dialplan I can see that only conference numbers from 8600051to 8600299 are handled. Does all this mean that even if I have a high capacity hardware, the vicidial code can only handle 249 agents on that server?

Scratch install
Operating sys: Slackware 13.37
mysql: 5.1.56
Asterisk: 1.4.26.2
VicidialVERSION: 2.4-364a BUILD: 120409-1136
No Digium/Sangoma Hardware | No Extra Software After Installation

[Vince-0]

Total agents per server is influenced more by Asterisk CPU utilization. I find between 30 and 50 agents per an Asterisk server in a multi-server configuration, depending on number of CPU cores and media services configuration like call recording.

[lyxn2011]

I wanted to know if the number of agents is limited by the software. Even if I successfully build a hardware which can handle up to 300+ agents, will the vicidial software allow me to have that many agents on that server? Will the vicidial code limit it to 249 agents?

[mflorell]

There is no software limit, but if you put 1 million users in it might slow the system down a lot.

[mcargile]

The biggest limiting factor in the number of Agents is Asterisk itself. It has locking issues. Throwing monstrously powerful servers at it, does not help with this. Sure your audio will sound perfect on the connected calls, but you will have many other problems that you will not be aware of.

One of the biggest issues I see is with overloaded systems. Clients jamming 100+ agents on a massive server and expecting it to work right. They will have transfer issues and blame it on Vicidial. When I get to looking it was because Asterisk for some reason routed the transfer call to the wrong MeetMe or never placed the call in the first place despite being told to. One of the biggest things that happens on these systems that most clients are completely unaware of is that Asterisk will place calls, but never connect them to anything. It is only when I have them take a close look at the vicidial_carrier_log and the vicidial_log table that they realize the scope of the issue. The two tables should be pretty close in size. Instead on an overloaded system they will be upwards of 30% off from each other. That means hat 30% of the calls they are placing never go anywhere, and it is because Asterisk lost the phone call.

All this may change with Asterisk 1.8 support, but then again it might get even worse. Only time will tell.

[williamconley]

I used to bump into maximum meetme rooms on Stupid Large servers (and with other applications that utilized massive meetme). But that limit always seemed to be in the 150+ meetme room realm .. and putting 150 agents on a single server is just silly to begin with. LOL

[shan]

Can you let me the current limit of maximum number of agents that can be login at the same time in asterisk with no call issues? Can anybody here share his latest experience? My vicibox configuration is pasted below. provided I have no hardware limitation issues, just want to the know the software limit ?

[mflorell]

The highest I've seen successfully per server was 100 agents used in an inbound only application with no waiting calls. For slow manual dial outbound I've seen a system that was able to handle 60 agents without too many issues. We usually recommend 20 agents per dialer for most applications. The largest production cluster we've had running was using a total of 850+ agents across 15 dialers with 5 web servers.

[shan]

So you mean, the solution is to do cluster installation with multiple servers running asterisk, and multiple servers running web? And the database can be one only?

[mflorell]

Yes, although all of our larger clients use additional slave databases for reporting as well.

[lmoreira]

The highest I've seen successfully per server was 100 agents used in an inbound only application with no waiting calls. For slow manual dial outbound I've seen a system that was able to handle 60 agents without too many issues. We usually recommend 20 agents per dialer for most applications. The largest production cluster we've had running was using a total of 850+ agents across 15 dialers with 5 web servers.

We manager a cluster with 40 dialers, 5 web servers and about 1k agents. Many campaigns running blended inbound/outbound calls. We place about 1,5 million calls every day for debt collection. That's our largest cluster so far.

[mflorell]

Thanks for posting your example lmoreira!

[dito]

dreamer thinking...
webrtc is more stable and working fine...
now call id can be get from the webrtc..
so ACD based on queues rather than conferences..
and if we are free from conferences why not sending the curl/originate to freeswitch rather than asterisk .. :p
webrtc-freeswitch-queues... vici science fiction mode !
but impossible is not matt florell !

[williamconley]

Still have to account for Call Monitoring, Recording and 3-way calling while in WebRTC.

At that point, you may be right.

Dream Away.

[mflorell]

Certainly not impossible, but I wouldn't be the one doing it

I've attempted to work with FreeSWITCH before, it has a much smaller support community, much more volatile development processes and the performance and stability differences are very minor. We've even attempted to use FreeSWITCH in production before years ago on our hosted platform and it crashed frequently when we attempted to use anything involving database connectivity at a rate similar to a VICIdial server. So, my impressions of using FreeSWITCH were not very favorable at all.

Also, as William mentioned, the recording, monitoring, 3way-calling, etc... are all based around using a conferencing engine, so you would have to figure all of that out as well if you wanted any of that to work. It would basically be a 1000+ hour project, with no guarantee that you would end up with anything any better than what you started with.

[dito]

Still have to account for Call Monitoring, Recording and 3-way calling while in WebRTC.

At that point, you may be right.

Dream Away.

morning ! whisper can be made through queue and 3 way calling can be a button that send caller and called into conf room if necessary ...

I've attempted to work with FreeSWITCH before, it has a much smaller support community

i am not defending FS at all but i am using both asterisk and FS in routing ... FS latest distrib can supporet a peac of 3000 sim calls (with no transcoding)
asterisk at 700 wich is already good performance (normally 400 - 500)

some mass dialing scripts and callcenter handler are already coded into the fusionpbx...
i am so old to dive into php but your work is almost perfect.. always copied / imitated / rebranded .. but all of them know you're the best
thanks for the good work .. nice continuation !

[mflorell]

I've seen Asterisk stripped-down and running on high-end hardware also handle 3000 concurrent channels. The problems come when you want to do complex routing or interacting with a database, and on both of these PBX platforms that greatly reduces their capacity.

[dito]

I've seen Asterisk stripped-down and running on high-end hardware also handle 3000 concurrent channels. The problems come when you want to do complex routing or interacting with a database, and on both of these PBX platforms that greatly reduces their capacity.

of course .. i only trust asterisk as i know it like i know my pocket.. i still not tested the version 15 they talk about very good enhancements :

Streams
Streams, at their core are logical flows of media. They can be unidirectional or bidirectional and are comprised of media formats. The media formats also contain a type. To simplify things streams only carry a single type of media. Streams can also carry an identifier in the form of a name. For a simple voice call, the stream concept adds no additional value. For video, and specifically WebRTC, streams are essential for things like multi-party video conferencing where a single client may have 8 video streams coming in, 1 video stream going out and 1 bi-directional audio stream.

Prior to version 15, Asterisk had no explicit interface for streams and simply had a single pipe that frames are written to and read from. The negotiated formats are scoped to the entire channel as a result. Interfaces that needed to manipulate media had to inject themselves into this single pipe and had to take special care to not manipulate frames they do not need to. This same pipe also carries control frames and other signaling related operations. The result was a very loose stream implementation. For Asterisk 15, the stream concept has been codified with a new set of capabilities designed specifically for manipulating streams and stream topologies that can be used by any channel driver.

WebRTC
To simplify configuration for users a new option, webrtc, has been created which controls configuration options that are required for WebRTC. If the webrtc option is set to "yes" then all options required for WebRTC are enabled. This does still require that DTLS certificates be manually created and configured.

BUNDLE support has been added which improves call setup time. BUNDLE allows multiple streams (for example audio and video) to use the same underlying transport. Since in WebRTC a transport has to go through ICE negotiation and DTLS negotiation this reduces each of those to only happening once. If additional streams are added to a call this also removes the need to do ICE negotiation and DTLS negotiation allowing the media to flow immediately.
Playback of media can now be done as a list rather than an individual resource. This allows easier application management when playing back multiple sounds/recordings.
Channels may be created and dialed separately, rather than as a single origination. This can allow a user to add a channel to a bridge before it has answered in order to facilitate early media.
The CURL function has been modified to be able to write retrieved files to disk. This can be used to retrieve media stored on a remote server for playback, for instance.
All mechanisms in Asterisk that can play media files can now retrieve remote media over HTTP/HTTPS and play that instead.
Extension state (i.e. hints) can now be published over SIP if using the PJSIP library.

some work done with ast15 :
http://blogs.asterisk.org/2017/09/20/asterisk-15-multi-stream-media-sfu/
https://github.com/asterisk/cyber_mega_phone_2k