When using Variphy Remote Phone Control, there are a number of conditions that could impact the ability to remotely control 1 or more Cisco IP phones, such as:
- the Cisco IP phone is not currently registered to Cisco Unified Communications Manager (CUCM)
- the Cisco IP phone is unreachable on the network from Variphy via HTTP or HTTPS
- the Cisco IP phone is not configured to authorize remote control for Variphy in CUCM Administration (Application User Controlled Device Association)
- the Cisco IP phone is experiencing security trust list or ITL configuration issues impacting its authentication process with CUCM
When attempting to control a Cisco IP phone in Variphy, if unsuccessful, you will see one of the following error message descriptions:
- Variphy Insight could not identify an IP address for Phone
- Variphy Insight was unable to establish a web connection to phone: the-SEP-phone-name with IP address: the-phone-ip-address
- The phone did not authenticate and accept the remote control request from Variphy Insight
Variphy Insight could not identify an IP address for Phone
This error message indicates that Variphy was unable to determine the Cisco IP phone’s IP address via CUCM.
Typically, this is because the phone isn’t currently registered or is still in the process of registering. To remotely control a Cisco IP phone in Variphy, the phone must have a valid IP address.
In CUCM Administration, check to see if the phone is registered to CUCM or if CUCM shows the phone’s IP address.
If CUCM shows an IP address for the phone, retry searching for the same phone (by name) in Variphy, which should show the same IP address and registration state as what CUCM shows.
If Variphy continues to not show an IP address for phone, this indicates there could be an issue with the Cisco RIS Data Collector service or the AXL RIS API in CUCM. This is extremely rare but we have seen this a handful of times over the last 10 years or so.
Fortunately in this case, there is a workaround in Variphy, which allows a phone to selected for control directly by its IP address.
Click the Control where button, enter the phone’s IP address, and then click the Control IP Phone button.
Variphy Insight was unable to establish a web connection to phone: the-SEP-phone-name with IP address: the-phone-ip-address
This indicates that Variphy was unable to establish either a HTTP or HTTPS connection directly to the phone, via its IP address. This could be caused by one (or more of the following):
- A network firewall or access control list (ACL) is preventing the Variphy server from connecting to the Cisco IP phone’s IP address. Typically Cisco IP phones reside on a separate VLAN for voice with restricted accessibility to/from data/other VLANs (where the Variphy server may be).
- Phone does not have Web Access enabled, which blocks any inbound HTTP(S) connections to the phone
- Phone does not have Web Access enabled its configuration
How To Check If/Enable Web Access for Common Phone Profiles or Cisco IP Phones in Cisco CUCM Administration
The Web Access field dictates whether the Cisco IP phone accepts inbound HTTP(S) connections via its IP address – this provides the ability for Variphy to connect the phone remotely.
Ensure that the Web Access field is set to Enabled in the Product Specific Configuration Layout on the Common Phone Profile or specific Cisco IP Phone’s device configuration page – this will be towards the bottom of the page.
After making any changes, any phones will need to be reset to have the changes take effect.
The phone did not authenticate and accept the remote control request from Variphy Insight
This is the most common error you may receive in Variphy Remote Phone Control and it indicates that the Cisco IP phone did not authorize Variphy to control it.
The most common causes for this error are:
Cause 1) The password for the Application User in Variphy is not correct.
In Variphy, click edit for the CUCM Cluster from the CUCM Clusters page in Setup & Administration.
In the Remote Phone Control section of the page towards the bottom, check that the Use CUCM Admin Login checked is checked. We strongly recommend enabling this to simplify the maintenance of CUCM Application User credentials in Variphy.
By enabling this option, Variphy will use the same Application user credentials for Remote Phone Control (as well as Phone Macros & Broadcast) which are specified in the Cluster Basics section at the top of the page.
If changes have been made to the Cluster, click the Save button at the bottom of the page and retry controlling the Cisco IP phone in Variphy.
If this didn’t result in any changes, proceed to Cause #2 below.
Cause 2) The Cisco IP phone is not in the list of Controlled Devices for the Variphy Application in CUCM Administration
In order for Variphy to be authorized to remotely control a Cisco IP phone, the phone must be part of the Variphy Application User’s list of Controlled Devices in CUCM Administration.
In CUCM Administration, select Application User from the User Management menu.
Identify and click the appropriate Application User which Variphy is configured to use to integrate with CUCM.
On the resulting page (Application User Configuration) in the Device Information section, the Controlled Devices field will show any existing Cisco IP phones which this user can remotely control with Variphy.
Click the Device Association button to add this Cisco IP phone to the list of Controlled Devices.
On the resulting page (User Device Association), search for desired phones which you would like Variphy to control and then select them via the checkbox in the left column.
Click Save Selected/Changes and repeat for additional phones as needed.
Save the changes to the Application User in CUCM and retry controlling the Cisco IP phone in Variphy.
If this didn’t result in any changes, proceed to Cause #3 below.
Cause 3) The Cisco IP phone is unable to connect/communicate with its configured Authentication URL
For Variphy Remote Phone Control to work, Cisco IP phones authorize remote control operations via their configured Authentication URL, which by default, will point to the CUCM Cluster’s Publisher Server.
In the error message in the Variphy Remote Phone Control window will typically show the Authentication Server/URL like in the following example:
For the vast majority of CUCM installations, the Authentication URL will/should point to the CUCM Publisher Server. This is also considered the default setup for a CUCM Cluster. In this case, the URL will look like the following example, where 10.20.30.44 is the IP address of the CUCM Publisher:
https://10.20.30.44:8443/ccmcip/authenticate.jsp, or (secure)
http://10.20.30.44:8080/ccmcip/authenticate.jsp (if using non-secure)
The Authentication URL can be configured to use either use HTTP or HTTPS, in CUCM Administration’s Enterprise Parameters page.
If the Authentication URL points to the CUCM Publisher:
If the Authentication URL is using the Publisher’s Hostname instead of the IP address, the phone may not be able to connect to the Authentication URL because of a DNS issue.
Consider changing this to use the CUCM Publisher server’s IP address – Variphy strongly recommends that IP addresses be used in the Authentication URL fields.
We have seen many cases over the years where DNS was not fully functional for the Cisco IP phones, particularly in Lab or Test environments.
If the Authentication URL points to a different server than the CUCM Publisher, consult the article for Phone Control Workaround for Informacast Systems.
Cause 4) The Cisco IP phone is experiencing security trust list or ITL configuration issues impacting its authentication process with CUCM
Manually test the authentication process between the phone and its authentication URL.
****Note that AUTHENTICATION URLs are CASE Sensitive****
Using the IP address of a phone, visit the URL in a browser window:
http://PHONE-IP-ADDRESS/CGI/Screenshot
When prompted for a login, enter the Application user login and password which should be able to control the phone.
The resulting screen will then help identify what the phone is receiving from the Authentication URL.
If the result is “CiscoIPPhoneErrorNumber = 0”, then the phone is actually unable to communicate with the Authentication URL.
DNS vs IP Address?
In some cases and very often in lab or CCIE study environments, the cause of this issue is that DNS is being used instead of the IP address in the Authentication URL. The DNS host name of the CUCM Publisher server is the default value set during CUCM installation and DNS often isn’t operational in lab environments.
It’s recommended to use an IP address instead of DNS in the Authentication URL.
Changing this setting in CUCM requires modifying one or more Enterprise Parameters in CUCM and resetting the appropriate phones (to test with).
Locate the Authentication URL fields in the Enterprise Parameters (within the System menu in CUCM Administration) and replace the hostname values with IP addresses, then reset the appropriate phone or phones to test this change with.
Test the remote phone control for an appropriate phone in Variphy Insight.
If the result is “CiscoIPPhoneErrorNumber = 4”, then the CUCM server identified by the Authentication URL is not authenticating the user login and password for the requested phone. Confirm that the User Id and password have been entered correctly and that the phone is explicitly listed as a controlled device for the Application User in CUCM Administration.
If the problem persists it’s possible that the CUCM authentication is out of sync or not functioning correctly. Try configuring and using a new Application User in CUCM (with the rights to control this phone) and repeating this process with the new Application User.
If the problem still persists and the Authentication URL is using HTTPS, there could be an ITL/security file issue preventing the phone from properly communicating with the Authentication URL. Try clearing out the ITL file for the phone.
If successful, a screenshot image (for newer/color phone models) or a set of X/Y coordinates (for 7940/7960 phone models) will appear in the browser.
Step 4) If the Authentication URL points to a server that is different that the CUCM Publisher, then a 3rd party server has been introduced into the system (such as for paging or another application) that now performs the authentication for the phones.
In this scenario, for Variphy Insight to be able to control and broadcast to phones, a user login that the 3rd party server/application identified in the Authentication URL will validate must be used and specified in the Cluster setup.
For example, if the Authentication URL points to a SynApps server/application, You could set the username and password for the Phone Administrator section to the default of ‘SynApps’ (Please note that the password is configurable for SynApps users and may have been changed). However, SA-Announce also automatically redirects the incoming authorization request to the CUCM publisher if it is not the user and password the software is expecting, so this should not be necessary as the Variphy application user account would be redirected accordingly.
In the Case of the Authenticaton URL pointing to to an InformaCast paging server, the Authentication should be redirected to the Publisher. However, the redirection may need to be configured in the InformaCast software. There may also be an issue with third generation phones, due to a bug fix that caused the phones to not re-attach parameters to a URL when redirected. Therefore if the authentication URL is pointed at the Informacast server it will only respond to auth requests for an informacast user. The InformaCast application requires the URL Authentication value in CUCM Enterprise parameters, Phone URLs, to be its IP address and path. For applications that are not using InformaCast, it redirects the application back to CUCM.
In order to test connectivity to the InformaCast server, use the following in a web browser
http://(serverIPaddress):8080/ccmcip/authenticate.jsp – for older versions of call manager (7.x) using non-secure
https://(serverIPaddress):8443/ccmcip/authenticate.jsp – for newer (8.x-9.x) version using secure
To Test Authentication redirection from a web browser through the InformaCast server, use the following link, replacing the server IP address, username, password, and device name accordingly.
http://(AuthServerIPAddress):8081/InformaCast/phone/auth/?userid=XXX&deviceName=SEPXXX&password=XXX
In the Event that the phone is able to authenticate and connect, but the screenshot comes back intermittently and the Device Tab comes back with an HTTP 500 error:
Check the logs after experiencing these issues. You should see one or more of these errors:
ERROR [com.variphy.cisco.avvid.inventory.ccmversion.impl.Impl] net.variphy.cisco.avvid.inventory.sql.axl.svc.NonAXLConnectorServerException: HTTP 599 error – Invalid AXL SOAP Version: 1.0
ERROR [com.variphy.insight.ui.phoneadmin.control.struts.PhoneScreenAction] net.variphy.cisco.phonectrl.phonepart.screen.svc.ScreenException: java.io.EOFException
ERROR [com.variphy.insight.ui.phoneadmin.control.struts.PhoneScreenAction] net.variphy.cisco.phonectrl.phonepart.screen.svc.ScreenException: ImageIO.read() returned null – likely due to invalid/incomplete response from phone
ERROR [StandardWrapper[/insight:action]] Servlet.service() for servlet action threw exceptionnet.variphy.cisco.phonectrl.phonepart.screen.svc.ScreenException: ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error
ERROR [com.variphy.cisco.phonectrl.mngr.model7945.impl.PhoneMngrImpl] net.variphy.cisco.phonectrl.phone.model7945.admin.svc.AdminException: net.variphy.cisco.phonectrl.phone.control.HttpAuthenticatorException: CiscoIPPhoneError = 3
(or other Error types containing “CiscoIPPhoneError=3”T
If the phone still encounters intermittent screen refresh issues, and continues to generate errors with CiscoIPPhoneError = 3 in them, this indicates and Internal File Error on the phone side that is not likely tied to CUCM authentication or network connectivity issues.
Try rebooting the phone, or re-applying the firmware if a simple reboot does not improve performance. Confirm that the phone is on the latest firmware version availiable.
