Audiocodes CDR

Über die Syslog-Funktion des Audiocodes (Siehe AC Syslog) können auch Daten zur Telefonie-Verwendung gesammelt werden. Dieses Skript werdet die Daten hieraus aus. Ziel ist nicht die personenbezogene Auswertung der Daten in Hinblick auf Profile, Arbeitszeitkontrolle o.ä., obwohl es natürlich kein großer Schritt dahin ist.

Was könnte interessieren ?

Wenn Sie etwas über den Inhalt der Daten nachdenken, dann sind folgende Werte auch ohne Bezug zu einzelnen Personen oder Rufnummern interessant.

  • Gesamtminuten
    Wie intensiv Lync das Gateway nutzt, lässt sich auch ohne Analyse der individuellen Gesprächsteilnehmer alleine an den gesamten GEsprächsminuten erfassen.
  • Verteilung der Gespräche über Zeit und Dauer
    Diese Zahlen sind wichtig um z.B. die "Busy Hour" zu ermitteln, also den Zeitraum der höchsten Belastung um basierend darauf zukünftige Empfehlungen zum Ausbau zu geben.
  • Anzahl Calls mit Ergebnisstatus, Eingehend, Ausgehend
    Sicher kann sich jemand in der Nummer irren, so dass keine Verbindung zustande kommt. Aber über längere Zeit sollte "Erfolgsrate" nicht allzu stark schwanken. Aber es kann durchaus interessant sein, ob bestimmte Nummern immer wieder falsch angerufen werden. Denkbar sind auch Auswertungen bezüglich "Wara Dialing", d.h. auffällige Anrufe
  • NPI/TON Auswertungen
    Gerade bei der Verbindung über ISDN ist neben der eigentlichen Rufnummer auch die Information zu NPI/TON wichtig. Insbesondere bei eingehenden Gesprächen kann dies sehr bei der Fehlersuche helfen. Es ist mir schon passiert, dass die vorgeschaltete TK-Anlage durch ein Update (unwissentlich oder absichtlich) diese Daten verändert hat und damit die Zustellung in Lync nicht mehr funktioniert hat. Es hilft, wenn man belegen kann, dass nicht Lync die Ursache für eine Unterbrechung war.
  • QoS Aussagen
    In den CDR-Datensätzen protokolliert der Mediant auch zumindest einfache QoE-Informationen mit. Das ist insbesondere interessant, wenn kein Monitoring Server vorhanden ist oder die Daten im Monitoring-Server nicht ausreichen. Denn bei Mediabypass sendet der Mediant leider keine entsprechenden QoE-Reports an Lync, so dass Sie nur die Seite des Clients sehen.
  • Abrechnung
    Erst am Ende würde ich die Funktion sehen, dass anhand der CDR-Daten auch nach Rufnummer eine Zuordnung der Gebühren möglich sein kann. Hier würde ich aber eher das Lync Monitoring sehen.

Und sicher noch einiges mehr. Es gibt also schon Gründe die CDR-Daten zumindest im Rahmen des erlaubten rechtlichen Rahmens zu erfassen.

CDR aktivieren

Um die Daten aber zu sehen, muss zuerst auf dem Mediant die CDR-Funktion aktiviert werden. Hier die passenden Einstellungen:

Sie sehen aber auch, dass der Mediant die Daten einfach per "SYSLOG" versendet, d.h. er speichert diese nicht lokal und sie müssen irgendwo einen SYSLOGD installiert haben. Dazu habe ich auf anderen Seiten schon etwas geschrieben:

Aufbau der Tabelle

Es ist etwas abhängig, wie der SYSLOG-Datensatz als Datei oder Eingabe aussieht, da verschiedene SYSLOG-Server die empfangenen Daten teilweise mit einem Zeitstempel, Source-IP-Adresse und der Severity o.ä. erweitern. Die vom Mediant gesendete SYSLOG-Meldung enthält neben der Source/Severity die folgenden Felder, die durch einen senkrechten Strich (Pipe) unterteilt sind. Manchmal sendet der Mediant auch einen "Header" mit, der wie folgt aussieht:

<142>|GWReportType|Cid |SessionId |Trunk|BChan|ConId|TG |EPTyp |Orig |SourceIp |DestIp 
 |TON |NPI |SrcPhoneNum |SrcNumBeforeMap |TON |NPI |DstPhoneNum |DstNumBeforeMap 
 |Durat|Coder |Intrv|RtpIp |Port |TrmSd|TrmReason |Fax |InPackets |OutPackets|PackLoss 
 |RemotePackLoss|SIPCallId |SetupTime |ConnectTime |ReleaseTime |RTPdelay |RTPjitter|RTPssrc
 |RemoteRTPssrc |RedirectReason |TON |NPI |RedirectPhonNum |MeteringPulses |SrcHost
 |SrcHostBeforeMap |DstHost |DstHostBeforeMap |IPG (description) |LocalRtpIp |LocalRtpPort
 |Amount |Mult |TrmReasonCategory|RedirectNumBeforeMap|SrdId (name) |SIPInterfaceId |ProxySetId
 |IpProfileId (name) |MediaRealmId (name) |SigTransportType|TxRTPIPDiffServ|TxSigIPDiffServ
 |LocalRFactor|RemoteRFactor|LocalMosCQ|RemoteMosCQ|SigSourcePort|SigDestPort|MediaType
<141>[S=199249] |GWReportType|Cid |SessionId |Trunk|BChan|ConId|TG |EPTyp |Orig |SourceIp |DestIp
 |TON |NPI |SrcPhoneNum |SrcNumBeforeMap |TON |NPI |DstPhoneNum |DstNumBeforeMap
 |Durat|Coder |Intrv|RtpIp |Port |TrmSd|TrmReason |Fax |InPackets |OutPackets|PackLoss
 |RemotePackLoss|SIPCallId |SetupTime |ConnectTime |ReleaseTime |RTPdelay |RTPjitter|RTPssrc
 |RemoteRTPssrc |RedirectReason |TON |NPI |RedirectPhonNum |MeteringPulses |SrcHost
 |SrcHostBeforeMap |DstHost |DstHostBeforeMap |IPG (description) |LocalRtpIp |LocalRtpPort
 |Amount |Mult |TrmReasonCategory|RedirectNumBeforeMap|SrdId (name) |SIPInterfaceId |ProxySetId
 |IpProfileId (name) |MediaRealmId (name) |SigTransportType|TxRTPIPDiffServ|TxSigIPDiffServ|
 LocalRFactor|RemoteRFactor|LocalMosCQ|RemoteMosCQ|SigSourcePort|SigDestPort|MediaType
 |AMD| % |SIPTrmReason|SIPTermDesc |PstnTermReason|LatchedRtpIp |LatchedRtpPort 2 

Hinweis:
Beachten Sie bitte, dass es in dem Header das Feld "TON" und "NPI" mehrfach gibt.

Achtung: Welche Firmware es genau war, habe ich noch nicht bestimmt, aber die 6.60A nutzt als CDR-Kennzeichen nun die "<141>" und nicht mehr <142> und addiert noch ein paar Felder dazu

Die Spalten im einzelnen mit Musterdaten:

Header Beispiel Beschreibung

GWReportType

CALL_END

Enthält den Typ und kann die folgenden Werte annehmen

CALL_START
CALL_CONNECT
CALL_END

Cid

30

 

SessionId

947042220

 

Trunk

0

Nummer der ISDN-Trunks

BChan

1

Nummer des B-Kanals

ConId

0

 

TG

1

 

EPTyp

ISDN

Endpunkt-Typ

Orig

RMT

 

SourceIp

192.168.100.100

 

DestIp

192.168.100.107

 

TON

2

 

NPI

1

 

SrcPhoneNum

5251304613

 

SrcNumBeforeMap

+495251304613

 

TON

2

 

NPI

1

 

DstPhoneNum

52467000971

 

DstNumBeforeMap

+4952467000971

 

Durat

3

 

Coder

g711Ulaw64k

 

Intrv

20

 

RtpIp

192.168.103.31

 

Port

24342

 

TrmSd

LCL

 

TrmReason

GWAPP_NORMAL_CALL_CLEAR

 

Fax

0

 

InPackets

173

 

OutPackets

152

 

PackLoss

0

 

RemotePackLoss

0

 

SIPCallId

6d15d4bc-7d91-4804-9ef9-5c5b4ec2e98

 

SetupTime

17:19:41.825  uTC Sun Nov 11 2013

 

ConnectTime

17:19:50.575  uTC Sun Nov 11 2013

 

ReleaseTime

17:19:54.350  uTC Sun Nov 11 2013

 

RTPdelay

0

 

RTPjitter

0

 

RTPssrc

1728345157

 

RemoteRTPssrc

3748250122

 

RedirectReason

-1

 

TON

0

 

NPI

0

 

RedirectPhonNum

 

 

MeteringPulses

0

 

SrcHost

netatwork.de

 

SrcHostBeforeMap

netatwork.de

 

DstHost

nawm1000.netatwork.d

 

DstHostBeforeMap

nawm1000.netatwork.d

 

IPG (description)

0 ()

 

LocalRtpIp

192.168.100.107

 

LocalRtpPort

7680

 

Amount

4

 

Mult

 

 

TrmReasonCategory

NORMAL_CALL_CLEAR

 

RedirectNumBeforeMap

 

 

SrdId (name)

0 (DefaultSRD)

 

SIPInterfaceId

0

 

ProxySetId

0

 

IpProfileId (name)

0 ()

 

MediaRealmId (name)

0 (DefaultRealm)

 

SigTransportType

TCP

 

TxRTPIPDiffServ

46

 

TxSigIPDiffServ

40

 

LocalRFactor

127

 

RemoteRFactor

127

 

LocalMosCQ

127

 

RemoteMosCQ

127

 

SigSourcePort

51511

 

SigDestPort

5060

 

MediaType

AUDIO

 

AMD

 

Erst ab Firmware 6.60

%

 

Erst ab Firmware 6.60

SIPTrmReason

 

Erst ab Firmware 6.60

SIPTermDesc

 

Erst ab Firmware 6.60

PstnTermReason

0

Erst ab Firmware 6.60

LatchedRtpIp

 

Erst ab Firmware 6.60

LatchedRtpPort 2

 

Erst ab Firmware 6.60

Die Daten sind also schon relativ umfangreich und durchaus für eine Auswertung interessant.

Auswerten mit PowerShell

Bitte erwarten Sie keine vollständige Auswertung oder gar eine fertige Software. Ich weiß ja nicht welche Ergebnisse Sie aus ihren Daten extrahieren wollen. Ich stoppe dort, wo die Daten in einem strukturierten Format in PowerShell für eine weitere Verarbeitung zur Verfügung stehen. für die weitere Verarbeitung in SQL Reporting Services, SharePoint o.ä. kann ich bei Bedarf dann auf die "richtigen" Entwickler und Designer bei Net at Work zurückgreifen, die das dann nach Kundenwunsch "schick" machen können.

Diese Beispiele basieren darauf, dass die CDR-Records aus dem SYSLOG schon extrahiert wurden und entsprechend vorliegen.

Leider ist der Header im Syslog nicht direkt geeignet, weil das Feld "TON" und "NPI" gleich dreimal enthalten ist. Da hat ein Entwickler wohl nicht aufgepasst. Das ist aber einfach zu lösen, da wir sowieso den Header mit angeben müssen.

Um die CDR-Dateien in PowerShell aufzubereiten bedarf es gar nicht viel: Wir müssen nur den Header definieren, damit dieser beim Import-CSV oder ConvertFrom-CSV mit angegeben werden kann. Hier am Beispiel mit ConvertFrom-CSV.

$header = "Syslog","GWReportType","Cid","SessionId","Trunk","BChan","ConId","TG","EPTyp",`
           "Orig","SourceIp","DestIp","TON1","NPI1","SrcPhoneNum","SrcNumBeforeMap","TON2",`
           "NPI2","DstPhoneNum","DstNumBeforeMap","Durat","Coder","Intrv","RtpIp","Port",`
           "TrmSd","TrmReason","Fax","InPackets","OutPackets","PackLoss","RemotePackLoss",`
           "SIPCallId","SetupTime","ConnectTime","ReleaseTime","RTPdelay","RTPjitter",`
           "RTPssrc","RemoteRTPssrc","RedirectReason","TON3","NPI3","RedirectPhonNum",`
           "MeteringPulses","SrcHost","SrcHostBeforeMap","DstHost","DstHostBeforeMap",`
           "IPG (description)","LocalRtpIp","LocalRtpPort","Amount","Mult",`
           "TrmReasonCategory","RedirectNumBeforeMap","SrdId (name)","SIPInterfaceId",`
           "ProxySetId","IpProfileId (name)","MediaRealmId (name)","SigTransportType",`
           "TxRTPIPDiffServ","TxSigIPDiffServ","LocalRFactor","RemoteRFactor",`
           "LocalMosCQ","RemoteMosCQ","SigSourcePort","SigDestPort","MediaType"


#Damit wird aus den langen Zeichenketten schöne einfach anzusprechende Objekte

get-content "cdrfile" | Convertfrom-Csv -Delimiter "|" -Header $header | where {$_.GWReportType -ne "GWReportType"}

Syslog               : <142>
GWReportType         : CALL_END
Cid                  : 52
SessionId            : 419014956
Trunk                : 0
BChan                : 23
ConId                : 4
TG                   : 1
EPTyp                : ISDN
Orig                 : RMT
SourceIp             : 192.168.100.100
DestIp               : 192.168.100.107
TON1                 : 2
NPI1                 : 1
SrcPhoneNum          : 5251304613
SrcNumBeforeMap      : +495251304613
TON2                 : 2
NPI2                 : 1
DstPhoneNum          : 5246700971
DstNumBeforeMap      : +495246700971
Durat                : 0
Coder                : g711Ulaw64k
Intrv                : 20
RtpIp                : 192.168.103.60
Port                 : 3942
TrmSd                : RMT
TrmReason            : GWAPP_NO_USER_RESPONDING
Fax                  : 0
InPackets            : 13001
OutPackets           : 7834
PackLoss             : 0
RemotePackLoss       : 0
SIPCallId            : 669cbd48-06a6-4714-bd53-2492510bcc42
SetupTime            : 09:43:36.975 uTC Mon May 21 2013
ConnectTime          :
ReleaseTime          : 09:43:50.975 uTC Mon May 21 2013
RTPdelay             : 1
RTPjitter            : 4
RTPssrc              : 2076268698
RemoteRTPssrc        : 864914907
RedirectReason       : -1
TON3                 : 0
NPI3                 : 0
RedirectPhonNum      :
MeteringPulses       : 0
SrcHost              : netatwork.de
SrcHostBeforeMap     : netatwork.de
DstHost              : nawm1000.netatwork.d
DstHostBeforeMap     : nawm1000.netatwork.d
IPG (description)    : 0 ()
LocalRtpIp           : 192.168.100.107
LocalRtpPort         : 7840
Amount               :
Mult                 :
TrmReasonCategory    : NO_ANSWER
RedirectNumBeforeMap :
SrdId (name)         : 0 (DefaultSRD)
SIPInterfaceId       : 0
ProxySetId           : 0
IpProfileId (name)   : 0 ()
MediaRealmId (name)  : 0 (DefaultRealm)
SigTransportType     : TCP
TxRTPIPDiffServ      : 46
TxSigIPDiffServ      : 40
LocalRFactor         : 127
RemoteRFactor        : 127
LocalMosCQ           : 127
RemoteMosCQ          : 127
SigSourcePort        : 63720
SigDestPort          : 5060
MediaType            : AUDIO

Die Ausgabe der Datensätze über die Pipeline können Sie sehr einfach mit PowerShell filtern oder mit "Group" auch zusammenfassen oder in andere Datenformate überführen.

Zukunft

Ich will es nicht beschwören aber vielleicht reichte ich später doch noch mal ein Stück Code und Beschreibung nach, um die Daten in eine SQL-Datenbank zu überführen und mit SQL-Reporting-Services o.ä. eine weitergehende Auswertung zu erlauben.

Wenn Sie selbst basierend auf meiner Vorarbeit eine solche Lösung umgesetzt und veröffentlicht haben, dann würde ich gerne davon erfahren und ggfls. hier zu verlinken.

Weitere Links