Amir Zmora is Co-founder and CEO of SwitchRTC. In this interview, Dan catches up with Amir on why he founded SwitchRTC and the problems it solves in the market.

Q. Hi Amir.  We’ve known each other for several years now, but my readers may not know much about your history.  Can you tell me a bit about your background as it relates to this space?  How did you get to this point?

VoIP, video and VoIP SDKs have been my bread and butter since 1999. For many years I worked for Radvision, a NASDAQ company that provided video solutions and VoIP SDKs. We were the #1 VoIP SDK provider and our products still power a large chunk of the VoIP products out there. My last position there was VP Products for the Technology business unit that developed those SDKs.

It was during that time that I started following WebRTC. Sometime after Radvision was acquired by Avaya, I left and started writing about WebRTC on my blog, TheNewDialTone, provided consulting services to companies mainly around VoIP and WebRTC and later down the road founded SwitchRTC due to a need I saw in the market.

I also co-started WebRTCStandards with the WebRTC Standards co-editor Dan Burnett and WebRTCIndex with Tsahi Levent-Levi from

Q. Since SwitchRTC may be new to some of my readers, can you say a bit about it?

SwitchRTC is a solution for real-time, low-delay distribution of video to a large audience that developers and service providers can embed and integrate into their application or service.

SwitchRTC serves both video CDN/broadcasting (WebRTC CDN) as well as large scale multiparty video for enterprise and consumer services.

SwitchRTC was designed as a Cloud Native solution in a decomposed architecture allowing for microservices to be dynamically launched as the load increases. These microservices may run in different physical locations.

Q. So why SwitchRTC?  What convinced you that the world needed your product?  What need was not being met?

WebRTC takes care of the client side of the communication, but the server side was left for the industry to provide. An ecosystem of solutions was created over the years including CPaaS that offer APIs in the cloud and various open source solutions.

There are several gaps we saw in the market:

One neck to grab and full control

The need for a solution with a commercial license and dedicated support that vendors and service providers can install in their private or public cloud. Many use cases can’t live with a solution hosted by others (CPaaS) and not in their control.

A commercial license with dedicated support is required because at the end of the day, companies are building their service based on this product and they need the confidence that the vendor has the expertise in the field and will support them in their journey.

A solution that scales

The need for a scalable solution that will enable delivery of video, in real-time, to a large audience. Things get tough as you scale and that is the problem we wanted to solve.

Flexible yet easy to use APIs

Having such a system with easy to use yet flexible APIs. Sounds simple but it isn’t, it is a profession and requires a lot of experience in developing SDKs. Highly flexible APIs typically come in contrast to simplicity. You need to build the APIs in such a way that those who want the basic stuff can get going very quickly with minimal work while those that really need to implement complex media scenarios can still do that.

We have been in this field for many years. The idea is not to follow the footsteps of some of the solutions that give you an SFU for free or for a very low cost but then you end up doing a project for a high sum with that vendor. The goal was to build a product that developers can easily adopt and quickly release their product to market with.

Q. Could you elaborate a bit more on the points you mentioned?  How are you able to scale without adding too much API complexity?

SwitchRTC was designed with scale and efficiency in mind. This means that we wanted a system that would be Cloud Native and allow for dynamic scaling and load distribution across multiple servers in different physical locations.

The architecture of SwitchRTC follows the Cloud Native methodology of microservices where each function is self-contained and can run in a different physical location. For example, SwitchRTC features a 1-to-n relationship between the signaling server and the media servers allowing for increased scalability. Media servers may be geographically distributed with a secure connection to the signaling server. This allows for load distribution as well as enhanced user experience since clients can be served by the closest server or the server whose connection has the shortest delay.

This architecture allows for distribution of sessions between media servers and even to split a single session among several media servers. It is also possible to decide which stream is sent to which user. These capabilities were planned in our architecture in order to allow for scalability and flexibility.

That’s an example of the API flexibility I mentioned before, you need to enable developers to implement their wildest dreams (and product management requirements)

Another important factor related to scale is the handling of Peer Connections. We decided to open a single Peer Connection with each client connected to the SwitchRTC SFU media server. There are other solutions that open a Peer Connection per stream. This means that if you have 20 users in a session, the SFU will need to open with each client 19 Peer Connection for receiving media streams + another Peer Connection for that client to send media to the media server. Each Peer Connection requires ICE processing (and several sockets to be opened for that) and security key exchange.

In the case of a 3 or 4 way call with just a handful of such sessions, opening a separate Peer Connection per stream is not a big deal. When you want to reach scale, this is a critical issue. The OPEX of the service would become dramatically higher as many more servers will be required to handle the same load that a well architected SFU could do with fewer resources. This is an example of how a flaw in architecture becomes a business issue.

The reality is that many companies are not aware of this design consideration and don’t have a way to really test for scale in the evaluation process. When they do get to scale it might be too late.

Q. You mentioned video broadcasting and using WebRTC to build a CDN.  Can you say more about that?

Applications such as webinars, education or large company meetings require asymmetric architectures where a handful of users broadcast video to a large audience. Many of these applications require real-time delivery of the video and sometimes even allow for some interaction with the audience during the session, for example, allowing a user to present his work or a question he has.

Such use cases require the SFU to limit the audience to receive-only mode but allow the host to upgrade specific users to presenter mode and later downgrade them back to viewer mode.

Low delay broadcasting of real-time content is a challenge. Traditional Flash based technologies such as RTMP that are currently used for such services are becoming obsolete. There is an increasing need for enabling these scenarios in the browser using WebRTC.

SwitchRTC is a natural fit for these type of scenarios. These large scale sessions require more than one server to support them due to networking, server CPU and memory limitations. Additionally, since an audience might be geographically distributed, best practice would be to serve the audience from a nearby server (lowest delay) rather than from a single data center location.

Q. Clearly your product uses WebRTC.  Is there any advice you would give to others who might contemplate a service based on WebRTC?

I would put it this way. Using anything other than WebRTC would be a mistake.

Additionally, some have taken the challenge and built a proprietary implementation of WebRTC. They claim their implementation is better.

Reality is, you have a group of talented engineers at Google who built the best media engine out there. Trying to build a different implementation of the same thing is wrong because:

  • Chances are slim you will get a better result
  • You’re investing resources in something that gives you no value, only a drawback of your system
  • You’ll need to continuously change the implementation as the standard evolves and Google changes their WebRTC implementation
  • You’ll have interop and compatibility issues

Q. You recently announced the SwitchRTC Technology Circle partner program.  Tell me about it.

There are companies that can’t allocate their internal resources for the application development or integration tasks; they simply prefer to outsource this work.

This is where the SwitchRTC Technology Circle partner program comes in. The idea was to save them the time of searching for custom development companies that would be able to do this work by having a set of companies that already have experience with SwitchRTC and are certified for using our APIs.

Q. So what’s next?  Anything you’re excited about or think needs addressing?

We continue to advance SwitchRTC in areas of scale and new features that are required by the market segments we are serving.

Thank you very much!  I look forward to talking with you again in the future.
Dr. Daniel Burnett has a history of almost 2 decades of experience with Web and Internet standards dealing with communications, having co-authored VoiceXML, MRCPv2, WebRTC, and many other standards. In creating AllThingsRTC, Dan aims to provide the innovators in the real-time communications space a forum for explaining the topics that really matter.