Guys, seems I found the solution with ARI.
Great.
I was mislead by similarity of originate parameters in AMI and ARI.
In AMI we either specify context, extention and priority OR application and application data.
In ARI we have also parameters 'app' and 'appArgs'.
But! Thery are not for calling dialplan application insted of context/exten/prio.
Let see what documentation tells:
POST /channels
Create a new channel (originate). The new channel is created immediately and a snapshot of it returned. If a Stasis application is provided it will be automatically subscribed to the originated channel for further events and updates.
Query parameters
endpoint: string - (required) Endpoint to call.
extension: string - The extension to dial after the endpoint answers
context: string - The context to dial after the endpoint answers. If omitted, uses 'default'
priority: long - The priority to dial after the endpoint answers. If omitted, uses 1
app: string - The application that is subscribed to the originated channel, and passed to the Stasis application.
appArgs: string - The application arguments to pass to the Stasis application.
callerId: string - CallerID to use when dialing the endpoint or extension.
timeout: int = 30 - Timeout (in seconds) before giving up dialing, or -1 for no timeout.
channelId: string - The unique id to assign the channel on creation.
otherChannelId: string - The unique id to assign the second channel when using local channels
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="">
I start to receive the following event on websocket:
{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 :-)
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
- Follow-Ups:
- Re: Asterisk AMI/ARI call origination complexity
- From: Matthew Jordan
- Re: Asterisk AMI/ARI call origination complexity
- References:
- Asterisk AMI/ARI call origination complexity
- From: Maxim Litnitskiy
- Asterisk AMI/ARI call origination complexity
- Prev by Date: Asterisk AMI/ARI call origination complexity
- Next by Date: Re: Asterisk AMI/ARI call origination complexity
- Previous by thread: Asterisk AMI/ARI call origination complexity
- Next by thread: Re: Asterisk AMI/ARI call origination complexity
- Index(es):