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
Beachte dazu auch MSXFAQ.DE:AC 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.
Audiocodes Syslog Viewer
Mittlerweile gibt es von Audiocodes ein eigenes Programm zum Anzeigen der SYSLOG-Dateien. Sie finden es im Download-Bereich von Audiocodes. Das Programm selbst prüft über die folgenden URLs die bei Audiocodes verfügbare Version.
http://redirect.audiocodes.com/install/syslogViewer/info.txt
Der Download ist auch direkt unter folgender URL möglich:
https://www.audiocodes.com/library/firmware
http://redirect.audiocodes.com/install/syslogViewer/syslogViewer-setup.exe
Der große Vorteil bei dem Programm ist, dass es die Meldungen "versteht" und sogar SIP-Diagramme erstellt. Hier ein Beispiel:
Der SyslogViewer kann aber noch mehr. Wenn mehrere SIP-Konversationen in einem Log sind, dann ordnet er diese zusammen und zeigt die Verbindungen samt SIP-Ablaufdiagram an. Hier sehen Sie rechts oben zwei Anrufe und das Ablaufdiagram des ersten Anrufs:
So ist es sehr viel einfacher und schneller möglich die betreffenden Anrufe und Probleme zu analysieren. Vor allem ist ein schneller Springen zu den Stellen möglich.
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 Error-Messages, 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 Skript
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.