Komandozeilen basierter Voip/Sip-Client

[sklaes]

Hallo zusammen,
wir betreiben bei uns in der Firma ein Monitoring-System. Dabei handelt es sich um Icinga (auf Linux-Basis), welches ursprünglich von Nagios abstammt und vergleichbar ist mit anderen MonitoringTools wie Check_mk oder OMD.
Hierzu schwirrt mit seit längerem eine Idee bezüglich der Alarmierung im Kopf herum.
Bisher ist es so gelöst, dass Icinga Mails an einen Dienstleister versendet, welcher sporadisch sein Posteingang prüft und dann den Bereitschaftshabenden per Telefon informiert. Dieses hat zur Folge, das zwischen dem Auftreten der Störung und dem Anruf z.T. mehr als eine Stunde vergeht. Meine Idee wäre nun, den Zwischenschritt rauszunehmen und die Anrufe direkt von Icinga aus zu tätigen.

Um die Idee umzusetzen benötige ich einen SIP Client bei dem Folgendes Möglich wäre:

1. Abspielen einer festen Ansage (Damit der Angerufene erkennt was man von Ihm möchte)
2. Optional: Abspielen der Störmeldung (TTS)
3. Warten auf auf eine Eingabe feste Ziffernfolge (Um sicherzustellen, dass keine AB den Anruf angenommen hat)
4. Beenden mit Rückgabewert (Erfolg/Misserfolg)

Bisher habe ich kein Tool gefunden dass eine Eingabe durch den Angerufenen auswertet.

Ich hoffe mir kann einer hier helfen.

Gruß
Sklaes

 

[Rache Klos]

Schon mal über SMS nachgedacht, oder muss es zwingend ein Anruf sein? Wir machen das seit Jahren via SMS und E-Mail. Ein Anruf zu starten, ist an sich aber auch nicht so schwer, da SIP recht einfach aufgebaut ist.

Ich kenne noch ein Tool, mit dem man auch Sprache übertragen kann. Allerdings müsste man da dann ein Audio File erzeugen, was man dann abspielen lässt. Wobei man das ja auch scripten kann, so dass man den Text via TTS in eini WAV File speichert und dann wiederum miti dem CMD SIP Tool den Anruf startet.

https://github.com/tmakkonen/sipcmd
https://wiki.ubuntuusers.de/eSpeak/

 

[sklaes]

@Rache Klos Danke für deine Antwort!
Bei SMS und E-Mail fehlt mir der Rückkanal, d.h. ich kann nicht beurteilen, ob die Störung tatsächlich angenommen wurde oder der Kollege weiterhin seelenruhig pennt.

So weit ich das seh kann sipcmd nur DTMF senden, jedoch nicht empfangen. Das einzige was damit denkbar wäre, ist es den Anruf aufzuzeichnen und nach Beendigung zu analysieren.
Dadurch kann ich jedoch dem Angerufenem keine Rückmeldung geben, ob seien Eingabe gültig war.

 

[Rache Klos]

Und was ist mit Anbindung eines Ticket Systems, die Alarmierung wiederum geht via SMS / E-Mail und die Annahme der Störung erfolgt über ein Ticket System.

 

[sklaes]

@Rache Klos
Ich bin mir gerade nicht sicher in wie weit mir das helfen soll. Nur dadurch, dass ein Ticket eröffnet wurde habe ich ja immer noch keine Gewissheit, dass die Störung angenommen wurde.
Evtl. besteht die Möglichkeit aus unserem Ticketsystem heraus (per Plugin) den usecase zu realisieren, falls es das ist was du sagen möchtest - müsste ich prüfen lassen.

 

[Rache Klos]

Naja in den anständigen Ticketsystemen gibt es Eskalationsstufen, die wiederum bei Überschreiten eine Aktion auslösen. Die Aktion könnte dann z.B. sein, dass eine Mail an einen oder mehrere Eskalationsmanager geht. Irgendwer muss doch bei euch prüfen, ob eine Störung bearbeitet wird oder nicht. Bei uns gibt es halt eine aktive Bereitschaft, die eine Störung per SMS gemeldet bekommt. Das ist zwar keine 100% Garantie, aber wiederum dessen Person ihre Pflicht, auf jeden Fall dafür zu sorgen, dass irgendjemand die Störung bearbeitet. An irgendeiner Stelle muss man sich ja schon auf Menschen verlassen, wenn am Ende des Tages bei euch keiner ans Telefon geht, ist die Störung ja auch nicht angenommen worden.

 

[sklaes]

Wir haben keinerlei Probleme damit das Mitarbeiter, die eine Störung gemeldet bekommen haben, diese nicht bearbeiten. Wir müssen nur sicherstellen, das sie die Nachricht auch wirklich wahrgenommen haben.
Sollte bei uns keiner ans Telefon gehen, dann würde die nächste Rufnummer gewählt werden bis die Störung angenommen wurde.

 

[Tarnatos]

Aber so vom Ablauf her muss es doch eigentlich keinen Telefon Rückkanal geben.

Störung tritt auf, Ticket System löst aus.

Techniker wird informiert.

Techniker reagiert und quittiert Störung im Ticket System.

Techniker reagiert nicht, Störung wird an den nächsten weitergeben.

Quittieren jeweils immer im Ticketsystem. Dort kann man dann jederzeit sehen wer wann was gemacht hat.

Ergänzung (17. März 2019)

Sonst gibt es auch noch Telegramm Plugins.

https://docqube.de/blog/2018-05-06-nagios-und-telegram/