My Profile Photo

Joshua Colp


#VoIP enthusiast, #FibreOP evangelist, #Fintech newbie, #VideoStreaming experimenter


REST? Who needs a REST ... interface?

Asterisk has traditionally provided primitive operations using a C based API approach. There has also been the Asterisk Manager Interface and Asterisk Gateway Interface but they do not provide the control that the C interfaces provide. The new REST API (ARI) is an extension of the C interfaces available to allow access to these lower level primitives.

Primitives are core operations which generally perform a specific operation. An example is adding a channel to a bridge, or calling a device. By using these primitives using your specific logic you can implement an application.

Exposing these primitives using REST opens Asterisk to a vast new pool of developers which can ultimately use a language of their choice. Would you like to use Node.js to write a queue application? Or a new voicemail application in python? ARI makes this possible.

What sort of primitives does ARI provide?

  • Channel recording
  • Channel playback
  • Channel origination
  • Channel music on hold
  • Channel ringback
  • Channel hangup (with reason)
  • Channel answering
  • Channel muting
  • Channel holding
  • Channel events
  • Channel variable manipulation
  • DTMF
  • Bridge manipulation (create, add channel, remove channel, destroy)
  • Bridge recording
  • Bridge playback
  • Bridge events
  • Sounds inspection

These primitives will change and expand as developers find new things that need to exist.

So, let’s talk documentation

All operations within ARI are required to be documented in JSON files using Swagger. The documentation itself produces part of the code within Asterisk and without it the operation will not exist. The produced code also includes validation for responses which ensures that responses to operations are also documented.

What languages are supported?

REST itself does not provide an SDK for various languages. Thankfully using the documentation JSON it is possible to automatically generate SDKs, or ones can be written manually.

What can be made?

This is really up to the users of ARI. Using the operations provided you can do a lot of cool stuff and if things are missing that would be beneficial/make sense they can be added.

What isn’t ARI?

Right now ARI is not a third party call control, monitoring, or application manipulation API. It’s for writing first class applications outside of Asterisk, such as app_queue or app_voicemail. It is not a replacement for AMI or AGI.

How can I get involved?

The asterisk-app-dev mailing list is a great place to discuss ARI and to help shape how it looks as an API. If you want to actually use ARI there is a helpful wiki page here that covers getting started with it.

Cheers,