Corrupt CDR records in Asterisk 1.2.x


#1

I have a problem with CDR recording in Asterisk 1.2.x. This is the
situation:

An Asterisk 1.2.0 (BRIstuffed-0.3.0-PRE-1 with florz) machine with a single
HFC-S ISDN BRI card. I log the call records to both the Master.csv and
MySQL.

The problem is that when an incoming call from the ISDN line is logged to
the CDR, the “src” and the “clid” field show up as something like ‘h?’
(random weird ASCII characters). This is in the MySQL table as well as the
Master.csv, so my guess is that it is not a MySQL problem. Furthermore, I
don’t think it is a zaptel/bristuff problem, because my AGI scripts get the
incoming number without problems all the time.
The internal SIP calls are logged without a problem all the time. It’s only
ISDN calls from the outside world that are corrupt.

When I stop Asterisk with “stop now” and restart it, the “src” and "clid"
fields are OK for a while, but after a few calls, or as some time passes by
(I don’t know what triggers it), it goes back to the ‘random ASCII
weirdness’.

I also tested this with Asterisk 1.2.4 (BRIstuffed-0.3.0-PRE-1h with florz)
and I have the same problem. Again, when I start Asterisk, everything is OK
for a while, and then suddenly, the src and clid fields are like ‘ÀÜ’

Anybody has a clue as where to start looking for a solution for this
problem? I can’t seem to find a single post, list e-mail or bug related to
this problem.

Thanks,

Jeroen Zwarts


#2

Hi,

I also have this problem. I investigated a bit, and it seems that it happens for everyone using HFC-S ISDN BRI cards.

I contacted Junghanns (the company which makes the bristuff patch), but they didn’t reply anything constructive :frowning:


#3

Reply to self:
Last week I had some time to figure out a workaround for the CDR logging problem.
I used an AGI-script together with de Mysql CLI application.
It is far from perfect, and I want to spend some more time to figure out a better way, but this seems to be working OK on my testmachine:

This is what I do:

I run a DeadAGI script in the Hangup extension like this:


exten => h,1,Deadagi (fixcdr.sh)
exten => h,2,Hangup()

The /var/lib/asterisk/agi-bin/fixcdr.sh looks like this:


#!/bin/bash

read agi_request
read agi_channel
read agi_language
read agi_type
read agi_uniqueid
read agi_callerid
read agi_calleridname
read agi_callingpres
read agi_callingani2
read agi_callington
read agi_callingtns
read agi_dnid
read agi_rdnsid
read agi_context
read agi_extension
read agi_priority
read agi_enhanced
read agi_accountcode

set – $agi_uniqueid
uniqueid="’"$2"’"

set – $agi_callerid
telefoonnummer="’"$2"’"

echo -e “mysql --user=asterisk --password=asterisk --exec=‘use cdr;UPDATE cdr SET src=\042$telefoonnummer\042 WHERE uniqueid=\042$uniqueid\042’” >> /test/runthis.sh

echo -e “mysql --user=asterisk --password=asterisk --exec=‘use cdr;UPDATE cdr SET clid=\042$telefoonnummer\042 WHERE uniqueid=\042$uniqueid\042’” >> /test/runthis.sh

And then I let cron run the runthis.sh script. And the runthis.sh executes the SQL strings in the file with the mysql monitor application.
The place where you put the runthis.sh must be writeable for the user that Asterisk runs on (in my situation running Gentoo it is the user asterisk with group asterisk)

As I already told, it is far from perfect (I have to find a way to empty the runthis.sh file after cron has taken care of the CDR updates, and it would be nicer to put the 2 SQL statements together).
I don’t think you can use this in a high volume environment too, because of the possible load increase on your database when running the runthis.sh.

But I wanted to share this with you, I hope it may be helpful to you people having problem with BRIStuff/CDR.

Jeroen


#4

I noticed that putting something like that:

[mappings]
Master-new.csv => “${CDR(clid)}”,"${CDR(src)}","${CDR(dst)}","${CDR(dcontext)}","${CDR(channel)}","${CDR(dstchannel)}","${CDR(lastapp)}","${CDR(lastdata)}","${CDR(start)}","${CDR(answer)}","${CDR(end)}","${CDR(duration)}","${CDR(billsec)}","${CDR(disposition)}","${CDR(amaflags)}","${CDR(accountcode)}","${CDR(uniqueid)}","${CDR(userfield)}"

into /etc/asterisk/cdr_custom.conf (I had to create a new file) repairs the logging magically…


#5

That would be much better if that works for me too! I’ll go test it right away.

Thanks!

Edit: Hmm, I already have a cdr_custom.conf with the exact same line that you wrote here. So I guess that doesn’t work for me. But i’ll have a look anyway…


#6

Should work for you, too.

I made this change when I added a second HFC card to the asterisk box, so now I’m not sure if it was that change that fixed it, or the second card (or both).

Anyway, let me know, I’m curious too.

BTW, I’m using asterisk@home 2.2, but it doesn’t seem to be raleted to asterisk@home.


#7

for what it’s worth…
I reported this error (on corrupt cdr records) to Junghanns also, a few weeks ago. They replied it would be fixed in a next version. (i reported it when using the 0.3.0pre1k version, but it’s not fixed in -l, so hang on a version)

cheers


#8

seems to be fixed with

Asterisk: 1.2.7.1
BRIsttuff: bristuff-0.3.0-PRE-1p


#9

That’s fixed, yes.

But make sure, after updating to a recent release, you are not suffering from the “HANGUP” problem. In some case (all?) the BRI interface doesn’t hangup like it should.

Meaning, if you call out your ISDN interface, and drop the line, the ZAP channel “seems” to be down, but the other side is still ringing. (as if it wasn’t hungup)

There’s a (temp) fix posted on the mailing list.

cheers


#10

I don’t seem to have that problem, - where do I find the mailing list you mentioned please?