<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 2:24 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="HOEnZb"><div class="h5">On Wed, Dec 4, 2013 at 3:16 PM, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:<br>

><br>
> On Wed, Dec 4, 2013 at 2:09 PM, Paul Belanger <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>><br>
> wrote:<br>
>><br>
>> 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<br>
>> > 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<br>
>> > 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<br>
>> > 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<br>
>> > 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<br>
>> > 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>
>> 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>
><br>
><br>
> The ActionID is not returned on every subsequent event, it is only returned<br>
> on the AMI event response to the AMI action. So AMI Originate has the same<br>
> problem. People "get around this" by doing a channel set variable to a UUID<br>
> (or something similar) during the Originate, then listening for the SetVar<br>
> event. It's clunky.<br>
><br>
> Tagging events to a transaction in ARI could work, but feels similarly<br>
> clunky. The following is possible:<br>
> POST /channels?endpoint=PJSIP/matt&tag=foobar<br>
>  => Receive StasisStart for channel 12345 with tag foobar<br>
>  => Receive 200 OK for channel 12345<br>
><br>
> This feels like a workaround, and not a solution.<br>
><br>
> As far as solving this for AMI goes, I'd probably keep Originate "as is",<br>
> and add a new AMI action that creates a channel only but doesn't run it. A<br>
> subsequent AMI action - or else an Originate that specifies the channel name<br>
> to run - could then start the execution.<br>
><br>
</div></div>Okay, so using your proposal, the series of events would be:<br>
<br>
1) POST /channels?endpoint=PJSIP/matt&app=hello-world<br>
<div class="im">  => Returns 200 OK with channel 12345<br>
<br>
</div>2) Setup event listener for channel 12345<br>
<br>
3) POST /channels/12345/run (some result returned?)<br>
<br>
4) Wait for event to be returned to listener<br>
<br>
Is that correct?<br clear="all"></blockquote><div><br></div><div>Not really.<br><br></div><div>You already have an event listener in the websocket connection. This is more about keeping sanity in clients, so that they "know" that when they service an event for a channel, they can feel confident that they knew about that channel before the event was received.<br>
<br></div><div>It's more like:<br><br></div><div>POST/channels?endpoint...<br></div><div> => Returns 200 OK with channel 12345<br><br></div><div>POST/channels/12345/run<br></div><div> => Returns 200 OK<br><br></div>
<div>=> Start receiving events about channel over websocket <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>