<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 2:09 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.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">On Wed, Dec 4, 2013 at 2:59 PM, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:<br>

> Ben Langfeld asked an excellent question at AdhearsionConf about channel<br>
> creation in ARI. Currently, when a channel is created via ARI, the response<br>
> contains the channel that was created in the message body. Asterisk will<br>
> then immediately begin running the channel (that is, dialling the specified<br>
> endpoint) while the response is being sent back to the client. While<br>
> "speedy", this creates the situation where the client can potentially<br>
> receive events for a channel before it has received the successful response<br>
> to the channel creation.<br>
><br>
> That seems less than ideal.<br>
><br>
> Ideally, you would create the channel and receive a response indicating what<br>
> channel you just created. Once you've done that, you'd initiate another<br>
> request to start running the channel. This is really the only way to keep<br>
> events from showing up until after you've received the handle to the<br>
> channel.<br>
><br>
> Something like:<br>
><br>
> POST /channels?endpoint=PJSIP/matt&app=hello-world<br>
>   => Returns 200 OK with channel 12345<br>
> POST /channels/12345/run<br>
><br>
> Thoughts?<br>
><br>
</div>My immediate response is how do we get around the issue using AMI<br>
Originate async? IIRC you would track the event using the ActionID<br>
which is user generated. So why don't we do the same thing? Add the<br>
ability for an application to tag events to transactions.<br>
<span class="HOEnZb"></span></blockquote><div><br></div><div>The ActionID is not returned on every subsequent event, it is only returned on the AMI event response to the AMI action. So AMI Originate has the same problem. People "get around this" by doing a channel set variable to a UUID (or something similar) during the Originate, then listening for the SetVar event. It's clunky.<br>
</div><div><br></div><div>Tagging events to a transaction in ARI could work, but feels similarly clunky. The following is possible:<br></div><div>POST /channels?endpoint=PJSIP/matt&tag=foobar<br></div><div> => Receive StasisStart for channel 12345 with tag foobar<br>
</div><div> => Receive 200 OK for channel 12345<br><br></div><div>This feels like a workaround, and not a solution.<br><br></div><div>As far as solving this for AMI goes, I'd probably keep Originate "as is", and add a new AMI action that creates a channel only but doesn't run it. A subsequent AMI action - or else an Originate that specifies the channel name to run - could then start the execution.<br>
</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>