Zingaya and WebRTC: An Interview With Alexey Aylarov

October 10, 2013

When a specific service is transformed into a developer platform.

Zingaya has been around for quite some time. Their offering included click-2-call buttons that can be embedded into any website. Recently, they have started offering an API platform as well, called VoxImplant. This is an interesting move, to say the least, as most vendors transition in the opposite direction with WebRTC – from providing generic APIs to developers to drilling down to specific verticals and use cases.

Alexey Aylarov

I approached Alexey Aylarov, Founder and CEO of Zingaya with a couple of questions on this transition they have made.

 

What is Zingaya all about?

Zingaya is about real-time communications between businesses and their customers. Our service lets you embed a click-to-call button into any webpage to let website visitors make a free call right from their browser (without any download/installation) to either company’s real phone number or to IP BPX/Call Center. It helps to improve customer service (support) or increase conversions (sales), depending on how you are using Zingaya.

 

Can you give an example of an interesting customer making use of Zingaya?

Of course, we have big airlines company from Russia (3rd one in Russia) using Zingaya on their website and in their mobile app for iOS using Zingaya mobile SDK. Their customers call them from all over the world. If you have some problem it is really convenient to use WiFi in the airport or hotel to make a free call to your airline and get help. Btw, around 30% of all their Zingaya calls are mobile calls from their app. They also use smart routing: for their premium customers they forward calls to one part of the contact center and for usual ones – to another.

 

You recently launched VoxImplant as well. Why?

We found out that a lot of people needed solution like VoxImplant:  people were asking us if they could use Zingaya for scenarios where it wasn’t suitable to use Zingaya as is as it wasn’t flexible enough. People were asking for the platform, while we had a service. We have rather good skills in building real-time communication technologies and we participate in WebRTC WG, at some point we decided that WebRTC won’t help everybody and there is still a place for cloud platform that will simplify development of real-time communication apps, especially for web developers. Of course, there were already companies like Twilio / Plivo and others, but we didn’t like the REST API approach they have chosen. We opted for a kind of an app engine approach, where the customer’s code that interacts with our VoxImplant API runs inside our own platform directly, which means less hassle in server development, deployment and maintenance for our customers.

VoxImplant architecture

 

Can you give an example of such a scenario that customers were requesting?

One popular scenario is integration with some web-based CRM. All your call control logic is deployed in the cloud (you can even add business logic there if it’s reasonable) and all CRM data is located somewhere on an external web service – you can make HTTP requests or send emails right from the call control scripts running in the cloud. Developers like our approach and our web-based scripts editor that lets them write (and soon debug), edit and deploy code in the cloud in real-time. It has some really nice features like auto-completion, give it a try 🙂

 

What excites you about working in WebRTC?

For us it’s about bringing high-quality real-time voice and video communications into web browser, we were dreaming about it since the beginning of Zingaya, but had to live with Flash for a long period of time. We always wanted to make VoIP as simple for end users as possible and that’s where WebRTC is going to be a game-changer, no more downloads/installation/setup, just click a button and make a call.

 

What signaling have you decided to integrate on top of WebRTC?

We have our custom signaling working over Secure Websockets, we decided that there was no reason to make complicated signaling and we had our own web-to-SIP gateway anyway, so we weren’t looking for direct interoperability between browser and SIP.

 

Backend. What technologies and architecture are you using there?

We use a lot of different technologies , we write our software by ourselves and don’t use Asterisk/FreeSWITCH/etc. Our Media Gateways, Media Servers and Cloud App Engine (VoxEngine) are written in C/C++ , Billing in Java, for SDKs it depends on the platform: it can be Javascript (Web), Objective C/C++ (iOS) and Java/C++ (Android).

Our cloud architecture is highly scalable we got dedicated servers in different parts of the world and we don’t use public clouds when it’s not required (we only use them for burst when the load increases fast). We still do support Flash in case when WebRTC in unavailable, and we do support UDP-data transfer for it as well as server-side audio enhancement.

 

Where do you see WebRTC going in 2-5 years?

Everywhere. I’m not joking, it will be spread among billions of devices and will be used for all real-time communication services.

 

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

Be ready to fix things on-the-fly until there is no W3C recommendation. WebRTC developers should be really flexible.

 

Given the opportunity, what would you change in WebRTC?

It’s better to address this question to our CTO, Andrey. But I would definitely work on UX/UI for WebRTC in browsers – it’s far from being perfect.

 

What’s next for Zingaya and VoxImplant?

We will be rolling out all features we have in mind till the end of the year and probably will continue in the next year too 🙂 WebRTC is evolving really fast. Of course, we are expecting to build a good development community around VoxImplant + show some great apps and integrations. And we still believe that every website with phone number should have our click-to-call button on it.

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.


You may also like

Comment

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}