ek-soft FAQ
Wie funktioniert die virtuelle TAPI und wozu benötigt man diese?
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
← zurück zum Suchergebnis"