IP phone reset problem.

-
In the IPT world, IP phones are bound to reset. Sometimes, after firmware upgrade we force phones to reset and other times, due to reboot of the CM server during maintenance window. However, unexpected ip phone reset is a problem. In order to troubleshoot any issue, it is most important to isolate the problem into parts.

In an issue of IP phone reset, it is important to collect evidences like-
  •     Is there any error appear on the IP phone screen when it resets?
  •     How many times have phone reset?
  •     How many phones are affected with this behavior?
  •     Is it a progressive issue?
  •     Did we make any changes on UC which might lead to this behavior?
  •     What firmware are affected phones running as compared to working ones?
  •     Are all affected phones connected to the same switch?
Unless its not a buggy behavior of phone's firmware, we should check the application logs under syslog viewer in RTMT to understand the reason code of the phone reset.

You would see an RTMT message like-

CCM|DeviceUnregistered - Device unregistered. Device name.:SEP000F9048529A Device IP address.:10.130.9.5 Device type. [Optional]:30006 Device description [Optional].:gmgiska Reason Code [Optional].:8 App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:10.130.8.21|<CLID::StandAloneCluster><NID::10.130.8.21><CT::AlarmSEP000F9048529A><DEV::SEP000F9048529A>

Here are the enums:-

// for DeviceUnregistered Alarm
        Unknown = 1,
        NoEntryInDatabase = 2,
        DatabaseConfigurationError = 3,
        DeviceNameUnresolveable = 4,
        MaxDevRegExceeded = 5,
        ConnectivityError = 6,
        InitializationError = 7,
        DeviceInitiatedReset = 8,
        CallManagerReset = 9,
        DeviceUnregistered = 10,
        MalformedRegisterMsg = 11,
        SCCPDeviceThrottling = 12,
        KeepAliveTimeout = 13,
        ConfigurationMismatch = 14,
        CallManagerRestart = 15,
        DuplicateRegistration = 16,

// for DeviceTransientConnection alarm
        // reason codes 1-9 are same as DeviceUnregistered alarm
        AuthenticationError = 10,
        InvalidX509NameInCertificate = 11,
        InvalidTLSCipher = 12,
        DirectoryNumberMismatch = 13,
        //MalformedRegisterMsg = 14, // commenting out since it
conflicts with reason code for
        ProtocolMismatch = 15,
        DeviceNotActive = 16,
        AuthenticatedDeviceAlreadyExists = 17

Most common reason codes are 6,8,9 and 13.

Connectivity error- is usually due to network glich. We should check the switch configuration and errors on switch port.

Keepalive timeout- could be due to lot of CTI requests to CUCM due to which keepalive messages are not reaching to the CM box. In order to check this, get sniffer capture from CUCM interface.

Call Manager Reset- Someone has reset the phones through web GUI. In order to check the culprit, analyze audit logs from RTMT, it will show you the user ID of the person who logged in during the time phones were reset.

Device Initiated Reset- It suggests that ip phones are resetting by themselves. There could be number of reason for such an issue, such as IP address lease timeout. Get console logs of ip phone to check what happened.

I hope this post gives you some insight of reset problems on Ip phone. :)

Comments

Post a Comment

Popular posts from this blog

Status: Local Agent is not responding. This may be due to Master or Local Agent being down.

-
If you have read my previous post , you would understand why LA and MA services are important for such a scenario and no component has backed-up, rather you get the above error message. Symptoms -   All Disaster Recovery Framework (DRF) services are down, and no new devices, schedules, or statuses can be viewed from the DRF console. Also, when you access the DRF admin pages, the above error message is received. Affected CM releases 6.1.5 and later. Resolution In order to resolve it, first, verify if the Certificate Serial Number in the keystore of Publisher is present in the Truststore of all Subscribers. Complete these steps: Log on to CUCM OS Administration page of Publisher server of the cluster setup. Choose Security > Certificate Management . The Certificate List window displays. You can use the Find controls in order to filter the certificate. Click on the ipsec.pem file and check the serial number of the certificate. Log on to CUCM OS Administr
Read more

Understanding code yellow

-
Understanding sample code yellow alert- Oct 3 01:00:10, cms01, Error, Cisco CallManager, ccm: 147896: Oct 03 05:00:10.616 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowEntry: CodeYellowEntry Expected Average Delay:362 Entry Latency:20 Exit Latency:8 Sample Size:10 Total Code Yellow Entry:14 High Priority Queue Depth:2 Normal Priority Queue Depth:12 Low Priority Queue Depth:70 Cluster ID:StandAloneCluster Node ID:cms01, 3652 The above alert is about code yellow entry, it shows the time when server enters code yellow state. There are no specifications to note at this alert, CM enters code yellow when it achieves the mentioned conditions for code yellow state as mentioned in service parameters. Oct 3 01:00:12, cms01, Error, Cisco CallManager, ccm: 147897: Oct 03 05:00:12.268 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowExit: CodeYellowExit Expected Average Delay:0 Entry Latency:20 Exit Latency:8 Sample Size:10 Time Spent in Code Yellow:2 Number of Calls Rejected Due to C
Read more