Troubleshooting
As initial installation finishes, Cisco TSP installer shows error "Could not load the dll file EncryptPassword.dll".
-
Re-run installer.
-
Choose Reinstall.
-
Click Next, then reboot the QMS server when prompted.
After successful installation, the TSP Notifier icon is not present in the Notifications area.
-
Reboot the QMS server.
No TSP profile listed in the TSP Notifier app, or the TSP Notifier app crashes after right-clicking its icon and selecting Cisco TSP Configuration.
-
Start Control Panel.
-
Double-click Phone and Modem.
-
Click the Advanced tab.
-
Click Add button.
-
Select CiscoTSP001.tsp.
-
Click Add button.
-
Select CiscoTSP001.tsp in the Providers list
-
Click Configure button.
-
Enter correct info in the User, CTI Manager, and Security tabs where needed
-
Click OK, then close Phone and Modem app.
-
Verify changes were saved by right-clicking the Cisco TSP Notifier app and clicking Cisco TSP Configuration on the menu. CiscoTSP001.tsp should appear on the list. Highlight it and click the Configure button.
-
Verify information in the User, CTI Manager, and Security tabs was saved correctly.
Phones in encrypted media environment are not registering as secure devices
Verify CUCM has been set up to allow devices to register as secure devices:
-
Log into CUCM Administration site.
-
Click on the System menu
-
Click on Enterprise Parameters.
-
Scroll down to the Secure Parameters section
-
Check the value of the Cluster Security Mode.
If the value is 0, CUCM has not been configured to allow secure device registration. Follow the steps outlined in the Media Encryption section, PBX Configuration, section 1.
After logging into the QMS server, the TSP initialization fails with a "bind socket failed" and/or an "Initializing Socket to listen on port xxxx failed" error.
This problem typically only occurs when multiple users are logged onto the QMS server simultaneously, either locally or through a Remote Desktop session, causing the TSP to initialize multiple times. Make sure only one user logs onto the QMS server at a time.
A QMS User configured with multiple extensions in a Forked Audio environment is not recording.
Verify the QMS User’s phone is configured properly in CUCM. See #6 under PBX Configuration in the Forked Audio – IP Phone-based Recording section.
A QMS User configured with multiple extensions in a Forked Audio environment is not recording, but the user’s IP phone has the Built-In-Bridge enabled.
Verify the QMS User’s list of extensions.
-
The QMS User’s primary extension must be the line 1 appearance in CUCM.
-
The QMS User’s primary extension cannot be the line 1 appearance for any other user in CUCM.
-
Any other line appearances configured for the QMS User in CUCM must be listed in the Additional Extensions field, separated by commas, in the Users view of the QMS Client for the QMS User.
-
The complete list of extensions for a QMS User, referred to as the User’s phone signature, must be unique. Another QMS User cannot have the same list of extensions, even if the extensions are listed in a different order. For example:
-
User 1 has a primary extension of 101, and Additional Extensions of 102 and 103. User 1’s phone signature is [101 102 103].
-
User 2 has a primary extension of 102, and Additional Extensions of 103 and 101. User 2’s phone signature is [102 103 101].
-
The phone signatures are duplicates, because they both contain the same list of extensions.
-
To resolve, update CUCM configurations to make sure all QMS Users have a unique extension assigned that is not shared.
-
The QMS Client Real-Time Activity view is showing users in an Idle state when calls are actively going on, in a Forked Audio configuration with QMS High Availability.
In situations where the primary Call Recording Service goes down, user states are reset to Idle after the Call Recording Service comes back up. A user state change must come from CUCM after the Call Recording Service restarts for Real-Time Activity to reflect the correct current state. This is not a bug, it is a limitation of the configuration necessary in CUCM to allow Forked Audio to work with a QMS High Availability cluster.
In a Forked Audio environment with "Create Dual Channel Recordings" enabled on the Call Recording Service, all of the audio is on only one channel.
This is not a bug, but a limitation in the way Forked Audio sends audio packets to the QMS server. For stereo encoding to create a dual-channel recording, two source IP addresses are needed, in order to determine which audio packets should go into each respective recording channel. Forked Audio will send audio packets to the QMS server either from an IP phone, or from a network gateway device. In either case, all audio is coming from one source IP address, which is associated with the recorded user. The result is all audio ends up on a single channel.