The Asterisk Rest Interface (ARI) over the last year received several enhancements that have been requested by the community:

• server side event filtering
• automatic context creation
• moving a channel between apps

Although these topics have been discussed previously, with Astricon, and the release of Asterisk 17.0.0 just around the corner I think it’s a good time to recall them once again.

Server Side Event Filtering

Historically, event filtering in an ARI application was client side only. All implicitly and explicitly subscribed events generated by Asterisk are sent to the client application. Typically the client then monitors those events reacting to only a few. This of course potentially generates a lot of unnecessary network traffic and processing. Server side event filtering to the rescue!

Now, an ARI application can specify events to filter server side. By enumerating an “allowed” or “disallowed” list clients can inform Asterisk which events to send or not send to the application. Depending on the use case, network traffic should notably improve.

Automatic Context Creation

Do you create ARI applications, and don’t want to write dialplan? If so then this feature is for you. It is essentially unsafe in most cases for ARI to operate on a channel unchecked. Control of a channel must be safely handed over to ARI first. In the past this could only be done using stated dialplan. For example:

exten => _.,1,Stasis(myApp)

At present, while explicitly specifying the Stasis dialplan application is still an option, it is no longer required. Now for registered clients, Asterisk implicitly constructs both a context based on the application name (e.g. stasis-<app name>), and extension similar to the above. Calls from endpoints that specify that context in their configuration are directly routed to the application.

Moving a Channel

It used to be that there was no way to directly move a channel from one Stasis application to another. The only available option was to continue the channel in dialplan and then direct it to enter a second stasis application. This is at best cumbersome since it involves dialplan, and awkward if arguments need to be propagated as well.

Luckily this is no longer the case. A new ARI command, move, is now available that allows the direct transfer of a channel from one stasis application to another. When issuing the command simply designate the application the channel is moving to, and then Asterisk takes care of the rest. You can even optionally specify application arguments.

Channel Router

Using both the automatic context creation and channel move functionality presents a new possibility that did not exist before: a channel router written using ARI. A PJSIP endpoint, for example, can be configured to go to an automatic context that directs the channel into a channel router ARI application. This ARI application can act much like the dialplan does today and depending on conditions direct the channel to another appropriate ARI application, and so on. If you’ve ever wanted to minimize or eliminate the dialplan this is for you!

More Info

As always, the most up to date information about ARI can be found on the wiki. Also as mentioned these topics were previously discussed here and here. Those post contain more details and examples if you’re interested. Lastly, the desire for these features was mainly community driven. Thanks for all the ideas, discussions, code reviews, and testing that went into making these features not just possible, but better.