[asterisk-app-dev] Originate/Channel Creation as a two step process

[Paul Belanger]

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