Open source telecom software project survey results 2019

Open Source Telecom
Software Project Survey
RESULTS
The purpose of this survey is to gather across the industry people's experiences and opinions on using
Open Source Telecom Software Projects (OSPs), and share an anonymized aggregate view of the
different projects with those that compete the survey.
Weblog that intro’ed the survey: http://alanquayle.com/2019/05/open-source-telecom-software-project-
survey/
I'm often asked to comment on the different projects, this is an attempt to provide something more
authoritative than my opinions based on who I last talked to 
© Alan Quayle, 2019

Survey Responses
Collected over period 21 May 2019 to 21 June 2019
Google Slides Responses 19
Google Sheet Responses 12
Google Survey Responses 64
Total Good Responses 95
Numbers are OK for indicative analysis, but need to be closer to 200 for fair representation across the
tens of thousands of people working on open source telecom software.

General Questions 1) Which OSPs do you use? (either in your current platform,
or clients’ platforms) OR Which OSPs do you have experience with? (for example
used in projects over the past 2 years)
Which OSPs do you use? Responses %
Asterisk 71 75%
FreeSWITCH 39 41%
Kamailio 41 43%
OpenSIPS 51 54%
Restcomm/Mobicents 3 3%
The only TAS we did not receive feedback from was SIPfoundry/sipxcom. I only recently made
contacts there, likely my lack of credibility in that community meant it did not receive much attention.
I spend most of my professional life being ignored ;)

General Questions 1) Which OSPs do you use? (either in your current platform,
or clients’ platforms) OR Which OSPs do you have experience with? (for example
used in projects over the past 2 years)
Management Interfaces / Solution Wraps /
Monitoring & Capture
Responses %
Elastix (for Asterisk) 1 1%
FreePBX (for Asterisk) 21 22%
FusionPBX (for FreeSwitch) 10 11%
Kazoo 2 2%
RTPProxy 18 19%
SIP3 0 0%
Sipcapture - Homer 31 33%
Sippy Softswitch 2 2%
VICIdial (for Asterisk) 7 7%
Wazo (for Asterisk) 15 16%
YETISwitch 0 0%
sipsak, sipp 1 1%
Note: sipsak is a CLI for testing using SIPp (Open Source test tool / traffic generator)
Nice to see RTPProxy being
used, it comes up in discussions
much more frequently.
Also nice to see more niche
projects like VICIdial being
used. This partially explains the
diversity of application areas we
see across the projects.
Even though Wazo is relatively
new (it is a fork from XiVo),
adoption is strong. It takes time
for projects to be adopted in
open source, stability and
reliability are critical.

General Questions 1) Which OSPs do you use? (either in your current platform, or clients’ platforms) OR
Which OSPs do you have experience with? (for example used in projects over the past 2 years)
WebRTC Projects Responses %
EasyRTC 2 2%
Janus 25 26%
Kurento 1 1%
Jitsi 31 33%
Mediasoup 2 2%
Medooze 0 0%
OpenVidu 0 0%
JSSip 7 7% both SIP and WebRTC client library
Additional ones generated but not considered
opentok 2 2% Not an open source project
Other
Matrix 22 23% I include as federation and its RTC capabilities can not be ignored
SylkServe 2 2% I wasn't aware of this project, it's definitely relevant.
Node-RED 1 1%
flow-based development tool for visual programming - included as
it raises some interesting issues on service development

Asterisk Project Survey
RESULTS

5 What is the main application(s) / market need(s)? (PBX, Conferencing, Contact
Center, Mobile App Comms, CPaaS, UCaaS, CCaaS, PBX, video CC, what is the
scale of the implementation (100, 1000, 10k, 100k, 1M+))
Application (66 responses) Responses %
PBX 50 76%
Conferencing 28 42%
Contact Center 37 56%
Mobile App Comms 6 9%
CPaaS 4 6%
UCaaS 7 11%
CCaaS 0 0%
Video CC 0 0%
Media App Server 6 9%
Scale (66 responses) Responses %
100 22 33%
1000 12 18%
10k 25 38%
100k 11 17%
1M+ 3 5%
The popular view is Asterisk is used for PBX implementations at enterprise scale. In talking with
Asterisk implementors I knew the application areas and scale were broader. This provides some
quantification on the breadth of Asterisk applications, we’ll compare projects at the end of this deck.
A follow-up question should focus on “How do you scale it?”

6 What to you consider the strengths and weaknesses of the OSP?
Strengths
41
responses %
Features 8 20%
Reliability 15 37%
Openness 3 7%
Flexibility 14 34%
Community 17 41%
Maturity 10 24%
Easy to set-up / configure 9 22%
Small footprint 8 20%
Well documented 3 7%
Weaknesses 33 results %
Uncertainty over new
ownership 5 15%
IPPBX centric 8 24%
Cloud support 7 21%
Multi-tenancy 6 18%
Scalability 9 27%
Performance 4 12%
Direction from Community 4 12%
Community, Reliability and Flexibility are top features. A correlation on the weaknesses is those
highlighting scalability, IPPBX-centric, cloud support, were NOT providing feedback on the solution
wraps / management interfaces.

7 How do you view the future of the OSP? (e.g. will remain dominant platform in
CPaaS, or will face increased competition from projects X in UCaaS, or
uncertainties around business model mean we are examining other OSPs but
have no plans to change).
Future (33 responses) Responses %
Will remain dominant IPPBX / remains
dominant project 19 58%
Depends on Sangoma 8 24%
Unknown / not sure 6 18%
Astricon (Oct 29-30) is going to be interesting, see you there!

8 What client protocol/interface/platform do you use to connect OSP, e.g. SIP.js,
JsSIP, sipML5, other SIP SDK, other in browser signaling (like raw JSON over
WebSockets) + WebRTC?
Client (47 responses) Responses %
SIP.js 19 40%
JsSIP 5 11%
SipML5 4 9%
Other SIP SDK 25 53%
In browser signaling 14 30%
WebRTC 20 43%
SIP phones / hard phones 22 47%
PJSIP 3 6%
We need to investigate what is used in “Other SIP SDK” in the next survey.

9 How active and vibrant is developer community (Quiet - some contributions
mainly from the core team – active from a limited number of companies - Lively
(>10 companies contributions))? (66 Responses)
At the end of
this report we’ll
do some
comparisons
between the
OSPs on the
community
questions.

10 Does the developer community make itself accessible for
participation (closed – OK – Open (with lots of fast help
(hours) and dev events))? (66 Responses)

11 How easy is it to engage with the community on features/issues that are
important to you? (difficult (no/slow response) – OK (responses can take days) –
good (rapid response, within hours, day max)) (58 Responses)

12 If you develop and enhance the platform yourself, how open do you find the
community to your submissions and pull requests? (closed – OK – welcoming) (49
Responses)

13 Do you find it easy to hire knowledgeable consultants, or otherwise access
operational support for the platform from outside your immediate organization
(easy – OK - hard) (59 Responses)
We’ll add geographic
focus on the next
revision of the survey as
I think the spread in
knowledgeable
consultants is in part
linked to this.
From my experience its
expertise in multiple
projects, e.g. Kamailio,
OpenSIPS, Asterisk,
FreeSWITCH and
others…

14 Have you developed your own low level features without
giving them back to the community, and if so, why? (38
responses)
Responses %
Yes 16 42%
No 22 58%
Comments
multi-tenant solution 3
tried and failed to contribute 3
3rd party proprietary app
development 5
planning to contribute 8

15 How do you architect your deployments (choices not exclusive and multi-
dimensional)
Responses %
Container Images 14 22%
Container Orchestration 9 14%
VM Images 48 75%
Bare Metal 41 64%
16 Do you use a configuration management/scripting
system like Chef, Puppet, Ansible, SaltStack, Terraform
or CloudFormation etc.
Responses %
none 4 8%
own / in-house 8 15%
SaltStack 2 4%
Ansible 29 56%
Pupper 9 17%
Bare Metal,
Ansible and
Self Hosted
(see next slide)
- This is not a
party for AWS
and Google 

17 Do you host on: own infrastructure, cloud provider, or both
Responses %
Own 28 55%
Cloud 11 22%
Hybrid 12 24%
18 How do you support redundancy? - no standardized approach, I've grouped
some responses, but almost every answer was difference in some way
Virtual Router Redundancy Protocol
OS Clustering
Local hardware redundancy
Multi-site + load balancing
Failover
Kamilio
Wazo
OpenSIPS proxy
SIP proxy
Multiple VMs
Heartbeat
Failover
Don't bother
Home designed cluster
In-house design, proprietary
We need to follow
up on the
redundancy
approaches. Is
there an opportunity
to better share
experiences /
architectures?

FreeSWITCH Project
Survey RESULTS

PBX 19 53%
Conferencing 15 42%
CPaaS 6 17%
UCaaS 4 11%
SBC 1 3%
Class 5 termination 1 3%
Class 4 telco interconnect 1 3%
100 9 14%
1000 10 15%
10k 10 15%
100k 5 8%
1M+ 3 5%
We’ll compare the projects at the end of the presentation. Quite similar to Asterisk, even though the 2
projects are not as similar as Kamailio and OpenSIPS. The scale responses did surprise me a little,
but this is linked to the importance of solution wraps to deliver the scale. Thought OpenSIPS has it
built-in.

Strengths (30 Responses) Responses %
Security 1 3%
Robustness / Stability of the
protocol implementations (SIP,
ICE) 10 33%
Flexibility of both configuration
and code 9 30%
Complete / Full featured 11 37%
Fast / Performant 3 10%
Modular 8 27%
Open 7 23%
Easy to interface with in-house
development 2 7%
Weaknesses (21 Responses) Responses %
WebRTC video implementation
is too heavy (even without
transcoding) 4 13%
Documentation 4 13%
Difficult to contribute back 7 23%
Slow release cycle 8 27%
Dev outputs seem to be slowing 5 17%
Installation 6 20%
Strong project with great feedback on completeness, robustness, and flexibility (code and
configuration). There is a concern, like Telestax / Restcomm on where is the business focus will go as
it is just one team. Open Source communities need clarity and stability.

Will dominate Open Source PBX 4 31%
Remain the same 4 31%
Not sure 5 38%
Both Asterisk and FreeSWITCH have uncertainties around their futures. Neither will be resolved in the
near term, execution over the next 18 months to 2 years will likely affect perception of these projects
going forward. We’re in a highly dynamic time in open source telecoms software.

SIP.js 9 33%
JsSIP 5 19%
SipML5 4 15%
WebRTC 12 44%
Custom / in-house 9 33%

At the end of
this report we’ll
do some
comparisons
between the
OSPs on the
community
questions.

10 Does the developer community make itself accessible for participation (closed
– OK – Open (with lots of fast help (hours) and dev events))? (28 Responses)

Responses)

responses)
Have you developed your own low level features without giving them back to the community, and if so, why? (15
responses)
Responses %
Yes 9 60%
No 6 40%
Comments
I've developed functions that are too specific to our environment to be of any interest to the project, and others that I've not sent
back because I had the feeling they would be ignored (if ever acknowledged) given the issues and PRs I had submitted in the
past.
Some features were rejected, others seemed not to be reviewed.

dimensional) (28 Responses)
16 Do you use a configuration management/scripting system like Chef, Puppet,
Ansible, SaltStack, Terraform or CloudFormation etc. (28 Responses)
Responses %
VM Images 20 31%
Bare Metal 14 22%
Responses %
SaltStack 2 7%
Ansible 19 68%
Pupper 5 18%
SaltStack 3 11%
Github 1 4%
AWS 2 7%

17 Do you host on: own infrastructure, cloud provider, or both (28 Responses)
some responses, but almost every answer was difference in some way
Responses %
Own 12 43%
Cloud 8 29%
Hybrid 8 29%
Failover
Don't bother
Home designed cluster
Call servers are managed by an orchestration platform to distribute offered load
Mutliple providers for SIP, ,
AWS + HAProxy for WebSockets
Multiple TURN servers for WebRTC
Pacemaker, Corosync
Redundant across 3 availability zones and two regions
Mostly multi-master on many layers, trying to follow eventual consistency on© Alan Quayle, 2019
We need to follow up
on the redundancy
approaches. Is there
an opportunity to better
share experiences /
architectures?

Kamailio Project Survey
RESULTS

PBX 17 43%
Conferencing 8 20%
CPaaS 13 33%
UCaaS 12 30%
SBC 2 5%
Class 5 termination 3 8%
Class 4 telco interconnect 3 8%
CCaaS 3 8%
Call routing / SIP routing 9 23%
Header manipulation 2 5%
Video CC 1 3%
100 0 0%
1000 13 34%
10k 14 37%
100k 10 26%
1M+ 15 39%
Broad base of projects with a slight bias to large scale deployments, which jives with my discussions
on implementations where Kamailio is used as the front-end with multiple Asterisk or FreeSWITCH
applications servers on the backend.

Performance 12 35%
Community 11 32%
Modularity 2 6%
Available Modules 3 9%
Flexible / Extensible / Open 12 35%
Secure 2 6%
Lightweight 3 9%
Stability 11 32%
Scalability 6 18%
Documentation is tough for
newcomers 4 67%
Can be tough to configure 3 50%
Strengths in Performance,
Community, Flexibility,
and Stability.
Weaknesses are well
known, “You’ve got to
know what you’re doing.”

Will remain dominant Open Source
Telecom Platform 15 100%
I think this is in part a reaction to the uncertainty hanging around Asterisk and FreeSWITCH. Kamailio
and OpenSIPS appear to have a more stable future.

Client (26 responses)
Response
s %
SIP.js 11 42%
JsSIP 4 15%
SipML5 0 0%
WebRTC 9 35%

At the end of
this report we’ll
do some
comparisons
between the
OSPs on the
community
questions.

Responses)
The love is
strong for
Kamailio 

We’ll add
geographic
focus on the
next revision of
the survey as I
think the
spread in
knowledgeable
consultants is
in part linked to
this.

giving them back to the community, and if so, why? (only 2
responses - not enough data)

16 Do you use a configuration management/scripting
system like Chef, Puppet, Ansible, SaltStack, Terraform or
CloudFormation etc. (26 Responses)
Responses %
VM Images 24 77%
Bare Metal 19 61%
Responses %
Ansible 19 73%
Pupper 7 27%
Terraform 3 12%
Packer 1 4%
Bare Metal,
Ansible and
Self Hosted
(see next slide)
- This is not a
party for AWS
and Google 

some responses, but almost every answer was difference in some way (23
Responses)
Responses %
Own 14 61%
Cloud 5 22%
Hybrid 6 26%
Redundancy (23 responses) - no standardized approach, I've grouped some responses, but almost every
answer was difference, except 'don't bother'
HA pairs, clusters, and global redundancy
Don't bother
Redis state replication
SIP proxies
AWS + HAProxy for WebSockets
Different az and region setup within AWS, managed database with inbuilt redundancy
Pacemaker, Corosync
Redundant across 3 availability zones and two regions
Mostly multi-master on many layers, trying to follow eventual consistency on data storage layer

OpenSIPS Project Survey
RESULTS

PBX 12 27%
Conferencing 4 9%
CPaaS 15 33%
UCaaS 14 31%
SBC 5 11%
ITSP 3 7%
CCaaS 4 9%
SIP Proxy / Router 12 27%
Video CC 5 11%
100 5 12%
1000 8 19%
10k 14 33%
100k 22 51%
1M+ 7 16%
Broad based of applications, and scale. With
a peak at 100k. Its considered
interchangeable with Kamailio, and designed
to be so. This dual sourcing of open source
projects gives implementors more
confidence.

Flexibility / Versatility (a
programmable SIP Server with
150 modules) 10 26%
Capacity (thousands of CPS,
millions of CC) 11 28%
Scalability 7 18%
Easy to use and setup 3 8%
Stability 9 23%
Community 7 18%
Performance 10 26%
Supportive Dev team 12 31%
Easy to customize 8 21%
Low resource requirments 6 15%
Complexity and learning curve 7 25%
Difficult to configure and debug 5 18%
Limited features 2 7%
Inability to handle media 4 14%
Lack of B2B function 3 11%
Documentation 8 29%
Small (but growing) user base 8 29%
Development team was called out for its
support. It’s a rapidly developing project
catching up to the more mature Kamailio
project. With lots of developer love.

Remain dominant competition to
Kamailio 8 47%
Will become the dominant VoIP
infrastructure project 9 53%
A comment made on OpenSIPS future that I think sets out the space both OpenSIPS and Kamailio
are addressing is: “OpenSIPS is an ideal tool for VoIP infrastructure / backbones. UCaaS will
cannibalize the market for the "last-leg to user" solutions, but when comes to infrastructure (SBCs,
VPBX, Trunking, Carriers), the market will be unchanged.”

SIP.js 12 43%
JsSIP 6 21%
SipML5 2 7%
WebRTC 11 39%
SIP SIMPLE client SDK 2 7%

At the end of
this report we’ll
do some
comparisons
between the
OSPs on the
community
questions.

The love is
strong for
OpenSIPS 

Responses)

We’ll add
geographic
focus on the
next revision of
the survey as I
think the
spread in
knowledgeable
consultants is
in part linked to
this. Plus
identify what
package of
skills people
are looking for.

Responses)
All 10 responses stated no. Several comments stated, almost everything goes back up, newer
developments need to show stability and continued used, then they are committed back.
Responses
Yes 0
No 10

Responses %
VM Images 26 87%
Bare Metal 19 63%
configuration management/scripting (25
responses) Responses %
own / in-house 0 0%
SaltStack 0 0%
Ansible 21 84%
Pupper 9 36%
M4 1 4%

18 How do you support redundancy? (26 Responses) - Interestingly OpenSIPS
clustering support is broadly used, this could be a deciding factor in its selection.
Hosting (28 responses) Responses %
Own 22 79%
Cloud 6 21%
Hybrid 10 36%
Redundancy (26 responses) Responses %
OpenSIPS provides clustering support that may be used for data
sharing/redundancy and service redundancy (with active/backup, active/active,
anycast models) 18 69%
Hot-spare servers using drdb/heartbeat 5 19%
Horizontal scalability (all nodes active) using SIP Thor 5 19%
Corosymc pacemaker, and dns redundancy 9 35%
Active / Active systems redundant across Availability zones and geographic
regions 7 27%
Multiple VM's 3 12%
DNS SRV 3 12%
Using both active-active and active-backup setups, with geo-redundancy. 4 15%

Mobicents / RESTCOMM
Project Survey RESULTS
I’ve included a brief review of the results for Mobicents / RESTCOMM, even though the number of
responses was low (3) so the results should be treated with caution as they are not representative, to show
how the move to a CPaaS offer can impact an open source project. I did follow-up with Telestax to let them
know their response numbers were low.

Summary of Results (3 responses - all were quite similar and from people I know
and trust to be fair in their opinions) Part 1
Application: CPaaS
Scale: 100
Strengths: GUI, some compatibility with Twilio API (there are several gaps), cloud available for fast
onboarding
Weaknesses: maintenance of self-hosted version, little community support
Future: Unclear given Telestax’s move to CPaaS and competitive gap with Twilio
Client: SIP inbound / outbound and the designer for the REST API
Developer community activity: 1 - Quiet
Developer community accessibility 1 to 2 - closed
Easy to engage with the community on features/issues: 2 to 3 - OK

Summary of Results (3 responses - all were quite similar) Part 2
Deployment architecture: VM image
Configuration management / scripting: None
Hosting: Hybrid
Redundancy: None

RTPproxy Results Project
Survey RESULTS
Only 2 responses received, so treat with caution.
It was nice to see this project being popular from an experience perspective. For the next survey we
should push for more feedback on the details of how this project is used.

RTPproxy Summary of Results (2 responses) Part 1
Developer community activity: 3 - OK
Developer community accessibility 5 - open
Easy to engage with the community on features/issues: 5 - Easy
Configuration management / scripting: Ansible
Hosting: Cloud
Redundancy: Across AZs and Regions

RTPproxy Summary of Results (2 responses) Part 2
Application: UCaaS
Scale: 100k
Strengths: Great media proxy, pretty much just does
that.
Weaknesses: lacks some newer, cooler stuff found in
RTPengine, lack of threading requires multiple
instances to be run and used.
Future: will continue to be used, it has a place for
offloading and can keep the outside world further from
your sensitive stuff. I could see it going away in favor of
rtpengine.
Client: RTPP and RTP
Developer community activity: 3 - OK
Easy to engage with the community on features/issues:
5 - Easy
Configuration management / scripting: Ansible
Hosting: Cloud
Redundancy: Across AZs and Regions

FreePBX Results Project
Survey RESULTS

PBX 14 67%
Conferencing 8 38%
CPaaS 0 0%
UCaaS 1 5%
100 16 80%
1000 4 20%
10k 0 0%
100k 0 0%
1M+ 0 0%
With FreePBX the application bias and scale conformed to the popular view of Asterisk, enterprise
scale PBX ( and conferencing).

Great management 10 59%
Great granularity of user
access rights 3 18%
Easy to use and setup 6 35%
Good GUI 9 53%
Community 3 18%
Weaknesses (10
Responses) Responses %
High Availability is expensive
and a bit of a kludge 5 50%
Poor scaling 3 30%
Lack of multi-tenant support 3 30%

Will remain dominant IPPBX
as its easy to use 6 55%
Depends on Sangoma 3 27%
Unknown / not sure 2 18%
Astricon (Oct 29-30) is going to be interesting, see you there!

We’ll need to add a section for people to name which “Other SIP SDK” they use rather than just checking a box :) However,
SIP.js and WebRTC are most popular.
Other SIP SDK 4 33%
WebRTC 1 8%

At the end of this report
we’ll do some
comparisons between
the OSPs on the
community questions.

Responses)

Responses)
All 7 responses stated no. Several comments stated, we are registered Sangoma partners with
authorization to submit code and patches for inclusion in the code, and have done so multiple
times..
Responses
Yes 0
No 7

Responses %
VM Images 9 75%
Bare Metal 7 58%
configuration
management/scripting (10
own / in-house 0 0%
SaltStack 3 30%
Ansible 6 60%
Pupper 1 10%

17 Do you host on: own infrastructure, cloud provider, or both (12
Responses)
18 How do you support redundancy? (9 Responses)
Own 7 58%
Cloud 4 33%
Hybrid 1 8%
FreePBX HA module and front
end SBC 4 44%
None 5 56%

FusionPBX Results Project
Survey RESULTS

FusionPBX Summary of Results (3 responses) Part 1
Application: PBX
Scale: 100
Strengths: Multi tenant support is great
Weaknesses: hard to understand configuration on specific features, not scaling
Future: Good
Client: Other SIP SDK, SIP phones / hard phones
Developer community activity: 4 - 5 Lively
Developer community accessibility 4 to 5 - open

FusionPBX Summary of Results (3 responses) Part 2
If you develop and enhance the platform yourself, how open do you find the community to your
submissions and pull requests: 4 to 5 welcoming
Do you find it easy to hire knowledgeable consultants, or otherwise access operational support for the
platform from outside your immediate organization : 4 hard
Hosting: Cloud provider
Redundancy: None

Janus Results Project
Survey RESULTS

Janus Summary of Results (4 responses) Part 1
Application: Conferencing, Mobile App Comms, Video CC, Radio broadcast
Scale: 100
Future: Will remain dominant
Client: in browser signalling, WebRTC
Developer community activity: 4 - 5 Lively
Easy to engage with the community on features/issues: 5 - Good
submissions and pull requests: 5 welcoming

Janus Summary of Results (4 responses) Part 1
Deployment architecture: VM image, CI
Hosting: Own, Cloud provider
Redundancy: None

Jitsi Results Project Survey
RESULTS

Jitsi Summary of Results (4 responses) Part 1
Application: Conferencing, Video CC
Scale: 100
Strengths: Makes video conferencing extremely simple
Future: Will remain dominant
Client: in browser signalling, WebRTC
Developer community activity: 3 OK
Developer community accessibility 3 - OK

Jitsi Summary of Results (4 responses) Part 2
Deployment architecture: BM, VM image
Hosting: Own, Cloud provider
Redundancy: None

Kazoo Results Project
Survey RESULTS

Kazoo Summary of Results (2 responses) Part 1
Application: PBX, CPaaS, UCaaS
Scale: 10k-100k
Strengths: Excellent once setup properly - reliable, right feature set
Weaknesses: hard to understand configuration
Future: not sure
Client: Other SIP SDK, SIP.js
Developer community activity: 4 Lively
Developer community accessibility 4 to 5 - open
Easy to engage with the community on features/issues: 4 to 5 - Good

Kazoo Summary of Results (2 responses) Part 2
submissions and pull requests: 4 welcoming
Deployment architecture: bare Metal
Configuration management / scripting: 2600Hz Cluster Manager
Redundancy: Kazoo does it natively

sipcature-homer Results

sipcapture-homer Summary of Results (4 responses) Part 1
Application: Troubleshooting of SIP traffic to/from carriers & UCaaS
Scale: 100k
Strengths: Highly Scalable stack
Weaknesses: UI portion has some rough edges
Future: Solid future, best of available options & in the longer term i think this will converge with other
logging and monitoring solution
Client: Other SIP SDK, SIP.js
Developer community accessibility 3 to 4 - OK

sipcapture-homer Summary of Results (4 responses) Part 2
Easy to engage with the community on features/issues: 3 to 4 - OK
submissions and pull requests: 3-4 OK
platform from outside your immediate organization : 3-4 OK
Deployment architecture: bare Metal & VM Images
Configuration management / scripting: Ansible & none
Hosting: Own & Cloud provider
Redundancy: None & across azs and regions

Vicidial Results Project
Survey RESULTS

Vicidial Summary of Results (2 responses) Part 1
Application: Contact Center, 1-1000 agents
Scale: 100-1000
Strengths: Ease to use, solid feature set
Weaknesses: None
Future: Solid Future, best of Open-Source contact center suites
Client: Other SIP SDK, SIP, IAX2, WebRTC
Developer community accessibility 4 to 5 - Open
Easy to engage with the community on features/issues: 4 to 5 - Good

Vicidial Summary of Results (2 responses) Part 2
submissions and pull requests: 4 Welcoming
platform from outside your immediate organization : 4 Hard
Deployment architecture: bare Metal & VM Images
Configuration management / scripting: Ansible & none
Hosting: Own & Cloud provider
Redundancy: None & across azs and regions

Wazo Results Project
Survey RESULTS
It was nice to see such a young project

PBX 4 33%
Conferencing 3 25%
CPaaS 1 8%
UCaaS 2 17%
CCaaS 1 8%
100 0 0%
1000 0 0%
10k 1 10%
100k 5 50%
1M+ 6 60%
Broad based of application, with a focus on scale. This shows how solution wraps / management
interfaces are enabling Asterisk to be used as scale.

Robust / Reliable 4 40%
Scalable 5 50%
Easily programmable 5 50%
Easy to use / configure 3 30%
Excellent B2BUA 2 20%
Responsive core team 3 30%
Lack of notoriety 3 30%
Growing community 3 30%
Not as flexible as Freeswitch
(e.g. rewrite header or sdp) 3 30%
Solid strengths in Scalability, Ease of Programming, and Robustness. Recognition from the
community on its need to grow and build awareness. With a weakness you’d expect compared to
more mature projects.

Future (6 responses) Responses
Growing fast, will become a
dominant project 6

We’ll need to add a section for people to name which “Other SIP SDK” they use rather than just checking a box :) However,
SIP.js and WebRTC are most popular.
Other SIP SDK 4 33%
WebRTC 3 25%
SIP (and SIPREC) 4 33%

10 Does the developer community make itself accessible for participation
(closed – OK – Open (with lots of fast help (hours) and dev events))? (19
Responses)

12 If you develop and enhance the platform yourself, how open do you find
the community to your submissions and pull requests? (closed – OK – welcoming)
(19 Responses)

16 Do you use a configuration management/scripting system like Chef,
Puppet, Ansible, SaltStack, Terraform or CloudFormation etc. (8 Responses)
Responses %
VM Images 5 50%
Bare Metal 4 40%
configuration management/scripting (8
own / in-house 0 0%
SaltStack 1 13%
Ansible 6 75%
Pupper 1 13%

17 Do you host on: own infrastructure, cloud provider, or both (6
Responses)
18 How do you support redundancy? (9 Responses)
Own 2 33%
Cloud 4 67%
Hybrid 3 50%
Redundancy with 2 VMs, each
of them are in different ESX
server 3 75%
Kamailio helps 1 25%

Matrix Results Project
Survey RESULTS

Matrix Summary of Results (3 responses) Part 1
Application: Conferencing, Collboration, Mobile App Comms, Chat, orchestrating deployments
Scale: 100-1000
Strengths: Community, Variety of adapters, Federation
Weaknesses: Complex set up
Future: Growing, one to watch
Client: In browser signaling, WebRTC, riot.im, mobile apps
Developer community accessibility 5 - Open
Easy to engage with the community on features/issues: 2 to 5 - OK to Good© Alan Quayle, 2019

Matrix Summary of Results (3 responses) Part 2
submissions and pull requests: 4 Welcoming
Deployment architecture: CI & VM Images
Configuration management / scripting: Ansible, Saltstack, Terraform, Packer
Redundancy: AWS ELB, multi-container/VM, managed shared filesystem on AWS, managed persistence
layers from AWS

Node-Red Results Project
Survey RESULTS
Only 1 response received. I include Node-Red as I think the industry could gain much from using this tool for application
development and integration with other services like GCP and Watson for comms related AI

Node-Red Summary of Results (1 response) Part 1
Application: Contact Center, CPaaS, CPaaS use case realization, connection to external services (e.g.
GCP, Watson for comms related AI)
Scale: 100-1000
Strengths: Extensibility, fot for purpose
Weaknesses: Awareness in telecoms domain
Future: Will most likely become more relevant as a tool, not sure how much in communications area.
Client: Vendor libraries, custom developed libraries, no SIP only HTTP
Developer community activity: 3 OK
Developer community accessibility 4 - OK to Open

Node-Red Summary of Results (1 response) Part 2
Easy to engage with the community on features/issues: 3 - OK
submissions and pull requests: 3 OK
Deployment architecture: VM Images
Configuration management / scripting: Ansible, Saltstack, Terraform, Packer
Redundancy: AWS ELB, multi-container/VM, managed shared filesystem on AWS, managed persistence
layers from AWS

Some Comparisons from

(>10 companies contributions))?
Asterisk FreeSWITCH
Kamailio OpenSIPS

10Does the developer community make itself accessible for participation (closed –
OK – Open (with lots of fast help (hours) and dev events))?
Asterisk FreeSWITCH
Kamailio OpenSIPS

good (rapid response, within hours, day max))
Asterisk FreeSWITCH
Kamailio OpenSIPS

community to your submissions and pull requests? (closed – OK – welcoming)
Asterisk FreeSWITCH
Kamailio OpenSIPS

(easy – OK - hard)
Asterisk FreeSWITCH
Kamailio OpenSIPS

A Few Take-Aways
● For configuration management / scripting, the answer is Ansible
○ Should we ask addition questions on usage and scripts, should each project share popular scripts to aid
adoption and setup?
● Native Cloud (AWS, Google, etc.) is not a popular choice
○ Is this because Telecom people are suspicious of the cloud?
○ Is it because we like to control everything from the metal up?
○ Are we always looking to save a dime? RTC is CPU intensive, and price is an issue.
○ Or is it that the complexity that AWS, Google, etc, imply are not worth our time? RTC is latency sensitive so it
that an issue?
● Is FreeSWITCH losing gas?
○ Or is this a temporary blip given the Signalwire announcement?

A Few Take-Aways
● Kamailio/OpenSIPS seem to be ridding the xCaaS storm well
○ Telecoms is still hacking low level stuff and will probably continue to be for some time
● Price, security and on-premises requirements make up a very big market that Twilio,
RingCentral, Taslkdesk can't disrupt yet..
● Matrix has a lot of promise and support, but we’re still waiting for that break-out
moment
○ I think it will be in another 5 years when we discover matrix is simply everywhere for federation
● Geography
○ Some in Europe were surprised at the size of the Asterisk responses, it would be interesting to map how the
projects are adopted around the world

Next Steps
● Survey ended up being long….
● Suggest we focus and have a couple of surveys to focus on aspects people
find important
● Looking for guidance…

Open source telecom software project survey results 2019

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Open source telecom software project survey results 2019

Similaire à Open source telecom software project survey results 2019 (20)

Plus de Alan Quayle

Plus de Alan Quayle (20)

Dernier

Dernier (20)

Open source telecom software project survey results 2019