Merkwürdige CDR-Einträge

[philwo]

Hallo,

ich habe in meiner MySQL-Datenbank in der der Asterisk seine CDRs speichern soll, gerade drei (für mich) sehr merkwürdige Zeilen entdeckt. Ich will die CDRs, wenn alles stabil läuft, zur Abrechnung gegenüber meinen Usern benutzen, aber das sieht mir irgendwie noch sehr komisch aus.. hier erstmal zwei ganz normale CDRs, danach drei komische Records. Sie sind genau in der zeitlichen Reihenfolge entstanden. Zwischen diesen CDRs gab es keine anderen.

Kurz zum Aufbau: Es gibt zwei Nebenstellen, 101 und 102. Beide können raustelefonieren. Die Calls gehen über Hosteurope raus, das ist unsere outbound Leitung. Über Hosteurope sollen aber keine Calls reinkommen! Die Nummer kennt niemand und eingehenden Anrufen von Hosteurope ist auch gar kein Context zugeordnet in der extensions.conf (der "catch-all Context" heißt bei mir "sonstiges" und enthält keine Anweisungen).

Die ersten beiden CDRs zeigen zwei normale Anrufe.

calldate: 2007-11-30 09:29:12
callerid: "Herr X" <101>
src: 101
dst: 00419876444333
dcontext: kunde
channel: SIP/101-08202670
dstchannel: SIP/hosteurope_out-081b7ae0
lastapp: Dial
lastdata: SIP/00419876444333@hosteurope_out
duration: 576
billsec: 563
disposition: ANSWERED
amaflags: 3

calldate: 2007-11-30 09:44:52
callerid: "Herr X" <101>
src: 101
dst: 01234888999
dcontext: kunde
channel: SIP/101-08202670
dstchannel: SIP/hosteurope_out-081b7ae0
lastapp: Dial
lastdata: SIP/01234888999@hosteurope_out
duration: 149
billsec: 139
disposition: ANSWERED
amaflags: 3

Die nächsten beiden CDRs kann ich mir überhaupt nicht erklären.

- Zur exakt der gleichen Zeit wie der erste Call scheint ein umgekehrtes Gespräch anzufangen?
- CallerID 102 kann so nicht stimmen - wenn es von uns kommt, steht immer der Name dabei und von außerhalb kommt wohl kaum eine CallerID "102" herein...
- Was soll "dst: s" mir sagen? "s" ist doch der Start-Context, aber.. den benutze ich nirgendwo!
- Channel hosteurope_out (!!) ist die Quelle (??) und ruft 102 an. Als dstchannel wählt Asterisk sich das Telefon 101 ???

calldate: 2007-11-30 17:08:58
callerid: 102
src: 102
dst: s
dcontext: kunde
channel: SIP/101-081b50f8
dstchannel: <leer>
lastapp: <leer>
lastdata: <leer>
duration: 33
billsec: 23
disposition: ANSWERED
amaflags: 3

calldate: 2007-11-30 17:09:21
callerid: 102
src: 102
dst: s
dcontext: sonstige
channel: SIP/hosteurope_out-082180a8
dstchannel: SIP/101-081b50f8
lastapp: <leer>
lastdata: <leer>
duration: 332
billsec: 325
disposition: ANSWERED
amaflags: 3

Hier noch: Im Channel steht <ZOMBIE>! Das tritt doch aber nur bei Transfers auf?

calldate: 2007-11-30 17:09:21
callerid: "Frau Y" <102>
src: 102
dst: 02345777999
dcontext: kunde
channel: SIP/102-081b9068<ZOMBIE>
dstchannel: SIP/hosteurope_out-082180a8
lastapp: Dial
lastdata: SIP/02345777999@hosteurope_out
duration: 10
billsec: 3
disposition: ANSWERED
amaflags: 3

Ich würde mich sehr freuen, wenn ihr mir helfen könntet, diese Verwirrung aufzuklären :-/ Wenn ich die Konfiguration posten soll, sagt mir einfach, welche genau benötigt wird.. sie ist größtenteils nach Betateilchens-Howto erstellt worden und enthält keine besonders komplizierten Sachen.

Viele Grüße!
Philipp

EDIT:
Ich benutze Asterisk 1.4.14 - die Fehler sahen mir zuerst ganz nach http://www.ip-phone-forum.de/showthread.php?t=146039 aus, aber das soll ja angeblich in meiner Version schon gefixed sein? :-/

 

[Netview]

Welchen Revisionsstand hat bei dir das modul cdr.c (show version files)?

Wenn der Revisionsstand 89622 ist, dann ist das Problem leider wieder reingerutscht:

closes issue #11379; OK, this is an attempt to make both sides happy. To the cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.

der angehängt patch hilft (jedoch nur bei rev. 89622 und höher !!!)

 

[philwo]

Danke für den Tipp!!! Ich werde ihn ausprobieren, denn ich habe Revision 89622

Allerdings habe ich den CDR-Kram jetzt schon komplett deaktiviert und durch eine Lösung ersetzt, die auf ANSWEREDTIME aufbaut...

[macro-outboundruf]
exten => s,1,Set(calltime=${STRFTIME(${EPOCH},UTC,%Y\-%m\-%d\ %H\-%M)})
exten => s,n,Dial,${ARG1}
exten => s,n,Goto,s-${DIALSTATUS}|1
exten => s,n(hangup),Hangup

exten => s-BUSY,1,Playtones,busy
exten => s-BUSY,n,Busy,5

exten => s-CANCEL,1,Hangup

exten => s-CONGESTION,1,Playtones,congestion
exten => s-CONGESTION,n,Congestion,5
exten => s-CONGESTION,n,Hangup

exten => h,1,GotoIf($[0${ANSWEREDTIME} = 0]?end)
exten => h,n,MYSQL(Connect connid <dbserver> <dbuser> <dbpass> <dbname>)
exten => h,n,MYSQL(Query resultid ${connid} INSERT\ INTO\ cdr\ VALUES\ (\'\'\,\'${calltime}\'\,\'${CALLERID(all)}\'\,\'${ARG1}\'\,\'${ANSWEREDTIME}\'\,\'${ARG2}\'))
exten => h,n,MYSQL(Disconnect ${connid})
exten => h,n(end),Goto(s|hangup)

[outbound_kd10000]
exten => _0.,1,macro,outboundruf|SIP/${EXTEN}@sipgate_out|kd10000

Funktioniert soweit sehr schön. Ich werde aber CDR mit Patch nochmal aktivieren und schauen, ob bei beiden das gleiche rauskommt, wäre ja mal interessant.

Viele Grüße,
Philipp