CTI Server

Unable to start CTI service showing "Error 2:Windows could not start the server service on Local computer"

a) Issue Description:
Unable to start CTI service showing "Windows could not start the server service on Local computer".
Event viewer logs:
b) Components to Verify:
What to Check
Where to Check
CTI Server
Verify if the websocket server port provided in config is already in use. Do a netstat to the port and check if port is used.
<add key="WebSocketServerPort" value="1337"/>
Below is the command to run in CTI server,
netstat -ano|findstr <port number>
CTI Service
Check if service is provided with valid exe path
1. Navigate to services window.
2. Check the CTI service.Right click the service and check the if provided the valid TetherfiCTIServer exe file.
c) Troubleshooting:
Avaya tsapi clientCheck if avaya tsapi client is installed in server.
Vc++ redist 2015
Check if Microsoft Visual C++ Redistributable 2015 (*84bit) is installed.
Note: The has to be x86 installed since Tsapi is a 32 bit program.

Unable to login to TMAC and error is Invalid extension

Issue description: Unable to login to TMAC and error is Invalid extension.

CTI server logs

2020-04-29 20:28:45,003 [3] ERROR TetherfiTSAPIServer.TetherfiTSAPIServer - Exception in ResetSessionForStation:System.NullReferenceException: Object reference not set to an instance of an object.

at TetherfiTSAPIServer.TetherfiTSAPIServer.ResetSessionForStation(String sessionID)

2020-04-29 20:30:34,277 [3] DEBUG TetherfiTSAPIServer.TetherfiTSAPIServer - SecurityLogout:,2,AVAYA#CMSIM#CSTA#AESSIM:2020-04-29 20:30:34,277 [3] ERROR TetherfiTSAPIServer.TetherfiAgentSession - Exception in GetWrapperServerSessionForStation:System.ArgumentNullException: Value cannot be null.

Parameter name: key

at System.Collections.Concurrent.ConcurrentDictionary`2.ContainsKey(TKey key)   at TetherfiTSAPIServer.TetherfiAgentSession.GetWrapperServerSessionForStation(String sessionID)

TSAPI server logs:

2020-04-30 08:48:37,246 [3] DEBUG TetherfiTSAPIWrapper.TSAPIWrapper - maindevice1:GetQueueStatus failed for extension maindevice1, invokeID 84855, reason is acsHandle is nullptr:

Solution: ws port in CTI server and in TMAC server has to be same.

Application unable to connect to the API on POM WAS server. Fails with error HttpWebRequest The underlying connection was closed: An unexpected error occurred on a send

Issue Description:

While configuring an API link from POM CTI server config and application trying to access an external API but fails with the following message ,

"HttpWebRequest The underlying connection was closed: An unexpected error occurred on a send"

Troubleshooting Information:

Step 1: Try to simulate the issue in the lab environment.  The error was not able to be simulated in a lab environment.

Step 2: Try to establish the connection to API via postman - successful

Try to call the API link from the browser - successful

Step 3: Create a custom application to trigger the API call from other servers and observe the behavior.

Simulate the UAT behavior from SIT servers.

Copy the same custom application for API call into 4 SIT servers

Server1: API call fails with error

Server2: API call is successful

Server3: API call fails with error

Server4: API call is successful

Step 4: Do a continuous netstat on the POM WAS server(where the API is deployed)  while making a call to API.

The connection to the port does not establish, we see the request in "TIME_WAIT" mode.

Step 5:Do a trace on the server level with Wireshark application

From Server where API fails: no server hello seen

From Server where API is successful: Server hello seen

Possible Root Cause:

The client-server handshake is failing. https://www.thesslstore.com/blog/explaining-ssl-handshake/




SCHANNEL setting on Registry for ciphers:

Server Hardening:

Since there is a difference between 2 SIT servers, a possible guess could be due to server hardening.

So the server hardening script was run on [Server2: API call is successful]

After the server was hardened the API call failed on Server2

While comparing the cipher and SChannel keys from a hardened UAT server that can make a successful  API call to the same POM WAS server, the difference was seen with the Diffie-Hellman key [enabled=0].

Adding the key to the client servers where the API call failed resolved the issue.

The difference in the key exchange algorithm between the server and client seems to have an impact. The dependency also will be the cipher order used in the server(POM WAS).