Nir, thanks for sharing.

You might want to add your upcoming service to https://webrtcindex.com

I think you’re missing the point. There is a fundamental flaw in how most people look at WebRTC. Let’s start with a very basic premise – WebRTC is NOT a signalling technology, it is a media processing and direct media transmission technology. As such, you can use whatever signalling you want. As long as the SDP gets to your endpoint correctly, it will be processed.

Now, this created an amazing opportunity to the various vendors around the world. Each one created their own version of “WebRTC Signalling”, and they are not compatible with each-other (in 99% of cases). Even the various Cloud Providers aren’t compatible with one another – your want compatibility, make it yourself.

Now, the various JS libraries that utilize SIP Over WebSocket for WebRTC are AWESOME! Why is that? simple, they enable the bridging between the legacy and the new at a fair ease. For example, at Cloudonix we provide a set of wrappers that enable companies to integrate with our WebRTC (SIP over WebSocket) endpoints at ease. They are based on SIPml5, which we found to be both complete, easy to use and most importantly – was flexible enough to enable us to do what we needed. We had some “philosophical” issues with JsSIP and SIP.js, but again, that’s something totally different.

In addition, sorry to say, very much like Asterisk 10 years ago, WebRTC had become the “magical” solution to various communication problems – when it’s absolutely an incomplete solution.

I think the cost of Twilio and the various other providers is so expensive, it doesn’t make any sense. They mainly take advantage of the fact that building and maintaining a global WebRTC signalling and media processing infrastructure is complex and requires attention. We will be launching our WebRTC endpoint processing offering in a few days, so you can visit https://cloudonix.io to learn more about it – but I totally understand your confusion.

If you would ask me what would be my preference to building something like this, this would be my answer:

1. Kamailio or OpenSIPS for your WebSocket processing and Signalling
2. RTPengine for NAT Media Relaying
3. CoTurn for STUN and TURN processing
4. SIPml5 as the JS library
5. Asterisk for media application development (or freeswitch, depending on your preference)

The various “WebRTC native” servers, such as Kurento and EasyRTC provide a “signalling” layer, however, if you need to bridge back to the native PSTN world, you will need additional tools like Janus, which will add another layer of complexity.

Silvia,

Thanks – some people do want such a thing, but in many cases, they end up unhappy as they have some specific requirements/needs that aren’t met. There’s a lot of variety out there in what people want and mean when they say something like “WebRTC JS library”.

There’s two solutions: get a company like WebRTC Ventures ti develop and maintain that component for you – or use something like our Coviu API to embed video rooms into your app.

Coviu is an embedding based solution but unlike YouTube, all the hard server work associated with WebRTC is done for you. Yes, we’re a telehealth company, but our video interface can be used without medical tools, custom branded and embedded in other apps through an API.

Ochui – thanks for sharing.

I think this is where a lot of the confusion lies – Kurento is a media server framework. It does has some rudimentary signaling of its own, but I wouldn’t pick it for signaling.

What you need in your feature set greatly affect what frameworks and projects you should use.

If you’re using SIP infrastructure, then sure (and I know you guys do at Audiocodes).

If you’re looking to make this a starting point for tackling the problem of what technology stack you need, then you’re doing it wrong.

Me? That I can’t help with a lot more information and context…