Incomming call is directly closed when any tapi client is connected

[A_nd_y]

Hi!

I'm just trying to get the TAPI client up and running and I've encountered a strange problem:

The driver is configured and outgoing calls can be started.
However, all incoming calls for an extension are immediately rejected as soon as any TAPI client is registered for it.
If I close the TAPI Client again, the phone rings again too.

Does anyone have a tip for me what this could be?

Some additional Infos:

Software version		65.0.8 (Debian64)
Build date			May 30 2020 18:30:57

[0:01:38:703]:7 DeliveredEvent(0xxxxxxxxxxx, yyyyyy17, 05af1c4a@pbx)

[0:01:38:703]:7 Incoming call from 0xxxxxxxxxxx

[0:01:38:703]:7 Notify new call to TAPI

[0:01:38:703]:5 TSPI_lineCloseCall

[0:01:38:719]:5 CSTA Tx: <?xml version="1.0" encoding="UTF-8"?>

<ClearConnection xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed6">

<connectionToBeCleared>

<callID>05af1c4a@pbx</callID>

<deviceID>17@************.com</deviceID>

</connectionToBeCleared>

</ClearConnection>



[0:01:38:719]:7 Clear connection with 0xxxxxxxxxxx

[0:01:38:719]:4 Call was not accepted by TAPI

[0:01:38:719]:5 CSTA Rx: <?xml version="1.0" encoding="UTF-8"?>

<ClearConnectionResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4"/>

[0:01:38:766]:5 CSTA Rx: <?xml version="1.0" encoding="UTF-8"?>

<ConnectionClearedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed4">

  <monitorCrossRefID>39</monitorCrossRefID>

  <droppedConnection><callID>05af1c4a@pbx</callID><deviceID>17</deviceID></droppedConnection>

  <releasingDevice><deviceIdentifier>17</deviceIdentifier></releasingDevice>

  <localConnectionInfo>null</localConnectionInfo>

  <cause>normalClearing</cause>

</ConnectionClearedEvent>

Quote

 

 

[Vodia PBX]

The trace is very useful. For whatever reason the TAPI subsystem decides to reject the call (see https://docs.microsoft.com/en-us/windows/win32/api/tspi/nf-tspi-tspi_lineclosecall). What I would try is installing it on another system, maybe an older operating system where we can be sure no process is interested in incoming calls except e.g. Outlook. Maybe on this system there is something else trying to consume incoming calls and this is causing the issue.

[A_nd_y]

I tested it again on two clean VM's (only Windows , the TAPI driver and EPhoneX64.exe).

On the first VM with Windows 7 on the last patch level it works.
On the second VM with Windows 10 1909 the call is rejected.

But it is noticeable that under Windows 7 the trace log is written first after EPhone opens the TAPI session.
Under Windows 10 the log is filled directly after the Windows logon.

I need the TAPI connection for our CRM system and my colleagues wait for a solution.
What can I do to get a working fix for the problem?

[Vodia PBX]

My guess would be that the network is not ready in the early stages of the boot up. However that would not explain why a call gets rejected—especially because obviously the TSP does receive traffic from the PBX so that cannot be the problem. In order to solve the problem there are essentially three paths:

The first one would be to back and forth and try to resolve the problem in a Windows 10 system. We could install the ephone.exe and try to reproduce the problem in a debug environment and then make changes to the TSP. Unfortunately debugging TSP is not as straightforward as debugging other programs (TAPI is a very old Microsoft technology; I am not even sure if the latest Visual Studio can still compile the code). What speaks for this solution is that there are still a lot of people out there using TAPI.

The second would be to try to avoid TAPI and instead talk to the CRM directly. For that the question is what CRM this is and if they have a API, ideally a REST API. This would make it possible to look into more features and make the installation of other systems easier.

The third would be to just use Windows 7 or find some registry entries that make Windows 10 behave like Windows 7 in the TAPI subsystem. This would be obviously the least desirable solution.