When Asterisk came along, it was exactly the sort of thing many were looking for. Telephony had been the purview of the giants like Mitel and Nortel. If you wanted a telephone system, you had to pay a lot for a fixed set of functionality. Asterisk gave similar functionality on commodity hardware and much cheaper telephony hardware developed by Digium.
Indosoft had developed against Windows drivers and the Pika cards that were available at the time. Discovering that Asterisk could provide the telephony side allowed Indosoft to adding features and serving clients needs rather than trying to make the phones ring. For the most part it was good. However, we did learn early on that we would be better off allowing Asterisk to handle the phones, but to take more of the responsibility for logic into the Q-Suite itself.
This realization first dawned when we were trying to incorporate the queue priority functionality that was built into Asterisk queues. We configured it as designed, we tested it, and found very quickly that Asterisk frequently crashed when deciding between two queues. It appeared that the feature had been a little rushed, or buggy, and wasn’t actually resolved for several months. It turned out to be easier to build our own implementation of queues. Later, we were able to add features that Asterisk queues did not have because we were already implementing the queue logic in the Q-Suite. When we began implementing multiple-server Asterisk contact center ACD, the fact that the Q-Suite was managing its own queues made it easy to spread the concept of the queue across multiple servers. Ultimately the queue functionality in Asterisk was fixed, and Q-Suite also allows those queues to be used as well.
Conferencing is another feature that has long been available in Asterisk. Some dialers use Asterisk to bridge agents and callers. Q-Suite does not do that. However, it does use the MeetMe conferencing application to bridge together three or more callers, when necessary. Originally, if a third participant had to join the call, a MeetMe conference would be constructed, and the agent, client and third party would be connected to it. The MeetMe would only end once the transfer was done, even after the agent had dropped out.
This was an effective approach to transfers, but Asterisk again presented an obstacle: MeetMe conferences are bound to a single core on the system. Back when it was first created, this solved some problems in regards to timing and audio mixing. There were usually only one or two cores on servers anyway. As the years went on, this limitation began to impact the sort of performance you could get from a single server. If CPU intensive transcoding was occurring (such as using G729 codec), you might notice audible degradation after a dozen participants. Each MeetMe conference was using the same core.
Unfortunately, the success of MeetMe on the Asterisk platform meant that there were few candidates for replacement. In Asterisk 1.8, the ConfBridge application did not provide the AMI or CLI interface that MeetMe did. It could not pass DTMF through. And, it had the unfortunate side effect of crashing Asterisk frequently. It clearly wasn’t an option for replacing MeetMe.
Again, more logic was put into Q-Suite. It can keep track of participants, decide which MeetMes are no longer necessary, and bridge the two call participants back together, then end the MeetMe they were using. This keeps the number of MeetMe conferences to an absolute minimum. Even call centers that do a lot of transfers generally don’t have a large volume of calls where all three participants in a transfer are bridged together.
Finally, as MeetMe conferences are usually bound to a single core, conferences are usually limited to a single Asterisk server. This becomes a problem with load balancing. Of course, Q-Suite manages things so MeetMes on multiple servers can interact as the same MeetMe, allowing scalable conferences transparently to end users.