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? -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
