Open Source Telecom Survey 2021 Results & Discussion, Alan Quayle

Open Source Telecom Software
Survey 2021

Three Surveys
© Alan Quayle, 2021
2020
2019
http://alanquayle.com/2019/12/deeper-dive-
into-the-open-source-telecom-projects/
• Broad review of most of the open
source projects, and common
deployment issues
• Filling in gaps on geography,
contributions, deeper dive into hosting
/ redundancy, plus missing projects
(drachtio, ASTPP, RTP Engine, etc.)
http://alanquayle.com/2020/07/open-source-
2020-survey/

Three Surveys
2021
https://alanquayle.com/2021/06/open-source-
telecom-software-survey-2021/
• Broad review of the popular open
source projects, focus on security,
serverless, telco, training,
STIR/SHAKEN, IoT, and adoption
barriers.

Contents
● 2019 Recapitulation
● 2020 Recapitulation
● 2021 Introduction
● General Survey Results
● Project Survey: Asterisk
● Project Survey: OpenSIPS
● Project Survey: Kamailio
● Project Survey: FreeSWITCH
● Project Survey: SIPCapture-HOMER
● Project Survey: Jambonz and Drachtio
● Project Survey: Wazo
● Project Survey: Vicidial
● Project Survey: Jitsi
● Project Survey: RTPEngine
● Project Survey: FreePBX
● Appendix 1: 2020 Results
Please note, if a Project Survey,
or a section in the General
Survey received less than 5
responses, the results are not
shown as its difficult to draw any
meaningful conclusions.

Which OSPs do you use? Responses %
Asterisk 71 75%
FreeSWITCH 39 41%
Kamailio 41 43%
OpenSIPS 51 54%
Restcomm/Mobicents 3 3%
2019 Recapitulation

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

Comparison: 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))
Asterisk FreeSWITCH
Kamailio OpenSIPS

Comparison: 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)
Asterisk FreeSWITCH
Kamailio OpenSIPS

A Few Take-Aways
● For configuration management / scripting, the answer is
Ansible
○ Should each project share popular scripts to aid adoption and setup?
● Native Cloud (AWS, Google, etc.) is not a popular choice
● 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
● There’s still much we can do together as a global community
to accelerate open source adoption

2020 Survey Recapitulation (87 Responses)

India: Speed of response
Australia and NZ: Speed of response
Russia: Language barriers
Central and South America: Language barriers
Europe: Finding knowledgeable consultants
North America: Finding knowledgeable consultants
Distributed team: Speed of response
Middle East: Speed of response
2020 Survey Recapitulation

Documentation is critical, also it must be up to
date with the current release – specific
comments were made multiple times.
Documentation needs a dedicated expert with
translation support (Google translate is not good
enough, check out #googletranslatefails for a
laugh). Given even Twilio has limited non-
English document support I think its too much
for open source projects to support.

• Training
• Development / Design
• VoIP Service / Applications (cloud /
premise / platform)
• WebRTC Applications
• Softswitch services
• Contact center applications
• Asterisk
• Maintenance of VoIP networks and services
• Consulting
• General OSS / RTC Development /
Deployment
• Predictive dialing, inbound acd, pbx
• Audit Services
Do you provide consulting for other companies on how to
deploy / manage / scale open source projects?
• Security
• OSS for Call Centers (ViciDial &
OpenSIPS)
• Network consulting
• RTC design / experience
• Premise architecture, hardware,
networking and configuration
• Managed / Hosted VoIP networks / services
• Installation, Customization, High availability
and Scalable setups for Open Source projects.
• Telco Consulting
• IMS on Kubernetes (based on Kamailio)
• OpenStack, Kubernetes, IAC
• RTC OSS strategy

A cautious approach to Serverless,
no geographic differences. We’ll
explore this more in TADSummit
EMEA / Americas in November.

Drachtio / Jambonz: Strengths, Weaknesses, Future
• Project Strengths
• Leverages public cloud computing, auto scaling, and top-notch maintainer.
• Aimed at area of market (SME) that is poorly served at present.
• Relatively new, easy to glue other projects together to fill gaps.
• Project Weaknesses
• No sms stack, TTS, conferencing, messaging etc.. and many other components that make it a complete CPaaS
enablement solution.
• Needs the community to take it to the next level.
• Risk: big companies with larger development budgets
• No legacy support.
• More documentation, tutorials, examples
• Future
• I think it’s too late to make a real impact.
• Game changer in CPaaS
• Hard to say
• Likely to be successful
Time is critical to confidence in open
source projects. They need to prove
they’ll be here for the long-run.

Drachtio / Jambonz Community
A respectable
result given the
youth of the
project and the
commitment of
Dave Horton.

RTPEngine: Strengths, Weaknesses, Future
• Stability and features
• Quality code, responsiveness of core team
• Feature rich and scalable
• Very efficient at what it does
• Integration with Kamailio, features, performance
• Better documentation with more examples
• Monitoring and performance checks could be improved.
• Ideally the system would include a turn server
• Future
• Not expecting changes
• Would like plugin architecture for tapping into media stream
• Future of Sipwise within ALE
• Strategy is not clear
• Awesome

RTPEngine: Community

• Security
• Repeat 2019 broader survey
• More details on existing platforms
• More telco core stuff, role of OSS in IMS, 5G SA, etc.
• Ask about API-related features being used inside of Asterisk, for
example, do you use AMI? ARI? AGI? FastAGI?
• Track serverless adoption
• Can we get web developers perspectives on the OS projects?
• Make it an annual survey and track progress of projects over time
Topics we should address in 2021

2021 Survey Introduction
● This survey follows on from the surveys run in 2020 and 2019. Thank you for
your continued support.
● Please complete the general survey, and then choose the specific project
surveys (separate forms) you want to provide feedback. If any question is not
relevant or you have no opinion, just skip it.
● Covered in the general survey this year are: Security, Serverless,
STIR/SHAKEN, barriers and benefits of OSS, telcos and OSS, Training, IoT,
and general geographic / category info.
● The project specific surveys follow the format of previous years with some
customizations to make them more relevant to the specific projects.
● 114 responses to general survey, +163 project survey responses (277 total)

2021 Results: What Region are you based?
2020
Similar
distribution to
previous years
with Europe
dominating
thanks to
University
support, e.g.
FOKUS
2021

2021 Results: What region(s) are most of your
customers based?
Given North America is the epicenter of
programmable communications,
Europe still dominates with customers.
Outside Europe / North America is
slightly greater number than last year.

2021 Results: Business Category
New question for 2021. Most
Universities are from Europe.
Telcos remain under-represented.
The importance of resellers /
channel was good to see, given
my experience from attending
events like Astricon.

2021 Results: Business Category
New question for 2021. Will
track how this changes. I was
surprised by the number of
medium sized businesses
(100-<1000).

2021 Results: What open source software do you use?
Linux
Linux 15
debian
linux 15
OpenSuS
E Linux 9
centos 9
linux mint 8
Manjaro 7
Percona 4
Ubuntu 3
DB
Postgres 19
MariaDB 9
REDIS 5
MongoDB 4
MySQL 4
CouchDB 4
Web/
Enterprise
Part 1
Ansible 19
Confluent
Kafka 19
Apache 18
Node.js 16
Docker 14
nginx 12
Grafana 12
HAProxy 11
RabbitMQ 9
PHP 8
Prometheus 7
suitecrm 7
Puppet 7
Web/
Enterprise Part
2
Jenkins 6
Zabbix 5
GnuCash 5
Perl 4
vscode 4
Kibana 4
SpagoBI 4
Elasticsearch 3
EspoCRM 3
QGIS 3
FRRouting 3
D3 2
Thunderbird 2
ActiveMQ 2
odoo 2
Karaf 1
Passbolt 1
Univention 1
Voice
OpenSIPS 24
Kamailio 23
FreeSWITCH 22
Asterisk 21
Homer 18
rtpengine 18
drachtio / jambonz 18
wazo 15
RTPproxy 15
freepbx 12
SIPp 11
Matrix 11
VICIDial 9
Jitsi 8
ASTPP 8
XiVO 7
Janus 5
Sippy/b2bua 5
WSO2 3
Restcomm 2
Open Source telecom
software is part of a suite
of open source projects.
Perhaps we should
investigate dominant
architectures?

2021 Results: How has the pandemic…..
Interestingly ‘not impacted’ dominates. Followed by acceleration in cloud/hosted. Video was relatively
small compared to the media coverage. In part this reflects the segment of the open source community
that contributes to this survey.

2021 Results: Open Source Barriers
This was the richest selection of
barriers raised so far, including
some interesting insights on
perceptions and mindsets.
Documentation remains the top.
Some projects consider their
documentation adequate for
their community. But for the
community to grow it needs to
be accessible by NEW people.

2021 Results: How Overcome Barriers?
There’s a long-term commitment to
building an organization that
understands open source, and is
committed to owning the product, its
roadmap, and the customer experience.
Companies successful with open source
do not happen overnight, they are built
over years. See Gamma buying Mission
Labs.

2021 Results: Benefits?
Control over your business, and
all the benefits that come from it
was top. The benefits of the
community back into the
business, e.g. rapid debugging,
deployment advice. An
underlying theme was being
human centered, rather than a
bureaucratic (corporate).
Main benefits of using open source
Control over your business - roadmap, customer experience,
understanding 47
Community 43
Customer focus 41
Speed - respond to customer needs in days not years 38
Interoperability 35
Innovation 33
Support 31
More Secure, plus understand how secure 27
No bureaucracy of closed source negotiations 26
Flexibility 24
Cloud native 22
Value 21
Almost always 20% TCO compared to licensed 19
No risk product will disappear 18
Stability 15

Importance in
overcoming
barriers
High Medium Low
Documentation and
training 68 13 8
Community 65 29 7
Roadmap, releases,
fixes, contributions 23 66 15
Security audits 21 61 18
Consultants 33 35 41
Support contracts 17 41 40
Documentation and community
remain top. Security has risen in
importance. Surprisingly support
contracts were not considered
important in overcoming the
barriers. While it was rated the
#2 barrier. Reflects mix of those
running / consuming projects.

IoT Section
● Are you using any of the open source telecom software projects for IoT
○ Yes 48, No 19 (59% of respondents answered this section)
○ I was surprised by the number of IoT projects, at over 40% of all respondents
● What tools / resources would help for your IoT projects?
○ Over-riding comment was keeping documentation up to date, particularly with
new devices. There is recognition its an impossible task. However, a subset
should be recommended and maintained in a relatively timely way.
● In your opinion what IoT projects require open source telecom software?
○ Enterprise IoT not consumer IoT dominated responses including routers,
cameras, door locks, and other access control and security devices.

STIR/SHAKEN
● Have you implemented STIR/SHAKEN for your project / deployment?
○ Yes 11, No 39 (44% of respondents answered this section)
● Do you have a need for STIR/SHAKEN in any open source telecom software?
○ Yes 21, No 26
○ Only if the project if focused on North American service providers is there a
need.
● When do you plan to implement STIR/SHAKEN?
● Have you taken part in
STIR/SHAKEN interoperability
testing?
○ Yes 12, No 31, planning 5

Training: How is it offered?
Given the pandemic, online
/ remote is top. Given my
experience working with
web-centric developers,
YouTube videos are quite
popular.
Investing in training is a
critical pillar for any project.
Commercial products make
large investments, and
while open source budgets
are not the same,
certifications and online
training courses will help
convert more businesses to
be confident with open
source.

Training: What type of training do you prefer?
Good documentation / manuals / tiers for different skill
levels 31
Online training 31
Tier training by knowledge / skill 28
Online with email / chat support 24
Hands-on guided builds based on real-world examples 22
On-line instructor-led training 20
YouTube videos 19
Online Udemy style 19
Lots and lots and lots of examples 19
Short how-to videos 17
Easy on ramp for web-centric developers 17
Webinars 15
On-site / in-person training 12
MOOC (A massive open online course, mooc.org) 11
Interestingly there are many more online
training options people prefer, including
with email / chat support, tiered by
ability level. With guidance to use
Udemy and MOOC.org.
Tiering of knowledge was mentioned in
several responses. Several web-
developers who completed the survey
mentioned the need for an on-ramp into
the project. Projects need new blood to
survive, being accessible to new
developers is critical.
A variety of video formats where also
seen as important. Plus lots and lots of
worked examples.

Training: What do you expect to pay for training?
In-person $1000 per day 20
Online $200 for the course 18
If investgating project - free 17
If core project to business - $1000 per day 17
MOOC pricing (free with $100-$200 for
verification) 16
Market rate for technology training 15
Online with chat/email support $100 pm 15
Webinar $100 per hour 15
Online free 12
<$500 9
No idea 8
MOOC pricing is interesting, free if
you just want to learn, if you want
the training recognized, then there’s
a fee. This enables people to
investigate for free, and then if they
require support, the training needs
to be verified. This avoids training
through support ;)
The pricing points vary greatly by
market. Within North America and
Europe, $1k per day for in-person
was often mentioned.

Serverless Plans
2021
2020 2021
No plans 41% 63%
Evaluating 34%
Implemented 12% 15%
This year 5% 7%
Next year 4% 15%
Don't care 3%
While implementation progresses slowly, more people
have made a decision against serverless adoption. See
discussion about RTC and serverless here:
https://blog.tadsummit.com/2020/11/02/serverless-
and-rtc-panel-discussion/. Industry has concluded
serverless’s role.

Serverless Pros:
● Good when starting a business, but as it scales, costs can explode
● Lower costs for bursty workloads that don't need dedicated VMs/containers
● Good for database, not for VoIP signaling or media processing
● Pay as you go
● No need to manage the security, upgrades, etc.
● If your application architecture is suitable, there are lots of positive benefits. Even just
architecting for serverless and then deploying containers on K8s or even own
infrastructure gives massive deployment flexibility.
● Scalability, no need for middle-ware e.g. JainSLEE, lightweight. resilience.
● Easy to deploy
● Great redundancy and survivability, therefore availability
● Already using
● Good concept can be useful in the right places for the right things such as automated
testing. © Alan Quayle, 2021

Serverless: Cons
● Very hard to architect efficiently with SIP and other stateful protocols/clients.
● Hype
● Harder traceability and debugging, latency issues
● Complexity explosion in management and devops
● No proven tech yet, legal issues (?)
● Not ready
● Cost is unpredictable with scale
● More complicated deployment. Cost related to automation and containerization. O&M
● Not for telco yet
● Loss of application control
● Sometimes difficult to debug and troubleshoot
● Less features
● Documentation and examples

Security: Internal Security Teams
Thank you for the honest
answers!
Though not a surprise this
does show RTC security is
falling through the cracks.

Security
● If you are using security testing tools for RTC, please list them
○ None 75%, SIPVicious / SIPVicious Pro 13%, Sipp 4%. Sipcrack suite 4%, Test RTC 4%
● Are you supporting RSA and/or Elliptic Curve TLS server certificates in SIP?

Security: Are you supporting/using encryption of
media?

Security:
● Are you supporting/using MD5
based digest authentication in SIP?
● Are you supporting/using SHA256/512
based digest authentication in SIP?

Security: Are you supporting/using token based
authentication (OAuth2/OpenID connect) for SIP?

Security: What type of defensive mechanisms for
RTC Security do you use?

Security:
● How is security hardening done?
○ Internally 63 (74%), Both 22 (26%)
● At which layer are defensive mechanisms applied?
○ Application, 20 (24%), Network 23 (27%), Both 42 (49%)
● What type of offensive
mechanisms, if any,
for RTC are used?

Security:
● How much of the security efforts
are reactive / proactive?
● Secure code review?

Security: What sort of security training is provided to
employees?

Project Survey: Asterisk (24 responses vs 66 in 2019)
● What is the main application(s) / market need(s)?
2021 2019
Similar results to 2019, with PBX and contact center top, though conferencing dropped in 2021. Added
C4/5 Softswitch for 2021 which is clearly an important use case. General survey, though well-answered,
did drop the number of responses to individual projects. However, overall response rate is the highest
we’ve ever achieved.

Project Survey: Asterisk
● In the past 18 months what new projects have you undertaken with Asterisk?
○ Wazo (3), Carrier class switches (13), Recording audio and voice bots (15),
Performances projects (9), migration to most recent version (10), migration to
pjsip from chan_sip (4), migration to ARI from AMI/AGI (7), TTS/STT (6), Call
center dialers, ACD, PBX (11)
● What is the scale of the implementation (calls / sessions per hour)?
2021 2019
More large scale
deployments in
2021 thanks to
OpenSIPS and
Kamailio.

● Strengths
○ Simplicity, Stability, Community, Maturity (same as last 2019)
○ Easy to fine consultants
○ AGI (Asterisk Gateway Interface) is great for separating advanced features from
core SIP functions
● Weaknesses
○ Leadership, ownership is unclear (same as 2019)
○ Can be a little tough to use as a softswitch.
○ Not that receptive to features that are not in their use case / roadmap.
● Future (results similar to 2019)
Similar results between
2019 and 2021.
Future (33 responses) Responses %
Will remain dominant IPPBX / remains
dominant project 19 58%
Depends on Sangoma 8 24%
Unknown / not sure 6 18%

● What client protocol/interface/platform do you use? Ordered by frequency mentioned.
○ Classic SIP phone (11), SIP.js (8), other SIP SDK (7), JsSIP (6), WebRTC (5), baresip (4), classic
SIP (not always a phone) (1), pass-through (pass-through: telco->kamailio->asterisk-
>kamailio->telco) (1)
● Have you developed your own low-level features without giving them back to the community, and
if so, why?
○ Was not accepted (5), customer specific feature (5)
● How do you architect your deployments (choices not exclusive and multi-dimensional)?
○ VM images 90%, bare metal 80%, container images 20%, container orchestration 0%
● Which configuration management/scripting system do you use?
○ Ansible (80%), Pupper, SaltStack, CloudFormation
● Where do you host your Project ?
○ Own (65%), Hybrid (20%), Cloud (15%)
● How do you support redundancy ?
○ Kamailio / OpenSIPS, redundant servers / hot back-up / clustering, auto-scaling groups, DNS
NAPTR/SRV load balancing, Pacemaker / Corosync

Project Survey: Asterisk, Metrics similar between
2019 and 2021

Project Survey: OpenSIPS (20 responses vs 45 in 2019)
2021 2019
Adding C4/5 Softswitch for 2021 is clearly an important use case. General survey, though well-answered,

Project Survey: OpenSIPS, What is the scale of the
implementation (calls / sessions per hour)?
2021 2019
Increase in the proportion of large scale
deployments between 2019 and 2021

Project Survey: OpenSIPS
● Strengths
○ Performance, Capacity, Flexibility, Support (same as last 2019)
○ Excellent C4 features
● Weaknesses
○ API not as rich as Asterisk or FreeSWITCH.
○ Error reporting can be confusing
○ Both Kamailio and OpenSIPS will continue to dominate this critical segment of
VoIP infrastructure / backbones
2019 and 2021.

Project Survey: OpenSIPS
○ Classic SIP phone (11), other SIP SDK (7), WebRTC (5), Classic SIP (not always a phone) (4),
contact center dialers (usually Asterisk based) (4).
if so, why?
○ No (same as 2019)
○ Ansible (80%), Pupper, Terraform
○ Own (75%), Cloud (20%), Hybrid (5%)
○ OpenSIPS replication, OpenSIPS clustering + Heartbeat/VRRP/anycast/geo-dns, Multiple
geographic cloud, heartbeat +virtual IP.

Project Survey: OpenSIPS, Metrics similar between
2019 and 2021

Project Survey: Kamailio (20 responses vs 40 in 2019)
2021 2019
Adding C4/5 Softswitch for 2021 is clearly an important use case. General survey, though well-answered,

Project Survey: Kamailio, What is the scale of the
2021 2019
Broader scale of deployments with 10k sessions
being the sweet spot that 1M+

Project Survey: Kamailio
● Strengths
○ Performance, Community, Flexibility, and Stability (same as last 2019)
● Weaknesses
○ “You’ve got to know what you’re doing.”
○ Complex
○ Both Kamailio and OpenSIPS will continue to dominate this critical segment of
VoIP infrastructure / backbones
2019 and 2021.

Project Survey: Kamailio
○ Classic SIP phone (11), WebRTC (7), JsSIP (5), other SIP SDK (5), Classic SIP (not always a
phone) (4), telco->kamailio->telco and telco->kamailio->media-services->kamailio->telco
○ (3), carrier trunks (3).
if so, why?
○ Ansible (65%), Pupper, SaltStack, Terraform, CloudFormation
○ Own (50%), Cloud (35%), Hybrid (15%)
○ SIP DNS SRV records, VRRP, Heartbeat/Corosync, HA, Anycast.

Project Survey: Kamailio, Metrics similar between
2019 and 2021

Project Survey: FreeSWITCH (21 responses vs 36 in 2019)
2021 2019
Adding C4/5 Softswitch for 2021 is clearly an important use case, in 2019 people added that use case.
Conferencing dropped, in part through the rise of video conferencing and bundling in UCaaS. General
survey, though well-answered, did drop the number of responses to individual projects. However, overall
response rate is the highest we’ve ever achieved.

Project Survey: FreeSWITCH, What is the scale of
the implementation (calls / sessions per hour)?
2021 2019
Narrower scale range, 10k being the sweet spot.

Project Survey: FreeSWITCH
● Strengths
○ Robust, flexible, full featured, open (same as last 2019)
● Weaknesses
○ Concern between Signalwire and FreeSWITCH community (more frankly stated
in 2021)
○ Concerns remain for both Asterisk and FreeSWITCH on the commercial impact
on the community. Nothing significant has changed, other than the concerns are
more frankly stated in this survey. Projects like Drachtio / Jambonz, will take
many years before being considered in a similar league to Asterisk and
FreeSWITCH. This situation will be BAU for the next 3+ years.
2019 and 2021.

Project Survey: FreeSWITCH
○ Other SIP SDK (8), WebRTC (7), SIP.js (5), Classic SIP phone (4), Classic SIP (not always a
phone) (3), telco->kamailio->telco and telco->kamailio->media-services->kamailio->telco
○ (3), Asterisk (2).
if so, why?
○ Ansible (35%), Pupper, SaltStack, Terraform, CloudFormation
○ Own (50%), Cloud (25%), Hybrid (25%)
○ cluster able configuration with autoscaling groups and DNS NAPTR/SRV load balancing, SIP
DNS SRV records, VRRP, Heartbeat/Corosync, HA, Anycast.

Project Survey: FreeSWITCH, Metrics similar
between 2019 and 2021

Project Survey: SIPCapture-HOMER (30 responses)
Homer Is a new project to the survey and achieved 30 responses.
● What is the scale of the
implementation (calls / sessions
per hour)?

Project Survey: SIPCapture-HOMER
● Strengths
○ Flexibility, stability, scalability, lots of use cases
○ Quality of the software and the team is quick to help and friendly!
○ Native Grafana integration
○ Simplicity in showing data with useful details about calls
○ Native hep integrations
○ HEP protocol is flexible and well-supported, making it a great / default way to ship SIP
traces off the server. I like that it is flexible to wrap other protocols.
● Weaknesses
○ Not enough updated documentation - new users can struggle. Documentation can be hard
to understand.
○ No analysis of the RTP stream
○ The GUI is hard to figure out, like searching for a SIP trace.
○ Complexity of the project due to its integration with a variety of time-series databases
makes it a bit daunting to know where to start sometimes.
It’s the people that make
the project!
Documentation as always
could be better.

● Future
○ Promising, I really hope the community continues to grow because this is a great
project, and we need it!
○ WebRTC and Integrations
○ More tooling for RTP stats
○ Support options
○ Its really a data analysis engine and isn't limited to just SIP.
○ Self-troubleshooting features in customer portal
○ Depends on making better (easier to use) analytical GUI tools
○ I'm hoping to use it to monitor and identify usage trends on our PSTN SIP trunk.

Project Survey: SIPCapture-Homer, What client protocol / interface /
platform do you use to generate traffic towards HOMER?

Project Survey: SIPCapture-Homer
● Have you developed your own low-level features without giving them back to the community, and if so, why?
○ Not yet
● Do you find it easy to hire knowledgeable consultants, or otherwise access operational support for the platform
from outside your immediate organization?
○ Geography dependent, even spread from easy to hard
○ Ansible (50%), Pupper, SaltStack, Terraform, CloudFormation, None (50%)
○ Own (33%), Cloud (33%), Hybrid (33%)
○ Generally not supported.
○ Over AWS have Homer installed on Kuberenetes. Multiple pods under the same ReplicaSet for each service
and a load balancer that directs the HEP traffic to all the pods and Application load balancer that allows us to
access to Homer Web UI, no matter how many pods we have. Database is on RDS, using Aurora with 2
instances (writer-reader) so DB is also redundant.

Project Survey: Jambonz and Drachtio (10 responses vs 29 in
2020)
Similar responses between 2020
and 2021

Project Survey: Jambonz and Drachtio
• Jambonz development has the community excited
• No sms stack, TTS, conferencing, messaging etc.. and many other components that make it a complete CPaaS
• Future
• Jambonz has shifted the perception of the project, there is a buzz about its future
• Hard to say
• Likely to be successful Similar results between 2020 and 2021. Launch of Jambonz
has the community excited.

Drachtio / Jambonz: Client
SIP.js continues to be popular.
Compared to other projects, the
use of WebRTC shows a bias
toward more web-centric projects /
web-centric developers.
and 2021

A respectable
result given the
youth of the
project and the
commitment of
Dave Horton.
and 2021

Drachtio / Jambonz : Architect Deployment
Similar result to last
year of own
infrastructure
dominating.
However, I was
expecting more
cloud deployments
with Drachtio /
Jambonz.
Similar responses

Drachtio / Jambonz Config Management / Scripting
In-line with all other
projects, the answer in
Ansible.
Similar responses

Drachtio / Jambonz Hosting
This one surprised me.
I expected to see more
Cloud hosting, while
own then hybrid are
more popular.
and 2021

projects, the answer is
Ansible.
and 2021

Drachtio / Jambonz: Redundancy
• VMware Vxrails
• AWS autoscale cluster for feature servers, DNS load balancing for SBC
• Multi AZ, Multi region
• ANYCAST Level
• Multi-AZ failover with alternate region replication
• Multiple active:active across AZ & geo
• DNS redundancy / SRV
• Multiple VMs
and 2021

Project Survey: Wazo (5 responses vs 12 in 2019)
● What is the main application(s) / market
need(s)?
When the sample size is 5 (2021), it becomes difficult to make comparisons. However, the focus does
appear more to PBX, than other applications.
2021 2019

Project Survey: Wazo, What is the scale of the
2021 2019
Small sample size limits what we can infer,
however, focus appears to be on smaller scale
deployments.

Project Survey: Wazo
● Strengths
○ Scalability, ease of programming, and robustness (same as last 2019)
○ The team: committed, knowledgeable, quality conscious with good forum
support.
● Weaknesses
○ Documentation
○ Does not stick with LTS versions of Asterisk
○ Not suited to production, requires too much technical skill to be deployed.
● Future
○ Because of the team, generally considered bright
○ New concern mentioned is what will happen between the project and business
side of Wazo, perhaps there is a need for greater clarity?
2019 and 2021.

Project Survey: Wazo
○ Classic SIP phone (4), WebRTC (2), Cisco SCCP (1), Wazo commercial product (1).
if so, why?
○ Ansible (80%), None (20%)
○ Own (75%), Cloud (25%)
○ Proxmox VE with Ceph, cold standby with image backup-restore after each update, no
redundancy

Project Survey: Wazo, 2021

Project Survey: Wazo, 2019
While the results of 2019, had the benefit of
being a relatively new project. They are quite
exceptional. 2021 showed a broader perspective
as the project matured.

Project Survey: Vicidial (5 responses)
● Application: Contact Center
● Scale: 100-1M+
● Strengths: Flexible, many features
● Weaknesses: Complicated
● Future: Good, excellent contact center
● Client: Classic SIP phone and WebRTC
● How do you architect your deployments: VM 50%, Bare metal 50%
○ None (100%)
○ Own (50%), Cloud (50%)
○ Web/DB clustering, failover and load balancing for Asterisk
Very similar responses

Project Survey: Vicidial (5 responses)

Project Survey: Jitsi (5 responses)
● Application: Conferencing 80%, UCaaS 20%
● Scale: 100
● Strengths: Makes video conferencing extremely simple
● Weaknesses: None, excellent project
● Future: Good, will remain dominant video conferencing platform
● Client: WebRTC
● How do you architect your deployments: VM 100%
○ Ansible (100%)
○ Own (100%)
○ Using Jitsi mechanisms for scalability (XMPP)
○ Heartbeat/Corosync
Similar responses

Project Survey: Jitsi (5 responses)

Project Survey: RTPEngine (5 responses)
● Application: Media relaying and manipulation. Used across PBS, CPaaS, UCaaS,
contact center, C4 softswitch
● Scale: 100 (20%), 1000 (40%), 10k (40%)
● Strengths: Security, Ease of use, developer support
● Weaknesses: Documentation, a concern on the lack of activity from the team
● Future: Good, will remain dominant video conferencing platform
● Client: WebRTC, Classic SIP phone, JSSIP, SIP.js, SipML5, other SIP SDK, SIP trunks
from carrier
● How do you architect your deployments: VM 3, bare metal 1, container images 1,
container orchestration 1
● Which configuration management/scripting system do you use? Ansible and
Terraform
● Where do you host your Project ? Own (2), Cloud (3)
● How do you support redundancy ? None
Similar responses

Project Survey: RTPEngine (5 responses)

Project Survey: FreePBX (5 responses)
● Application: PBX (5), UCaaS (2), contact center (1), mobile app comms (1), multi-canal
sourcing ( tchat, whatsapp, facebook, sms..) (1)
● In the past 18 months what new projects have you undertaken with FreePBX?
○ Cloud FreePBX, Small office systems, Contact center
● Scale: 100 (3), 1000 (2)
● Strengths: FreePBX is magnificent. Flexibility we have on configuring custom
application (PBX-ERP DB interaction - Call routing - CID enriched info)
● Weaknesses: Low awareness in Europe. Expensive and slow support from Sangoma.
Dependence on stable connectivity and network health
● Future: Uncertain: IPBX must be a server for all kind of exchanges. Worry Sangoma
will make it more commercial.
Similar responses

● Client: Classic SIP phone (3), JsSIP (2)
● How do you architect your deployments: VM 100%
○ CloudFormation, Promox, none
○ Own (2) Cloud (3)
○ 2 cloud servers in two different locations, with IP adress manageable. Backup in
less2 minutes.
○ VMware backup - Vmotion - HA with carp protocol
Similar responses

A Few Take-Aways from 2021
● Training: An interesting dichotomy is where people do not expect to pay for training when
investigating a project but will pay when the project is part of their business.
○ MOOC.org pricing is interesting. Its free if you just want to learn, if you want the training recognized,
then there’s a fee.
○ This enables people to investigate for free, and then if they require support, the training needs to be
verified. This avoids training through support ;)
○ Feedback on this point has been mute so far. However, I do consider it a firm recommendation from
the study.
● While the mature projects did not change much, we did see projects like Wazo’s results
change a little, though the sample size is small, so I warn against inferring too much. Simply
the community is maturing.
○ Given the small changes over 1 year, my recommendation is we do the project surveys every 2 years.
● Open Source telecom software is part of a suite of open source projects used. Perhaps we
should investigate dominant architectures?
○ This one is quite complex, I’ve discussed with several people, there are popular projects, such as
Ansible, Confluent, Grafana. But once we get into the details it becomes much harder to draw out
common architectures because of the multitude of situations and wanting to keep secrets.

A Few Take-Aways from 2021
● Company’s that use open source make a long-term commitment to building an organization that
understands open source, and is committed to owning the product, its roadmap, and the
customer experience.
○ Companies successful with open source do not happen overnight, they are built over years.
○ Gamma buying Mission Labs is an example of a large company buying in the necessary expertise, to build a
product team around that core.
● Documentation, documentation, documentation
○ Check out Twilio – but we need to find a way to help solve this industry-wide issue.
○ General agreement on it being an issue, but motivation to solve it appears low.
○ Some have argued their docs are great for their existing consultants, but what about new channels?
○ From the OpenSIPS summit we did discuss the importance of recognizing community members’
documentation contributions as much as code contributions.
○ Many community members are intimidated by the abilities of the core team, so do not contribute. While
they can make excellent documentation contributions.

Jambonz @ TADHack
Check out https://youtu.be/tVcfPC5lEsE and https://youtu.be/9c6cSbxjXS4

Appendix 1: Open Source Telecom
Software Survey 2020

2020 Survey – Hot of the Press!! (87 Responses)

India is growing in importance.
FOKUS is important to Europe.
English speaking countries
appear to over-index in the
survey.

Europe and North America
dominate deployments. There
is much room for growth
around the world.

India: Speed of response
Australia and NZ: Speed of response
Russia: Language barriers
Central and South America: Language barriers
Europe: Finding knowledgeable consultants
North America: Finding knowledgeable consultants
Distributed team: Speed of response
Middle East: Speed of response

Europe and America follow the
overall curve and are the
sources of the 5 scores. India,
Middle East, Russia, ANZ
generally 3 or 4.

No significant geographic
dependency. FreeSWITCH
was slightly US-centric.

Documentation is critical, also it must be up
to date with the current release – specific
comments were made multiple times.
Documentation needs a dedicated expert with
translation support (Google translate is not
good enough).

India average score: 4
Middle East: 5
ANZ: 4
Europe: 1-5, with average 3
Americas: 1-2

• Training
• Development / Design
• VoIP Service / Applications (cloud /
premise / platform)
• WebRTC Applications
• Softswitch services
• Contact center applications
• Asterisk
• Maintenance of VoIP networks and services
• Consulting
• General OSS / RTC Development /
Deployment
• Predictive dialing, inbound acd, pbx
• Audit Services
Do you provide consulting for other companies on how to
deploy / manage / scale open source projects?
• Security
• OSS for Call Centers (ViciDial &
OpenSIPS)
• Network consulting
• RTC design / experience
• Premise architecture, hardware,
networking and configuration
• Managed / Hosted VoIP networks / services
• Installation, Customization, High availability
and Scalable setups for Open Source projects.
• Telco Consulting
• IMS on Kubernetes (based on Kamailio)
• OpenStack, Kubernetes, IAC
• RTC OSS strategy

What are your views of Serverless: Pros
● Lower costs for things that don't need dedicated VMs/containers
● Good for database, not for VoIP signaling or media processing
● Pay as you go
● No need to manage the security, upgrades, etc.
● If your application architecture is suitable, there are lots of positive benefits. Even just
architecting for serverless and then deploying containers on K8s or even own
infrastructure gives massive deployment flexibility.
● Scalability, no need for middle-ware e.g. JainSLEE, lightweight. resilience. Ready for
EDGE and 5G
● Easy to deploy
● Great redundancy and survivability, therefore availability
● Already using
● Good concept can be useful in the right places for the right things such as automated
testing. © Alan Quayle, 2021

What are your views of Serverless: Cons
● Very hard to architect efficiently with SIP and other stateful protocols/clients.
● Hype
● Harder traceability and debugging, latency issues
● Complexity explosion in management and devops
● No proven tech yet, legal issues (?)
● Not ready
● Cost is unpredictable with scale
● More complicated deployment. Cost related to automation and containerization. O&M
● Not for telco yet
● Loss of application control
● Sometimes difficult to debug and troubleshoot
● Less features
● Documentation and examples

A cautious approach to Serverless,
no geographic differences. We’ll
explore this more in TADSummit
EMEA / Americas in November.

Drachtio / Jambonz Applications and Scale
Note Yate, Isabell, and SylkServer
did not have enough responses
While Jambonz targets CPaaS,
Drachtio’s applications are seen more
broadly and similar to other TAS
(Telecom Application Server). With SIP
routers providing scale to 1M+
implementations.
29 responses

Drachtio / Jambonz: Strengths, Weaknesses, Future
• No sms stack, TTS, conferencing, nessaging etc.. and many other components that make it a complete CPaaS
• Risk: big companies with larger development budgets
• Future
• I think it’s too late to make a real impact.
• Hard to say
• Likely to be successful
Time is critical to confidence in open
source projects. They need to prove
they’ll be here for the long-run.

Drachtio / Jambonz: Client
SIP.js continues to be popular.
Compared to other projects, the
use of WebRTC shows a bias
toward more web-centric projects /
web-centric developers.

A respectable
result given the
youth of the
project and the
commitment of
Dave Horton.

Drachtio / Jambonz: Finding Consultants
Given the youth
of the project, the
web-friendly
approach helps
with this result.

Drachtio / Jambonz : Architect Deployment
year of own
infrastructure
dominating.
However, I was
expecting more
cloud deployments
with Drachtio /
Jambonz.

Ansible.

Drachtio / Jambonz Hosting
This one surprised me.
I expected to see more
Cloud hosting, while
own then hybrid are
more popular.

projects, the answer is
Ansible.

Drachtio / Jambonz: Redundancy
• VMware Vxrails
• AWS autoscale cluster for feature servers, DNS load balancing for SBC
• Multi AZ, Multi region
• ANYCAST Level
• Multi-AZ failover with alternate region replication
• Multiple active:active across AZ & geo
• DNS redundancy / SRV
• Multiple VMs

RTPEngine Applications and Scale
35 responses

RTPEngine: Strengths, Weaknesses, Future
• Stability and features
• Quality code, responsiveness of core team
• Feature rich and scalable
• Very efficient at what it does
• Integration with Kamailio, features, performance
• Better documentation with more examples
• Monitoring and performance checks could be improved.
• Ideally the system would include a turn server
• Future
• Not expecting changes
• Would like plugin architecture for tapping into media stream
• Future of Sipwise within ALE
• Strategy is not clear
• Awesome

RTPEngine: Client
When I saw the popularity of
WebRTC it got me thinking about
whether this is a shift in all
projects compared to 2019. Some
of the feedback in the final section
of the survey asked about tracking
such trends over time.

RTPEngine: Community

RTPEngine: Finding Consultants
Non-European
regions are more
likely to score 4 or 5

RTPEngine: Architect Deployment
year of own
infrastructure
dominating.

RTPEngine: Config Management / Scripting
Ansible.

RTPEngine: Hosting
Own / Hybrid
dominates

RTPEngine: Redundancy
• Multi server setup with DNS SRV and/or Failover
• Redis cluster aws elasticache
• Multiple instances via OpenSIPS.
• Load balancing from the SBC/application server
• Active / Passive deployment + Redundancy
• Kamailio
• Multiple SBC
• Cluster
• Multiple Cloud Providers

ASTPP Applications and Scale
10 responses

ASTPP: Strengths, Weaknesses, Future
• This is powerful and a user-friendly open source project which runs on FreeSwitch.
• Adapted for calling card business only
• Future
• Anyone can implement addon to meet their needs and plug it into the system.
• The strategy is not clear. Try to reach the wholesale business, but not sure about the
architecture and technical choices for this market

ASTPP: Community

ASTPP: Finding Consultants

ASTPP: Architect Deployment

ASTPP: Hosting
Our first project where
cloud provider
dominates!

• Should we include flexiWAN?
• 90% No, 10% Yes
Final Questions: flexiWAN and COVID-19 Impact

• Security
• Repeat 2019 broader survey
• More details on existing platforms
• More telco core stuff, role of OSS in IMS, 5G SA, etc.
• Ask about API-related features being used inside of Asterisk, for
example, do you use AMI? ARI? AGI? FastAGI?
• Track serverless adoption
• Can we get web developers perspectives on the OS projects?
• Make it an annual survey and track progress of projects over time
• Please let me know what else?
Final Questions: Topics we should address in 2021

Open Source Telecom Survey 2021 Results & Discussion, Alan Quayle

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Open Source Telecom Survey 2021 Results & Discussion, Alan Quayle

Similar to Open Source Telecom Survey 2021 Results & Discussion, Alan Quayle (20)

More from Alan Quayle

More from Alan Quayle (20)

Recently uploaded

Recently uploaded (20)

Open Source Telecom Survey 2021 Results & Discussion, Alan Quayle