<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 20, 2013 at 5:20 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Ron Arts wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So how would I set that res_sip used my sorcery module 'fuzzbox'?<br>
Like this?<br>
</blockquote>
<br></div>
To delegate "endpoint" types to fuzzbox:<br>
<br>
[res_sip]<br>
endpoint=fuzzbox<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And would I need to issue a reload command, or would it work on a<br>
'dynamic realtime' basis,<br>
and it would have some 'check and refetch if changed' mechanism?<br>
</blockquote>
<br></div>
It queries the configured wizards, it's up to them to do whatever. If you are caching then it will query the cache first. If you need immediate changes then you have to make your own caching wizard or cache within your module and invalidate when it's out of date.<div class="HOEnZb">
<div class="h5"><br></div></div></blockquote><div><br></div><div style>If you get *really* interested in playing around with things...</div><div><br></div><div style>There are a number of frameworks that made their way into Asterisk 12 as a result of the challenges we found ourselves facing. Two of the big ones are:</div>
<div style>* Stasis - an internal message pub/sub message bus that conveys the state of the most important objects throughout Asterisk</div><div style>* Sorcery - a CRUD-ish data abstraction layer that lets you mask away real time/conf file parsing/AstDB access/wherever else you want to get your data</div>
<div style><br></div><div style>One of the really cool things about Stasis is that - for the primary telephony objects in Asterisk (bridges, channels, device state, etc.) - it caches the last known state in an internal cache. Consumers can subscribe for updates; they can also query the cache for the last known value. Currently, all of this is internal, and the cache is rather simple - an in memory container of the objects.</div>
<div style><br></div><div style>Sorcery lets you push your run-time objects out to whatever you specify (if you have a wizard for it). It can also update objects.</div><div style><br></div><div style>Now, this is where it gets really interesting.</div>
<div style><br></div><div style>Technically, with a bit of effort, you could forward Stasis's primary caches to a secondary cache that was created with Sorcery. (And no, we haven't done this yet - partially because we didn't need to use Sorcery in Stasis, and partially because we've been wanting to keep Stasis as fast as possible. Forwarding things from one cache to another should be relatively fast however) Now you can persist all of the run-time objects in whatever you want - the AstDB - or a MySQL database. Your channel state, bridge state, device state, etc. can all be cached in a hierarchy, going all the way out to an external system.</div>
<div style><br></div><div style>Going the other direction - re-creation of state within Asterisk from an external system - would be a monumental amount of effort. However, I suspect that simply having Asterisk's state readily available for the perusing would open up a lot of interesting applications for people building systems with Asterisk.</div>
<div style><br></div><div style>I suspect we're going to have lots of fun things to build on top of Asterisk 12.</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>