I found another strange problem that I need to check with the community.
I noticed that when I initiate a call via AMI (I am using an application that uses AMI for monitoring the phone status and initiate calls), sometimes I get the wrong disposition (call status) in the CDR. Sometimes even though the billsec parameter is bigger then 0, the disposition is NO ANSWER. I tested this couple times, and it happens quite randomly - usually if the billsec parameter is bigger then 0, the disposition is ANSWERED. I have noticed this problem on all the trunks and on internal calls.
This is an CLI output of a call that got answered, but disposition is NO ANSWER
[Dec 13 09:12:32] VERBOSE[15196] manager.c: == Manager 'account' logged on from 127.0.0.1
[Dec 13 09:12:32] VERBOSE[15196] netsock.c: == Using SIP RTP CoS mark 5
[Dec 13 09:12:33] VERBOSE[15199] pbx.c: -- Executing [0011223344@internal_calls:1] Set("SIP/102-0000093c", "CDR(userfield)=00000000000") in new stack
[Dec 13 09:12:33] VERBOSE[15199] pbx.c: -- Executing [0011223344@internal_calls:2] Dial("SIP/102-0000093c", "SIP/GSM_Trunk/0011223344") in new stack
[Dec 13 09:12:33] VERBOSE[15199] netsock.c: == Using SIP RTP CoS mark 5
[Dec 13 09:12:33] VERBOSE[15199] app_dial.c: -- Called GSM_Trunk/0011223344
[Dec 13 09:12:33] VERBOSE[15196] manager.c: == Manager 'account' logged off from 127.0.0.1
[Dec 13 09:12:34] VERBOSE[15199] app_dial.c: -- SIP/GSM_Trunk-0000093d is ringing
[Dec 13 09:13:16] VERBOSE[15199] pbx.c: == Spawn extension (internal_calls, 0011223344, 2) exited non-zero on 'SIP/102-0000093c'
And this is the call that does not have the wrong disposistion parameter (call was answered abd the disposition is ANSWER)
[Feb 2 12:54:45] VERBOSE[11884] pbx.c: -- Executing [0011223344@internal_calls:1] Set("SIP/102-0000020f", "CDR(userfield)=00000000000") in new stack
[Feb 2 12:54:45] VERBOSE[11884] pbx.c: -- Executing [0011223344@internal_calls:2] Dial("SIP/102-0000020f", "SIP/GSM_Trunk/0011223344") in new stack
[Feb 2 12:54:45] VERBOSE[11884] netsock.c: == Using SIP RTP CoS mark 5
[Feb 2 12:54:45] VERBOSE[11884] app_dial.c: -- Called GSM_Trunk/0011223344
[Feb 2 12:54:45] VERBOSE[11884] app_dial.c: -- SIP/GSM_Trunk-00000210 is ringing
[Feb 2 12:54:57] VERBOSE[11884] app_dial.c: -- SIP/GSM_Trunk-00000210 answered SIP/102-0000020f
[Feb 2 12:55:53] VERBOSE[11884] pbx.c: == Spawn extension (internal_calls, 0011223344, 2) exited non-zero on 'SIP/104-0000020f'The main difference is the “app_dial.c: – SIP/GSM_Trunk-00000210 answered SIP/102-0000020f” that I do not get when the disposistion parameter is wrong even though the call was answered (disposition is NO ANSWER)
Output to other trunks are a bit different, but I replicated the problem on multiple trunks and I have some additional debug for someone that needs further debugs.
My AMI application has one active connection to the AMI on which it is listening for AMI Events that Asterisk generates. For any call that users initiate via AMI application, the application creates a new AMI connection for the time of setting up the call (a couple of seconds). That is why you see the manager logging on and off during the call in the first debug. Perhaps this might have something to do with the problem.
I checked the bug tracker and ran into a similar problem, but there was no solution for this:
issues.asterisk.org/view.php?id=15928
I replicated the problem on Asterisk 1.6.2.8 and 1.6.2.16.1. For CDR’s I am using csv and PosgreSQL.
Has anyone had a similar problem before?