Troubleshooting practice questions

debug isdn q931

Why it fails: Debugging Q.931 displays layer 3 call signaling for ISDN, including cause codes and call states, but it does not show which dial-peer was selected for the incoming call. It would confirm the busy cause code but not the dial-peer matching problem, so it is not the best tool to verify POTS dial-peer selection.

show dial-peer voice summary

Why it fails: This command provides a summary of configured dial-peers, including their tags, types, and status, but it does not show real-time matching results for incoming calls. It is useful for a configuration overview, not for troubleshooting why a specific inbound call failed to match a POTS dial-peer.

show voice port summary

Why it fails: This command displays the operational status of voice ports, such as whether they are up or down, but it does not indicate dial-peer matching. Since the PRI is up and no calls are active, the issue is likely in dial-peer configuration, not port status, making this command unhelpful here.

Disable the firewall on the HDS node.

Why it fails: Disabling the firewall removes a security control without confirming it is the cause; HDS registration requires specific outbound ports, not simply an open node. It is tempting because blocked egress is a common registration fault, and it would be correct to verify required ports are permitted, not to disable filtering entirely.

Restart the Cisco Webex Hybrid Services host.

Why it fails: Restarting the Hybrid Services host does not resolve why newly deployed HDS nodes fail to appear; registration depends on outbound connectivity and correct configuration. It is tempting because restarts clear transient service faults, and it would be correct if a previously working connector had stopped responding after a service crash.

Re-download the management certificate.

Why it fails: Re-downloading the management certificate addresses certificate trust, not the missing registration that occurs when nodes cannot reach Webex cloud services. It is tempting because certificate errors do block HDS communication, and it would be correct if logs showed TLS or trust failures between nodes and Control Hub.

Latency

Why it fails: RTCP jitter reports measure packet arrival timing variance, not absolute delay. Latency is a constant or slowly varying delay, which produces stable inter-arrival times and low reported variance. Latency would be indicated by consistently high round-trip times rather than fluctuating RTCP statistics.

Codec Mismatch

Why it fails: A codec mismatch produces a permanent failure such as one-way audio or garbled speech from call setup, not fluctuating RTCP statistics. It is tempting because codec problems degrade audio, but they do not cause variable packet arrival timing; jitter variance reflects network transport behaviour instead.

Packet Loss

Why it fails: Packet loss is reported separately through RTCP fraction lost and cumulative lost fields, and it causes gaps rather than timing variance. It is tempting because loss degrades audio, but jitter specifically measures variation in packet inter-arrival times, which loss statistics do not express.

show voice class sip-profiles

Why it fails: This command only lists the configured voice class sip-profiles and their rules; it does not display live normalised messages. It is tempting because it confirms which profiles exist and are bound to dial-peers, which is useful when verifying configuration before applying debug ccsip messages to watch the actual normalisation.

debug voip ccapi inout

Why it fails: debug voip ccapi inout traces call-control API signalling between dial peers and applications, not the SIP messages after profile normalisation. It is tempting because it is a standard voice-troubleshooting debug, and it would be the correct choice when diagnosing call routing or dial-peer matching failures rather than SIP header rewriting.

debug sip-ua

Why it fails: debug sip-ua traces SIP user-agent signalling for endpoints and registrations, not CUBE's normalised SIP messages. It is tempting because it shows SIP traffic, and it would be the correct choice when troubleshooting SIP gateway registration or endpoint signalling issues rather than CUBE profile normalisation.

show sip-profile

Why it fails: No such CUBE exec command exists; SIP profile inspection uses show voice class sip-profiles, and live normalised output comes from debug ccsip messages. It is tempting because the name suggests a direct profile-viewing command, which would be the right choice if the goal were merely confirming profile configuration rather than watching messages.

The calendar integration license is invalid.

Why it fails: A licence problem would surface as an entitlement or provisioning error, not as the connector reporting Down. Licensing governs whether Hybrid Calendar is available to the organisation at all, so it would be the answer if the feature were missing from Control Hub entirely rather than the connector failing to connect.

The user's password expired.

Why it fails: An expired user password affects that user's sign-in and mailbox access, not the connector's service-level connection to Exchange. Password expiry would be the answer when a single user cannot authenticate, whereas a Down connector indicates the service itself cannot establish or maintain its connection.

The user is not in the correct group in Active Directory.

Why it fails: Connector status reflects the service's ability to reach Microsoft 365 and Exchange, not individual user membership. Group placement governs which users receive calendar features once the connector is healthy, so it would be the answer when a specific user's mailbox fails to sync despite a healthy connector.

System Health Reports

Why it fails: System Health Reports aggregate CPU, memory and service status rather than per-phone signalling, so they cannot show why a specific phone's registration was rejected. They are tempting for broad CUCM health checks, but registration troubleshooting needs the phone's Skinny or SIP exchange with the call manager.

Cisco TFTP Logs

Why it fails: TFTP logs cover configuration file and firmware downloads during phone boot, ending before registration signalling begins, so they miss the Skinny or SIP exchange with the call manager. They are tempting because failed config downloads do block registration, but the actual registration attempt is logged elsewhere.

Cisco Tomcat Logs

Why it fails: Cisco Tomcat logs record Cisco Unified Communications Manager servlet and web application activity, not phone registration signalling. Registration failures appear in the Cisco CallManager and SDL trace files, where Skinny or SIP registration attempts and rejections are logged. Tomcat logs would be the right source for troubleshooting CUCM web administration or Cisco Unified Reporting problems.

show class-map configuration

Why it fails: Listing class-map definitions only shows match criteria and configured actions, not the live markings applied to packets arriving on the ingress interface. It is tempting because class-maps define classification, and would be the right check when verifying that traffic matches the intended class before a policy is attached.

show ip rtp statistics

Why it fails: RTP statistics expose jitter, packet loss and stream counters for active calls, but never the Layer 3 marking bits on ingress frames. It is tempting because one-way audio points at RTP flow problems, and would be correct when confirming whether media packets are actually traversing the path.

show qos interface

Why it fails: This command reports interface-level QoS policy attachment and queue statistics, not the DSCP or CoS values actually marked on ingress packets. It is tempting because it confirms where service-policies are applied, and would be correct when verifying that a policy-map is bound to the interface.

The remote cluster is not configured with a route pattern for the local cluster, so the call is rejected.

Why it fails: The failure occurs on the local cluster before the call is sent to the remote cluster. The 'No Route to Destination' cause code is generated locally when no route pattern matches. The remote cluster's configuration is irrelevant if the call never reaches it due to local digit analysis failure.

The SIP trunk is not configured with a calling search space that includes the partition of the route pattern.

Why it fails: The calling search space on the SIP trunk affects the trunk's ability to place calls, but the route pattern is used by the originating device's CSS. The device's CSS must include the partition of the route pattern. The trunk's CSS is used for inbound calls or when the trunk initiates a call, not for outbound calls from a phone.

The SIP trunk is not registered to the remote cluster, so the call cannot be routed.

Why it fails: SIP trunks in Cisco Unified CM do not register to remote clusters; they are statically configured with a destination address. Registration is not required for SIP trunk operation. The failure is more likely due to dial plan mismatch, not registration.

Use the show call active voice brief command to inspect the codec negotiated for video calls.

Why it fails: This command displays active voice call details such as codec and call state, but it does not reveal how video packets are classified or marked by the QoS policy on the router. Codec information is useful for bandwidth planning, yet it does not confirm the per-hop QoS treatment that the engineer is trying to validate.

Run the show interfaces command to check the interface error counters for video drops.

Why it fails: Interface counters show physical and data-link errors such as CRC and output drops at the aggregate level, not per-class QoS classification or marking. They cannot tell the engineer whether video matched the correct class or received the intended treatment, so they are insufficient to confirm QoS handling for video traffic.

Run the debug ip rsvp command to observe reservation messages for video flows.

Why it fails: Debugging RSVP shows reservation signaling and admission control activity, not the classification or marking of video packets in a QoS policy. Even if RSVP is deployed, this output does not confirm that video traffic matches the correct class-map or receives the intended per-hop treatment, so it does not verify classification and marking as required.

To monitor network bandwidth.

Why it fails: Cisco Unified Reporting compiles snapshots of CUCM cluster health, such as database replication and service status, not live traffic volumes. Bandwidth monitoring requires tools like Cisco Prime Collaboration or SNMP polling. The name suggests analytics, which misleads candidates toward network telemetry rather than report generation.

To manage real-time call logs.

Why it fails: Real-time call monitoring is provided by Cisco Real-Time Monitoring Tool (RTMT), which streams counters and alarms live. Cisco Unified Reporting produces on-demand, point-in-time reports from the CAR database, not live call logs. The overlap in reporting terminology makes this option tempting, but RTMT is the correct tool for real-time data.

To perform bulk configuration.

Why it fails: Bulk configuration belongs to the Bulk Administration Tool (BAT), which imports CSV files of users, phones and lines. Cisco Unified Reporting only generates and downloads system reports, so it cannot modify configuration. It is tempting because both are CUCM administration menus, but BAT is the correct choice for mass provisioning.

Phone NTP settings

Why it fails: NTP settings only synchronise phone clocks and have no bearing on codec negotiation, so they cannot force G.711. It is tempting because clock or timezone mismatches cause odd endpoint behaviour, and NTP would be the right area for registration or certificate time failures.

SIP Trunk Security Profile mismatch

Why it fails: SIP trunk security profiles govern TLS, digest authentication and encryption on trunk connections, not the codec chosen for an intra-region call between endpoints. It is tempting because trunk misconfigurations do break calls, and it would be correct when a SIP trunk fails to establish or authenticate.

Location-based bandwidth limit

Why it fails: Location bandwidth limits cause call admission control to deny or downgrade calls when the location's allocated bandwidth is exhausted; they do not silently substitute G.711 for Opus. It is tempting because locations influence codec selection, and it would be correct when calls are rejected across a constrained WAN link.

Media Termination Point

Why it fails: A Media Termination Point is a CUCM software resource that terminates and re-originates media for supplementary services such as hold or DTMF conversion; it does not rewrite SDP addresses in SIP messages crossing a NAT boundary. Deploying an MTP would not make the private address routable, so the provider would still transmit RTP to an unreachable destination.

SIP Normalization and Transparency

Why it fails: SIP normalization scripts modify headers and SDP for interoperability between different SIP implementations, but they do not perform address translation between public and private realms. The provider is already sending media to the signaled address; the problem is that the address is private, which normalization alone will not fix without an address-rewriting function.

RSVP

Why it fails: RSVP reserves bandwidth along the media path for call admission control, but it does not rewrite Session Description Protocol addresses. Enabling RSVP would not correct the private IP address advertised in the SDP, so the provider would still send RTP to an unreachable address and one-way audio would persist regardless of the reservation.

CS3 (Class Selector 3)

Why it fails: CS3 is recommended for call signaling traffic, not voice bearer. Call signaling requires reliable delivery but is less delay-sensitive than voice bearer. Using CS3 for voice bearer would not provide the strict priority treatment needed, as CS3 typically maps to a different queue than EF. Voice bearer should be marked EF to ensure it is placed in the low-latency queue.

AF41 (Assured Forwarding 41)

Why it fails: AF41 is recommended for interactive video traffic, not voice bearer. While AF41 provides assured forwarding with low drop precedence, it does not offer the same strict priority as EF. Voice bearer requires expedited forwarding to minimize latency and jitter. Using AF41 for voice bearer could result in voice packets being queued behind other traffic, degrading call quality.

AF31 (Assured Forwarding 31)

Why it fails: AF31 is recommended for call signaling traffic in Cisco QoS baseline, not for voice bearer. Using AF31 for voice bearer would not give it the strict priority treatment it requires. Voice bearer needs a DSCP value that indicates low latency and high priority, such as EF. AF31 provides assured forwarding but not expedited forwarding, so it is unsuitable for voice payload.

utils service restart Cisco Database Layer Monitor

Why it fails: Restarting the Database Layer Monitor service clears a hung replication agent, but a state '3' block requires the replication repair command to reset the replication link itself. The service restart suits a stopped or unresponsive monitor, not an established blocked replication state.

utils system restart

Why it fails: A full system restart reboots the node and interrupts call processing across the cluster, yet it does not reset the blocked replication link that state '3' indicates. System restart is the correct step for a frozen or unresponsive server, not for repairing replication.

utils network ping

Why it fails: Pinging verifies network reachability between nodes, but state '3' means replication is blocked at the database layer, not that packets are dropping. Network ping is the right first step when nodes cannot reach each other at all.

Check the 'Route Filter' list.

Why it fails: Route filters control which directory numbers or patterns a route pattern or translation permits; they do not reveal whether a CSS contains the destination partition. Checking the CSS partition membership directly is required. Route filters are tempting because they also restrict dialled-number reachability, and they would be correct when calls fail due to blocked number patterns.

Use the 'Route Pattern' report in Cisco Unified Reporting.

Why it fails: The Route Pattern report lists patterns and their partitions, not which CSSs contain those partitions, so it cannot confirm CSS-to-partition reachability. It is tempting because it inventories route patterns, and would suit auditing dial-plan pattern usage rather than tracing a specific CSS's partition membership.

Reset the SIP trunk.

Why it fails: Resetting the SIP trunk drops and re-establishes signalling without revealing CSS partition membership, so it cannot confirm why the call is rejected. It is tempting as a generic fix for trunk faults, and would be right when a SIP trunk is stuck or unregistered rather than when a CSS lacks partition access.

Incorrect Model

Why it fails: An incorrect model leaves the phone without a matching device entry, so Cisco UCM replies with a 403 Forbidden rather than staying silent. It is tempting because model mismatches commonly prevent registration, and would be correct if the phone received an explicit rejection response.

Device Pool mismatch

Why it fails: A device pool mismatch causes the Cisco UCM to reject the REGISTER with a 403 Forbidden, which is still a response. It is tempting because device pool settings determine the assigned CUCM and date/time group, and would be correct if registration failed after a server reply.

Wrong Password

Why it fails: A wrong password produces a 401 Unauthorized response from the registrar, so the phone would receive a reply rather than silence. It is tempting because authentication failures commonly block registration, and would be correct if the server returned an authentication challenge.

SIP Early Offer

Why it fails: SIP Early Offer is used to provide the called party with the media capabilities in the initial INVITE, which can help with media cut-through and reduce post-dial delay. However, it does not directly solve NAT traversal issues. NAT traversal requires mechanisms like STUN, TURN, or ICE, or on CUCM, the SIP Profile parameter 'Enable ANAT' or 'MTP Required' for certain scenarios. Early Offer alone does not ensure RTP flows through NAT.

Media Termination Point (MTP)

Why it fails: An MTP can be used to provide media termination for calls that require it, such as for DTMF conversion or when a SIP endpoint does not support early media. While an MTP can help with NAT traversal by anchoring the media, it is not the primary feature to verify for NAT traversal. The correct feature is often 'MTP Required' on the SIP trunk, but for endpoint-to-endpoint calls, other mechanisms are used. Thus, MTP is not the most direct answer.

Skinny Client Control Protocol (SCCP)

Why it fails: SCCP is a signaling protocol used by Cisco IP Phones to communicate with CUCM. It is not used for NAT traversal of media. The phones in this scenario are likely using SIP or SCCP, but the media (RTP) is what is affected. SCCP does not provide NAT traversal mechanisms. Therefore, checking SCCP is not relevant to solving the one-way audio issue.

Device > Device Settings > Common Device Configuration

Why it fails: Common Device Configuration holds device-level settings such as softkey templates and phone button templates, not region-pair codec policy. It would be the right place to apply a shared configuration profile across many phones of the same model.

System > Device Pool

Why it fails: A device pool groups phones for CallManager assignment, date/time and region settings, but codec selection between two sites is governed by the region pair, not the pool. Device pools suit bulk phone provisioning and firmware or cluster assignment.

System > Location

Why it fails: Locations define bandwidth and call admission control between sites, not which codec is negotiated; codec policy lives in regions and their pairwise links. Locations would be correct when limiting the number of calls across a constrained WAN link.

Cisco Discovery Protocol logs

Why it fails: Cisco Discovery Protocol logs record Layer 2 neighbour advertisements and topology, not media stream routing to the cloud. They would be the right choice when diagnosing adjacency or VLAN issues between switches, but they carry no information about Hybrid Media Service media paths.

System event logs

Why it fails: System event logs capture node-level platform events such as service restarts or hardware faults, not per-call media routing decisions. They are the correct source when investigating why a node or its services failed, but they do not show whether media reached the cloud.

Call processing logs

Why it fails: Call processing logs record signalling and call-control transactions, not the media stream itself. They are the right choice when diagnosing call setup failures or SIP issues, but media routing to the cloud is traced through the media-specific logs instead.

The phone's directory number.

Why it fails: The directory number identifies the line and is already proven valid because the phone registered; it has no bearing on RTP flow. It tempts engineers because DN misconfiguration causes call failures, and checking it would be correct when calls cannot be placed or received rather than when audio is missing.

The CSS of the device.

Why it fails: CSS is for routing, not media pathing.

The phone's firmware version.

Why it fails: Firmware version does not govern RTP media path selection, and the phone already registers successfully, so signalling is functional. It tempts engineers because firmware faults can cause odd behaviour, and a firmware upgrade would be correct when a known bug breaks media handling on a specific model after registration succeeds.