ek-soft FAQ
Virtuelle TAPI
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt derzeit vor einer kritische Schwachstelle in Apache Java-Bibliothek log4j. (CVE-2021-44228; CSW-Nr. 2021-549032-1432).
Kein Produkt aus unserem Hause verwendet die bemängelte Java-Bibliothek log4j. Es sind keine Aktionen erforderlich
Letzte Änderung am: 14.12.2021, 14:03 Uhr
Meldung: Mind. ein Telefongerätetreiber ist nicht mit Tapi.DLL kompatibel
Dies ist ein Problem, das im Zusammenhang mit dem Microsoft Windows Dialer.exe zu stehen scheint und hat nichts mit unserem Windows-TAPI-Treiber zu tun. Es kann auch mit anderen Treibern wie CISCO oder Avaya und sogar AVM-Fritz beobachtet werden. Das Problem ist, das eine falsche Vorgabe durch den Microsoft Dialer für die Adresse der TAPI-Leitung verwendet wird.
Es kann wie folgt gelöst werden:
1. Führen Sie dialer.exe aus.
2. Gehen Sie zu „Extras“ -> „Verbindungen über“ und wählen eine Leitung aus. (Klicken Sie auf OK wenn Sie Treiber-Fehlermeldungen sehen.)
3. Kümmern Sie sich nicht um die Adress-Einstellung, da Sei bei dem Fehler nicht die Auswahl haben. Klicken Sie nur auf OK.
4. Schließen sie jetzt die dialer.exe.
5. Starten sei die Registry und gehen Sie zu HKEY_CURRENT_USER -> Software -> Microsoft -> Windows -> CurrentVersion -> Dialer
6. „Preferred Address“ wird wahrscheinlich auf -1 gesetzt sein. Setzen Sie den Wert auf 0.
7. Starten Sie die dialer.exe erneut.
Testaprooved4
Letzte Änderung am: 27.02.2019, 15:20 Uhr
Die virtuelle TAPI ist Bestandteil des DIALit Enterprise Servers (ab 4.2). Ist kein DIALit vorhanden, kann die virtuelle TAPI auch separat lizenziert werden (CTIgate Tapi- und Socket-Server). Mit dieser Lösung wird der Original TAPI Treiber des/der TK-Hersteller nur noch am JServer benötigt, nicht mehr am Client oder auf einem Terminalserver.
Die virtuelle TAPI benötigt man z.B. dann, wenn ein Tapi2.x Treiber eines TK-Herstellers auf dem eingesetzten Client PC oder Terminalserver nicht betrieben werden kann, weil z.B. keine Freigabe für Terminalserver besteht oder keine 64 Bit Version z.V. steht. Außerdem ist die Problematik der Rechtevergabe wesentlich einfacher gelöst und auch ein Rollout ohne echte TAPI am Client läuft wesentlich reibungsloser. Außerdem gibt es manche TK-Hersteller deren TAPI Treiber nur an einem PC abgegriffen werden kann, über die virtuelle TAPI kann dieser von dort aus in das gesamte Firmennetzwerk publiziert werden.
Funktionsweise der virtuellen TAPI 2.x:
Die Original Tapi2.x besteht auf einem Windows Betriebssystem aus der Microsoft tapi32.dll. Diese wird mit den lokal zu installierenden Original TAPI Treibern der TK-Hersteller versorgt.
Bei 64 Bit Betriebssystemen wird von 32 Bit Programmen die tapi32.dll im Windows-Syswow64 Verzeichnis benutzt. 64 Bit Programme nutzen die tapi32.dll aus dem Windows-System32 Verzeichnis. Bei 32 Bit Betriebssystemen gibt es nur eine tapi32.dll im System32 Verzeichnis.
Eine Tapi 2.x Applikation lädt die tapi32.dll. Sie findet diese über die PATH Systemvariable, welche standardmäßig in das entsprechende System Verzeichnis verweist. Typischerweise sucht eine Applikation eine zu ladende DLL aber immer zuerst im eigenen Programmverzeichnis. Die Idee ist es also, im Programmverzeichnis der ausführenden EXE eine ek-soft tapi32.dll (32 oder 64 bit) zu platzieren um damit die Original tapi32.dll zu emulieren. Die ek-soft tapi32.dll kommuniziert dabei mit einem eigenem verschlüsseltem Protokoll mit dem CTIgate, welches auf dem DIALit Jserver läuft. Das CTIgate wird nur noch dort über die TAPIConnectoren von den Original TAPI Treibern der TK-Hersteller versorgt.
Durch diese Technik ist es möglich alle „TAPI Problematiken“, insbesondere im Terminalserverumfeld zu eliminieren.
Die ek-soft tapi32.dll verhält sich gegenüber der Tapi2.x Applikation wie die Original TAPI. Aus der TAPI Spezifikation sind die gängigsten Line-Funktionen in die virtuelle TAPI implementiert worden. Phone-Funktionen werden typischerweise von Standard TAPI Applikationen nicht benutzt und werden daher auch nicht unterstützt. So könnte es also sein, dass falls eine uns unbekannte Applikation eine solche Line- oder Phone-funktionen verwenden möchte, es nicht funktioniert. Daher die notwendige Vorklärung, am besten mit Verträglichkeitstest.
Eine aktuelle Liste mit den unterstützten Funktionen und bereits getesteten Applikationen kann bei ek-soft abgerufen werden.
Bekannt ist, dass Microsoft ab Office 2007 eine „fremde“ tapi32.dll nicht akzeptiert. Hier gibt es um aus Office wählen zu können, außer DIALit Enterprise selbst, oder dem „abgespecktem“ Office/Outlook-Addin des CTIGnomes, derzeit keine Möglichkeit auf die Original TAPI am Client oder Terminalserver zu verzichten.
Die tapi32.dlll im System Verzeichnis von Windows lässt sich ebenfalls nicht austauschen. Diw Windows dialer.exe kann auch nicht in eine anderes Verzeichnis verlagert werden. Die Windows dialer.exe kann daher nicht mit der virtuellen TAPI betrieben werden.
Grundsätzliche Voraussetzung, damit eine „fremde“ Applikation an der virtuellen TAPI betrieben werden kann ist, dass diese auch an dem Original TAPI Treiber funktionieren würde. Benötigte TAPI Funktionen die schon im TAPI Treiber nicht unterstützt sind, kann auch das CTIGate über die virtuelle TAPI nicht zur Verfügung stellen.
Tapi 3.x Applikationen sind selten anzutreffen. Tapi 3.x wird daher nicht unterstützt.
Letzte Änderung am: 29.07.2015, 09:31 Uhr
Wenn Dateien während des Setup ausgetauscht werden müssen, oder Dienste neu gestartet werden müssen, wird dies während des Setup angezeigt. Am Ende des Setups kann die Aufforderung zum Neustart des Computers dann mit Ja oder nein beantwortet werden. Somit ist kein zwingender Neustart sofort erforderlich. Allerdings empfehlenswert, weil eine Installation noch nicht vollständig abgeschlossen ist und evtl. erforderliche Dateien noch nicht in der richtigen Version vorliegen. Auf einem Terminalserver der nachts automatisch neu gestartet werden kann, würde es Sinn machen, die Installation erst kurz vor Feierabend anzustoßen.
Letzte Änderung am: 11.10.2014, 10:34 Uhr