Which Command Should the Administrator Use 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.

AF41 (34)

Why it fails: AF41 is commonly used for interactive video, not voice. While it provides assured forwarding, it does not offer the strict priority that voice requires. Using AF41 for voice could lead to increased delay and jitter during congestion, violating voice quality requirements.

CS3 (24)

Why it fails: CS3 is typically used for call signaling traffic, not voice media. Using CS3 for voice bearer would cause the service provider to treat voice as signaling, likely resulting in incorrect per-hop behavior and potential quality degradation. Voice media requires EF to ensure low latency and jitter.

CS5 (40)

Why it fails: CS5 is sometimes used for voice signaling or broadcast video, but not for voice media. Using CS5 for voice bearer would not meet the service provider's requirement for EF. Voice media must be marked EF to guarantee the required QoS treatment.

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.

authentication username user password pass

Why it fails: The authentication command supplies the credentials used to authenticate to the SIP registrar. It does not control how often the gateway re-registers. Configuring authentication is required for registration, but it does not set the expiry timer. Therefore, this command would not change the registration refresh interval from its default, and the provider's requirement for a 60-second refresh would not be met.

registrar ipv4:10.1.1.1 expires 60

Why it fails: The registrar command is used to specify the SIP registrar's IP address, not the registration expiry timer. While some platforms accept an expires parameter on the registrar command for specific purposes, the canonical way to set the registration expiry for sip-ua registration is through the authentication or registration-specific timer. In this scenario, using registrar expires 60 would not reliably override the default 3600-second registration expiry, so the provider would still see a 3600-second refresh interval.

retry invite 3

Why it fails: The retry invite command controls how many times the gateway retries an outbound SIP INVITE when it does not receive a final response. It is used for call setup retries, not for SIP registration refresh. This command has no effect on the registration expiry timer, so it would not satisfy the provider's 60-second re-registration requirement and could lead to the registration being considered stale by the provider.

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 sip-ua calls

Why it fails: The 'show sip-ua calls' command shows SIP user agent call information, but it is specific to SIP signaling and may not provide a comprehensive view of all active calls across different signaling protocols. It also lacks the detailed call leg and codec information that 'show call active voice brief' provides for voice gateways.

show voice call status

Why it fails: The 'show voice call status' command displays the status of voice ports and their call state, but it does not provide detailed information about all active calls, such as call legs, codecs, and durations. It is more focused on the physical voice port status rather than the end-to-end call details needed to verify active calls.

show dial-peer voice summary

Why it fails: The 'show dial-peer voice summary' command displays a summary of configured dial peers and their operational state, but it does not show active calls or their details. It is useful for verifying dial-peer configuration, not for monitoring ongoing calls.

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.

Set the Route List's distribution algorithm to Broadcast and ensure the Route Group for Provider A is listed first.

Why it fails: The Broadcast distribution algorithm sends the call to all Route Groups simultaneously, which is used for features like simultaneous ring. It is not appropriate for routing to SIP trunks where you want a sequential failover. Broadcasting to two providers would cause the call to be sent to both, potentially resulting in multiple call legs and billing issues. This does not achieve the desired primary/secondary behavior.

Set the Route List's distribution algorithm to Circular and ensure the Route Group for Provider A is listed first.

Why it fails: The Circular distribution algorithm rotates through the Route Groups, starting with the first one and then moving to the next for subsequent calls. It does not provide a strict primary/secondary failover for a single call; instead, it load-balances across Route Groups. This would cause some calls to go to Provider B even when Provider A is available, which is not the desired behavior.

Set the Route List's distribution algorithm to Longest Idle and ensure the Route Group for Provider A is listed first.

Why it fails: The Longest Idle distribution algorithm is used for hunting to the member that has been idle the longest. It is typically used for line groups or hunt pilots, not for Route Lists to SIP trunks. Applying this algorithm to a Route List would not provide the simple primary/secondary failover; it would select the trunk based on idle time, which is not relevant here.

A shared device pool.

Why it fails: A shared device pool groups phones for firmware and configuration, not dial-plan reachability. It cannot make extensions routable between sites. It is tempting because device pools genuinely simplify provisioning and are correct when standardising phone settings across a deployment — but cross-site extension dialling requires a global dial plan with site links and a directory URI or E.164 pattern.

A translation pattern for each extension.

Why it fails: A translation pattern rewrites digits but does not advertise extension reachability between clusters, so remote sites still cannot dial those extensions directly. It is tempting because translation patterns genuinely handle digit manipulation, such as stripping or prefixing access codes, and would be correct where numbering formats must be normalised rather than shared across sites.

A route pattern that includes all extensions.

Why it fails: A route pattern listing every extension cannot scale across sites and breaks when numbering changes, because it hard-codes each directory number rather than matching a dialable range. Route patterns are for steering calls to gateways or trunks; a site-specific route pattern would be correct when directing particular dialled numbers to a specific egress device.

SIP Profile

Why it fails: A SIP Profile controls SIP signaling behavior such as timers, early offer, and header handling for SIP endpoints and trunks. It has no role in counting or limiting media bandwidth, so it cannot restrict how many G.711 calls are allowed across a constrained link; that function belongs to the bandwidth-aware Location configuration.

Device Pool

Why it fails: A Device Pool groups devices that share common settings such as region, date/time group, and calling search space, but it holds no bandwidth counter of its own. Bandwidth enforcement is delegated to the Location referenced by the device pool, so configuring the device pool alone would not limit the number of concurrent calls across the WAN link.

Region

Why it fails: Regions define which codec is used between groups of devices, controlling call quality and per-call bandwidth consumption, but they do not enforce an aggregate limit on how many simultaneous calls a site can place. A region tells CUCM which codec to negotiate; it does not deny a call when the total bandwidth of all active calls would exceed the WAN link capacity.

Neither dial peer is selected; the gateway rejects the call because two POTS peers cannot share the same voice port.

Why it fails: Multiple POTS dial peers can reference the same voice port; this is a common design for separating emergency and non-emergency traffic. The gateway does not reject the call. It performs normal dial-peer matching and will select the most specific peer, so the call proceeds using the appropriate outbound POTS peer.

Dial peer 20, because the gateway selects the peer with the lowest preference value configured under the dial peer.

Why it fails: Preference is used only as a tiebreaker when two dial peers have equally specific destination patterns. In this scenario, the patterns differ in specificity, so preference is not consulted. Dial peer 20 is not chosen simply because it might have a lower preference number; specificity is evaluated first.

Dial peer 20, because wildcard patterns always take precedence over literal patterns to allow flexible routing.

Why it fails: Wildcard patterns are less specific, not more. Cisco IOS dial-peer matching evaluates specificity, and a literal pattern such as 911 outranks the wildcard 9T. The gateway does not prefer T because it is a wildcard; it would only select dial peer 20 if no more specific match existed for the dialed digits.

Translation pattern that rewrites the called number to CUBE's IP address

Why it fails: A translation pattern is used to manipulate digits, not to route calls to a specific destination. You cannot rewrite a called number to an IP address. Routing to CUBE is done via a SIP trunk that has CUBE's address configured. Therefore, this option is technically invalid and does not achieve the goal.

H.323 gateway configured on CUCM with destination address of CUBE

Why it fails: An H.323 gateway is used for H.323 signaling, not SIP. If CUBE is deployed as a SIP border element, CUCM should use a SIP trunk to communicate with it. Configuring an H.323 gateway would result in protocol mismatch and calls would fail. Therefore, this is incorrect for a SIP trunk scenario.

Route group with CUBE as the only member

Why it fails: A route group is a list of gateways or trunks that can be used for routing. However, a route group alone does not point to CUBE; it must be associated with a route list and route pattern. While a route group containing the SIP trunk to CUBE is part of the configuration, the question asks for the element that points to CUBE as the next hop. The SIP trunk itself is the element that specifies the destination address.