• ISDN-Rufumleitung in der Vermittlungsstelle
  • Download
• QEMU Guest Agent installieren
• TLS-Zertifikat austauschen

Diese Seite fasst Erfahrungen zusammen, die ich beim Einrichten unserer STARFACE-Telefonanlage sammeln konnte.

ISDN-Rufumleitung in der Vermittlungsstelle

Normalerweise erfolgt die Umsetzung einer vom Benutzer eingerichteten Umleitung in der STARFACE-Telefonanlage, d.h. bei einer Umleitung auf eine externe Nummer wird durch die STARFACE eine Verbindung zu dieser Nummer hergestellt und auf die eingehende Verbindung geschaltet.

Diese Lösung hat zwei Nachteile:

• Am Endgerät, an das der Anruf weitergeleitet wurde, sieht man nur die Nummer der Telefonanlage und nicht die des Anrufers.
• Bei einem Anruf über ISDN werden zwei B-Kanäle (einer für den eingehenden und einer für den ausgehenden Anruf) benötigt.

ISDN bietet allerdings auch die Möglichkeit eine Rufumleitung in der Vermittlungsstelle zu veranlassen (CD-PR, Call Deflection Partial Routing). Dies muss die Telefonanlage allerdings entsprechend signalisieren, was bei der STARFACE in der Standard-Konfiguration nicht der Fall ist.

Ich habe deshalb ein kleines Modul geschrieben, das eine entsprechende Signalisierung übernimmt. In der aktuellen Version funktioniert das Modul allerdings nur für Umleitungen vom Typ "Immer" und "Besetzt". Umleitungen bei Zeitüberschreitungen werden aufgrund von Beschränkungen durch die für das Modul verfügbaren Funktionen weiterhin durch die Standard-Funktion der STARFACE-Anlage übernommen.

Damit das Modul korrekt funktioniert, müssen in der Konfiguration alle Leitungen eingetragen werden, für die es aktiv sein soll. Dies sind normalerweise alle externen ISDN-Leitungen. Je nach Anschlusstyp (Mehrgeräte- oder Anlagen-Anschluss) muss zwischen dem SrxDeflect- und SrxReroute-Kommandos gewählt werden (siehe Referenz). Bei einigen Tests funktionierte SrxReroute an einem Vodafone/Arcor-Anlagenanschluss.

Download

Das Modul wird kostenlos zur Verfügung gestellt, entsprechend gibt es keine Gewähr für korrekte Funktionsweise und die Nutzung erfolgt auf eigene Gefahr. Es wird unter den Bedingungen der GNU General Public License Version 3 zur Verfügung gestellt.

• ISDNUmleitung_v92.sfm (für STARFACE ab Version 6.4.2)
• ISDNUmleitung_v91.sfm (für STARFACE ab Version 6.1)
• ISDNUmleitung_v89.sfm (für STARFACE ab Version 5.1)
• ISDNUmleitung_v88.sfm (für ältere STARFACE Versionen)

QEMU Guest Agent installieren

Wenn die STARFACE als VM auf einem QEMU/KVM (z.B. mit libvirt) Host läuft, will man, dass sie heruntergefahren wird, wenn der VM-Host heruntergefahren wird. Dummerweise reagiert die STARFACE standardmäßig nicht auf ein einzelnes ACPI-Shutdown-Event, sondern braucht drei solcher Events innerhalb von 30 Sekunden, was die normalen Shutdown-Skripte von libvirt nicht unbedingt sicherstellen.

Der einfachste Weg das zu lösen ist den QEMU Guest Agent in der STARFACE-VM zu installieren (und in der VM-Konfiguration auf dem Host einen Channel für dem QEMU Guest Agent anzulegen). Dann erfolgt das Herunterfahren über den Guest-Agent statt per ACPI-Event.

Die ausführliche Anleitung für die Installation des QEMU-Guest-Agent ist bei RedHat zu finden. Hier sind die wesentlichen Schritte:

Sollte STARFACE irgendwann von CentOS 6 auf eine neuere Version wechseln, wären die Schritte wie folgt anzupassen:

Vom VM-Host aus, kann das Funktionieren der Verbindung mit dem Guest Agent wie folgt überprüft werden:

TLS-Zertifikat austauschen

Das TLS-Zertifikat für Tomcat und der zugehörige private Schlüssel ist in einem Java-Keystore gespeichert.

In älteren Versionen von STARFACE befindet sich dieser unter  /usr/share/tomcat6/ssl/tomcat.keystore, in neureren Versionen unter /opt/tomcat/ssl/tomcat.keystore und /var/starface/tomcat/ssl/keystore.jks.

Das Passwort für den Keystore lautet „changeit“. Falls nicht nur ein neues Zertifikat hochgeladen werden soll (was über die Webserver-Oberfläche möglich ist), sondern auch der private Schlüssel ausgewechselt werden soll, kann diese Datei mit der Software KeyStore Explorer bearbeitet werden.

KeyStore Explorer kann leider nicht mit Zertifikaten und Schlüsseln im PEM-Format umgehen. Deshalb muss zunächst eine PKCS12-Datei mit dem Schlüsselpaar (Server-Zertikat, privater Schlüssel für Server-Zertifikat, ggf. Zertifikate von Zwischenzertifizierungsstellen) erstellt werden. Dies kann mit OpenSSL erfolgen:

Beim Export muss ein Passwort angegeben werden. Dieses Passwort muss dann erneut beim Import in KeyStore Explorer angegeben werden.

Der Eintrag muss in KeyStore Explorer unter dem Namen tomcat importiert werden. Ein ggf. schon vorhanderer Eintrag gleichen Namens kann ersetzt werden. Beim Import wird auch nach einem Passwort gefragt mit dem das importierte Schlüsselpaar geschützt werden soll. Dort muss das Passwort „changeit“ (das gleiche, dass auch den gesamten Key-Store schützt) angegeben werden.

Falls sich das Zertifikat der Root-CA geändert hat, muss dieses ebenfalls unter dem Eintrag root importiert werden. Auch hier kann ein ggf. schon vorhandener Eintrag ersetzt werden. Um ein evtl. im PEM-Format vorhandenes Zertifikat der Root-CA zu importieren, muss dieses zunächst in das DER-Format umgewandelt werden: