Dial the self-provisioning IVR extension and associate the phone to an end user.

Plug the phone into the network.

Summary:
The Self-Provisioning feature allows end users to associate a phone to their own user account without administrator intervention. After the feature is enabled by the administrator in Cisco UCM, the process is user-driven. The user physically connects their phone and then initiates the provisioning process through an interactive voice response (IVR) system.

Correct Option:

A. Dial the self-provisioning IVR extension and associate the phone to an end user:
This is the core user action. The user dials a specific extension (e.g., 7777) which connects them to a Self-Provisioning IVR application. This system guides them through the steps to log in and associate the phone they are calling from with their corporate user account.

B. Plug the phone into the network:
This is the necessary first physical step. Once the phone is powered and connected to the network, it will register with Cisco UCM. It will typically start with a default configuration that allows it to access the self-provisioning IVR extension.

Incorrect Option:

C. Ask the Cisco UCM administrator to associate the phone to an end user:
This defeats the entire purpose of the Self-Provisioning feature. The feature is designed to eliminate the need for administrator involvement in this specific task, empowering users to manage their own device associations.

D. Enter settings menu on the phone and press ,,# (star, star, pound):
This key sequence is not the standard method for initiating self-provisioning. The standard and documented method is for the user to dial a specific IVR extension from the phone's handset.

E. Dial the hunt pilot extension and associate the phone to an end user:
A hunt pilot is used for distributing incoming calls to a group of lines. Dialing a hunt pilot would simply place a call to a business department and would not connect the user to the self-provisioning IVR application.

Reference:
Cisco Unified Communications Manager Features and Services Guide, Self-Provisioning (This guide details the self-provisioning process, confirming that users plug in the phone and dial a specific IVR number to associate the device).

Only nodes that have Cisco Unified CM service enabled

Summary:
The TFTP service in a Cisco UCM cluster is responsible for serving configuration files, firmware (loads), device defaults, and localization files to endpoints. For redundancy and load distribution, this critical service can run on multiple servers within the cluster. However, it has specific co-dependency requirements with other core services.

Correct Option:

C. Only nodes that have Cisco Unified CM service enabled:
This is the correct answer. The TFTP service has a strict dependency on the Cisco CallManager (CCM) service. According to Cisco's serviceability rules, the TFTP service can only be activated on a server where the Cisco CallManager service is also active and running. This is typically all subscriber nodes in a cluster.

Incorrect Option:

A. Any node:
This is incorrect. The TFTP service cannot run on a standalone node that does not have the core Cisco UCM services. For example, it cannot run on a node dedicated solely to the IM & Presence Service or on a node where the CCM service has been deactivated.

B. Any subscriber nodes:
While this is often true in practice, it is not the most precise technical definition. A "subscriber node" is defined as a server that runs the Cisco CallManager service. The rule is dependency-based: TFTP requires CCM. Therefore, the accurate answer is defined by the service dependency, not simply the node's general role.

D. Any two node:
This is incorrect and nonsensical. It implies a fixed number, which is not the case. A cluster can have more than two nodes running the TFTP service for redundancy, and the enabling of the service is based on the service dependency rule, not an arbitrary count.

Reference:
Cisco Unified Communications Manager Serviceability Administration Guide, Service Activation (This guide outlines the service activation rules and dependencies, confirming that the TFTP service is dependent on the Cisco CallManager service).

The Cisco IP Phone does not know the IP address of the TFTP server

Option 150 string was not specified, or an incorrect Option 150 string was specified

Summary:
For a Cisco IP Phone to register, it must successfully download its configuration file from a TFTP server. This process fails if the phone cannot locate the TFTP server. The phone discovers the TFTP server's IP address through DHCP, specifically using DHCP options 150 or 66. If these options are missing, incorrect, or if the phone cannot resolve a hostname provided in the option, the TFTP download will fail.

Correct Option:

B. The Cisco IP Phone does not know the IP address of the TFTP server:
This is the fundamental reason for a TFTP download failure. Without the correct TFTP server address, the phone has no destination from which to request its configuration file. This is precisely what DHCP options 150 and 66 are designed to provide.

E. Option 150 string was not specified, or an incorrect Option 150 string was specified:
DHCP option 150 is the standard method for providing one or more TFTP server IP addresses to Cisco IP Phones. If this option is not configured on the DHCP scope, or if it contains an invalid IP address, the phone will be unable to locate the TFTP server and the download will fail.

Incorrect Option:

A. The DNS server was not specified, which is needed to resolve a hostname in an Option 150 string:
This is incorrect. DHCP option 150 is defined to provide IP addresses, not hostnames. Therefore, DNS resolution is not required for an option 150 configuration. Option 150 should point directly to the IP address of the UCM publisher/subscriber(s).

C. The Cisco IP Phone does not know the IP address of any of the Cisco UCM Subscriber nodes:
The phone does not need to know the individual UCM subscriber nodes for the initial TFTP boot process. It only needs the address of the TFTP server (which runs on the UCM nodes). Call control redundancy is handled after registration via the information within the downloaded configuration file.

D. Option 100 string was not specified, or an incorrect Option 100 string was specified:
Option 100 is obsolete and was used for very old SCCP firmware. Modern phones and deployment practices rely on options 150 or 66 for TFTP server discovery. Option 100 is not a relevant cause for TFTP failure in current implementations.

Reference:
Cisco Unified Communications Manager Network Protocols Port Reference, DHCP (This document confirms the use of DHCP options 150 and 66 for TFTP server provisioning for Cisco IP Phones).

Media Termination point

Summary:
A DTMF mismatch occurs when two sides of a call use different methods to send dual-tone multi-frequency (DTMF) digits. An FXS port on an MGCP gateway typically uses in-band audio (sending the actual tones in the voice stream), while a SIP trunk often requires out-of-band signaling using RFC 2833 (telephone-event). A media resource is needed to "translate" between these two different methods.

Correct Option:

A. Media Termination point:
This is the correct resource. A Media Termination Point (MTP) is specifically designed to provide media processing services, and one of its key functions is DTMF interworking. When an MTP is inserted into the call, it can detect the in-band DTMF tones from the FXS side and convert them into out-of-band RFC 2833 packets to send over the SIP trunk, and vice-versa, resolving the mismatch.

Incorrect Option:

B. Conference Bridge:
A conference bridge is used to mix audio streams from multiple participants into a single conference call. It is not designed or used for the function of converting between different DTMF signaling methods on a point-to-point call.

C. Annunciator:
An annunciator is a media resource that plays pre-recorded audio messages, such as "The number you have dialed is not in service." It does not process or interwork DTMF signaling.

D. Trusted relay point:
This is a distractor term and not a standard, configurable media resource in Cisco Unified Communications Manager. The correct term for the resource that handles this function is a Media Termination Point (MTP).

Reference:
Cisco Unified Communications Manager System Guide, Media Resources (This guide describes the different media resource types and explicitly lists DTMF interworking as a key function of a Media Termination Point).

xStatus HDMI Output

Summary:
The Cisco TelePresence SX80 uses a structured CLI with specific command prefixes. To troubleshoot a video output issue, you need a command that shows the current, real-time status of the HDMI output, such as its resolution, refresh rate, and connection state, to determine if the system is correctly detecting and sending a signal to the display.
Correct Option:

A. xStatus HDMI Output:
This is the correct command. The xStatus command prefix is used to retrieve the current runtime status and readings from the system. xStatus HDMI Output will display the live status of the HDMI output port, including its resolution, refresh rate, and whether a display is detected, which is essential for diagnosing a "no video" issue.

Incorrect Option:

B. xStatus video Output:
This is not a valid command. While xStatus is the correct prefix, the specific syntax for checking output status is xStatus HDMI Output or xStatus Video Output [number] for more specific monitor details, not the generalized "video Output".

C. xconfiguration video Output:
This command is used to view or change the configuration settings for the video output, such as the default resolution. It shows how the system is set up, not the real-time operational status of the connection, which is needed to see if the display is actively receiving a signal.

D. xcommand video status:
This is not a standard, documented command for the SX80 CLI. The correct prefixes are xStatus, xConfiguration, and xCommand for different functions, and this specific syntax does not exist.

Reference:
Cisco TelePresence SX80 API Reference Guide (This official API guide documents all the xStatus, xConfiguration, and xCommand values, confirming that xStatus HDMI Output is the command to check the status of the HDMI output).

ip dhcp-sip

ip domain lookup

Summary:
The command no ip domain lookup disables the router's ability to perform DNS resolution for any purpose, including translating hostnames to IP addresses (A records) and performing SRV lookups crucial for SIP trunking to service providers. To restore this functionality, the DNS lookup feature must be re-enabled, and specific configuration is needed to define which DNS servers the gateway should use for these queries.

Correct Option:

B. ip name-server:
This command is required to specify the IP address of one or more DNS servers. Without a defined name server, even with lookup enabled, the gateway has no destination to send its DNS queries (A record or SRV) to.

E. ip domain lookup:
This command is required to re-enable the DNS resolution feature that was globally disabled by the no ip domain lookup command. This is the foundational step that allows the gateway to once again attempt to resolve hostnames.

Incorrect Option:

A. ip dhcp excluded-address:
This command is used in a DHCP pool configuration to prevent a router from assigning specific IP addresses within a scope. It is completely unrelated to DNS configuration or functionality.

C. ip dhcp pool:
This command is used to enter configuration mode for creating a DHCP address pool to assign IP addresses to clients. It is not involved in configuring the router itself as a DNS client.

D. transport preferred none:
This command is used under a SIP UA configuration to remove a preference for using TCP or UDP, allowing the system to choose the transport based on the NAPTR/SRV records. While related to SIP, it does not enable the underlying DNS resolution mechanism itself.

Reference:
Cisco IOS IP Addressing Services Command Reference, ip name-server (This command reference covers the ip name-server and ip domain lookup commands, which are essential for configuring a router as a DNS client).

Normalization is achieved by stripping or translating the called numbers.

Summary:
In a globalized call-routing environment, users may dial numbers in various local formats (e.g., with or without a country code, with different trunk access codes). For consistent and accurate routing—especially for PSTN calls—Cisco UCM must transform these diverse dialed strings into a single, standard format (typically the full E.164 format with a '+' prefix). This process is known as normalization.

Correct Option:

A. Normalization is achieved by stripping or translating the called numbers.
This is the correct high-level description. Normalization is the process of manipulating the dialed digits. This is primarily accomplished using Translation Patterns or SIP Normalization Scripts on trunks. These tools can be configured to:

Strip unwanted prefixes (e.g., a leading '9' for an outside line).

Prepend a country code (e.g., adding '1' for North America).

Add the '+' prefix to conform to the E.164 international standard.

Incorrect Option:

B. Call ingress must be normalized before the call being routed.
While this describes the goal (normalization should happen early), it is not the "how." This statement describes a requirement or a point in the process, not the actual method or tool used to achieve it.

C. Normalization is not required. This is incorrect.
Without normalization, calls dialed in different local formats by users in different countries would not be routed correctly, especially over a SIP trunk to a service provider that expects a uniform E.164 format.

D. Normalization is achieved by setting up calling search and partitions at the SIP trunk for PSTN connection.
Partitions and Calling Search Spaces (CSS) are used for authorization (controlling which destinations a device can call), not for transformation of the dialed number itself. They do not perform the digit manipulation required for normalization.

Reference:
Cisco Unified Communications Manager System Guide, Call Routing and Globalization (This guide explains the concept of globalization and details the use of translation patterns and normalization scripts to manipulate dialed numbers).

Network Congestion

Incorrect QoS

Summary:
Poor call quality after a call is successfully connected is a media path issue, not a call signaling or routing problem. The audio stream (RTP packets) is experiencing degradation as it traverses the network. This is typically caused by problems that introduce packet loss, jitter, or latency, which directly impact the clarity and continuity of the audio.

Correct Option:

C. Network Congestion:
This is a primary cause. When a network link is oversubscribed, routers and switches will drop packets if their buffers become full. This packet loss results in choppy audio, gaps, or dropouts, severely degrading call quality.

D. Incorrect QoS:
Quality of Service (QoS) is the mechanism used to prioritize real-time traffic like voice over data traffic. If QoS is not configured or is configured incorrectly, voice packets are treated as "best-effort." They can be delayed (increasing jitter and latency) or dropped during periods of congestion, leading to poor quality.

Incorrect Option:

A. Incorrect Partition:
An incorrect Partition or Calling Search Space (CSS) is a call routing and authorization issue. It would prevent the call from being connected in the first place, resulting in a reorder tone or a "Not Found" message, not poor quality on a connected call.

B. No region relationship:
A missing region relationship is a Call Admission Control (CAC) issue. It would prevent the call from being set up if it would exceed the configured bandwidth limit between locations. The user would receive a "not enough bandwidth" message, not a connected call with bad quality.

E. Incompatible Codec:
An incompatible codec is a call setup (signaling) issue. If two endpoints do not share a common codec, the call will fail during the SIP/SDP negotiation phase and will not connect at all. It will not result in a connected call with poor audio.

Reference:
Cisco Collaboration System Solution Reference Network Designs (SRND), Quality of Service (This design guide extensively covers the impact of network congestion and the critical need for proper QoS configuration to ensure high-quality voice and video media).

SNMP

Video is typically variable bit rate.

Database replication is not synchronized on the Unified CM nodes

Configure a Forced Authorization Code on the international route pattern.

Set call forward All CSS to restrict international dial patterns.