Müll in CDR-Einträgen

[thepontifex]

Hi,

ich werte gerade hier meine CDR Einträge aus und da fällt mir auf, dass einige Einträge weder eine 'src-Nummer' noch eine 'dst-nummer' eingetragen haben.

An der Wählregel, die Asterisk ausgeführt hat, erkenne ich dann zwar, dass der Anruf auf die Durchwahl 0 ging, aber wieso steht denn bei 'src' und / oder 'dst' nix drin?

Gruss
Frank

 

[mausk]

Habe ein ähnliches Problem: Bei mir steht allerdings nicht nichts drin, sondern irgenwie Müll (z. Bsp.: z ). Und dies, obwohl auf dem Endgerät eine vernünftige CallerID angezeigt wird.

Kennt jemand diese Problem bei * 1.2.0 mit bristuff?

 

[merlinab]

habe gleiches Problem wie mausk

Hallo mausk,
ich habe leider genau das gleiche Problem wie du. In meiner Master.csv und in der MySQL-Tabelle tauchen immer wieder so kryptische Zeichen auf. Ich habe leider keien Idee was das ist.
Bitte gib mir bescheid, wenn du eine Lösung hast ;-)

Danke dir
Merlin

 

[poeschl]

Hi,

bei mir ähnlich - bei full logging tritt dann (neben den restlichen Infos) immer folgender Eintrag auf:

Jan 15 13:16:31 DEBUG[32574] pbx.c: Function result is '@<E4>'
Jan 15 13:16:31 DEBUG[32574] pbx.c: Function result is '@<E4>'

Die kryptischen Zeichen (also hier das @<E4>) variieren allerdings. Interessanterweise erkennt asterisk selbst aber die korrekte Rufnummer (entsprechende Nummer statt der X ;-)) - wird auch auf den Telefonen angezeigt:

Jan 15 13:15:43 VERBOSE[2236] logger.c: -- Accepting voice call from '175XXXXX' to '1XXX' on channel 0/1, span 2

Läuft bei mir auf Fedora Core 4 mit 2 HFC-Karten (TE- und NT-Mode) und bristuff-0.3.0-PRE-1f (Problem bestand aber auch bei 1d).

Ciao,
Andreas

 

[VOIPdani]

Habe ähnliches Problem

Hallo!

Mir gehts genau so. In meiner cdr-Tabelle stehen auch ab und zu ziemlich kryptische Zeichen bei src.

Meine sehen so aus:

�w�
@�
 P
��
�C
`�
8b

Ziemlich komisch. Nur was bedeuten diese Zeichen eigentlich?

 

[mausk]

Interessanterweise erkennt asterisk selbst aber die korrekte Rufnummer

Wenn man die Rufnummer mit SetCDRUserField im Userfeld einträgt, dann erscheint sie auch richtig
Ausserdem habe ich festgestellt, dass nach einem Neustart (nicht reload) von Asterisk werden die Rufnummern wieder korrekt eingetragen und irgendwann plötzlich ist es dann wieder vorbei (Rufnummer kryptisch, Userfeld OK).

Gibt's denn für dieses Problem wirklich keine Lösung :noidea: ???

 

[mausk]

Die Rufnummer kann man folgendermassen im Userfeld eintragen:

exten => s,n,SetCDRUserField(${EXTEN})

Evtl. muss das Userfeld zuerst noch aktiviert werden. (Siehe http://www.voip-info.org/wiki-Asterisk+cmd+SetCDRUserField)

 

[udosw]

Meine beiden *e schreiben seit ca. 16.02.06 bei eingehenden Anrufen irgendwelche kryptischen Zeichen (z.B. XXXX) in das Feld "src" der CDR-Tabelle. Nicht immer (aber immer öfter ).

Und zwar fast immer wenn der Anruf über Channel "Zap" reinkommt.

Zeitlich könnte es mit dem letzten Bristuff-Update übereinstimmen.

In der CLI-Konsole wird die Nummer des Anrufers richtig angezeigt, auch per CLIP richtig zum Telefon übertragen, aber sowohl in der CVS- als auch in der MySQL-Datenbank steht Müll.

Tritt bei zwei Asterisken gleichermaßen auf. Version siehe Signatur.

Udo

EDIT von Maik: Ich hab mal gerade die Sonderzeichen entfernt. Die haben anscheinend unseren RSS-Feed kaputt gemacht.

 

[speedy1980]

Asterisk 1.2.2 mit Bristuff PRE-1k ... das mußt Du mir mal erklären. Die *k Version arbeitet mit Asterisk 1.2.4.

Achja die zaptel.conf und zapata.conf wären ganz interessant.

 

[VOIPdani]

Hallo!

Ich habe das Problem auch schon seit längeren, konnte aber leider noch keine Lösung dafür finden. In einem anderen Thread (http://www.ip-phone-forum.de/showthread.php?t=83664) wurde das Problem auch schon diskutiert, aber vielleicht finden wir hier eine Lösung die kryptischen Zeichen aus den cdr-Einträgen zu verbannen?!

lg Dani

 

[udosw]

s.a.: http://www.ip-phone-forum.de/showthread.php?p=540404

Da hab ich in
http://www.ip-phone-forum.de/showthread.php?p=540404#post540404
dasselbe Thema angefangen.

OK, wenn ich mir meine CDR-Datenbank so angucke, würde ich folgendes sagen: Das Problem tritt nur auf
- bei eingehenden Anrufen auf einem Zap-Channel (hier: HFC-Karte).
- das "src"-Feld in der CDR-Datenbank ist verstümmelt,
- das Problem betrifft sowohl die csv-Dateien (/var/log/asterisk/cdr-csv/master.csv) als auch die MySQL-Datenbank (cdr_mysql-Modul)

Mehr zufällig ist mir folgendes aufgefallen:

CLI> zap show status 
Description                              Alarms     IRQ        bpviol     CRC4      
HFC-S PCI A ISDN card 0 [TE] layer 1 AC  OK         0          0          0         
ZTDUMMY/1 1                              UNCONFIGUR 0          0          0         
 
---und---
 
# lsmod |grep zap
zaphfc                 14364  3 
zaptel                189444  11 zaphfc
crc_ccitt               2176  3 zaptel,ppp_async,hisax

Der ZTDUMMY hat da ja wohl nichts zu suchen.

Ich hab' also mal alle module entladen, alle zaptel-Pakete rausgeschmissen und nur bristuff (zaptel und zaphfc) neu kompiliert und installiert.

Jetzt funktioniert es wieder - mal sehen, wie lange ...

Udo

 

[mausk]

Ich hab' also mal alle module entladen, alle zaptel-Pakete rausgeschmissen und nur bristuff (zaptel und zaphfc) neu kompiliert und installiert.

Jetzt funktioniert es wieder - mal sehen, wie lange ...

Udo

Also bei mir funktionierts grundsätzlich immer nach einem Restart von *.
Wie lange es dann funktioniert, konnte ich leider noch nicht feststellen.

 

[udosw]

Ich habe inzwischen rausgefunden, dass ein entladen un neu-laden vom chan_zap-Modul das Problem vorübergehend beseitigt. Nach ein paar Stunden ist es dann wieder da.

pingu*CLI> [B]unload chan_zap.so[/B]
  == Manager unregistered action ZapDialOffhook
  == Manager unregistered action ZapHangup
  == Manager unregistered action ZapTransfer
  == Manager unregistered action ZapDNDoff
  == Manager unregistered action ZapDNDon
  == Manager unregistered action ZapShowChannels
  == Unregistered application 'zapEC'
  == Unregistered channel type 'Zap'
    -- Unregistered channel 1
    -- Unregistered channel 2
    -- Unregistered channel 3
pingu*CLI> [B]load chan_zap.so[/B]
 Loaded /usr/lib/asterisk/modules/chan_zap.so => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
    -- Registered channel 1, PRI Signalling signalling
    -- Registered channel 2, PRI Signalling signalling
    -- Automatically generated pseudo channel
  == Starting D-Channel on span 1
  == Registered channel type 'Zap' (Zapata Telephony Driver w/PRI)
  == Manager registered action ZapTransfer
  == Manager registered action ZapHangup
  == Manager registered action ZapDialOffhook
  == Manager registered action ZapDNDon
  == Manager registered action ZapDNDoff
  == Manager registered action ZapShowChannels
  == Registered application 'zapEC'
pingu*CLI>

Die fehlerfhaften CDR-Einträge (src- und clid-Feld) haben immer 4 Zeichen, die ab dem Auftreten des bei jedem Anruf gleich sind, bis zum neu-laden des Moduls.

Es betrifft nur auf der HFC-Karte eingehende Anrufe.

Komischerweise finde ich in den englischsprachigen Foren keinerlei Hinweise auf dieses Problem.

Leute, die dasselbe Problem haben, sollten mal folgende Fragen beantworten. Vielleicht finden wir irgendwelche Gemeinsamkeiten:

Bei mir (privat und Firma):
- ISDN-Provider: Arcor
- ISDN-Anschlusstyp: Mehrgeräte und Anlagenanschluss
- ISDN-Karte: HFC no-name-Karte von Conrad
- Asterisk: 1.2.4-BRIstuffed-0.3.0-PRE-1k (selbst-kompiliert, mit und ohne florz-Patch und als Debian-Paket von "deb http://rapid.dotsrc.org/")

Udo

 

[betateilchen]

Auf Wunsch von udosw wurden die beiden Threads mit nahezu gleichem Inhalt zusammengelegt.

 

[udosw]

Auf Wunsch von udosw wurden die beiden Threads mit nahezu gleichem Inhalt zusammengelegt.

Das ging aber schnell, danke .

So, Rettung naht, Kapejod weiß Bescheid:
http://lists.digium.com/pipermail/asterisk-users/2006-March/141908.html
Allerdings ist der Fehler bei Junghanns schon seit einem Monat bekannt. Aber OK, it's CeBIT time, und da haben die Kollegen bestimmt anderes zu tun.

Udo

 

[betateilchen]

Das ging aber schnell, danke

Du hast halt Glück gehabt, daß ich grade vom Weintrinken nach Hause kam (es ist grade Besen-Saison) :mrgreen:

 

[VOIPdani]

Hallo,

da ich die Einträge der CDR-Tabelle gerne Auswerten möchte, wollte ich an der Stelle nochmals nachfragen ob schon jemand eine Lösung gefunden hat?

WIE kann ich diese kryptischen Zeichen aus der CDR rauskriegen??

 

[clan]

Der Fehler scheint in Asterisk 1.2.5 behoben zu sein, jedenfalls hat unser Server damit keine Probleme mehr. Laut ChangeLog wurden auch einige Fehler im cdr behoben. Der andere Server (mit quadBRI und bristuff) leidet leider auch darunter

 

[VOIPdani]

Gut, dann werd ich mal warten bis Junghanns einen neuen BRIstuff rausbringt, der Asterisk 1.2.5 enthält und hoffen das dann das Problem nicht mehr auftritt!

 

[udosw]

Das war wohl nix ...

Nach Update auf Asterisk 1.2.6-BRIstuffed-0.3.0-PRE-1n bleibt das Problem leider bestehen: Immer noch fehlerhafte CDRs bei eingehenden Anrufen über ZAP.

Das ist ja echt ärgerlich .

Udo