Troubleshooting

Applies to StoneLock

Troubleshooting related to phone/jabber locking:

Can’t access StoneLock service from IP Phone

• Check StoneLock Licenses are active on IAS and involved service is running.

• Check IP Phone user is properly configured on the IAS and the relevant phone device is retrieved  by the AXL service running on CUCM.
• Check that XML phone service is subscribed to user's phone device and IAS Server is reachable by the phone via http/https.

Can’t access to StoneLock from Jabber Desktop/Mobile Imagicle gadget

• Check StoneLock network configurations, make sure IAS server is reachable from clients on port 80 (http) or port 443 (https).
• Check StoneLock Licenses are active on IAS and that the involved service is running.

While trying to lock/unlock line from IP Phone, I get incorrect PIN message

• To avoid the case a wrong PIN is being inserted, define a new PIN in IAS user database.
• Phone status is not correctly refreshed. Check via Web Portal that phone IP address is available and PUSH test is positive. Check also that phone is visible from AXL.

While phone is locked, I have no confirmation about actual lock status

• Please note that some phone devices are not showing lock status. This is why we recommend to configure an audio announcement in CUCM, triggered by StoneLock when phone is locked (CURRI method required). This will work for analog phones, too.

TAPI troubleshooting

1. If an IP Phone does not appear in Admin -> Support -> (details) page, it cannot be monitored by Stonelock. It must have both the "Detected by AXL" and "Detected By TAPI" flags. If not, please double check device association on the CallManager, and AXL configuration on the IAS server.

2. Check that the option "Allow Control of Device from CTI" is enabled in the phone configuration (Device --> Phone)

3. Check that the AXL Service is active. In case of CUCM cluster installations, check that the IP address you entered in the IAS telephony services mask is the one of the node on which the AXL service is activated.

CURRI troubleshooting

Outgoing call fails

Check Calling Search Space and Partition configuration, there are two common issues in this configuration:

• Loop creation, E.g. with the translation pattern and the called Directory Number in the same partition
• Call Flow is interrupted at some level, E.g. caller Calling Search Space include Translation Pattern, but Translation Pattern Calling Search Space doesn't include the partition containing IP phones

If calls pass but they aren't listed in the Calls History

First of all, we could be in the case that External Call Control hasn't been triggered. Check Calling Search Space and Partition configuration, translation pattern could not be involved in the call flow, use Cisco utility to analyze call flows in order to verify the translation pattern involvement.

If Cisco Call routing do trigger the External Call Control, there are two family of issues, depending on External Call Control Profile Call treatment on failures configuration:

• Allow calls option specified: there should be a problem with Imagicle Application Suite External Call Control (CURRI) Web service
  • Check your network configuration
    • Verify that Imagicle Application Server port 80 is reachable from Cisco CallManager.
    • In Imagicle Application Server performance Monitor add SAS:ECC-Curri: Last http HEAD request this counter shows the time elapsed from the last Cisco CallManager connection with IAS, Cisco CallManager tries to connect to IAS Web Service every 20 seconds in order to assure the connectivity and persist a connection for obtain faster routing responses. Check that this performance counter shows compliant information.
    • Verify that in StoneLock Global Settings Cisco External Call Control (CURRI) is chosen as Block Engine Technology.
• Block calls option specified: External Call Control hasn't been triggered
  • Check Calling Search Space and Partition configuration, translation pattern could not be involved in the call flow, use Cisco utility for analyse call flows in order to verify the translation pattern involvement

If Outgoing Call isn't blocked but it's listed in the Calls History

In this case you must verify the reason for the application decision, options are:

• License is not valid: check your license
• Called number is included in white list: calls for numbers in white list aren't blocked
• User has been recognized: if user hasn't been recognized, call isn't blocked, check Imagicle Application Suite configuration

If there is no block message specified

If you specified a block audio message in the Imagicle Application Suite StoneLock Settings Web Page but when a call is blocked caller can't hear any message you must verify the Calls History Web Page:

• if the call is displayed, check calls details, ECC Response section
  • if decision is continue, call hasn't been blocked, so caller isn't in block state
  • if decision is deny, but there is no Message field, check StoneLock settings, you could haven't configured the message (E.g. you forgot to save settings)
  • if decision is deny and there is a Message field check the field value:
    • the value and the Cisco CallManager Announcement Identifier must match exactly, if they don't, let them match
    • the Announcement must be available for the locales of all the phones that are using the service
• If the call isn't displayed, check earlier in this section

If the call isn't redirected to the specified number

If you specified a redirection number in the Imagicle Application Suite StoneLock Settings Web Page but calls is only blocked without redirection, you must verify the Calls History Web Page:

• If the call is displayed, check calls details, ECC Response section
  • if decision is continue, call hasn't been blocked, so caller isn't in block state
  • if decision is deny, check StoneLock settings, you could haven't configured the redirection number (E.g. you forgot to save settings)
  • if decision is divert check the divert destination field value:
    • if the number is correct, check Diversion rerouting Calling Search Space in External Call Control Profile configuration, if everything seems to be ok, try to reconstruct the call flow with Cisco Dialled number analyzer in order to determine where the call fails
    • if the number isn't correct, change it in the StoneLock settings
• If the call isn't displayed, check earlier in this section

Cisco Call Manager and Imagicle web service Troubleshooting

Regarding External Call Control - CURRI plugin, Cisco Call Manager could raise some error events to Administrator (You can monitor them also with your Cisco Call Manager Real Time Monitoring Tool). Possible Alarms are:

A web service connection error occurs when Unified CM fails to establish a connection with the web service. The following reasons may cause this failure:

• The web service is not in service.

• Slow responses from the web service that cause Unified CM to time out for two consecutive call routing or Keep-Alive requests.

Unified CM handles this failure with the following actions:

• Issues a ConnectionFailureToPDP error alarm.
• Switches to standby web service for call routing requests, if two URIs are provisioned in the external call control profile to operate in active-standby mode.
• Starts sending all call routing requests to the other web service that Unified CM still has good connections with, if two URIs are provisioned in the external call control profile to operate in load balance mode.
• Retries to establish connections to the web service.
• If no web service is available for call routing request, then follows the Call Treatment on Failure configuration as set on the external call control profile to route the call.

Actions

Check your network configuration

• Verify that Imagicle Application Server port 80 is reachable from Cisco CallManager.
• In Imagicle Application Server performance Monitor add "SAS:ECC-Curri: Last http HEAD request" this counter shows the time elapsed from the last Cisco CallManager connection with IAS, Cisco CallManager tries to connect to IAS Web Service every 20 seconds in order to assure the connectivity and persist a connection for obtain faster routing responses. Check that this performance counter shows compliant information.

Cisco Call Manager routing request timer expires before receiving the call routing response from the Imagicle web service:

The routing request timer is the maximum time in milliseconds that Unified CM waits for the response from the web service for a call routing request. The routing request timer can be provisioned in an external call control profile in the range of 1000 to 5000 milliseconds. If the timer is not set in the external call control profile, the cluster wide service parameter “External Call Control Routing Request Timer” takes effect. The default value for the timer is 2000 milliseconds.

Unified CM takes the following actions when the routing request timer expires before receiving the call routing response:

• Issues an AwaitingResponseFromPDPTimeout error alarm.

Routes the call following the Call Treatment on Failure configuration set on the external call control profile.

Actions

Check your network configuration

The Imagicle web service can return a 4XX or 5XX error response to Unified CM to indicate invalid call routing requests or internal errors when processing a request from Unified CM.

Unified CM takes the following actions for a 4XX or 5XX error response from the Imagicle web service:

• Issues a FailureResponseFromPDP error alarm.
• Routes the call following the Call Treatment on Failure configuration on the external call control profile.

Unified CM takes the following actions when the response from the web service contains the status indicating request errors:

• Issues an ErrorParsingResponseFromPDP warning alarm.
• Routes the call by following the call routing directive in the response.

Actions

Imagicle Application Suite Application Server is answering to Cisco Call Manager requests, but it's encountering some problems.

• Check configured External Call Control Profile link.
• Check StoneLock Enterprise service status, try to restart it.

Cisco CallManager encountered a problem parsing Imagicle Application Suite Application Server requests.

Unified CM takes the following actions when it fails parsing the response:

• Issues an ErrorParsingDirectiveFromPDP error alarm.
• Routes the call following the “Call Treatment on Failure” configuration on the external call control profile.

Actions

• Check StoneLock Enterprise service status and Internet Information Service on Imagicle Application Suite, try to restart it.