[Home]

Summary:ASTERISK-09182: Persistent CDR Start Disagreement
Reporter:Leo Brown (netfuse)Labels:
Date Opened:2007-04-04 07:20:32Date Closed:2007-04-23 10:44:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/cdr_csv
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Having had issues with "mysql server gone away" for mysql_cdr, we've updated to the 1.4 trunk, and now get no CDR logged in the CSV or MySQL.

As soon as a call is connected, the terminal logs:

[Apr  4 12:04:50] WARNING[63217]: cdr.c:482 ast_cdr_merge: CDR start disagreement for IAX2/tag4-1

We've disabled the SQL addon (also built from today's 1.4 branch) to no avail.

I would provide more information, but being a clean build with no relevant debug info providable (IAX2/SIP debug obviously won't help here), I wouldnt know what to include.

Any ideas?

Thanks,
Leo

****** ADDITIONAL INFORMATION ******

----modules.conf----
[modules]
autoload=yes

----cdr.conf----
[general]
enable=yes
Comments:By: Leo Brown (netfuse) 2007-04-04 07:53:58

For the record, this appears on both incoming IAX2 and SIP calls, to any number of target IAX2 bridges on different asterisk builds.

By: Leo Brown (netfuse) 2007-04-04 08:01:33

Update - it seems when updated to 1.4, Asterisk stopped logging to cdr-csv/Master.csv and now instead writes to cdr-custom/Master.csv. The MySQL configuration that previously worked still no longer writes, and the message continues to baffle. MySQL configuration follows, and MySQL confirmed running and accessible under these creds:

[global]
hostname=localhost
dbname=cdr
table=cdr
password=myPass
user=root
timeout=10
spool=/var/log/asterisk/mysql.spool

By: Leo Brown (netfuse) 2007-04-04 14:34:04

Update - MySQL seems to be logging properly again, after numerous minor changes. Persistent problem remains that cdr-csv/Master.csv is not updated and console continues to write 'disagreement' message. LB

By: Rob M (nyt) 2007-04-05 04:44:01

I'm seeing the same messages.  Did not test mysql logging...



   -- Starting simple switch on 'Zap/1-1'
   -- Executing [s@incoming:1] Answer("Zap/1-1", "") in new stack
   -- Executing [s@incoming:2] BackGround("Zap/1-1", "menu") in new stack
   -- <Zap/1-1> Playing 'menu' (language 'en')
 == CDR updated on Zap/1-1
   -- Executing [0@incoming:1] Goto("Zap/1-1", "noc|s|1") in new stack
   -- Goto (noc,s,1)
   -- Executing [s@noc:1] Queue("Zap/1-1", "noc|tn|||44") in new stack
   -- Started music on hold, class 'default', on channel 'Zap/1-1'
   -- outgoing agentcall, to agent '121', on 'Local/121@queue-2433,1'
   -- outgoing agentcall, to agent '122', on 'Local/122@queue-0060,1'
   -- outgoing agentcall, to agent '129', on 'Local/129@queue-df04,1'
   -- Executing [121@queue:1] Dial("Local/121@queue-2433,2", "SIP/121| 45| tmw") in new stack
   -- Called 121
   -- Started music on hold, class 'default', on channel 'Local/121@queue-2433,2'
   -- outgoing agentcall, to agent '127', on 'Local/127@queue-4ff4,1'
   -- Executing [122@queue:1] Dial("Local/122@queue-0060,2", "SIP/122| 45| tmw") in new stack
   -- Called 122
   -- Started music on hold, class 'default', on channel 'Local/122@queue-0060,2'
   -- Executing [129@queue:1] Dial("Local/129@queue-df04,2", "SIP/129| 45| tmw") in new stack
   -- Called 129
   -- Started music on hold, class 'default', on channel 'Local/129@queue-df04,2'
   -- Executing [127@queue:1] Dial("Local/127@queue-4ff4,2", "SIP/127| 45| tmw") in new stack
   -- Called 127
   -- outgoing agentcall, to agent '221', on 'Local/221@queue-e7cf,1'
   -- Started music on hold, class 'default', on channel 'Local/127@queue-4ff4,2'
   -- Executing [221@queue:1] Dial("Local/221@queue-e7cf,2", "SIP/221| 45| tmw") in new stack
   -- Called 221
   -- Started music on hold, class 'default', on channel 'Local/221@queue-e7cf,2'
   -- SIP/127-081f3528 is ringing
   -- SIP/121-081ffdb0 is ringing
   -- SIP/122-081ede38 is ringing
   -- SIP/129-081e6fe0 is ringing
   -- SIP/221-081fb6f8 is ringing
   -- Call on SIP/221-081fb6f8 left from hold
   -- Stopped music on hold on Local/221@queue-e7cf,2
   -- SIP/221-081fb6f8 answered Local/221@queue-e7cf,2
   -- Agent/221 answered Zap/1-1
[Apr  5 05:40:23] WARNING[17941]: cdr.c:482 ast_cdr_merge: CDR start disagreement for Local/221@queue-e7cf,2
   -- Stopped music on hold on Local/121@queue-2433,2
   -- Stopped music on hold on Local/122@queue-0060,2
   -- Stopped music on hold on Local/129@queue-df04,2
   -- Stopped music on hold on Zap/1-1
[Apr  5 05:40:24] WARNING[17935]: cdr.c:482 ast_cdr_merge: CDR start disagreement for Zap/1-1
[Apr  5 05:40:24] WARNING[17935]: cdr.c:510 ast_cdr_merge: CDR answer disagreement for Zap/1-1
[Apr  5 05:40:24] WARNING[17941]: cdr.c:510 ast_cdr_merge: CDR answer disagreement for Local/221@queue-e7cf,2
   -- Stopped music on hold on Local/127@queue-4ff4,2
 == Spawn extension (queue, 122, 1) exited non-zero on 'Local/122@queue-0060,2'
 == Spawn extension (queue, 121, 1) exited non-zero on 'Local/121@queue-2433,2'
 == Spawn extension (queue, 127, 1) exited non-zero on 'Local/127@queue-4ff4,2'
 == Spawn extension (queue, 129, 1) exited non-zero on 'Local/129@queue-df04,2'
 == Spawn extension (queue, 221, 1) exited non-zero on 'Local/221@queue-e7cf,2'
 == Spawn extension (noc, s, 1) exited non-zero on 'Zap/1-1'
   -- Hungup 'Zap/1-1'

By: Rob M (nyt) 2007-04-05 04:45:54

Asterisk SVN-branch-1.4-r55957

By: pj (pj) 2007-04-05 11:01:58

"core show channels verbose" shows empty value in "Duration" column
also are empty/not shown "CDR Variables" for particular channel (in "core show channel ..." output).
Asterisk SVN-trunk-r59805

By: Rob M (nyt) 2007-04-20 20:44:28

with everything upgraded, this seems to have gone away.

By: Steve Murphy (murf) 2007-04-23 10:44:13

Yes, in a series of debug sessions and commits, the issues brought forward here were all solved.

The start/answer/end disagreement messages were innocuous; they were merely reporting the flow of control thru the CDR merge routine, I erased those. As for the state during a dial, I moved the CDR merging to the end the Dial() app. ForkCDR and NoCDR() apps were updated to work with the new regime. The merge routine was fixed to include vars, attached CDRs, etc.

A few problems remain, but hopefully, CDR's are now more accurate, and don't lose things like Answer times, and give better info thru things like transfers, parking, etc.