
Show HN: Vialer-js – Open-source WebRTC communication platform - jvanveen
https://github.com/vialer/vialer-js
======
fenesiistvan
I am a VoIP developer and my recommendation for WebRTC is to just use any
legacy Softswitch or IP-PBX. These are more matured software, with tons of
features and all of them has support (also) for WebRTC. Most of them has much
better performance than Node.js implementations (you can handle more
simultaneous clients). Both open-source and commercial software is available
with good support:

-Asterisk: [https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+S...](https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+Support)

-FreeSwitch: [https://freeswitch.org/confluence/display/FREESWITCH/WebRTC](https://freeswitch.org/confluence/display/FREESWITCH/WebRTC)

-Mizutech: [https://www.mizu-voip.com/Software/VoIPServer.aspx](https://www.mizu-voip.com/Software/VoIPServer.aspx)

If you choose a softswitch which doesn’t have built-in WebRTC support, you can
easily add it using a WebRTC-SIP gateway module:

-Doubango: [https://github.com/DoubangoTelecom/webrtc2sip](https://github.com/DoubangoTelecom/webrtc2sip)

-MRTC: [https://www.mizu-voip.com/Software/WebRTCtoSIP.aspx](https://www.mizu-voip.com/Software/WebRTCtoSIP.aspx)

-Janus: [https://janus.conf.meetecho.com/](https://janus.conf.meetecho.com/)

On the client side you can use any RFC 7118 compilant WebRTC client:

-SIPML5: [https://www.doubango.org/sipml5/](https://www.doubango.org/sipml5/)

-WebPhone: [https://www.mizu-voip.com/Software/WebPhone.aspx](https://www.mizu-voip.com/Software/WebPhone.aspx)

-SIP.js: [https://sipjs.com/](https://sipjs.com/)

~~~
pbowyer
Do you have a recommendation for a VoIP softphone with good Opus support?
(Windows) Jitsi is the best I've found to date, as it lets me adjust:

    
    
        * Sampling rate
        * Encoder average bitrate (kbps)
        * Use DTX
        * Use inband FEC
        * Minimum expected packed loss (%)
        * Encoder complexity
    

but I'm keen to try others.

~~~
degenerate
It's sad how little traction Opus has in the VoIP community. I thought for
sure it would have been fully implemented in many PBX systems by now.

------
jvanveen
Author here: The first priority of the project is to offer a solid generic
audio-only calling experience to our users. This includes all functionality
that people would expect from a softphone. At the same time, we want to build
something that is generic and useful to any SIP-over-wss provider in the short
term. The build mechanism and module-system should accomodate this. It is
still under construction ([https://github.com/vialer/vialer-
js/tree/feature/restructure...](https://github.com/vialer/vialer-
js/tree/feature/restructure-module-loading)), but most of the hardcoded
dependencies are already dealt with.

Besides the current SIP Call implementation, we are preparing the codebase for
additional signalling implementations as well. The centralized SIP Call
implementation is great to use with all the functionalities a PBX offers
(queues, on-hold, transfers, being available to any device), but browser-to-
browser p2p also has its strong points. Privacy-aware chat, video and file
transfer seem easier to implement and maintain with nothing more than
JavaScript and another browser as a backend. The signalling part will be a bit
of a design challenge. Ideally, this would be p2p and encrypted too, so people
don't need to rely on one server/provider to find their contacts and setup
connections with.

~~~
diggan
> The core of the software is designed around the notion of a generic 'Call'
> abstraction, that allows it to be flexible about using different technology
> stacks

This quote is from the website linked from the GitHub repository. I skimmed
the code to try to find the abstractions to switch out the technology stack,
but could not find anything. Could you provide some pointers?

~~~
jvanveen
I need to change that description, because it is too premature at the moment.
The main Calls handling code is in [https://github.com/vialer/vialer-
js/blob/develop/src/js/bg/m...](https://github.com/vialer/vialer-
js/blob/develop/src/js/bg/modules/calls/index.js) and still relies on SIP. It
is a small step to add the required abstractions for alternative signalling
mechanisms though, because most of the SIP-related logic is centralized
already.

There is currently a SIP Call implementation in
[https://github.com/vialer/vialer-
js/blob/develop/src/js/bg/m...](https://github.com/vialer/vialer-
js/blob/develop/src/js/bg/modules/calls/call/sip.js)

The first approach to use the Call abstraction is in
[https://github.com/vialer/vialer-
js/blob/develop/src/js/bg/m...](https://github.com/vialer/vialer-
js/blob/develop/src/js/bg/modules/calls/call/connectab.js)

It is a proprietary API-based click-to-dial calling method(which still need to
be moved to its own repo) that doesn't use SIP or WebRTC, but uses the same
call flow nevertheless.

At the moment, most of the focus is on stabilizing the SIP-based softphone.
We're about to complete a first working opensource build without proprietary
modules this week.

The Calls-related code will be dealt with when there is an alternative
signalling mechanism available. It would be interesting to investigate
existing networking solutions like Matrix, but also to experiment a bit with
p2p overlay networks ourselves. I did some prior R&D on the subject
([https://wearespindle.com/articles/end-to-end-encryption-
betw...](https://wearespindle.com/articles/end-to-end-encryption-between-node-
js-and-webcrypto/)) to tackle issues like ECDH encryption with WebCrypto, but
there are still a lot of uncertainties and unhandled topics that need to be
addressed. Work in progress :-)

~~~
jvanveen
Some more background info about the project:
[https://wearespindle.com/articles/building-a-softphone-a-
jou...](https://wearespindle.com/articles/building-a-softphone-a-journey-from-
poc-mvp-to-mlp/)

------
sam_goody
There are a few open source RTC platforms.

On first blush, Vialer seems to be softphone centric - audio only, mostly peer
to peer, softphone features. These others target one to many video streaming.

Is that right?

\- [https://www.kurento.org](https://www.kurento.org)

\- [https://mediasoup.org](https://mediasoup.org) (for node)

\- [https://janus.conf.meetecho.com](https://janus.conf.meetecho.com)

\-
[https://github.com/opentok/OpenTokRTC-V2](https://github.com/opentok/OpenTokRTC-V2)

OT: is there a way to do markdown in HN comments?

~~~
ianhawes
Kurento was killed off after the Twilio acquisition.

~~~
kwindla
You may know more than I do, here, but AFAICT, Kurento is still around and
seems to be maintained: [https://github.com/Kurento/kurento-media-
server](https://github.com/Kurento/kurento-media-server)

The Twilio folks certainly have built a bunch of additional stuff that's not
part of core Kurento, for the Twilio Video product, though.

~~~
j1elo
I can confirm that Kurento is still around and maintained. Soon to release
version 6.8

------
kodablah
Does signalling phone home? Would be neat to do serverless signalling. It
might be doable by putting the offer in the URL (and letting people text it to
each other) or maybe packing the offer in a QR code or maybe using a DHT
inside of JS. I have been toying w/ the IPFS JS impl, and have successfully
connected to the DHT and done lookups over web sockets, but I would assume
that the webrtc transport would allow you to participate in the DHT.

~~~
dbrgn
While I'm not aware of any serverless signalling solution that includes
support for stuff like Trickle ICE, at least there are trustless E2E-encrypted
solutions like [https://saltyrtc.org/](https://saltyrtc.org/) (Disclaimer: I'm
involved, but it's an open source project.)

------
benoits
If any senior VoIP/SIP/WebRTC dev is interested, my telemedicine startup just
won the tender for building the WebRTC platform used by all hospitals in the
Paris region. Includes some cool medical devices data streaming too. We're
desperately understaffed so we're offering very competitive compensation, PM
me. Stack is React+Node.js+Kurento but could change based on your input.

------
Fifer82
Does anyone have time to ELI5 WebRTC?

~~~
j1elo
WebRTC is just a consensus between multiple parties about how to coordinate
and send pure data, or just audio and video, from one peer to another.

Then that phrase would extend into multiple layers of complexity. This could
be the first one:

\- The "coordination" part is done with SDP, a type of plain-text messages
that are used by both parties to reach an agreement about what video/audio
codecs they are capable of understanding, and other similar details.

\- The "send audio and video" part is done by using ICE to find suitable ports
by punching holes in router NATs, which is a common problem we have in current
networks. Once ports have been agreed upon, then the audio/video is sent using
good old (encrypted) RTP protocol.

Anyone could implement this consensus in their applications, and so be able to
send audio/video to other apps that implement the same details, but the most
relevant implementations of this standard are those integrated into web
browsers, because then they expose all this functionality to their JavaScript
engines, thus allowing to control all this from a web page.

------
pierut
hey why does the web need a real-time clock

