<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 6:03 PM, Krandon <span dir="ltr"><<a href="mailto:krandon.bruse@gmail.com" target="_blank">krandon.bruse@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div>
                <div>
                    <div><span style="color:rgb(160,160,168)">On Monday, June 16, 2014 at 9:12 AM, Matthew Jordan wrote:</span></div></div><span></span><div><div><span style="font-size:14px">Hey Matt/Everyone,</span></div>
<div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">I actually really like the ideology behind this. The idea that ARI is truly a platform for which people can build complex telephony apps without having to write them in C is really neat. Also, since it's WebSockets, inherently very horizontally scalable which was somewhat of a challenge previously. I do understand some barrier to entry for people who are transitioning from AMI/AGI or even dial plan if they are "porting" an app because of functionality/apps that have to be essentially rewritten/rethought. As with any project, however, I strongly believe that more and more apps will become the "core" of several libraries for interfacing with ARI. It gives a lot of power to the individual utilizing the ARI interface.</span></div>
<div><span style="font-size:14px"><br></span></div></div></div></div></blockquote><div><br></div><div>Thanks!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div><div><div><span style="font-size:14px"></span></div><div><span style="font-size:14px">With the TALK_DETECT function, I could re-create AMD and it would actually would be way more extendable (not to mention decently fast). </span></div>
<div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">I have at least tested the scalability of concurrent calls and requests generating lots of events and have been extremely impressed so far. This may be the scalability freak in me, but is there a way I can tell the ARI not to send me events that I don't care about when first connecting to /events? For example, RTP related events. I remember seeing something about not having pub/sub for a reason. I could just discard processing the packet, but with the load we've been dealing with, even that is very expensive.</span></div>
<div><span style="font-size:14px"><br></span></div></div></div></div></blockquote><div><br></div><div>Some background, and then a few thoughts on this topic.<br><br></div><div>When we started Asterisk 12, we had two goals with the APIs:<br>
(1) Fix the presentation of the lifetime of a channel to external entities<br></div><div>(2) Provide something that lets people build their own Queue, VoiceMail, ConfBridge, and other communications applications<br><br></div>
<div>In order to do both, we needed to find a way to unify a variety of information sources in Asterisk. In prior versions of Asterisk, a lot of information that was generated was tightly coupled with the producer of that information. For example, AMI events were strings that were formed directly by the producers of the events, information about who was bridged with whom was directly produced by MeetMe, ConfBridge, and code in features.c, etc. While tightly coupling the producers/consumers is "fast" (no layers of abstraction to get in the way), it had a lot of drawbacks:<br>
</div><div>(1) Complexity in large portions of the code base and duplicated (and inconsistent) logic. Think CDRs and you'll know what i mean.<br></div><div>(2) No way to 'share' information. This was the big one: the event subsystem and AMI had a large amount of the information we would need for any API. Somehow we we had to unify that.<br>
<br></div><div>Thus was born an internal message bus - Stasis (which is where the dialplan application got its name from) - which is a pub/sub message bus internal to Asterisk that sucked up the event subsystem, AMI events, and a whole host of other stuff.<br>
<br></div><div>In Asterisk 12, everything is built on top of that message bus - CEL, CDRs, AMI, ARI, certain interesting features of attended transfers/parking, several resource modules (res_statsd), and other things.<br>
<br></div><div>As with anything, there are no free lunches: the message bus allowed us to unify state and create a consistent picture of channels, bridges, and other objects. It decoupled the logic in Asterisk, making the source *much* easier to maintain, debug, fix, and extend. On the other hand, producing events can be (but is not always) a bit more expensive than it was in previous versions. A recent patch (<a href="https://reviewboard.asterisk.org/r/3568/">https://reviewboard.asterisk.org/r/3568/</a>) went through and cleaned up some of the more inefficient production of messages, but there's more room for improvement possible.<br>
<br>One area that would be interesting to explore is what you suggested - eliminating messages entirely. Currently, if you filter events out through AMI, this is done after the Stasis message is produced, published, received, and converted into an AMI event. The savings you get from filtering these events out is relatively minor on the Asterisk side - on the consumer side, it is still nice obviously (as you don't have to parse and toss out messages you don't care about). On the other hand, if you don't care about RTCP information (for example), why produce the Stasis message at all? Allowing the elimination of certain classes of messages has the potential to cut down traffic substantially in the message bus.<br>
<br>There would, of course, be tradeoffs: for example, a branch currently in development consumes those RTCP messages and transmits the data to a Homer SIP Capture server for live call quality monitoring. Killing the producer means everyone doesn't get the message. We'd want to be very careful about what messages we allow folks to eliminate - some messages that seem 'chatty' and are possible candidates for elimination could have strange ripple effects in various core parts of the code (CDRs in particular).<br>
<br></div><div>Two other points:<br>(1) ARI does not produce the RTCP events. The events you get over ARI are more limited in scope. Since we didn't have to worry about backwards compatibility with the first version of the interface, we took the opportunity to not put in every event someone has created for AMI. I'm sure over time this will change - but right now, at any rate, the events should be much more meaningful for everyone.<br>
</div><div>(2) Today, unlike AMI, you only get events for things you are subscribed to - not the entire system. This has the benefit of reducing the processing on the consumer side, at the cost of having to understand and manage the subscription model. I think there's benefits to having a 'global pipeline' as well as the 'show me only the things in my app' - it would be a good discussion to have at AstriDevCon this year.<br>
</div><div><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div><div><div><span style="font-size:14px"></span></div>
<div><span style="font-size:14px"></span></div><div><span style="font-size:14px">Even sett</span><span style="font-size:14px">ing channel variables in Stasis, then /continue to execute a dialplan app, then stasis again, reading the resulting channel vars. I actually don't think it's that much of a "hack" and could make for a really elegant app/app infrastructure, though not quite as sexy, I mean, extendable. </span></div>
<div><span style="font-size:14px"><br></span></div></div></div></div></blockquote><div><br></div><div>That does kind of stink. There's a few other situations I've seen as well where a channel gets tossed into a Stasis app just so the external app knows to make a subscription to it.<br>
<br></div><div>Giving access to change some aspect of a channel outside of an application is a one way ticket - you can do it and be backwards compatible, but once you've granted access to a channel, you can't remove it. There are some functions that modify the state of a channel in 'special' ways, such as the SHELL function, that make me a little concerned about removing that restriction without some careful thought.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div><div><div><span style="font-size:14px"></span></div><div><span style="font-size:14px">Gone are the days of using manager to throw two people into a queue, crossing your fingers and hoping some weird masquerade a) makes it to a CDR which can be tracked and b) doesn't blow up - big props to the Asterisk dev team on that! (unrelated to ARI, but still very important for the growth and implementation of ARI - imho)</span></div>
<div><div><br></div><div><span style="font-size:14px">I'll report back results of an AMD implementation using TALK_DETECT - checking out the latest Asterisk 12 now.</span></div><div><span style="font-size:14px"><br></span></div>
</div></div></div></div></blockquote><div><br></div><div>Thanks! Looking forward to what you find out -<br><br>Matt<br></div><div> </div></div><br>-- <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>