While the Asterisk External Application Protocol was touched on in a previous post, with regards to a specific use case, here we’ll introduce a few more details about an underlying framework being developed for Asterisk 19 to support such a use case, as well as future scenarios.

What is it?

The Asterisk External Application Protocol (AEAP) is really two things depending on your perspective. From an Asterisk developer perspective it’s both an API, and protocol that is used to connect and communicate with an application external to Asterisk. From an external application developer perspective, it’s a custom protocol that’s used to negotiate and interact with an Asterisk subsystem (e.g. Speech-to-Text).

At the core of both perspectives is the protocol. In this context, a protocol is simply any predefined terminology, or set of instructions that’s used to facilitate the exchange of data between client and server. It’s possible for the protocol to be unique for each subsystem, but of course it’s in everyone’s best interest to create a common one that can be used across subsystems. So we’ll be doing our best to strive for commonality, and minimize protocol customization.

Where is this protocol you say? It’s currently a “work in progress”. However, a first cut of the protocol for the Text-to-Speech, and Speech-to-Text use cases can be found here. Again, please do take into consideration the protocol definition is under development, and will likely change.

AEAP Framework

For those working the Asterisk side of things a framework is being developed in order to make it easier to read, write, and parse external protocol communications. The goal of the AEAP framework is to handle most, if not all, of the connecting, sending and receiving, serial and deserialization of messages, and triggering of message events to and from an external application. In doing so, hopefully a developer implementing a sub-module will then only have to focus on sub-module specific protocol interactions.

To start, the framework will only have limited support for its messaging (JSON only) and transport (Websocket only) mechanisms. However, the framework is meant to be extensible in a way to ease additions of future functionality. So hopefully it’ll be non difficult to add other capabilities later.

Using the AEAP Framework

So how will it work? Sub-module implementers will be able to create an “aeap” object configuring it with the type of transport to use. The transport is the base communication layer. Again, to start only the websocket (‘ws’) transport type will be supported. As well, and only in client mode. Thus, initially AEAP will be client only with the external application acting as the server.

Once created, both request and response handlers can be registered by name with the “aeap” object. Upon receiving a named request or response from the external application the associated handler is triggered. Implementers will also be able to register data objects to be passed to handlers along with the received message. To start, only JSON based message types will be supported.

Using the same “aeap” object, messages will be able to be sent to an external application. Upon sending it’ll even be possible to tell “aeap” to wait for a response to the sent message, and/or configure a timeout (i.e. a timeout handler is raised if a response is not received within a certain amount of time). Thus, enabling a type of transactional process if you will.

In Summary

That’s the basics of the soon to be established Asterisk External Application Protocol (AEAP). Again please keep in mind this is still a work in progress (both protocol and framework), and we’ll be sure to keep you apprised as things develop. As always please keep an eye on the wiki for the most current and up to date information.