If you choose a softswitch which doesn’t have built-in WebRTC support, you can easily add it using a WebRTC-SIP gateway module:
On the client side you can use any RFC 7118 compilant WebRTC client:
* Sampling rate
* Encoder average bitrate (kbps)
* Use DTX
* Use inband FEC
* Minimum expected packed loss (%)
* Encoder complexity
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?
There is currently a SIP Call implementation in https://github.com/vialer/vialer-js/blob/develop/src/js/bg/m...
The first approach to use the Call abstraction is in https://github.com/vialer/vialer-js/blob/develop/src/js/bg/m...
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...) 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 :-)
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://mediasoup.org (for node)
OT: is there a way to do markdown in HN comments?
I've been doing a comparison of these some time ago and here's what I remembered:
There are 3 ways of doing webrtc:
- Mesh -> everybody sends and receives to every other participant. -> Needs almost no infrastructure, but obviously doesn't scale well.
- SFU -> acts as a relay, so people only need to have 1 upload, but still download everybody -> Needs some infrastructure, scales better than mesh but still limited by amount of downloads per participant
- MCU -> makes compositions in the cloud so people only have 1 upload and 1 download -> Very expensive in terms of infrastructure, infrastructure is hard to scale, but least amount of traffic and processing by participants.
These seem to be the most well-known solutions:
- Kurento -> was very complete, but is more or less dead since Twilio bough the team (they had some recent activity, but are really lagging behind now).
- Janus -> a set of building blocks to build which can be used to build an SFU or MCU.
- mediasoup -> sfu with node bindings. Was very new when I did my comparison, no idea how mature it is now.
- Jitsi -> Very nice SFU, bought by Atlassian, but they still put a lot of work in the open-source version (contrary to what Twilio did with Kurento). Highly recommend if you want to deploy your own SFU.
- Intel WebRTC -> both sfu and mcu, but documentation is limited and it specifically targets intel platforms (originally based on 'licode' which is yet another alternative)
Next to that you'll also need turn and stun servers if you want to deal with any business networks (coturn seems to be the go-to if you need a turn server).
Despite the 'open' in the name, opentok is a closed platform from the leading webrtc provider (tokbox). They provide the server infrastructure (usually SFU and Turn servers).
Some alternatives are twilio video, vidyo, temasys.
We eventually went for a CPAAS (tokbox), happy with them so far. We also use Janus for some customer-specific integrations.
Note that the summary is very, very limited. You may also care for a lot of other stuff, such as: Sip integrations, Broadcasting to HLS or RTSP, Recording/Archiving, Security practices, GDPR Compliance, Licenses, Browsers support, SLA's, ...
It's pretty alpha at the moment but I'd be interested in working with others to further it more if there's any interest.
The Twilio folks certainly have built a bunch of additional stuff that's not part of core Kurento, for the Twilio Video product, though.
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.