Outbound call shown as "O_ANSWERED" but CDR "NO ANSWER"

[Dcdata]

Good evening guys,

I am running TNG for Asterisk version 1.1.1.13 in this specfic environment.
When running a detailed Transaction report TNG indicates the call outcome of "O_ANSWERED" and a cost for the call, but when looking at the CSV CDR directly from Asterisk, the disposition is "NO ANSWER".

Please see the Master.csv excerpt as follows (numbers changed for privacy reasons:
"2XXX","2XXX","07268XXXXX","from-internal","SIP/2XXX-000083c8","SIP/trunkXXX-000083c9","Dial","SIP/trunkXXX/277268XXXXX,300,Tt","2016-05-01 00:16:29","2016-05-01 00:16:33","2016-05-01 00:17:04","35","31","NO ANSWER","DOCUMENTATION","","1462054589.58303",""

Why did TNG assume the call to be answered? Is it due to the fact that the 'billsec' field is non zero, even though the 'disposition' field indicates "NO ANSWER"?

Thank you in advance.

Kind regards
David.

[Luanda_Junzi]

Evening David

Can you do grep the line.

Code: Select all

less Master.csv | grep  "NO ANSWER" | head

pull a report on tng with those 10 numbers just to see if its specific numbers or its TNG habit

Regards

Luanda

[Dcdata]

Thank you Lwanda.

I've sent the log excepts through to your personal email address.

[Luanda_Junzi]

Good day David

Thank you for the logs, can you please pull a report for those number in the logs.
Preferably detail transaction report .


Kind Regards

Luanda

[Dcdata]

Thank you Luanda.

I've now emailed through the screenshots of the TNG detailed transaction reports performed against each destination number.
From what I can see, it seems that TNG is ignoring the CDR disposition field, and assuming the call to be answered if the CDR billsec field is greater than zero.

Is there any way to change this behavior in TNG so that the disposition field is read and used to determine the final answered or unanswered state of the call please?

Kind regards
David.

[Luanda_Junzi]

Evening David

Yes it seems like it.

Format

Code: Select all

Master.csv => "${CDR(clid)}","${CDR(src)}","${CDR(dst)}","${CDR(dcontext)}","${CDR(channel)}","${CDR(dstchannel)}","${CDR(lastapp)}","${CDR(lastdata)}","${CDR(start)}","${CDR(answer)}","${CDR(end)}","${CDR(duration)}","${CDR(billsec)}","${CDR(disposition)}","${CDR(amaflags)}","${CDR(accountcode)}","${CDR(uniqueid)}","${CDR(userfield)}"

Data from CSV file

Code: Select all

"2427","2427","035xxxxxx","from-internal","SIP/2427-0002cca0","SIP/273128xxxxx-0002cca1","Dial","SIP/273128xxxxx/27357xxxxxx,300,Tt","2016-07-13 01:18:16","2016-07-13 01:18:16","2016-07-13 01:18:54","38","38","NO ANSWER","DOCUMENTATION","","1468365496.309732",""

I think they should be a way rule you can have in place to rectify this behavior.

I will have a chat with Leon tomorrow then give you an update.

Regards
Luanda

[Luanda_Junzi]

Hi David

The matter will be escalated to development.
I will give you update once I have the feedback.

Please share the script for the workaround
I will test on my side to see if it will give the exact results.

Regards
Luanda