Asterisk has been switching from the legacy chan_sip channel driver to a new SIP stack based on the PJSIP library. We have been using the new SIP stack in Wazo Platform for over a year now. The way we configure the SIP channel driver as of Wazo Platform 20.03 still relies on the API that existed for chan_sip with a translation layer in wazo-confgend to convert the chan_sip configuration to a chan_pjsip one.

The translation system we are using at the moment does not deliver all the values we could get from a properly configured chan_pjsip. Moreover, the standard format of the pjsip.conf file is hard to override without using the PJSIP Wizard.

We chose to use this change in API to make the SIP configuration as multi tenant as possible.

In this article we will look into the process of making this new API multi tenant.

Introduction​

In our pursuit of enabling companies to build their IP communication infrastructure and deliver innovative communication services with our open-source, API-centric solutions, Wazo's Class 4 engine can be easily deployed with different methods:

• Docker compose: run the platform on a single machine using the Docker images together with docker-compose.
• Kubernetes: install the platform using our Helm chart and run the platform on your Kubernetes cluster.
• Ansible-based deployment: install the platform on a set of Debian Buster machines, either bare-metal or virtual machines, using our Ansible recipes.

So, beside the fast containerized way with docker-compose or helm chart for Kubernetes, Wazo's C4 can be deployed with Ansible on virtual machines or bare-metal.

We've been tasked with integrating the Jabra headset in our Web and Desktop applications, the task may appear simple but we had some unexpected challenges imposed by Jabra.

This article is the first one of a series about the work that we do at Wazo around Asterisk application scalability. For this first post, we will describe some high level aspects of the approach we take to scale Stasis applications. We will explain which components are involved and their role. Let’s take a simple application as an example.

At Astridevcon 2018, the developer conference that happens just before Astricon every year, there was a lot of interest around the streaming of audio outside of Asterisk. During the following year, we decided to tackle that problem and see what we could come up with.

During a Hackaton in January 2019, we developed an Asterisk module that adds a way to connect to the Asterisk websocket and receive the audio from the selected channel over the websocket. The code for that module can be found here.

At Astricon 2019 we presented that module. Unfortunately, the presentations at Astricon have not been recorded. This article will get you started playing with our Asterisk module.

During 2 days, the Kamailio developers (The well-known SIP proxy) met in Dusserdolf in the wonderful places of SipgateDE.

An important subject was approached in detail: KEMI (Kamailio Embedded Interface). KEMI start with the 5th Kamailio version.

KEMI is a framework allowing to use a language other than native language to program our Kamailio engine. With KEMI, we can use Javascript, LUA, Python, LUA, Ruby and Squirrel.

Introduction​

As we started with the deployment of our C4 (Class 4) SBC and routing solution on a Kubernetes Cluster through a Helm Chart, we knew that scaling would be a core feature.

Dynamic scaling brought additional complexity in the configuration of our Kamailio components. Having a cloud-native solution meant that we had to find a way to make SBCs and routers auto-configure themselves without human intervention or static configurations, which will bound the size of our architecture.

We wanted to deploy Wazo on different kinds of platforms, not only containerized with Kubernetes but also with Docker compose or on Virtual machines using Ansible recipes. We had to choose a tool that will help us in service discovery and the flexible configuration of our components. That's where we decided that HashiCorp Consul was the right tool to use.

As a consumer of the API on Wazo Platform the first step you need to do before almost anything else is to authenticate. The process of authentication on Wazo Platform is basically creating a token using your username and password. This can be done using the /token API of wazo-auth. Here's an example from the command line.

Introduction​

As already mentioned We're focused on delivering a Cloud-Native telecom solution with all the bells and whistles in the next months. The Cloud Native Computing Foundation defines:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

In our pursuit of enabling companies to build their IP communication infrastructure and deliver innovative communication services with our open-source, API-centric solutions we could not avoid enabling our users to deploy Wazo Platform on a cloud solution as easy as possible.

We started with a deployment of our C4 (Class 4) SBC and routing solution on a Kubernetes Cluster through a Helm chart.

Hello Wazo Platform community!

As you might have known, 2 months ago the old Wazo Community forum (https://projects.wazo.community/) lost 2 years of data due to a bad upgrade and failing backups. Plus, it's been plagued by spamming bots which forced us to allow subscription on approval only... that we can't deal with since dozens of bots try to subscribe every day! Hence we chose to switch it to read-only for archiving purpose, and switch to a brand new one, modern and hosted.

Here is the new forum : https://wazo-platform.discourse.group/.

And if a forum doesn't fit you, feel free to come talk with the community on our Mattermost https://mm.wazo.community/wazo-platform.