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.

Hier sind noch Hinweise zum CDR
AC Syslog

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:

• AC Syslog
• NXLog
• Syslog

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:

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.

• ConvertFrom-Csv
  http://technet.microsoft.com/en-us/library/hh849890.aspx
• Import-Csv
  http://technet.microsoft.com/en-us/library/hh849891.aspx

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

• AC Syslog
• NXLog
• Syslog
• ConvertFrom-Csv
  http://technet.microsoft.com/en-us/library/hh849890.aspx
• Import-Csv
  http://technet.microsoft.com/en-us/library/hh849891.aspx