[asterisk-dev] Adding ARI subscription type for module's notification event

Joshua C. Colp jcolp at digium.com
Wed Jan 2 16:01:35 CST 2019

On Wed, Jan 2, 2019, at 5:23 PM, Sungtae Kim wrote:
> Hi, Asterisk team,
> I'm thinking about adding the new feature for the Asterisk.
>  It's "Adding Resource item for subscription".
> Purpose:
>  Currently, the ARI subscription supports 3 types of subscriptions.
>  Channels, Bridges, Endpoints.
>  It's a good enough to see and check to what/how/where the channels is going.
> But using the ARI, it's not an easy to check the resource(module)s. 
> Simply, the ARI does not support module's notification message sending 
> and receiving.
> I would like to add the 1 more subscription type which is "Resources".
>  This feature is designed for sending/receiving the module's 
> notification messages.

I think this really encompasses a few things.

ARI was originally designed to write telephony interaction applications, not for events relating to applications and knowing what they are doing to write monitoring applications. AMI currently serves this purpose instead. That's not to say ARI couldn't do the same, but it's not something anyone has truly implemented or flushed out. This is why the subscriptions are for more low level core concepts like channels, bridges, and endpoints because those are needed for constructing telephony applications. I think before any subscribing functionality like you've mentioned could be added this would need to be discussed and done - that is extending ARI to be for more than just writing the types of applications you can now but for monitoring the applications inside of Asterisk. What applications, what the events would look like, that kind of thing. I think people would be most excited about this potentially.

>From an implementation perspective for the module subscription ARI (and the internal message bus) was also not written to know or care about where messages originate. This would need to be recorded somewhere in order to allow any kind of subscription mechanism. Ideally in a way that does not incur any extra overhead.

Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

More information about the asterisk-dev mailing list