[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:all-tabpanel ]

Pedro Guillem updated ASTERISK-25596:
-------------------------------------

    Description: 
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

  was:
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.

'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


> 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
>            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)