Troubleshooting Scenario Questions

The PSTN provider is using an unsupported codec

Why it fails: Unsupported codecs cause 488 Not Acceptable Here or 415, not 403 Forbidden, because the CUBE signals media negotiation failure rather than authorisation rejection. Codec mismatch would be the cause when calls connect but have no audio, or when the offer lacks a mutually supported codec.

The Webex cloud is unreachable

Why it fails: The INVITE already reached the CUBE, so the Webex cloud path is functioning; a 403 is generated locally by dial-peer matching or translation rules. Cloud reachability would be the cause if the CUBE could not register or route to Webex at all, producing timeouts rather than 403.

The user's directory number is not in the PSTN white list

Why it fails: A 403 from the CUBE indicates the dial peer or translation rule rejected the INVITE before any directory-number authorisation check; PSTN white lists govern outbound calling permissions, not inbound INVITE acceptance. White listing would be relevant when restricting which numbers users may dial out to.

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.

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.

Dial-peer not defined

Why it fails: This would prevent all calls.

Codec mismatch

Why it fails: H.450.3 forwarding depends on supplementary-service signalling over the H.225/H.245 control channel, not media encoding, so a codec mismatch cannot block the forward. Codec alignment matters when establishing audio paths between endpoints, which is a separate concern from call-diversion signalling.

SIP profile missing

Why it fails: A SIP profile controls SIP timers, headers and transport behaviour, not H.450.3 forwarding; the missing element is supplementary-service configuration on the dial peer. It is tempting because SIP profiles commonly cause CUBE feature failures, and would be correct if the fault were malformed SIP signalling rather than H.450 handling.