Click2Call WebRTC Cloud-Based Call/Support Center Solution

This was a side project I pursued from January to July 2022. The goal was to create an easy-to-customize call-support center solution that customers could register for and obtain a website widget via an HTML JavaScript link tag to install on their websites ,this is similar to Consolto. The business model was Business-to-Business (B2B), and the aim was to provide an easy-to-use support center solution for businesses. In this post, I'll share insights into my approach and the tools used to create this system. This may be helpful for others who want to build something similar and learn from my experience.

System Desing and tools

The system design is based on a Microservice Architecture, anchored on the separation of data of concerns. I leveraged Janus Server for audio calls, video calls, and screen sharing capabilities. Dev Ops targeted GitHub CI/CDs via GitHub Actions and tested and deployed on Amazon Web Services (AWS). I used Aurora MySQL for the database, which was a bit pricey in the region I was using.

Database - Aurora MySQL?

Java:

• ?Spring boot-based Eureka Service Registry meaning all services were clients to this server and had to register at start-up time respectively, Load Balancing?
• API Gateway With Netflix's Zuul and Spring Boot, its function is to handle Authentication, Security , Dynamic Routing, Rate limiting,Load Balancing
• ????- Cron jobs service powered by Quartz Scheduler framework?and stored jobs in a database

Python:

?Built using Fast API framework, used to build the?Ticketing Service, AI-powered Chat reply suggestion Service (not fully complete ), Notifications Service with Emails (SMS to be added later)?

NodeJS:

Used Express for the API services and Socket IO for WebSocket for live chats.?

PHP -?the front-end Admin Dashboard, where the customer support agents were to engage with widget users that are seeking support on their website.

AWS Lambdas were used for small task services, and all the above services except for the WebSocket services registered to the Eureka Service. The above services were deployed via Elastic Container Service (ECS) in a selected cluster.

User-facing Website Widget

The website widget was built with vanilla JavaScript and Socket.IO library, Janus Server main client script. The widget served as the UI tool that website users seeking support used to communicate with the backend.?

System Flow Description

Here is where the customer started, the customer (website owner) would sign up and go through KYC until they could access their Admin panel. During the sign-up process, customers would obtain their widget, which they could plug onto their website. Once the widget is deployed on the website, it pops up at the bottom right corner of the page (as shown above image), and the journey starts. The website user can fill in their details and await the availability of a free support agent. The website widget user can start an audio call, share their screen, or convert the audio call to a video call, once a session starts.

The UI wasn't the best, but the focus was more on functionality. One of the significant challenges was web sockets, and although the native implementation was possible, native WebSocket showed me flames lol a lot, it was a lot of work. I eventually used the Socket IO library for both the web server and client since it proved to be a better option. Scalability of WebSocket was a tricky setup, and although I had hints on how it could be done, it was challenging to fit it into my design and tech stack, yes, I had hints on how this could be done it was a bit tricky and managing sessions across different servers' instances (EC2 instances) also possibly across AWS clusters, even in different regions, was a bit of a tricky to set up. As a solution,?I was thinking of implementing Redi Adapter, but I had to prioritize other pressing issues and time constraints.

Yes, the App was making, and receiving calls both audio and video working 80+% of the time, session management was working, also having text-based conversion was working until the end.

Debugging was another pain point, especially when debugging on a remote server. It was not a walk in the park, and I had to depend on and?go through AWS cloud watch logs and at times, log into the docker containers to review for hours. Memory usage was also a challenge, but I could monitor which processes were taking too much RAM and tried to leverage CPU computation capability. Also had to monitor Janus Server as well?in terms of issues that arise at the time.

I even went on to lengths to create a desktop app for the system, but due to time limitations, I had to focus on the web issues as much until the main requirements were met.

In conclusion, developing a system such as the Click2Call WebRTC Cloud-Based Call/Support Center solution was a daunting task. It came with technical debts and a lot of reconsideration (on system design decisions given the unforeseen issues), but it was a learning experience that I wouldn't trade for anything. Janus Server is a great server that I think it is very easy and has a vibrant open community. You can find more details about this project and its links, including Janus Server, system codebase, AWS, GitHub Actions Documentation, and Redis Adapter, on my GitHub repo.?

Thanks for reading!