<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 21, 2013 at 1:40 AM, Ron Arts <span dir="ltr"><<a href="mailto:ron.arts@oneip.nl" target="_blank">ron.arts@oneip.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> If you get *really* interested in playing around with things...<br>
><br>
> There are a number of frameworks that made their way into Asterisk 12 as a<br>
> result of the challenges we found ourselves facing. Two of the big ones are:<br>
> * Stasis - an internal message pub/sub message bus that conveys the state of<br>
> the most important objects throughout Asterisk<br>
> * Sorcery - a CRUD-ish data abstraction layer that lets you mask away real<br>
> time/conf file parsing/AstDB access/wherever else you want to get your data<br>
><br>
> One of the really cool things about Stasis is that - for the primary<br>
> telephony objects in Asterisk (bridges, channels, device state, etc.) - it<br>
> caches the last known state in an internal cache. Consumers can subscribe<br>
> for updates; they can also query the cache for the last known value.<br>
> Currently, all of this is internal, and the cache is rather simple - an in<br>
> memory container of the objects.<br>
><br>
> Sorcery lets you push your run-time objects out to whatever you specify (if<br>
> you have a wizard for it). It can also update objects.<br>
><br>
> Now, this is where it gets really interesting.<br>
><br>
> Technically, with a bit of effort, you could forward Stasis's primary caches<br>
> to a secondary cache that was created with Sorcery. (And no, we haven't done<br>
> this yet - partially because we didn't need to use Sorcery in Stasis, and<br>
> partially because we've been wanting to keep Stasis as fast as possible.<br>
> Forwarding things from one cache to another should be relatively fast<br>
> however) Now you can persist all of the run-time objects in whatever you<br>
> want - the AstDB - or a MySQL database. Your channel state, bridge state,<br>
> device state, etc. can all be cached in a hierarchy, going all the way out<br>
> to an external system.<br>
><br>
> Going the other direction - re-creation of state within Asterisk from an<br>
> external system - would be a monumental amount of effort. However, I suspect<br>
> that simply having Asterisk's state readily available for the perusing would<br>
> open up a lot of interesting applications for people building systems with<br>
> Asterisk.<br>
><br>
> I suspect we're going to have lots of fun things to build on top of Asterisk<br>
> 12.<br>
><br>
<br>
</div></div>So basically AMI on steroids. But I would be concerned about performance.<br></blockquote><div><br></div><div style>Possibly - one of (many) reasons why we haven't gone down this road just yet. There are some other frameworks in Asterisk 12 to alleviate this however - we now have generic threadpools that tasks can be serialized and pushed to. Stasis makes use of these threadpools - so the servicing of publications does not have to take place on the publisher thread. This helps prevent situations where publishing data impacts your real-time tasks.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If asterisk is heavily loaded internal state changes happen really<br>
often, and pushing<br>
these out will cost you even more CPU and system load. Being able to<br>
query the cache<br>
would only be interesting to re-sync state after a problem, because<br>
normally you can<br>
subscribe to changes anyway. </blockquote><div><br></div><div style>Yes, and CPU/system load is a concern even if you push publication out to a threadpool. If such a system existed, however, you could:</div><div style> * Tell Sorcery to only store items in memory. That would emulate the system currently. Alternatively, if Sorcery was only populated as a forwarded caching topic, you could just turn it off all together.</div>
<div style> * Create a configuration mechanism to assign thread priority and/or affinity to threadpools to prevent them from starving threads servicing real-time information</div><div><br></div><div style>This is all hypothetical, of course :-)</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It would be interesting to be able to subscribe<br>
to stasis externally, but that's what probably stasis-http is for?<br></blockquote><div><br></div><div style>Sort of.</div><div style><br></div><div style>Stasis-HTTP is going to get renamed to ARI (Asterisk REST Interface), as we found having multiple "Stasis" things confusing. Stasis is now (mostly) just the message bus. ARI's purpose is a bit more specialized than Stasis, although it makes heavy use of Stasis.</div>
<div style><br></div><div style>ARI exists as a mechanism to control the raw telephony objects in Asterisk from an external source. When a channel enters into an application that hands control of the channel over to ARI, that channel is owned by the external source. The source can manipulate media, create bridges, create new channels, etc. The best way to describe ARI is it allows you to write your own applications for Asterisk - rather than relying on VoiceMail, or Queue, or large monolithic C apps - you can own the channels and bridges and devices and whatnot and write your own in your language of choice.</div>
<div style><br></div><div style>This may sound something like AGI - where ARI differs are in a few key aspects:</div><div style> * Where AGI acted in the context of a single channel, with ARI you implicitly aggregate multiple channels together into application groups. Manipulating multiple channels with AGI was always a bit tricky and usually required integration with AMI.</div>
<div style> * With ARI, you can create bridges, channels, and other objects directly in the context of a specific ARI application. You don't have to Originate a channel to the dialplan, redirect them into another AGI, then combine them somehow with a channel already in an AGI if you need a new channel in your ARI application.</div>
<div style> * You own more than just the channel. Owning the bridges means that you can bridge channels, remove channels from bridges, combine bridges, etc. all without involving the dialplan or going back to the dialplan.</div>
<div style> * ARI is asynchronous. Operations can be queued up, stopped, etc. When an operation isn't in effect, the channel just waits for the next one to come in. This includes media manipulation.</div><div style> <br>
</div><div style>So, ARI is an interface that uses Stasis and exposes some of Stasis. It doesn't expose all of it.</div><div style><br></div><div style>You could theoretically build all sorts of things on Stasis - in fact, David Lee wrote a statsd server integration module as a proof of concept. There's a brief description of interacting with the message bus on the wiki at <a href="https://wiki.asterisk.org/wiki/display/AST/Using+the+Stasis+Message+Bus">https://wiki.asterisk.org/wiki/display/AST/Using+the+Stasis+Message+Bus</a></div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
By the way, this may be after the fact, but is there a specific reason<br>
for choosing<br>
long-poll http over other message queue protocols like zeromq, or mqtt?<br></blockquote><div><br></div><div style>ARI uses WebSockets to send events.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm sorry if I'm rambling or keeping you from more useful work...<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div style>Not at all! We're excited about the work that's going on in 12 - keep the questions coming! </div></div><div><br></div>
-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</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>