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

[Matthew Jordan]

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.

-- 
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/9b7c44a4/attachment.html>