Audiocodes Syslog

Ein VoIP-Gateway überwacht man am besten per Syslog. Gateways haben in der Regel keine Festplatte oder andere "große Speicher" aber können ihre Ausgaben per SYSLOG an ein Überwachungssystem senden.

Achtung
Damit dieser Parser funktioniert, benötigen Sie mindestens die Firmware 6.6.
Vorherigen Versionen fehlt der Teil "[S=17464150] [SID:654404550]"

Achtung: Firmware 6.6 hat das Syslog-Format geändert. So wird die uhrzeit nicht mehr am Ende angehängt. Wer die Meldungen mit einem SyslogD protokolliert, tut gut daran die Daten mit einem Zeitstempel zu versehen.

Syslog aktivieren

Per Default ist der Syslog auf dem Gateway natürlich abgeschaltet. Wenn eh niemand lauscht muss das Netzwerk und das Gateway nicht zusätzlich belastet werden. Auch wenn viele Installationen den Syslog nur für die Fehlersuche starten, so habe ich es mir angewöhnt, zumindest ein Basislogging auf dem Gateway aktiv zu lassen undzusätzlich auf einem Server die Syslogdaten anzunehmen und abzuspeichern, z.B. mit NXLog.

Aktiviert wird der Syslog unter "Configuration - System - Syslog", zumindest in der Firmware Version 6.6. Ansonsten suchen Sie einfach nach SYSLOG.

Hinterlegen Sie hier die IP-Adresse des SYSLOG-Servers.

Überwachen mit Syslog

Es gibt eine ganze Menge von Produkten, die auch auf Windows laufen, Meldungen per SYSLOG annehmen und in Textdateien oder Datenbanken ablegen. Auch der Microsoft Operation Manager kann solche Logs annehmen. Ich empfehle aber eher einen einfacheren Syslog-Dämon wie z.B. NXLog, der die Daten z.B. in Dateien schreibt. für die Einrichtung und Fehlersuche ist aber auch ACSYSLOG eine nette Software, die Audiocodes bereitstellt. Es ist kein Dienst sondern eine interaktiver Windowsclient, der diverse Meldungen aber auch hervorheben kann, so dass man relativ schnell bei Fehlern die Ursache finden kann. Hier mal ein Musterauszug.

2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(   lgr_psbrdex)(1275139   )  pstn recv <-- INCOMING_CALL (src:17012345678 dst:304613 redirect1: redirect2:) Trunk:0 Conn:255 BChannel:23 OffhookInd:0 MoreDigits:0 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275140   )  #52:LOCAL_INCOMING_CALL_EV(Trunk:0 Conn:255 Bchannel:23 ServiceCap=V SrcPN=17012345678 DstPN=304613 SrcSN= DstSN= SrcNT=2 SrcNP=1 SrcPres=0 SrcScrn=3 DstNT=4 DstNP=1 RdrctNum= RdNT=0 RdNP=0 RdPres=0 RdScrn=0 RdRsn=0 Excl=0 Display= OrigPN= CPC=-1 TpEv=66) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275141   )  |       #52:LOCAL_INCOMING_CALL_EV [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(lgr_media_service)(1275142   )  MscmlSignalFeature Allocated ResourceID: 80 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275143   )  EndPoint channel# 52 ::Active DSP ChannelsCounter (D|A)= 1|0  [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(   lgr_psbrdif)(1275144   )  pstn send --> ISDNCallProceeding() Trunk:0 Conn:255 BChannel:23 Loc:0 Des:1 rc:0 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_call)(1275145   )  (#38) Call Allocated. [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275146   )  |       #52:NEW_CALL_EV (send)  : (UnKnown) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275147   )  |       |       #38:NEW_CALL_EV:(UnKnown) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(  lgr_stk_mngr)(1275148   )  Resource StackSession <#38> Allocated [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275149   )  |       |       #38:Call changing states from:IdleState to:NewCallState_Tel2IP [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275150   )  |       |       |       #38:NEW_CALL_EV(Unknown) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_call)(1275151   )  |       |       #38GetNextUI:GlobalUI=1621395776, mACAddrLsb=2341793 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_call)(1275152   )  |       |       #38GetNextUI:GlobalUI=1621395777 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(       lgr_num)(1275153   )  PhoneNumber::AddPrefix - Number change from 17012345678 to 217012345678 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(       lgr_num)(1275154   )  PhoneNumber::AddPrefix - Number change from 217012345678 to 1217012345678 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275155   )  |       (to 304613) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275156   )  |       #52:SETUP_EV (send)  : (UnKnown) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(lgr_media_service)(1275157   )  #52:SignalSubscribtionState changing states from:SUBSCRIBTION_STATE_IDLE to:SUBSCRIBTION_STATE_READY [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275158   )  |       |       #38:SETUP (TO:304613, FROM:1217012345678):(UnKnown) [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_call)(1275159   )  new call from EndPoint [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(       lgr_num)(1275160   )  PhoneNumber::RemovePrefix - Number change from 1217012345678 to 17012345678 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(       lgr_num)(1275161   )  PhoneNumber::AddPrefix - Number change from 17012345678 to +4917012345678 [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(       lgr_num)(1275162   )  PhoneNumber::AddPrefix - Number change from 304613 to +495251304613 [Time: 11-29-2012@19:38:06]
....
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	(      lgr_flow)(1275186   )  ---- Outgoing SIP Message to 192.168.100.100:5068 from SIPInterface #0 ---- [Time: 11-29-2012@19:38:06]
2012-11-29 18:38:07	Local0.Notice	192.168.100.107	INVITE sip:+495251304613@192.168.100.100;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.168.100.107;branch=z9hG4bKac1924406339;alias
Max-Forwards: 70
From: <sip:+491701234567@nawm1000.netatwork.de;user=phone>;tag=1c1924385001
To: <sip:+495251304613@192.168.100.100;user=phone>

Syslog für CDR

Das Gateway kann aber auch " Verbindungdaten" per Syslog senden. Natürlich können sie hier auch einen anderen SYSLOG-Server angeben. Schließlich gibt es durchaus Firmen, bei denen die Einzelverbindungsnachweise an anderer sicherer Stelle abgelegt werden. Sie können aber auch den gleichen SYSLOGD nutzen, denn die CDR-Einträge sind gut von den normalen Debuglogs zu unterscheiden.

Hier eine Beispielausgabe.

<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 
<142>|CALL_START  |30   |419014956      |0    |1    |-100 |1    |ISDN      |RMT  |192.168.100.100 
  |192.168.100.107     |2    |1    |5251304613          |+495251304613       
  |2    |1    |5246700971          |+495246700971       |-1   |N/A          
  |0    |                    |0    |UNKN |REASON N/A                            
  |0    |0         |0         |0         |0             |669cbd48-06a6-4714-bd53-2492510bcc42            
  |09:43:36.975 uTC Mon May 21 2013  |                                   |                                 
  |0        |0        |0             |0             |-1             |0    |0    |                  
  |-1                  |netatwork.de        |netatwork.de      
  |nawm1000.netatwork.d|nawm1000.netatwork.d|0   ()                            
  |192.168.100.107     |7840           |         |     |N/A              |                  
  |0     (DefaultSRD)           |0              |0              |0           ()                  
  |0            (DefaultRealm)                            |TCP             |46           
  |40             |127         |127          |127       |127        |63720        |5060     
  |AUDIO     
<142>|CALL_CONNECT|50 |2018811590 |0 |21 |1 |1 |ISDN |RMT |192.168.100.100 |192.168.100.107 |2 |1 |5251304621 |+495251304621 |2 |1 |5254809780 |+495254809780 |-1 |g711Ulaw64k |20 |192.168.103.19 |18790|UNKN |REASON N/A |0 |0 |0 |0 |0 |bb8f2dd9-6397-41b8-87cc-36b63b9fedc0 |08:27:08.550 uTC Mon May 21 2013 |08:27:20.550 uTC Mon May 21 2013 | |0 |0 |0 |0 |-1 |0 |0 | |-1 |netatwork.de |netatwork.de |nawm1000.netatwork.d|nawm1000.netatwork.d|0 () |192.168.100.107 |7220 | | |N/A | |0 (DefaultSRD) |0 |0 |0 () |0 (DefaultRealm) |TCP |46 |40 |127 |127 |127 |127 |62327 |5060 |AUDIO
<142>|CALL_END |52 |419014956 |0 |23 |4 |1 |ISDN |RMT |192.168.100.100 |192.168.100.107 |2 |1 |5251304613 |+495251304613 |2 |1 |5246700971 |+495246700971 |0 |g711Ulaw64k |20 |192.168.103.60 |3942 |RMT |GWAPP_NO_USER_RESPONDING |0 |13001 |7834 |0 |0 |669cbd48-06a6-4714-bd53-2492510bcc42 |09:43:36.975 uTC Mon May 21 2013 | |09:43:50.975 uTC Mon May 21 2013 |1 |4 |2076268698 |864914907 |-1 |0 |0 | |0 |netatwork.de |netatwork.de |nawm1000.netatwork.d|nawm1000.netatwork.d|0 () |192.168.100.107 |7840 | | |NO_ANSWER | |0 (DefaultSRD) |0 |0 |0 () |0 (DefaultRealm) |TCP |46 |40 |127 |127 |127 |127 |63720 |5060 |AUDIO

Auch bei CDR sehen Sie, dass sich Audiocodes zwar des Syslog-Protokolls über 514/UDP bedient, aber die übermittelten Texte nicht der "RFC5424 The Syslog Protocol " folgen. Der Header ist zwar noch mit der <142> codiert (Facility 17 (=Local1) und Severity = 6 (information), aber danach kommt kein Zeitstempel sondern einfach die Zeile

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>

Glücklicherweise gibt es mit NXLog eine sehr flexible Lösung auch solche Logs zu verarbeiten. Über die Konfiguration kann NXLOG die CDR-Einträge gezielt heraus filtern und anderweitig ablegen oder weiter geben.

Syslog-Auszug

Ein Mediant 1000 senden z.B. sehr ausführliche Meldungen an diesen Server, die Informationen zur internen Verarbeitung enthalten aber auch die decodierten SIP-Meldungen, was speziell beim Einsatz mit TLS bei der Fehlersuche hilfreich ist. Zudem werden Normalisierungen, Routingentscheidungen und vieles mehr angezeigt. Hier mal ein "Auszug" einer solchen Aufzeichnung.

<132>[S=17464150] [SID:654404550] (   lgr_stk_ses)(17433722  )   (#599)SIPSBCDialogLeg Deallocated
<132>[S=18874922] [SID:1267902267] (   lgr_stk_ses)(18843421  )   <SESSION #755> SendToCall - event: RELEASE_ACK_EV  m_Call#1566
<132>[S=18874923] [SID:1267902267] (      lgr_flow)(18843422  )   |       |       (#1566)SBCCall <- (#755)SIPSBCDialogLeg: RELEASE_ACK_EV
<132>[S=18874924] [SID:1267902267] (      lgr_flow)(18843423  )   |       |       (#1566) SBCCall changing states from:DisconnectingState to:DisconnectedState
<132>[S=17464151] [SID:654404550] (     sip_stack)(17433723  )   Resource SIPMessage deleted - #9
<132>[S=17464152] [SID:654404550] (     sip_stack)(17433724  )   Resource SIPMessage deleted - #182
<132>[S=18874925] [SID:1267902267] (      lgr_flow)(18843424  )   |       (#1566)SBCParticipantEndPoint <- (#1566)SBCCall: RELEASE_ACK_EV
<132>[S=17464153] [SID:654404550] (       lgr_sbc)(17433725  )   (#66) SBCRoutesIterator Deallocated.
<132>[S=18874926] [SID:1267902267] (      lgr_flow)(18843425  )   (#1566) SBCParticipantEndPoint changing states from:ReleaseingState to:ReleasedState
<132>[S=18874927] [SID:1267902267] (   lgr_psbrdex)(18843426  )   DELETE_RSRC inserted für (#1566)SBCParticipantEndPoint
<132>[S=17464154] [SID:654404550] (       lgr_sbc)(17433726  )   (#170) FEATURE Deallocated.
<132>[S=18874928] [SID:1267902267] (      lgr_flow)(18843427  )   (#502)SBCController <- (#1566)SBCParticipan
<132>[S=18874950] [SID:1267902267] (      lgr_call)(18843449  )   (#1567) CALL Deallocated.
<132>[S=18874951] [SID:1267902267] (      lgr_call)(18843450  )   (#1566) CALL Deallocated.
<132>[S=18874952] [SID:1267902263] ErrMgs=7 -- Invalid RTCP packet SSRC:  Expected = 0x3430736d  Received = 0xdf201dba [Code:0x3700e] [CID:72]
<132>[S=18874953] [SID:1267902263] (      lgr_flow)(18843451  )   ---- Incoming SIP Message from 10.1.1.1:5060 to SIPInterface #1 udpTransportObject[#1] ----
<132>[S=18874954] [SID:1267902263] SIP/2.0 183 Session Progress 
<132>Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bKac147569030 
From: "Carius, Frank" <sip:+4952513094613;ext=613@msxfaq.de;user=phone>;tag=1c146383577;epid=488482777B 
To: <sip:+4952467009@10.1.1.1:;user=phone>;tag=gK08f696aa 
Call-ID: 14627078130920131@10.1.1.1: 
CSeq: 1 INVITE 
Contact: <sip:+4952467009@10.1.1.1::5060> 
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,OPTIONS 
...

Syslog auf dem Ethernet.

Syslog-Pakete sind meistens UDP-Pakete, d.h. Ungesichert. Wenn niemand "hört" dann sind die Daten einfach verloren. Wer daher dauerhaft überwachen will, sollte einen Dienst wie z.B. NXLog einsetzen und die empfangene Daten in Dateien speichern. Gerade der Einsatz einer SyslogD-Software liefert gerne Dateien, die aber nicht genau dem entsprechend, was der Sender übermittelt. Viele SyslogDaemons addieren z.B. einen Zeitstempel, die IP-Adresse des Senders und andere Mehrwerte. Einen Blick auf die "nackten" Daten bekommen Sie aber z.B. mit jedem Netzwerkschnüffler wie NetMon 3 oder WireShark und einem Filter auf "udp.port ==514":

Achtung: Hier mal ein Auszug einer anderen Datei, die etwas anders aussieht. Hier sind vor den eigentlichen SYSLOG-Daten noch ein Zeitstempel, Syslog-Severity und IP-Adresse des Absenders zu sehen. Zudem sind die Felder mit einem "Tabulator" getrennt, was an den kleinen orangenen Pfeilen zu sehen ist. Dies ist aber eine Aufbereitung durch den SYSLOGD, den sie verwenden.

Wenn ich den Syslog z.B. durch NXLog nutze, dann wird das Log einfach so unverändert protokolliert und es beginnt direkt mit dem String.
Danach ist es aber nur noch ein String, der manuell zu parsen ist. Aber auch dieses Feld folgt bestimmten Regeln, auch wenn es Ausnahmen gibt.

Zeitstempel im Trace

Wer Logs auswertet, ist froh um einen Zeitstempel als Anhaltspunkt. Je "dümmer" ein Gerät ist, desto kniffliger ist eine korrekte Zeit. viele Geräte können keinen NTP-Server abfragen oder senden gar keine Zeit mit. Ideal ist natürlich, wenn man dazu auf der Empfängerseite einfach einen Zeitstempel addiert. Das hat zudem den Vorteil das ein Protokoll mehrerer Syslog-Sender auch zeitsynchron ist.

Achtung
Die Firmware 6.6 sendet keine Zeitstempel per Default mehr mit. Ich habe daher meinem NXLog beigebracht, lokal einen Zeitstempel zu addieren. Eventuell müssen Sie ihren eigenen Logger oder das Skript anpassen.

Der Audiocodes Mediant kann einen NTP-Server fragen und sendet auch einen Zeitstempel mit. Aber das Verhalten hat sich je nach Firmware geändert. Hier ein paar Beispiele:

  • Gar keine Datum und Zeit-Information im SYSLOG
    So gesehen an einem "Audiocodes-Sip-Gateway-Mediant 1000/v.5.60A.030.003"
<133>( sip_stack)(6072349 ) New SIPMessage created - #60
  • Nur die uhrzeit angehängt
  • Datum und Zeit am Ende der Message angehängt
    So gesehen an einem "Audiocodes-Sip-Gateway-Mediant 1000/v.6.40A.042.004"
<133>( sip_stack)(6072349 ) New SIPMessage created - #60 [Time: 05-21-2013@14:00:57]
  • Nur die uhrzeit angehängt
    Gesehen an einem "Audiocodes-Sip-Gateway-MP-112 FXS/v.6.20A.025"
<133>( sip_stack)(2907629 ) Resource SIPMessage deleted - #28 [Time: 14:43:05]
  • Gar keine uhrzeit mehr direkt im Syslog
    So gesehen an einem "Mediant 1000 - MSBG/v.6.60A.027.014"
<133>[S=5248] [SID:626747846] ( sip_stack)(4868 ) SIPTCPMngr::ReleaseTransportObj - #495
  • Syslog-Server
    Und dann gibt es natürlich noch die Syslog-Server die selbst in die Logdateien gerne weitere Daten addieren.

Achtung:
Die Zeitstempel im Log sind nicht immer akkurat. ich verzichte mittlerweile darauf und lasse vom Syslog-Server einen Zeitstempel addieren.

Parsen der Syslog-Ausgaben

Sicher könnte ich ein PowerShell-Skript schreiben, welches selbst direkt auf 514/UDP lauscht und die Daten verarbeitet. Aber das würde in den meisten Fällen mit einem bestehenden SyslogD wie NXLog in Konflikt stehen, der eh schon die Daten einsammelt und als Datei speichert. Also ist das Skript einfach ein Textparser, der die Daten per STDIN annimmt und in kleine Häppchen aufteilt. Über Programme wie Get-Tail kann ich bestehende Dateien einfach nachverarbeiten und muss daher auch nicht "Realtime" arbeiten. Schaut man sich die Zeilen mal an, dann sind vier Zeilen zu erkennen:

<132>[S=18874952] [SID:1267902263] ErrMgs=7
<132>[S=18874953] [SID:1267902263] (      lgr_flow)(18843451  )   ---- Incomi
<132>[S=18874954] [SID:1267902263] SIP/2.0 183 Session Progress
Mehrzeiligen Einträge ohne S und SID Eintrag und vor allem ohne <132>-Prefix
<142>|CALL_START  |30   |419014956      

Es gibt also ErrorMessages, interne Meldungen zur Verarbeitung, Manchmal noch ein CDR-Eintrag und die SIP-Meldungen. Siehe auch (AC SNMP). Seit der Firmware 6.6 sind zwei Felder sehr interessant.

  • [S=xxxxx]
    Dies ist eine Sequenznummer, die zumindest bei Audiocodes immer weiter hochgezählt wird und ihnen ermöglicht, fehlende Zeilen zu erkennen. Syslog nutzt nämlich UDP und wenn da mal ein Paket verloren geht, würde dies sonst nicht auffallen.
  • [SID:xxxxxxx]
    Jede SIP-Session bekommt hier eine zufällige Nummer, die aber während der kompletten Transaktion unverändert beibehalten wird. Sie ist also ein sehr guter Filter, um alle Meldungen zu einer bestimmten Verbindung zu gruppieren. Beim Betrieb per SBC, bei dem der Mediant zu beiden Seiten per SIP spricht, bleibt diese Nummer für beide SIP-Meldungen erhalten, so dass Sie hier dann die komplette Transaktion filtern können

Auswerten per Script

Es gibt mehrere Dinge, die per Skript mit den SYSLOG-Dateien interessant sein könnten

  • Konvertierung nach Snooper
    Auf der Seite Syslog2Snooper habe ich schon das Dateiformat von Snooper beschrieben, um SIP-Daten zu visualisieren. Ein kleines Skript kann die SYSLOG-Ausgaben einlesen und so schreiben, dass diese von Snooper gelesen werden. Die Fehlersuche kann so deutlich einfacher sein.
  • Call-ID-Trennung
    Analog dazu könnte ein Skript gezielt nach den SIP-Paketen suchen und die Übertragungen nach Call-ID in einzelne Dateien aufteilen. So könnten einzelne Transaktionen schon vorab extrahiert werden
  • Fehlersuche
    Das Gateway protokolliert Fehlermeldungen ebenfalls per SYSLOG. Es wäre durchaus interessant diese Meldungen z.B. in ein Enterprise-Reporting zu melden
  • Auditing
    Auch Zugriff auf die Verwaltungsoberfläche können so protokolliert werden. für ein Auditing und Change-Management sind solche Events wichtig. Allerdings sollten sie im Rahmen eines Log-Managements vielleicht direkt die Meldung per SYSLOG an das Überwachungssystem überlegen
  • CDR-Auswertung
    Die Protokollierung der CDR-Records ist natürlich sowohl für eine Gebührenabrechnung eine Quelle aber auch für Statistiken interessant, z.B. wir intensiv die Leitungen belegt sind, wie viele Gesprächsminuten pro Zeiteinheit genutzt werden. So können Engpässe frühzeitig erkannt werden.

Sicher fallen ihnen noch andere Skripte ein.

Weitere Links