vicidial.org

mflorell wrote: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.

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

At that point, you may be right.

Dream Away.

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

mflorell wrote: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.

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.