Hi guys.
I'd like to discuss a wierd issue related to call origination from 3-rd party apps.
IMHO call origination is the most important thing when embedding telephony somewhere.
The problem is in one important place.
When call origination fails we need to know it and reflect accordingly.
Let's review a few examples with AMI and ARI where it fails.
1. AMI.
Let originate a call:
Action: Originate
Channel: SIP/eltex/65010000
Application: Echo
ActionID: 12341234
Async: true
Response: Success
ActionID: 12341234
Message: Originate successfully queued
Great. We have ActionID to track it.
Everything is fine when call is connected.
But often it fails to connect and we must know the reason - cause code and message.
And here we are - it's not as simple as it could be.
Let see events:
Event: Hangup
Privilege: call,all
Channel: SIP/eltex-00000002
Uniqueid: 1396800231.4
CallerIDNum: <unknown>
CallerIDName: <unknown>
ConnectedLineNum: <unknown>
ConnectedLineName: <unknown>
AccountCode:
Cause: 19
Cause-txt: User alerting, no answer
Event: OriginateResponse
Privilege: call,all
ActionID: 12341234
Response: Failure
Channel: SIP/eltex/65010000
Context:
Exten:
Reason: 3
Uniqueid: <null>
CallerIDNum: <unknown>
CallerIDName: <unknown>
We do have ActionID in OriginateResponse message. But how can we know cause code and cause message?
Only from Hangup event.
But Hangup event does not have our ActionID it has Uniqueid.
But OriginateResponse does not have Uniqueid.
So it's impossible to properly track failed AMI originated calls without inventing some hacks to solve the situation.
One solution is to use CallerID to track call path as this field is in all messages.
But it does not help when we have to keep real caller id and name.
I tested this situation on all Asterisk versions from 1.4 to 11. All as described above.
2. ARI. Now let see how we originate calls with ARI.
We use POST /channels API. Something like that:
data = ""> 'endpoint': 'SIP/%s@%s' % (phone, provider),
'extension': '1',
'context': 'test',
'priority': '1',
'channelId': channel_id,
'timeout': '60',
}
ret = ari_post('channels', data="">
Again everyhing is fine if call is answered and put into Statis app:
[test]
exten => 1,1,Noop()
same => n,Wait(1.5)
same => n,Stasis(dialer)
same => n,Wait(2)
same => n,Hangup()
We do have channelId. And when ChannelHangupRequest event comes into our dialer websocket we already know it is ANSWERED and can distinguish it by channel id. Fine.
But again what if call was not connected? CONGESTION, FAILED, NO ANSWER, BUSY?
ChannelHangupRequest does not come into our websocket!
So for this time I created the following hack.
I used cdr_pgsql and created AFTER INSERT TRIGGER on cdr table.
This trigger function takes disconnect cause by uniqueid and updates my table we this cause:
CREATE OR REPLACE FUNCTION update_channel_status() RETURNS trigger AS $$
BEGIN
UPDATE dialer_subscriber SET status = NEW."disposition"
WHERE channel_id = NEW."uniqueid";
RETURN NEW;
END; $$ LANGUAGE 'plpgsql';
CREATE TRIGGER update_channel_status AFTER INSERT on asterisk_cdr
FOR EACH ROW EXECUTE PROCEDURE update_channel_status();
Why at all I post all this here?
If ARI is just started to evolve may be developers can implement some direct "inhouse" feature to track not connected calls in ARI app?
Thanks for reading.
Regars,
Max.
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
