<div dir="ltr"><div><div>Hey everyone:<br><br></div>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.<br><br></div><div>== Sorcery Caching ==<br><br></div><div>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:<br></div><div>* 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.<br></div><div>* Atomicity of configuration information for module operations.<br></div><div>* Integration with other subsystems, such as the XML documentation engine.<br><br></div><div>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:<br><br></div><div>[res_pjsip]<br></div><div>endpoint=realtime,ps_endpoints<br></div><div><br></div><div>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:<br><br></div><div>[res_pjsip]<br></div><div>endpoint/cache=memory<br></div><div>endpoint=realtime,ps_endpoints<br></div><div><br></div><div>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.<br><br></div><div>The new Sorcery Cache that is in 13.5.0 provides full, configurable caching support. That includes:<br></div><div>* Object expiration via an object lifetime<br></div><div>* Maximum number of objects allowed in the cache<br></div><div>* Object staleness, which can force an auto-refresh of an object<br></div><div>* Options to control when the cache is purged<br></div><div>* AMI/CLI commands to manipulate the cache<br><br></div><div>Note that this is configured the same way as shown previously, with a small adjustment for which subsystem provides the cache:<br><br></div><div>[res_pjsip]<br></div><div>endpoint/cache=memory_cache<br></div><div>endpoint=realtime,ps_endpoints<br></div><div><br></div><div>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.<br></div><div><br></div><div>More information on this feature can be found on the wiki:<br><br><a href="https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching">https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching</a><br><br></div><div><br></div><div>== Push Configuration ==<br><br></div><div>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?<br><br></div><div>Typically, configuration in Asterisk works something along the following lines:<br></div><div>* Some consumer realizes they need configuration information for some operation<br></div><div>* The consumer asks their provider, Sorcery - in this case - for that information<br></div><div>* Sorcery tries to find which backend provides that information<br></div><div>* Sorcery asks that backend<br></div><div>* Backend provides the information<br></div><div>* The information is translated into the right format/validated<br></div><div>* The consumer gets the information<br><br></div><div>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.<br><br></div><div>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:<br></div><div>(1) Update the configuration<br></div><div>(2) Reload the module(s) in Asterisk<br><br></div><div>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.<br><br></div><div>For example, take a PJSIP endpoint for "Alice". We can push Alice's endpoint directly into Asterisk using the following:<br><br><code class="java plain">curl -X PUT -H </code><code class="java string">"Content-Type: application/json"</code> <code class="java plain">-u asterisk:secret -d </code><code class="java string">'{"fields":
 [ { "attribute": 
"allow", "value": "!all,g722,ulaw,alaw"}, {"attribute": "context", "value": 
"default" }, {"attribute": "auth", "value": "alice" }, {"attribute": 
"aors", "value": "alice"} ] }'</code> <code class="java plain">https:</code><code class="java comments">//localhost:8088/ari/asterisk/config/dynamic/res_pjsip/endpoint/alice</code><div class="line number2 index1 alt1"> </div>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.<br><br></div><div>No reloads necessary!<br><br></div><div>More information on Push Configuration can be found on the wiki:<br><br><a href="https://wiki.asterisk.org/wiki/display/AST/ARI+Push+Configuration">https://wiki.asterisk.org/wiki/display/AST/ARI+Push+Configuration</a><br></div><div><br><br></div><div>== ARI Module Operations ==<br><br></div><div>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:<br><br></div><div><span style="font-family:monospace,monospace">curl -X PUT -u asterisk:secret <a href="https://localhost:8088/ari/asterisk/modules/chan_sip">https://localhost:8088/ari/asterisk/modules/chan_sip</a><br></span></div><div><br></div><div>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.<br></div><div><br><br></div><div>== A Few Final New Features ==<br><br></div><div>In addition to the previously mentioned features, a few other very nice improvements have been made. These include:<br></div><div>* Addition of the 'rtptimeout' option to the PJSIP stack<br></div><div>* New AMI events for the PJSIP stack that help to inform of lifecycle changes in Contacts<br></div><div>* Support for ';line' functionality for PJSIP outbound registrations<br></div><div><br></div><div>A huge thank-you to all the contributors for new features in this release, including George Joseph and Dmitriy Serov.<br><br></div><div><br>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.<br><br></div>Thanks!<br clear="all"><div><div><div><div><br></div><div>Matt<br><br></div><div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</div></div></div></div></div>