Asterisk 1.4.4 multiple CDRs

Asterisk Asterisk Support
1

Anyone know why I might be getting multiple CDRs for incoming calls on 1.4.4? I did not used to get this on 1.4.2.

[pstn-in] exten => s,1,Dial(SIP/201&SIP/202&SIP/203,15,tL(3600000)
is resulting in 1 CDR for the incoming call (from ZAP line in this case) PLUS one CDR for each sip phone.

Previously I only got one record. I’m sure this is just a config issue that shows up because somethings been fixed but I can’t quite see what it is. It’s like there’s one CDR for each channel instead of each call.

Any ideas?

2

Much worse than this, call forwards of incominig calls appear to have their caller id overwritten so: -

Call comes in on a Zap line with callerid ABC <0123456> to SIP/200, then transferred to SIP/205, in 1.4.2 the CDRs would have read: -

“ABC <0123456>” called “200” for some duration
"ABC <0123456>" called “205” for some other duration

Under 1.4.4 it seems to show: -

“200” called “200” for some duration
"200" called “205” for some other duration

so the original caller ID is lost completely.

Odd.

3

I am using:
asterisk 1.4.4
zaptel 1.4.2.1
Centos 4.4 (rhel 4)

I also see multiple CDRs (two CDRs). The first one is

logger.c: -- Nobody picked up in 10000 ms chan_zap.c: Requested indication -1 on channel Zap/4-1 rtp.c: Channel 'Zap/4-1' has no RTP, not doing anything cdr_pgsql.c: cdr_pgsql: SQL command executed: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield) VALUES ('2007-05-15 22:49:16','','','s','default', 'Zap/2-1','','','',12,0,'NO ANSWER',3,'','117928','') channel.c: Hanging up channel 'Zap/2-1' chan_zap.c: zt_hangup(Zap/2-1) Hangup: channel: 2 index = 0, normal= 12, callwait = -1, thirdcall = -1
and then further down the message.log

logger.c: -- Hungup 'Zap/2-1' app_dial.c: Exiting with DIALSTATUS=NOANSWER pbx.c: Launching 'VoiceMail' <snip> cdr_pgsql.c: cdr_pgsql: inserting a CDR record. cdr_pgsql.c: cdr_pgsql: SQL command executed: INSERT INTO cdr calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield) VALUES ('2007-05-15 22:49:15','"LAST, NAME " <1234567890>','1234567890','s','incoming','Zap/4-1','Zap/2-1','Hangup','',40,39,'ANSWERED',3,'','117928','')

It looks like it logs a separate entry for Channel 2??!? I don’t know why?
in my dialplan (extension.conf)

exten => s,5,Dial(Zap/2|10|t) exten => s,6,Voicemail(su1000)

I can’t figure out why?
It didn’t do it in 1.4.2.

4

Okay I think I found the answer.
Check out this thread http://lists.digium.com/pipermail/asterisk-users/2007-April/186315.html.

5

Well spotted! That answers one point, about the extra records.

I’ve still got the one outstanding about transfeerd calls completely loosing (overwriting) their caller id (even on the 1st leg CDR) but at least there’s some light at the end of the tunnel.

6

The Overwriting of the callerID is also affecting 1.2.17 .

I have a server on 1.2.10 and its fine on 1.2.17 the callerID is overwitten. I am about to write a workaround using the channelid and accountcode. to get over the problem. As all calls have the callerIDnum set for outgoing cli.

Ian

7

hello, any progress on this? i’ve the same problem with doubled CDR when NO ANSWER sate.

8

Hello! I’m Steve Murphy. If you have a CDR problem,
it’s either because I broke it, or haven’t gotten around to fixing it yet.

I am working on 2 main fronts right now. One is developing a new CDR system based
on events (like manager, but tailored to CDRs), and the other is to try to fix the existing
CDR system.

The original CDR system was developed before Asterisk was able to do forwarding.
It’s been hacked quite a bit, but, really, it is not able to handle transfers in general. In some situations, it will do the job, but that’s just plain luck.

Any changes I make are going to be disruptive, and break people’s implementations. So, unless the fix is fairly simple, I won’t be applying them to 1.2 or 1.4. I have a branch, the asterisk/team/murf/CDRfix5 branch, which is based on trunk, where I am doing the ‘radical’ fixes, and these may someday be applied to trunk, and might be done in time to make it into 1.6.

The ‘radical’ fix changes the philosophy behind generating CDR’s. First, I take the code out that posts (detaches) a cdr on hangup. Instead, I go the bridging code and form a CDR for each bridge that takes place. So, no conversation, no CDR. If this isn’t what you want, I will supply a CDR_CONTROL function, so you can create your own CDR’s. It’s customized to work well in the dialplan. You can set the start, answer and end times, and you pretty much are allowed to change any field to what you want. If you change your mind, you can destroy them. You can have several overlapping CDR’s. It’s up to you. So, if you absolutely must track stuff like incoming calls that hang up in the dialplan before they talk to somebody, you should be able to do stuff like this in the dialplan using CDR_CONTROL. ForkCDR will become useless, as it relied on the hang-up methodology to actually get the CDR’s posted.

I’m finding that some (most? all?) SIP phones will be hard to tie forwarded calls together in CDR’s, because they don’t use asterisk bridges to accomplish 3-ways. The phone itself links the two channels, and there’s no trace in asterisk of what’s going on.

At any rate, in the interests of making as few enemies as possible, I’d love to try to poke the system to solve the problems you are seeing. Unfortunately, I’m off Mon-Wed this week for vacation. As soon as I get back, I’d like to investigate the probs with double CDRs, and maybe calm down the NO ANSWER cdrs for grouped calls, and hopefully fix that nagging prob with clid getting lost. I have made a bunch of fixes to 1.4 and trunk Thurs/Fri, so you might try updating and see if any of the changes I made have helped or harmed.

murf

9

murf

I have been following your posts on -users and -dev, and on your blog, and I think you heading on the right awy to getting CDR’s fixed. I have also had issues trying to trace forwarded and redirected calls from the CDR in it current form, and its not been good…:frowning: I hope, no, I know your new implemenation will turn out awesome. I especially like that you dont forget the rest of the Asterisk community when writing new code, you keep us in the loop, and you actually make an effort to canvas the Asterisk community to find out what our opinions are. I really like that.

btw, I think AEL2 kicks ass!