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.
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:
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.
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…
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.
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)
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)
