On Wed, Dec 4, 2013 at 2:24 PM, Paul Belanger <paul.belanger at polybeacon.com>wrote: > On Wed, Dec 4, 2013 at 3:16 PM, Matthew Jordan <mjordan at digium.com> wrote: > > > > On Wed, Dec 4, 2013 at 2:09 PM, Paul Belanger < > paul.belanger at polybeacon.com> > > wrote: > >> > >> On Wed, Dec 4, 2013 at 2:59 PM, Matthew Jordan <mjordan at digium.com> > wrote: > >> > Ben Langfeld asked an excellent question at AdhearsionConf about > channel > >> > creation in ARI. Currently, when a channel is created via ARI, the > >> > response > >> > contains the channel that was created in the message body. Asterisk > will > >> > then immediately begin running the channel (that is, dialling the > >> > specified > >> > endpoint) while the response is being sent back to the client. While > >> > "speedy", this creates the situation where the client can potentially > >> > receive events for a channel before it has received the successful > >> > response > >> > to the channel creation. > >> > > >> > That seems less than ideal. > >> > > >> > Ideally, you would create the channel and receive a response > indicating > >> > what > >> > channel you just created. Once you've done that, you'd initiate > another > >> > request to start running the channel. This is really the only way to > >> > keep > >> > events from showing up until after you've received the handle to the > >> > channel. > >> > > >> > Something like: > >> > > >> > POST /channels?endpoint=PJSIP/matt&app=hello-world > >> > => Returns 200 OK with channel 12345 > >> > POST /channels/12345/run > >> > > >> > Thoughts? > >> > > >> My immediate response is how do we get around the issue using AMI > >> Originate async? IIRC you would track the event using the ActionID > >> which is user generated. So why don't we do the same thing? Add the > >> ability for an application to tag events to transactions. > > > > > > 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. > > > > Tagging events to a transaction in ARI could work, but feels similarly > > clunky. The following is possible: > > POST /channels?endpoint=PJSIP/matt&tag=foobar > > => Receive StasisStart for channel 12345 with tag foobar > > => Receive 200 OK for channel 12345 > > > > This feels like a workaround, and not a solution. > > > > 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. > > > Okay, so using your proposal, the series of events would be: > > 1) POST /channels?endpoint=PJSIP/matt&app=hello-world > => Returns 200 OK with channel 12345 > > 2) Setup event listener for channel 12345 > > 3) POST /channels/12345/run (some result returned?) > > 4) Wait for event to be returned to listener > > Is that correct? > Not really. 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. It's more like: POST/channels?endpoint... => Returns 200 OK with channel 12345 POST/channels/12345/run => Returns 200 OK => Start receiving events about channel over websocket -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131204/0b769488/attachment.html>
