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

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-25596:
-----------------------------------

    Assignee: Pedro Guillem
      Status: Waiting for Feedback  (was: Triage)

You will need to provide the complete console output and dialplan which produced this to confirm if it is the correct behavior. As well yes, CDR behavior is different in 13 and above. It now conforms to a specification detailed on the wiki[1] and can result in multiple records. The behavior won't be changed unless it's not behaving according to the wiki.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification

> 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: Pedro Guillem
>            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)