A key mechanism Cisco IP Phones use to authenticate request to their web server such a Screen Shots or HTTP based key presses (i.e. in SRST mode or unregistered) is based on the phones configured Authentication URL. The Authentication URL parameter is configured within Enterprise parameters as the default for all phones, but can be configured directly on each device configuration if required.
With a default installation of CUCM it's common that the default Authentication URL may not work correctly as it uses the publisher CUCM hostname, so if the IP Phone does not have DNS setup (or configured correctly) then it will be unable to authentication requests to it's web server. In addition to this even if the Authentication URL is updated to use an IP Address other factors such as ITL related issues on the phone can prevent the phone from updating it's configuration and/or connecting to HTTPS based resources.
Therefore it's is generally best to use a non-secure (HTTP) Authentication URL in order to ensure the phones web server can always authenticate request even when it has an ITL issue. This ensures that even if a phone has an ITL issue and/or unregistered it can still be controlled remotely given that the phone Web Server and Settings Menu are enabled.
To ensure that all phone models use a non-secure (HTTP) Authentication URL it is necessary to replace the default HTTPS based URL within the "Secured Authentication URL" in Enterprise Parameters on on the device configuration page.
Here is an example of the configuration in Enterprise Parameters that uses a HTTP URL for both secure and non-secure Authentication URL parameters:
Once a valid Authentication URL is configured, when a request to a secured resource on a Cisco IP Phone web server is accesses (i.e. a screenshot: http://[Phone_IP]/CGI/Screenshot) the credentials submitted are passes to the Authentication URL for validation and a positive or negative response is returned according to the users access permission to that device.
The default authentication mechanism within CUCM is based on User Device Association, if the submitted user credentials are valid and the device is associated to that user then a positive response is returned to the IP Phone, which will then proceed with access to the requested resource. It should be noted that the response is cached in the phone for a period of time, so if another request to a secure resource is submitted from the same user credentials then it will be authorised immediately without having to communicate with the Authentication URL again. The means that even if lots of requests are submitted to a secured resource (i.e. continual screenshot refreshes) on the first request will submitted to the Authentication URL until the phone is reset or the locally cached credentials time-out.
Therefore when using the default CUCM authentication mechanism with PhoneView it is a requirement to perform device association with all phones within the cluster to the 'Phone Control' user setup with CUCM for use with PhoneView.
Comments
0 comments
Article is closed for comments.