[asterisk-dev] New Features Coming in 13.5.0

[Matthew Jordan]

Hey everyone:

As you may have noticed, yesterday the announcement for 13.5.0-rc1 was sent
out to the list. This release contains a lot of new and interesting
features that I thought would be nice if we highlighted.

== Sorcery Caching ==

For those who aren't familiar the Sorcery framework in Asterisk 13: Sorcery
acts as a Data Abstraction Layer, sitting between its consumers and all the
various types of configuration providers in Asterisk. Sorcery provides its
consumers:
* A pseudo ORM (pseudo because in C we don't really have objects, and the
configuration provider may not be relational). For a consumer's in memory
objects, Sorcery does provide a level of type safety, input validation, and
other helpful operations that typically require a lot of boilerplate code.
* Atomicity of configuration information for module operations.
* Integration with other subsystems, such as the XML documentation engine.

A consumer's in-memory objects are mapped to a configuration provider in
sorcery.conf. For example, the snippet below maps res_pjsip's endpoint
objects to a realtime backend, with optional data passed to the realtime
backend of 'ps_endpoints' - in this case, the table name:

[res_pjsip]
endpoint=realtime,ps_endpoints

Since its inception, Sorcery has had a notion of caching. For example, we
could tell Sorcery to put an in-memory cache for our previous endpoint
object using the following:

[res_pjsip]
endpoint/cache=memory
endpoint=realtime,ps_endpoints

However, this cache was pretty simplistic: once something got defined in
it, it would stick around. This, unfortunately, made it not so useful for
most scenarios.

The new Sorcery Cache that is in 13.5.0 provides full, configurable caching
support. That includes:
* Object expiration via an object lifetime
* Maximum number of objects allowed in the cache
* Object staleness, which can force an auto-refresh of an object
* Options to control when the cache is purged
* AMI/CLI commands to manipulate the cache

Note that this is configured the same way as shown previously, with a small
adjustment for which subsystem provides the cache:

[res_pjsip]
endpoint/cache=memory_cache
endpoint=realtime,ps_endpoints

Note that you aren't limited to using a cache in front of a realtime
backend; you can theoretically use a cache in front of any object managed
by Sorcery to improve performance.

More information on this feature can be found on the wiki:

https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching


== Push Configuration ==

ARI has received a new feature that allows for Sorcery managed
configuration to be pushed into Asterisk, as opposed to pulled. What does
that mean?

Typically, configuration in Asterisk works something along the following
lines:
* Some consumer realizes they need configuration information for some
operation
* The consumer asks their provider, Sorcery - in this case - for that
information
* Sorcery tries to find which backend provides that information
* Sorcery asks that backend
* Backend provides the information
* The information is translated into the right format/validated
* The consumer gets the information

The issue, of course, comes when that information isn't asked for often and
an external system updates the information in the backend. Traditionally,
Asterisk is notified of such a configuration change via a "module reload"
of the affected system.

While this works, a "module reload" is a bit of a heavy weight operation.
We have to reload everything in the module, when only a small piece of
information may have been updated. What's more, external systems now have
to perform two steps:
(1) Update the configuration
(2) Reload the module(s) in Asterisk

Push configuration flips this around. External systems now have the ability
to update the configuration directly in Asterisk via ARI, and let Asterisk
- via Sorcery - update the persistent storage itself. In this scenario,
there are no module reloads.

For example, take a PJSIP endpoint for "Alice". We can push Alice's
endpoint directly into Asterisk using the following:

curl -X PUT -H "Content-Type: application/json" -u asterisk:secret -d
'{"fields":
[ { "attribute": "allow", "value": "!all,g722,ulaw,alaw"}, {"attribute":
"context", "value": "default" }, {"attribute": "auth", "value": "alice" },
{"attribute": "aors", "value": "alice"} ] }' https:
//localhost:8088/ari/asterisk/config/dynamic/res_pjsip/endpoint/alice

While that's a lot to digest, we can take the endpoint we want to create,
represent its fields as JSON, and push it directly into Asterisk. Asterisk
- with Sorcery configured correctly - will then write that back into the
backing data storage for PJSIP endpoints - which could be anything from the
AstDB to a relational database. The next operation inside Asterisk that
asks for Alice's endpoint will get the newly pushed information.

No reloads necessary!

More information on Push Configuration can be found on the wiki:

https://wiki.asterisk.org/wiki/display/AST/ARI+Push+Configuration


== ARI Module Operations ==

While Push Configuration is nice, it is only applicable to Sorcery managed
configuration. Manipulating modules - load, reload, unload - is a very
common operation. Those operations are now supported natively in ARI as
well. As an example, to reload chan_sip you would do the following:

curl -X PUT -u asterisk:secret
https://localhost:8088/ari/asterisk/modules/chan_sip

Note that the new module operations were implemented by Benjamin Ford and
Scott Emidy, two co-op students here at Digium, as part of their final
project as co-op students. They planned the project, wrote the Swagger
specification for the new operations, survived withering code reviews,
wrote a bevy of tests to cover the new functionality, tweaked the module
API in Asterisk, and wrote the ARI commands - and did a great job.


== A Few Final New Features ==

In addition to the previously mentioned features, a few other very nice
improvements have been made. These include:
* Addition of the 'rtptimeout' option to the PJSIP stack
* New AMI events for the PJSIP stack that help to inform of lifecycle
changes in Contacts
* Support for ';line' functionality for PJSIP outbound registrations

A huge thank-you to all the contributors for new features in this release,
including George Joseph and Dmitriy Serov.


Note that as with all new features in Asterisk, these features have
automated tests in the Asterisk Test Suite. However, if something did get
missed, please make sure you file an issue and let the developer community
know.

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150728/2cc3fd7a/attachment-0001.html>