[Home]

Summary:ASTERISK-22874: CDR Lines Missing
Reporter:Daniel Journo (journo)Labels:
Date Opened:2013-11-20 17:04:13.000-0600Date Closed:2013-12-07 20:49:14.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:CDR/cdr_csv
Versions:11.6.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:CentosAttachments:
Description:I've noticed that CDR lines are intermittently missing. I WAS logging to ODBC and I thought it was an issue with that. But when I enabled CDR-CSV, I found that lines are missing on that too.

unanswered=no during the test.
Setting unanswered=yes seems to show up the missing cdrs, but then i end up with duplicate lines for every cdr line.
Therefore I am still logging this bug because neither unanswered=yes or unanswered=no helps.


The first line is always logged, but then the call goes to a Local channel, which is intermittently logged.

Here is the dialplan. Sorry for the complexity. It is build automatically by our backend.

I am testing by hanging up after the call enters the queue, when the caller can hear music. Although, I think the issue occurs randomly but repeatable. I would say 1 in 10 calls.

{noformat}
exten => 0800123456,1,Set(__EXTERNALCALL=YES)
exten => 0800123456,2,Set(__CALLFROM=${CALLERID(number)})
exten => 0800123456,3,Set(TIMEOUT(absolute)=18000)
exten => 0800123456,4,Set(CDR(userfield)=${UNIQUEID})
exten => 0800123456,5,Set(__UNIQUECALLID=${UNIQUEID})
exten => 0800123456,6,Set(GROUP(ActiveCallsToNumber)=0800123456)
exten => 0800123456,7,Set(GROUP(ConcCallsForcompany)=1)
exten => 0800123456,8,NoOp(ActiveCallsToNumber = ${GROUP_COUNT(0800123456@ActiveCallsToNumber)})
exten => 0800123456,9,NoOp(Total Active Calls to company = ${GROUP_COUNT(1@ConcCallsForcompany)})
exten => 0800123456,10,ExecIf($["${CALLERID(number)}"=="01615550000"]?Set(CALLERID(number)=01615551234))
exten => 0800123456,11,ExecIf($["${CALLERID(name)}"=="01615550000"]?Set(CALLERID(name)=01615551234))
exten => 0800123456,12,Set(__TRANSFER_CONTEXT=company_phones)
exten => 0800123456,13,Set(CDR(accountcode)=company)
exten => 0800123456,14,AGI(/var/lib/asterisk/scripts/pre_incomingcall_check.php)
exten => 0800123456,15,AGI(/var/lib/asterisk/scripts/SetRecordingName.pl,${CALLERID(number)})
exten => 0800123456,16,SET(DB(RECORDINGNAME/${CHANNEL(name)})=${RecordingFilename})
exten => 0800123456,17,Set(__VOICEMAILBOX=4)
exten => 0800123456,18,GotoIf($["${CALLERID(number):0:2}"!="44"]?20)
exten => 0800123456,19,Set(CALLERID(number)=0${CALLERID(number):2})
exten => 0800123456,20,GotoIf($["${CALLERID(number)}"=""]?23)
exten => 0800123456,21,Set(CALLERID(number)=9${CALLERID(number)})
exten => 0800123456,22,Goto(25)
exten => 0800123456,23,Set(CALLERID(number)=Withheld)
exten => 0800123456,24,Set(CALLERID(name)=Withheld)
exten => 0800123456,25,Set(CDR(accountcode)=company)
exten => 0800123456,26,Dial(LOCAL/company_101@queue/n)

[queue]

exten => company_101,1,Set(__CALLTO=company_201)
exten => company_101,2,Macro(mixmon,nobeep)
exten => company_101,3,Answer()
exten => company_101,4,Wait(1)
exten => company_101,5,Playback(/var/lib/asterisk/clientsounds/features/1/queues/1)
exten => company_101,6,Set(CDR(userfield)=${UNIQUECALLID})
exten => company_101,7,Queue(company_101,tC,,,9999)
exten => company_101,8,GotoIf($["${QUEUESTATUS}"="TIMEOUT"]?108:208)
exten => company_101,108,Set(CALLERID(number)=9${CALLERID(number)})
exten => company_101,109,Set(CDR(accountcode)=company)
exten => company_101,110,Goto(voicemail,company_2,1)
exten => company_101,208,Set(CALLERID(number)=9${CALLERID(number)})
exten => company_101,209,Set(CDR(accountcode)=company)
exten => company_101,210,Goto(voicemail,company_1,1)
{noformat}
Comments:By: Matt Jordan (mjordan) 2013-11-20 17:51:15.846-0600

To quote our long conversation in IRC:

{quote}
(05:20:12 PM) danfromuk: mjordan: ive removed some of the dialplan in the issue. I'll test unanswered=yes, however if it hits a queue, i would expect it to be marked as answered. In fact, the first channel is marked as ANSWERED in the cdr
(05:21:49 PM) danfromuk: can unanswered=yes be placed in [csv]? or can it only be placed in [general]
(05:28:56 PM) danfromuk: mjordan: unanswered seems to have resolved it. Weird that it worked intermittently with unanswered=no
(05:38:57 PM) danfromuk: mjordan: I cant use unanswered. It creates duplicate lines in the cdr. Of all channels, not just the Local ones.
(05:39:44 PM) mjordan: I wasn't saying that you should use it, but if your mysteriously not present channels show up when unanswered=yes, then you have your answer as to why they aren't showing up
(05:40:14 PM) mjordan: keeping in mind that the reason why they aren't showing up then isn't a bug
(05:40:26 PM) mjordan: they aren't showing up because they aren't Answered
(05:41:52 PM) danfromuk: mjordan: I wouldnt class them as unanswered, because there is an Answer() cmd, and the caller hears prompts and menus before hitting a queue.
(05:43:04 PM) mjordan: What is the disposition of the channel in the CDR with unanswered=yes?
(05:43:42 PM) danfromuk: mjordan: ANSWERED
(05:44:50 PM) mjordan: For both the ;1 and the ;2?
(05:45:38 PM) mjordan: and when you go into the Queue, what is the disposition of the channel that talks to the Queue member?
(05:46:06 PM) mjordan: I'd imagine you have something like: SIP/foo, Local/company_648;1 as one record
(05:46:16 PM) mjordan: and Local/company_648;2 ... ? as another record
(05:46:18 PM) danfromuk: mjordan: one moment. unanswered is now 'no' but i'm still seeing duplicate cdr lines.
(05:46:45 PM) danfromuk: I'm going back to 11.5.1. One moment.
(05:46:54 PM) mjordan: I'm not sure what you mean by duplicate CDR lines. And this behavior hasn't changed in any version recently.
(05:47:00 PM) mjordan: Or quite frankly, since 1.8.0-ish
(05:47:35 PM) mjordan: the last time we changed behavior of CDRs was Asterisk 12, and we rewrote most of it (and most people will probably hate it)
(05:47:59 PM) danfromuk: The same cdr record, twice. Identical fields.
(05:48:39 PM) mjordan: I'm not aware of that happening in any issue I've seen. At this point, I think if you want someone to look at this more in depth, you'll need to attach a full DEBUG log to the issue, along with sample records demonstrating what you're seeing.
(05:48:44 PM) mjordan: Include as well the channel names involved.

{quote}

So, to reiterate, what we'll need at this point to figure out why the behavior is the way that it is:
# DEBUG logs (that is, DEBUG up through ERROR messages) showing the call flow of a sample call that reproduces this problem
# The channel names involved, and the expected output
# CDR records showing the erroneous output

By: Matt Jordan (mjordan) 2013-12-07 20:49:07.156-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines