The post Welcome New, and Returning, Asterisk Users! appeared first on Asterisk.

Taskpool: A Hunch Turned Performance Improvement

I’m happy to say that PJSIP has now been moved over to the same API! This was a journey that involved multiple revisions and attempts, but as of the latest releases (20.18.0, 22.8.0, 23.2.0) it has shipped. Let’s talk about the two aspects that made it complex.

Taskpool Execution In Taskpool

Almost everything in PJSIP executes within a taskprocessor. This means that there are cases where the code will queue a task on a taskprocessor from within a taskprocessor – sometimes synchronously. With the prior threadpool implementation this was perfectly acceptable as a new thread could be created if none were available and things would go on. With taskpool this is not the case. It may not be configured to allow unbound growth of threads. As a result taskpool had to be made more intelligent about where tasks execute in this scenario, such as allowing them to be executed within the current thread. This was done for PJSIP but is available to all taskpool API users, and happens transparently without knowledge of the API user.

Pausing A Taskprocessor

In certain scenarios in Asterisk we have a process called masquerade that essentially replaces the contents of one channel with that of another. It’s commonly involved in certain transfer scenarios or AMI Redirect cases. To accomplish this PJSIP has to pause the taskprocessor handling the SIP dialog and SIP session so that no further actions occur on it, and it is free to manipulate the channel in a more substantial manner. With threadpool since new threads could be created if none were available the easiest way to do so was to just block the thread until told to unpause. With taskpool blocking a task like that is not allowed as another thread may not be available to handle things, blocking everything. Taskpool takes a different approach and instead doesn’t block the thread but stops handling any tasks queued to the taskprocessor handling the SIP dialog and SIP session. Essentially there is no longer a thread handling the taskprocessor. After the taskprocessor is unpaused it is given back to the taskpool and a thread resumes handling the tasks. This ensures no thread is blocked waiting for a taskprocessor to be unpaused.

The Impact

Just like stasis from a user perspective only the configuration options changed and defaults were updated to better reflect the actual requirements of most users so few people will need to touch it – just upgrading your Asterisk will gain you this improvement. On my system the impact to CPU usage is about a 5-10% reduction. It’s not as much as stasis, but every bit helps!

The post Taskpool + PJSIP Has Landed! appeared first on Asterisk.

Threadpool

The threadpool API provides common methods for a configurable pool of threads that can be used to do work. It’s arbitrary what the work is allowing it to be used in different ways. The two heaviest users of it have been PJSIP and Stasis for their threading models, heavily focusing on dispatching work to be done in an asynchronous manner. The threadpool is convenient for this because it can be configured to have a fixed number of threads or to grow and shrink as needed.

Based on trends I’ve seen for awhile (such as posts and comments about the stasis/pool and stasis/pool-control taskprocessors) I had a hunch that the cost of using the threadpool API was high. After looking at the implementation I became more convinced of this. The threadpool API has a single queue of work for all tasks and uses a second separate management queue to manage the pool itself. Each pushing of a task to the threadpool results in 2 tasks being queued, instead of one. The actual task to be worked and a task to manage the threadpool (grow it, wake up a waiting thread). If the threadpool can’t respond fast enough to tasks being added or there is a fixed number of threads allowed then the single queue of work can grow and grow. This is what causes the stasis/pool taskprocessor messages that some people have seen.

This led me to writing some efficiency tests to see how much work the threadpool implementation can do. In the efficiency tests the work is minimal which helps isolate the results to just the time spent in the threadpool implementation.  There are two tests with the first one being the pushing of a large number of tasks that then get executed by threadpool threads. The second test uses multiple serializers which then also get executed by threadpool threads. These tests both execute for 30 seconds with 50 threads and aim to essentially flood the threadpool with as much use as possible over that time.

Running the efficiency tests gave the following results on my development system:

Threadpool Push: 22,809,319 tasks executed (760,310 per second)

Threadpool Serializer Push: 16,590,999 tasks executed (553,033 per second)

As you can see the serializer usage incurs an approximate 27% penalty on my system.

These results and usage allowed me to better understand the activity in the threadpool. I came to the conclusion that the threadpool API is really good for medium to long running tasks, but is inefficient for short to medium duration tasks. The overhead of managing the threadpool itself just isn’t worth it.

Taskpool

I decided to come up with an API specifically focused on short to medium duration tasks, taking into account all I had learned from threadpool as well as usage of tasks in general. This new API is called taskpool.

Taskpool is effectively a pool of taskprocessors that can be used to execute tasks but shares the configurability of the threadpool API. It can have a fixed number of taskprocessors or it can grow and shrink as needed. A substantial difference to threadpool is that there is no single queue of work. Instead when a task is pushed it is immediately allocated to a specific taskprocessor and queued directly on it. There is also no separate management queue that manages the taskpool. If the taskpool needs to grow it is done when pushing a task. If it needs to shrink this is done asynchronously in the background using a periodic scheduled item.

You might immediately think “but taskprocessors have issues!”. I want to set the record straight. Taskprocessors themselves are actually pretty efficient. The users of the taskprocessor API are really the fundamental cause of taskprocessor issues. If they are slow or don’t use taskprocessors efficiently, then a symptom is taskprocessor issues.

As part of implementing taskpool I wrote efficiency tests that are equivalent to the threadpool efficiency tests to give a comparison. Running these tests on my development system yielded the following results:

Taskpool Push: 61,255,016 tasks executed (2,041,833 per second) – 2.69x more tasks executed than threadpool

Taskpool Serializer Push: 48,997,697 tasks executed (1,633,256 per second) – 2.95x more tasks executed than threadpool

For taskpool the serializer usage penalty is actually less, approximately 20%.

These results were just from my system and having others run them for comparison has shown cases of even better results – as high as 20x. It’s very dependent on the system itself and CPU but no matter what it is an improvement for everyone. This is a great demonstration of how the usage of taskprocessors can make a huge difference in performance. Throughout all of this no changes have been made to taskprocessors themselves. I explored doing so but did not find any changes that would improve them.

So Where Is Taskpool Being Used Right Now?

The current major user of taskpool is stasis for message dispatching as of Asterisk 20.17.0, 22.7.0, and 23.1.0. It has been changed over internally to use taskpool with the only user facing change being the configuration changing to taskpool (with threadpool options still being supported). For power users who have examined “core show taskprocessors” this has also changed for stasis with the pool and pool-control taskprocessors being removed and replaced with stasis taskpool ones.

Early reports have shown that this has improved CPU usage a noticeable amount (anywhere from 20-30% less CPU usage) and solved performance issues for people which is great to hear. If you’re interested in using it all you have to do is update to one of the versions listed above or newer. There’s nothing else to do.

The post Taskpool: A Hunch Turned Performance Improvement appeared first on Asterisk.

To make the module available you need to select it in “make menuselect” under the “Resource Modules” category, far at the bottom under “External”.

Once selected the module will be downloaded and installed as part of the installation process, just like can be done for the DPMA module. You still need to configure the module, however, with the specific details. You can find documentation on this on the Sangoma Knowledge Base wiki article.

Something important to note is this module only supports PJSIP. The old chan_sip module is not supported.

I did a quick webinar about the trunking module:

You can view it here.

The post Sangoma Trunking Module appeared first on Asterisk.

Two versions of Asterisk have now transitioned to new support status, check them out below!

Asterisk 18 Has Reached End of Life

Asterisk 18 was a Long Term Supported (LTS) release that is now officially End of Life (EOL). This means it will no longer receive updates of any kind, including security patches or bug fixes. If you’re still running Asterisk 18, it’s time to plan your upgrade to a supported version to ensure your system remains secure and functional.

Please consider reviewing the details on what’s new and what’s changed between major versions since 18:

• Asterisk 19.0.0 UPGRADE.txt
• Asterisk 20.0.0 UPGRADE.txt
• Asterisk 21.0.0 ChangeLog
• Asterisk 22.0.0 ChangeLog
• Asterisk 23.0.0 ChangeLog

Of particular note is the removal of chan_sip in Asterisk 21 — and, therefore, all later versions like 22 and 23 — in favor of chan_pjsip. Check your dial plan e.g. extensions.conf file for lines containing:

  Dial(SIP/...)

Because if you find them, then there’s going to be more work to do in Asterisk 22, as you convert to:

  Dial(PJSIP/...)

…and make additional necessary changes in other configuration related to PJSIP.

Asterisk 21 Enters Security Fix Only Status

Asterisk 21 is a standard release that has transitioned to Security Fix Only (SFO) status. While it will continue to receive critical security patches for one more year (until October 2026), no new features or non-security updates will be released.

Stay Supported, Stay Secure

We strongly encourage all users to upgrade to a currently supported version of Asterisk. Staying up to date ensures you benefit from the latest features, performance enhancements, and — most importantly — security protections.

To help you plan your upgrade, check out the related documentation and the official Asterisk Versions page which includes detailed support timelines and lifecycle information.

Let’s keep your toolkit for telephony applications robust and secure — upgrade today!

The post Asterisk 18 Now End of Life, Asterisk 21 Security Fix Only appeared first on Asterisk.

As you may have seen from email, forum, and social media publications we will indeed be having an AstriCon 2026 event on March 5th and 6th of next year. New this year is we will be having it as part of the SCALE event. This is a large open source event with tons of additional content and other events. Even if you have a colleague or employee that is not focused on Asterisk, you may find other content that is right up their alley to enjoy! If you’d like to speak please apply through our call for speakers form. Even if you think what you have to say isn’t interesting enough, submit anyway! We’ll gladly consider it.

Thanks!

The post AstriCon 2026 Is Happening! appeared first on Asterisk.

Users of Asterisk’s ARI interface are no strangers to using WebSockets to receive call processing events. Additionally, there have been recent enhancements that allow ARI application developers to use the same WebSocket they receive events on to make REST calls. This can eliminate the need to use HTTP for making call control requests. We’ve now taken WebSocket capabilities one step further by allowing media to be exchanged via WebSockets as well using a new channel module “chan_websocket”.

Features of chan_websocket:

• The channel driver is codec agnostic for the most part. The most popular codecs are fully supported. This means that you won’t have to do any transcoding between Asterisk and your AI engine.
• Secure connections are supported.
• You can send bulk data to Asterisk, like a file or a response from an AI agent, and the channel driver will take care of breaking that audio up into appropriately sized frames.
• Along with breaking the audio up into correctly sized frames, the channel driver will also time them appropriately so you don’t have to do it yourself. Additionally, the channel driver will automatically insert silence to maintain the timing if your app doesn’t send any audio.
• There’s a control path available on the websocket that allows you to issue commands like “ANSWER”, “HANGUP” and “PAUSE_MEDIA”.
• You can receive media related events over the control path like being told that a large chunk of audio you sent to Asterisk has been fully played to a caller.
• The channel driver can accept incoming websocket connections from your app as well as make outgoing connections to your app. This can help overcome NAT issued and can enable better failover opportunities.
• Although the driver is targeted at ARI ExternalMedia users, it’s not tied to ARI and can be used directly from the Dial dialplan app.

More info:

Full information is available on the Asterisk Documentation website and there are code samples in the GitHub asterisk/asterisk-websocket-examples repository.

Availability:

The new channel driver is currently available in the master, 20, 21, 22 and 23 branches on GitHub and is included in the latest 20.16.0-rc1, 21.11.0-rc1 22.6.0-rc1 and 23.0.0-rc1 release candidates.

The post Exchanging media between Asterisk and apps has just gotten easier! appeared first on Asterisk.

The post AstriDevCon July 2025 appeared first on Asterisk.

So how does it work?  The AsteriskVoiceBridge is an ARI application written in Go that connects Asterisk, Deepgram and OpenAI to create a real time voice application.  The basic structure of the application looks like this:

When a call is placed into stasis, the ARI controller builds the following call structure within Asterisk:

Once the above call structure is built, the Voice Business Logic Controller then sends a GET message to a local http server to retrieve a json configuration file that provides instructions and tools for the AI service that determines how to set up the parameters for the session.

The AsteriskVoiceBridge then takes the RTP stream from Asterisk, converts it into audio segments and then sends those segments to Deepgram to perform Speech to Text on the incoming call.  That text is then sent to an AI Agent created using OpenAI.  As the AI Agent responds, the text of those responses is sent to Deepgram for Text to Speech conversion, which is then sent back to Asterisk as RTP.

Once the AI Agent determines which tool best matches the caller’s intent, it will send that choice to the Voice Business Logic Controller (VBLC).  The VBLC will then ‘use’ that tool by issuing a subsequent GET to the local http server that matches the chosen tool to retrieve either a new set of instructions and tools for the AI and/or local commands to execute via the ARI controller.

The AsteriskVoiceBridge includes an example demo IVR that lets the user choose between support, sales and accounts, then transfers the call to the corresponding destination in dialplan.

Our hope is that this demonstrates a model for how to build a voice service using Asterisk, but please note that the AsteriskVoiceBridge is intended for educational purposes only and should not be used as the basis for any production service.

The post Asterisk Voicebridge appeared first on Asterisk.

In this post we will show how to set up the services call structure using node-ari-client.

First we create the client:

let ari = await client.connect(
ariServerUrl, ariUser, ariPassword);

This client is routed to via the Stasis dialplan:

[ext_med_service]
exten => 411,1,noOp()
same => n,Answer()
same => n,Stasis(ari-snooper)
same => n,Hangup()

Once we receive a StasisStart event, check to make sure that this is a call coming in from the expected dialplan (this is to prevent the snoop and external media channels from triggering recursive events when they enter Stasis):

ari.on("StasisStart", async (event, chan) => {
    let dialed = chan.dialplan.exten.concat("-", chan.dialplan.context);
    if (dialed != "411-ext_med_service") {
        /* Only start a new call for callers into our app. */
        return;
    }

Create the service bridge:

    let serviceBridge = ari.Bridge();
    try {
        await serviceBridge.create({type: "mixing"});
    } catch(error) {
        console.error(error); /* also hangup channels */
    }

Create the snoop channel and add it to the service bridge:

    let snoopChannel;
    try {
        chan.snoopChannel({
            spy: "in",
            app: "ari-snooper",}, (snerr, snchan) => {
                if (snerr) {
                    console.error(snerr);
                } else {
                    snoopChannel = snchan;
                        try {
                                serviceBridge.addChannel({channel: snchan.id});
                            } catch (error) {
                                console.error(error);
                            }
                }
        });
    } catch (error) {
        console.error(error); /* also hangup channels */
    }

Last we create the external media channel and it to the service bridge:

    let externalChannel = ari.Channel();
    externalChannel.on('StasisStart', (event, echan) => {
        serviceBridge.addChannel({channel: echan.id});
        });
    try {
        let resp = await externalChannel.externalMedia({
                app: "ari-snooper",
                external_host: "127.0.0.1:9595",
                format: "ulaw"
            });
    } catch(error) {
        console.error(error);
    }
}

With this structure, Asterisk will send all incoming audio on the original channel to 127.0.0.1:9595 as a raw ulaw stream.  Your application listening on this IP and port would record that stream to analyze or otherwise proxy off to an external service.

So far the external media and snoop channels are in a bridge, but the original caller is not.  This is so that the original caller can be placed into another bridge, conference or application independent of the attached service.  For example, if we want to add the caller to a ‘call’ bridge with other extensions:

let callBridge = ari.Bridge();
try {
    await callBridge.create({type: "mixing"});
} catch(error) {
    console.error(error);
}
callBridge.addChannel({channel: chan.id});

From there you would add your other channels to the call bridge as you would typically.

A note about this call structure, if you want the service to be able to respond by sending audio back from the external media channel over the service bridge to the user channel via whisper on the snoop channel, there needs to be an audio source already feeding the user channel to whisper into.  This means the user channel has to be bridged with another channel that is generating audio or be in playback (presumably silence.)

Hopefully this gives you a head start on making your own services application using ARI!

The post ARI snooping, an example in JavaScript appeared first on Asterisk.