Serverless call center

I translated this from the challenge I wrote when I applied for Ignition Program.

Context

Working freelance at the time, I was contacted by an old colleague who knew my experience with Asterisk (and Voice over IP software) for a project.

Back then (more than five years ago) we worked together at a French telecom operator with a whole system of interactive voice response software running on Asterisk.

Even though I had not worked on VoIP for a few years, I accepted to look into it.

Client’s specifications

The client already had a precise architecture in mind based on Asterisk, but he did not have the knowledge in-house to do it himself.

He wanted me to set up an Asterisk server and to develop a small application to handle this scenario:

• Incoming call is redirected to a pool of agents
• If the caller’s number is “known”, we redirect to the same agent as last time
• Else redirect to random agent

Moreover, we would also need essential features for a call center:

• Call transfer between agents
• Managers need to be able to listen in on calls
• Voicemail
• All calls must be recorded

The caller should not know that he is calling a call center, as he will always be connected to the same agent or his voicemail if unavailable.

Asterisk + SIP Trunk Architecture

The client asked me to set up a SIP trunk with an Asterisk server:

A SIP trunk is a network link with a telecom operator which allows delivering phone calls over the internet via the SIP protocol.
This service is usually billed as a subscription with a predefined number of simultaneous calls.

This is the kind of architecture that I have seen for at least ten years in VoIP.

However, multiple design problems hit me in 2017:

• Multiple SPOF (Single point of failure), if the Asterisk or SIP trunk goes down, there is no more service.
• The service is not scalable, if the number of clients increases, we will need to increase the size of the SIP trunk and to upgrade the Asterisk server.
• An Asterisk server requires some knowledge to be administrated, just adding a new agent would not be a simple task.
• Significant fixed costs: server purchase/renting + SIP trunk subscription

Serverless architecture

I did some research to see how we could approach this problem from a cloud perspective.

Twilio

I quickly find my way to Twilio, which I had already tested on other projects.

Twilio is a cloud communications platform which allows (via API) to make and receive phone calls or SMS. All services are billed on usage.
Twilio uses a system of webhook and callback for each call which can dynamically describe the scenario to follow.
Also, Twilio has many features out of the box: call recordings, call status and logs via API…

With Twilio, we can completely replace the Asterisk server and the SIP trunk, and we will only pay for what we use (pricing per minute)

AWS + Serverless

To complete the solution, we still needed to host our application somewhere.
I wanted to continue in my approach by proposing a serverless architecture.

All those services are fully managed by AWS, no need to worry about a server crash in the middle of the night or an unexpected traffic spike.
Those services are highly scalable, and you will only pay for what you use.
(The first million of requests per month on API Gateway and Lambda are free)

With these tools, I now only needed to write the different functions of the API.

Conclusion

I managed to convince my client of the benefits of a cloud approach.
The result is more efficient, more scalable, and ensures a better service level.

Despite my lack of knowledge of Twilio, I completed the project in two days.
If I had to set up the Asterisk and SIP trunk, I would have required at least one week.

If the project is successful, they will have no problem to scale.
Otherwise, it will cost next to nothing.