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

[Denis Olenev (JIRA)]

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

Denis Olenev edited comment on ASTERISK-25596 at 1/19/17 5:00 AM:
------------------------------------------------------------------

I had similar problem.

Asterisk certified/13.8-cert4

One call produced two record. One correct record, second record had the same values except 'start','end','answered' fields, which was empty.

The reason of duplicates record - cdr_odbc.so module.
# asterisk -rx "module show like odbc"
Module                         Description                              Use Count  Status      Support Level
cdr_adaptive_odbc.so           Adaptive ODBC CDR backend                0          Running              core
cdr_odbc.so                    ODBC CDR Backend                         0          Running          extended
cel_odbc.so                    ODBC CEL backend                         0          Running              core
func_odbc.so                   ODBC lookups                             0          Running              core
res_config_odbc.so             Realtime ODBC configuration              0          Running              core
res_odbc.so                    ODBC resource                            0          Running              core
res_odbc_transaction.so        ODBC transaction resource                0          Running              core
7 modules loaded

I turn him off in modules.conf
'noload => cdr_odbc.so'

Restart server and things is fine.





was (Author: venoel):
I have similar problem.

Asterisk certified/13.8-cert4

One call produced two record. One correct record, second record had the same values except 'start','end','answered' fields, which was empty.

The reason of duplicates record - cdr_odbc.so module.
# asterisk -rx "module show like odbc"
Module                         Description                              Use Count  Status      Support Level
cdr_adaptive_odbc.so           Adaptive ODBC CDR backend                0          Running              core
cdr_odbc.so                    ODBC CDR Backend                         0          Running          extended
cel_odbc.so                    ODBC CEL backend                         0          Running              core
func_odbc.so                   ODBC lookups                             0          Running              core
res_config_odbc.so             Realtime ODBC configuration              0          Running              core
res_odbc.so                    ODBC resource                            0          Running              core
res_odbc_transaction.so        ODBC transaction resource                0          Running              core
7 modules loaded

I turn him off in modules.conf
'noload => cdr_odbc.so'

Restart server and things is fine.




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