This document was generated from CDN thread
Created by: Engineering Department on 05-05-2009 10:28:27 PM
I am getting an *Error* Provider Open Failed message when I view the trace log for a particular using running the Cisco TSP. I have attached the log file. The lines are not showing up and when I run a netstat -a to see if port 2748 is open I see that it has a status of Time_Wait. Any ideas on what we should check next? Is it a network issue, TSP issue or Call Manager issue?
Thanks.
Dustin
Subject: RE: *Error* Provider Open Failed
Replied by: David Staudt on 06-05-2009 01:27:17 AM
You might check to see if the user has been assigned 'Standard CTI Secure Connection.' This causes UCM to reject the TSP connection if not fully secured - the typical symptom is a timeout such as you are seeing.
If a non-secure connection is ok, just remove the user from the Secure Connection group.
Subject: RE: *Error* Provider Open Failed
Replied by: Engineering Department on 06-05-2009 01:46:47 AM
Thanks so much David. What would require a user to be a member of the Standard CTI Secure Connection group? In other words, why would a telecom admin choose to have this user a member of this group?
The funny thing is the lines displayed in dialer temporarily. After a reboot they disappeared.
Dustin
Subject: RE: *Error* Provider Open Failed
Replied by: David Staudt on 06-05-2009 04:48:02 AM
The TSP is supplied (in the TSP config UI) with a UCM user credential to connect. By default, this TCP connection to UCM is insecure. By adding the TSP user to the Standard CTI Secure Connection group, this basically 'turns on' secure connection capability (i.e. TLS - see the TAPI dev guide for details.) However, just adding the user to the secure group only effects the 'server side' i.e. the UCM. However if you don't follow through and also configure the client side - the TSP - to use a TLS connection, then you have a mismatch: insecure non-TLS TSP client, and secure TLS UCM server. This prevents the connection from occurring (UCM will not fallback to an insecure connection.)
The advantage of using a secure TSP connection would be to prevent wire-snooping or man-in-the-middle attacks from compromising TSP signaling data (I guess: call IDs.) This turns out to be needed pretty rarely in practice. Note, enabling the TSP to use TLS does not automatically mean that the media/RTP of a call is encrypted.
Subject: RE: *Error* Provider Open Failed
Replied by: Engineering Department on 07-05-2009 08:37:59 PM
How can enabling TLS cause the lines to show up again? Are you assuming that someone is or some thing is interupting the CTI messages as they travel to and from the CTI Mgr? if this is the case, i can see why enabling this will help. I am still working with the telecom vendor in getting this going. Thanks for the help.
Subject: RE: *Error* Provider Open Failed
Replied by: Erik Lauterbach on 29-05-2009 07:29:29 AM
We've got the same errors occuring but we dont use the secure group on the cucm and have not set the secure connection in TSP. Some of the clients are getting this error others not. The error started to appear after we added a primary DNS adress to the cucm and the saving freezed the server so we had to shut it down hard. After that the server came up normaly but then these errors occur on some of the clients. Only a complete reset of the TSP (removing the cisco.tsp entry in telephone and modem options) works to get the lines back working. But on some clients the error comes up again after restarting the computer.... What's causing this!??????
Subject: RE: *Error* Provider Open Failed
Replied by: David Staudt on 29-05-2009 03:04:21 PM
The symptoms you guys are describing definitely sound fishy, so probably not a simple configuration issue. In order to determine the final root cause, we would need to see the logs from the TSP (detailed level/all types) as well as the CTI-Manager service logs from the UCM.
Subject: RE: *Error* Provider Open Failed
Replied by: Erik Lauterbach on 08-06-2009 12:57:25 PM
Problem was solved by restarting the CTI Service..... even a server restart didn't help. We had to manually restart the CTI service again after server was back online. After that all symptoms disappeared.
