Stasis has been a core part of Asterisk for a while now. However, state management within it is a bit precarious. A new stasis_state module has been created to help address some of the complications that arise when attempting to store, and administer state within stasis.

Stasis Cache and Topic Pool

Typically, the stasis cache stores published state information. Depending on the subsystem in use, messages published to stasis may be placed into the cache. These retained messages can then be queried by consumers. While the stasis cache does maintain state it falls short with regards to tracking that state’s lifetime.

This is even worse with regards to topic pool. In the initial implementation there was no way to remove topics once added to a pool. This has since been remedied, but the fix didn’t entirely alleviate the problem.

Also while not technically the fault of the stasis cache, or the pool, current user implementations needlessly expose stasis API’s to their own consumers. For instance, the core MWI module publishes and writes messages to the cache, but then an MWI backend like app_voicemail queries the cache directly for mailbox data while at the same time storing its own mailbox state. This complicates things, and again makes it hard if not impossible to track state lifetimes in some situations.

Stasis State

A new stasis_state module has been created to help mitigate the problems associated with the stasis_cache module and topic pooling. This new module both stores, and manages message state for stasis. It also maintains the associated topic for the state, and stores only the latest published state for that topic. It essentially combines the best of the stasis_cache with the best from the stasis topic pooling framework.

Consumers no longer have to worry about a state’s lifetime. It implicitly creates, and tracks state internally based on the number of publishers and/or subscribers to it. Using the appropriate API call consumers need only add a publisher, or subscriber to a stasis state managed topic (via the topic’s unique id). Subsequently, when consumers are no longer publishing, or they unsubscribe, and the number of publishers and/or subscribers reaches zero, then the state and associated topic are freed.

Additionally, and moving forward core components needing this functionality will hide the stasis state interface. By doing so the burden lessens for backends. This means they no longer have to deal with more than one interface. For instance, backend consumers of the MWI core, which now uses the new stasis_state API under its hood, only have to use MWI core methods for access to mailbox indication information.

Who cares?

You might be thinking “that’s interesting and all, but if it’s all hidden why do I care?” If you are a user of Asterisk it’s always good to know what has possibly changed. Even if it’s something low level that stuff “underneath” probably affects a module you use on a daily basis (for instance modules that use MWI, app_voicemail, res_pjsip_mwi etc…). As always we greatly appreciate testing and reporting of any issues.

If you are a developer you might want to create something using the new module. Or more likely if you’re using a module that itself uses the new stasis_state stuff it’s good understand how that stuff is working to avoid code duplication and such.

In any case hopefully it’s all a step in continuing to make Asterisk better.