[asterisk-bugs] [JIRA] (ASTERISK-25596) CDR engine dispatching 2 cdrs - one for PartyA and another combined PartyA-PartyB

[Pedro Guillem (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228524#comment-228524 ] 

Pedro Guillem commented on ASTERISK-25596:
------------------------------------------

Just switched to Asterisk 11.20 and the dialplan works as expected. 
I will stick to this version for now.. i presume.

I went trough the new CDR docs and fully understood how the system is shooting the CDRs nowdays, i still however couldn't think of a reason version >12 engine is dispatching an additional CDR for PartyA if the call was successfully bridged to PartyB.

What do you guys think?

> CDR engine dispatching 2 cdrs - one for PartyA and another combined PartyA-PartyB
> ---------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25596
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25596
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 13.6.0
>         Environment: Linux Debian-Jessie (64bit). Compiled from source. Default cdr.conf (from make samples).
>            Reporter: Pedro Guillem
>            Assignee: Unassigned
>            Severity: Critical
>
> Normally Asterisk creates a single CDR per call (for both bridged legs). 
> For some reason, its creating two cdrs per call.
> This happens when i upgrade from 1.4 to 13.6. I know there are a lot of changes in 8 years, but this one (if its indeed a change in the cdr engine) is totally meaningless. Why on earth would anyone want 2 cdr records for the same call?
> The first cdr that is being dispached is the PartyA (incoming) CDR. It logs almost empty data, with no dstchannel offcourse. I assume its the state of the PartyA alone after Hagnup().
> '19591652', '2015-11-29 21:03:02', '<900100>', '900100', '57XXXXXXXXX', 'default', 'SIP/162.XX-XX-XX-00000000', '', 'Hangup', 'rated', '', '0', '', '0', '0', 'ANSWERED', '0', '200121', 'Ether1-1448848954.0', '57XXXXXXX', '00', NULL, '0', NULL
> Second CDR is the ONLY desired CDR, which includes relevant information regarding the combined PartyA-PartyB transaction. (Note this one includes the duration, billsec, dstchannel and the bridged call data)
> '19591651', '2015-11-29 21:02:34', '<900100>', '900100', '57XXXXXXXX', 'default', 'SIP/162.XX.XX.XX-00000000', 'SIP/vox-00000001', 'Dial', 'rated', '', '0', '20200', '28', '20', 'ANSWERED', '0', '200121', 'Ether1-1448848954.0', '57XXXXXXX', '0', '0', '67', NULL
> I tried setting "unanswered=no" in cdr.conf, but the outcome is the same if the call is answered. The engine logs 2 records instead of one.
> Werid. Please share some light on what needs to be changed in order to produce ONE single cdr record per call.. NOT an independent CDR for  PartyA and a separate one for the bridged call.
> I must insist the relevant CDR is the bridged output.. not the PartyA incoming channel.
> Best regards, and thanks for any hints.
> Pedro



--
This message was sent by Atlassian JIRA
(v6.2#6252)