[asterisk-app-dev] Asterisk AMI/ARI call origination complexity

[Matthew Jordan]

On Thu, Jun 5, 2014 at 5:13 AM, Maxim Litnitskiy <litnimaxster at gmail.com> wrote:

<snip>

>
> So when I change parameters to the following:
>
> data = {
>                 'endpoint': 'SIP/%s' % provider,
>                 'extension': DIALER_EXTENSION,
>                 'context': DIALER_CONTEXT,
>                 'priority': '1',
>                 'channelId': channel_id,
>                 'timeout': '60',
>                 'app': 'dialer',
>                 'appArgs': 'originated',
>             }
>             ret = ari_post('channels', data=data)
>
> I start to receive the following event on websocket:
>

This problem was discussed on this mailing list late last year:

http://lists.digium.com/pipermail/asterisk-app-dev/2013-December/000239.html

The preferred mechanism to solving this problem is to provide your own
channel unique ID when originating a channel. That applies to both AMI
and ARI.

ARI - https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Channels+REST+API#Asterisk12ChannelsRESTAPI-originateWithId
AMI - https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+ManagerAction_Originate

Any events you may receive about the created channel can be tied back
to the action that caused its creation.

> {u'application': u'dialer', u'cause': 18, u'channel': {u'accountcode': u'',
> u'name': u'SIP/provider1-0000032b', u'caller': {u'name': u'', u'number':
> u''}, u'creationtime': u'2014-06-05T13:41:25.613+0400', u'state': u'Down',
> u'connected': {u'name': u'', u'number': u''}, u'dialplan': {u'priority': 1,
> u'exten': u'', u'context': u'no'}, u'id': u'1401961285.6_provider1_1'},
> u'timestamp': u'2014-06-05T13:41:57.614+0400', u'type':
> u'ChannelHangupRequest'}
>
> {u'timestamp': u'2014-06-05T13:41:57.614+0400', u'application': u'dialer',
> u'type': u'ChannelDestroyed', u'cause': 18, u'cause_txt': u'No user
> responding', u'channel': {u'accountcode': u'', u'name':
> u'SIP/provider1-0000032b', u'caller': {u'name': u'', u'number': u''},
> u'creationtime': u'2014-06-05T13:41:25.613+0400', u'state': u'Down',
> u'connected': {u'name': u'', u'number': u''}, u'dialplan': {u'priority': 1,
> u'exten': u'', u'context': u'no'}, u'id': u'1401961285.6_provider1_1'}}
>
>
> And everyting is easily matched on channel id.
> Great!
> Sorry for taking your time :-)
>
> P.S. But anyway I don't see appArgs anywhere in websocket messages :-)
>

Origination always comes in one of two flavours:

(1) Originate a channel to a location in the dialplan, using a
context/extension/priority tuple
(2) Originate a channel directly to an application, optionally with
some arguments presented to the application.

In either case, the arguments passed to the Stasis application are
presented in the StasisStart event. They are not presented on every
single subsequent event: that would be redundant, as every channel
that is handed over to ARI through the Stasis application has a
StasisStart event.

-- 
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