Nir, thanks

I see things slightly differently. Many go for WebRTC because they have to (browser). Others because it makes sense (it is cheaper in the long run).

It is very new, but very real and very here. If Israel’s largest HMO can use it successfully for a year now after ditching a proprietary video chat service, then most can do the same. Only question is what is the right approach in each case.

For the past 12 years I’ve been building VoIP projects and the past 3 years were filled with WebRTC related work as well. Most people can’t really distinguish between classic WebRTC (JSON RPC Signalling + WebRTC Media) to ‘good old’ SIP Over WebSocket (SIP Signalling + WebRTC Media) to something totally proprietary. This confusion tends to put many of the customers into a situation where they are stuck, after developing an app and then changing developers.

Another issue is that WebRTC is in a constant state of flux, staying on top of the recent developments and updates is a full time job. APIs are being obsoleted almost on a monthly basis, making the race for updates and upgrades an endless effort. We recently invested over a month of work updating our code to the latest version of WebRTC, only to realize that so many APIs were removed, we had to “recreate” them from scratch.

In other words – the tech is very new, in my personal view, still much a buzzword for techs to raise funds and look cool. The first step is to truly know and understand that your solution requires WebRTC and what parts of it – and only then move forward with an implementation.