<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 7:42 AM, Ben Merrills <span dir="ltr"><<a href="mailto:b.merrills@mersontech.co.uk" target="_blank">b.merrills@mersontech.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We had a similar discussion a while back about executing dialplan applications from within ARI. Please see: <a href="http://lists.digium.com/pipermail/asterisk-app-dev/2014-February/000367.html" target="_blank">http://lists.digium.com/pipermail/asterisk-app-dev/2014-February/000367.html</a><br>

<br>
Although this doesn't provide you with an answer, it may help you to understand the current thinking of the asterisk/ari development team<br>
<span class="HOEnZb"><font color="#888888"></font></span><br clear="all"></blockquote></div><br></div><div class="gmail_extra">I'm going to chime in again on this topic, because I do think that this is one of the hardest points to grasp with the new interface.<br>
<br></div><div class="gmail_extra">To begin, it's important to understand how dialplan execution works within Asterisk. When a channel is executing dialplan, a dedicated thread - the pbx_thread - "owns" the channel. It is responsible for a variety of things: understanding the location of the channel in the dialplan stack, servicing frames from the channel in a timely fashion, running each application, and more. The pbx_thread is the thread that services the channel.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">With AGI, you are performing remote execution of dialplan. Hence, executing any dialplan application from your AGI is completely within the scope of that interface. The pbx_thread is still the owner in this case - it just happens to be waiting for your command from the AGI. When it gets said command, it goes off and executes the dialplan just as if it were walking through statements in extensions.conf. There's a key point here however - while it is off executing dialplan, your AGI can't do anything with the channel. It doesn't own the channel - it merely gets to instruct the pbx_thread what to go do. If, for example, you sent said channel off into VoiceMail and then decided you wanted instead to Playback howler monkeys to the channel, you couldn't do that: the pbx_thread is off on its mission, and can't be interrupted.<br>
<br></div><div class="gmail_extra">With AMI, you don't really own channels - nor can you do much with them. There's really only two operations that affect the state of a channel - Redirect and Bridge. In the case of Redirect, you are "simply" moving a channel to a new location in the dialplan. Again, a pbx_thread still owns the channel - even when this occurs. With Bridge, you are doing something a bit more creative: both channels are stolen from their pbx_thread and shoved into a bridge. Now, of course, there is a slight problem - what happens when those channels leave the bridge? Unless AMI uses redirect on the channels from the bridge it created for them, there's no place for them to go - the threads that serviced them are long gone, and they don't have anywhere to return. They get hung up.<br>
<br></div><div class="gmail_extra">Contrasting both of these interfaces with ARI, there's two key differences:<br>(1) In AGI and AMI, you are constrained by the dialplan. This is not a terrible thing - dialplan is, after all, very powerful. But dialplan applications are an abstraction over Asterisk's core resources, and often they don't expose exactly what you want to do - or you have to do some strange machinations to get them to do what you want.<br>
</div><div class="gmail_extra">(2) AGI (in particular) and AMI (to a lesser extent) are channel based. While channels are still the most powerful construct in Asterisk, there are other resources - such as bridges and endpoints - that can also be manipulated - and typically are by dialplan applications.<br>
</div><div class="gmail_extra"><br>ARI seeks an alternative path: get the channel out of the dialplan and hand it over to something external. Because we remove the dialplan from the equation, we can let something external asynchronously control the channel as well as bridges, endpoints, and other things.<br>
<br></div><div class="gmail_extra">As an example, take the Bridge AMI action and an equivalent operation in ARI.<br><br>When you execute Bridge in AMI in Asterisk 12, the following is what actually occurs:<br></div><div class="gmail_extra">
(1) Create a new bridge.<br></div><div class="gmail_extra">(2) Find the first channel. If the channel is in a bridge, perform a bridge move operation. If the channel is not in a bridge, panic and do the following:<br></div>
<div class="gmail_extra">(2a) Issue an ast_channel_yank on the channel. This will (carefully) perform a masquerade: a new channel is created, the private data structure is taken from the existing channel and moved to the new channel, and the existing channel is hung up in a silent fashion. This is done to 'steal' the channel from the running pbx_thread.<br>
</div><div class="gmail_extra">(2b) Take the new channel - which we now own - and perform an ast_bridge_impart into the newly created bridge.<br></div><div class="gmail_extra">(3) Find the second channel. If the channel is in a bridge, perform a bridge move operation. If the channel is not in a bridge, panic again and do the following:<br>
</div><div class="gmail_extra">(3a) Issue an ast_channel_yank on the second channel. This will (again carefully) perform the dreaded masquerade: create a new channel, move the private data structure over, hang up the existing channel silently, and 'steal' the channel from the running pbx_thread.<br>
</div><div class="gmail_extra">(3b) Take the new channel - which again we now own - and perform an ast_bridge_impart into the newly created bridge.<br></div><div class="gmail_extra">(4) Return success<br><br></div><div class="gmail_extra">
Consider, instead, adding two channels to a bridge in ARI:<br></div><div class="gmail_extra">(1) Make the bridge. This directly maps to ast_bridge_create.<br></div><div class="gmail_extra">(2) Add the first channel. Since ARI owns the channel, there is no need to yank it from something else. Call ast_bridge_impart.<br>
</div><div class="gmail_extra">(3) Add the second channel. Since ARI owns the channel, again, there is no need to yank it from somewhere else or perturb an existing thread. Call ast_bridge_impart.<br></div><div class="gmail_extra">
(4) Rejoice in the lack of insanity.<br><br></div><div class="gmail_extra">If, on the other hand, ARI allowed a channel to be 'owned' by a dialplan application, we could not make the assumptions in steps 2 and 3 that ARI 'owns' the channel. We'd have to go through some severe machinations to get ownership again. And this is a relatively trivial case: manipulating media, for example, on a channel in a dialplan application has a lot of strange corner cases that could be extremely volatile.<br>
<br></div><div class="gmail_extra">Hence, the goal for ARI is not to turn it into dialplan execution. Instead, we want to find a way to enable use cases currently met by dialplan applications - typically in a fashion that provides information asynchronously to ARI applications. Hence, the TALK_DETECT function as a way to enable WaitForSilence/WaitForNoise.<br>
<br></div><div class="gmail_extra">Matt<br></div><div class="gmail_extra"><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>