CDR broken on transfers

[lorsungcu]

When a call is transferred, the CDR does not show the correct time for the users involved in the transfer. Both callers get credit for the entire call, rather than the time being split according to how long they were actually talking. I have a ticket open for this but absolutely no word on when it will be fixed. I would rather not go to the trouble of fixing my scripts to account for an oversight like this; if nothing else, I'd ask that Digium provide a way to parse the strings that are sent along with the TALKING events, so we can use those to determine the actual call length. Below is an example of the issue, and what needs to change:

Code: Select all

<call id="50409" origination="incoming" start_time="2011-10-12 09:21:37" from="CUST - MAIN - <6125551234>" from_name="CUST - MAIN -" from_number="6125551234" to="User B <4490>" to_account_id="1113" to_name="User B" to_number="4490" [b]total_duration="1374" talk_duration="1330"[/b]>
    <events>
        <event start_time="2011-10-12 09:21:37" type="INCOMING_PROVIDER" display="Received call over Channel Group (PRI_B)"/>
        <event start_time="2011-10-12 09:21:37" type="INCOMING" display="Received call over channel 2 over phone number (6125554321)" incoming_did="6125554321"/>
        <event start_time="2011-10-12 09:21:37" type="INTERNAL" display="Rang Auto Attendant MAIN <800>"/><event start_time="2011-10-12 09:22:13" type="INTERNAL" display="Rang Operator L1 <2036>"/>
        <event start_time="2011-10-12 09:22:16" type="TALKING" display="Talked to User A <6528> for 1 minute, 8 seconds"/>
        <event start_time="2011-10-12 09:23:24" type="TC_BLIND_TRANSFER" display="Call was blind-transferred to 4490 by User A <6528>"/>
        <event start_time="2011-10-12 09:23:24" type="OUTGOING" display="Dialed number (4490)"/><event start_time="2011-10-12 09:23:24" type="INTERNAL" display="Rang User B <4490>"/>
        <event start_time="2011-10-12 09:23:29" type="TALKING" display="Talked to User B <4490> for 21 minutes, 2 seconds"/>
        <event start_time="2011-10-12 09:44:31" type="HANGUP" display="Call was hung up by User B <4490>"/>
    </events>
</call>

Each of the TALKING events need to be parsed out and the time assigned to each of the extensions, then the original callID should be discarded. New callIDs should be created, using the original as a base. Digium, please post a solution that will account for all types of transfers, and be compatible with whatever long term fix you decide on. If you could also explain why you use seconds to show call/talk length, but then elsewhere use human readable strings, that'd be great.

For the record, Digium has confirmed that the problem is present in 4.6 through the latest 5.x release. The CDR is inaccurate in the user's page, the admin page, and whatever you pull out through the API.

[chrisM8]

Hi, that is correct. CDR will not work with transfers in current versions of Asterisk. One of the possible workarounds is to use custom build "billing engine" (daemon running in a background) which listens for Asterisk Management Event (sent via TCP socket), parses them, keeps track of all call legs, transfers and constructs correct CDR/Billing info.

[chrisM8]

... the trouble is AMI events emitted by Asterisk changed from version to version !!!, see:

http://lists.digium.com/pipermail/aster ... 50637.html

so need to be very careful when doing upgrades as your AMI based billing/CDR might stop working all of sudden.

[lorsungcu]

Thanks for the response, Chris; I don't think that Switchvox is using 1.8x though (that might have changed, it'd be great to know, so we could have some idea of what was broken..).

Can Digium reply? In speaking with support, they said this was by design. I really find that hard to believe. Either reply, confirming this is incorrect behavior, or reply and explain why it would be the desired behavior. My customers do not understand why, and I can't say I do either. If this is incorrect behavior, please post the issue on the "Switchvox Today" page, so future customers know what to expect.

http://www1.digium.com/en/products/swit ... hvox-today

If it is incorrect, a workaround using the API to retrieve accurate call information would be expected, or an ETA for a release that includes a fix. If you will not be confirming either way, please say that, so I know what to expect.

[dpodolsky]

What you are describing is not broken behavior, but this is how the Call Logs feature is intended to be used. The Call Logs report all of the events on the call. If that call rings, cascades, transfers, etc, all those events are logged as part of the call. Having all those events listed out is very beneficial so a user / admin can see where and how the call originated, what path it took, and eventually where it ended up.

Since there can be multiple events on a call, the attributes on the call XML tag represent the cumulative values for that call. The total_duration is the entire duration of the of the call including all events, and the talk_duration is the cumulative of all the talking events on the call.

If a developer wants to get individual talk times for the call they should go through each of the events and look for TALKING events and then log who did the talking and for how long. Currently the events only have a display attribute with all the information formatted in a string. I have worked with support to enter a feature request to get the account and duration split into attribute values in the event.

Example:
Current XML:
<event start_time="2011-10-18 11:26:32" type="TALKING" display="Talked to David P <104> for 3 minutes, 4 seconds" />

Requested XML:
<event start_time="2011-10-18 11:26:32" type="TALKING" display="Talked to David P <104> for 3 minutes, 4 seconds" account_id="1004" duration="184" />

I agree this will making parsing the events easier.

However, getting the account_id and the duration is possible today with some simple parsing. If you are having difficulty writing this code reach out to other developers on this board for help and I am sure they could provide some tips.