Free 300-810 Practice Test

The primary IM and Presence server is in a "Failed Over" state, which means it has recovered from the failure but has not resumed its active role. This indicates that automatic fallback is not enabled. To immediately restore normal operations, the administrator must manually initiate the fallback process. This is done by clicking the "Fallback" button in the Server Recovery Manager interface on the IM and Presence Serviceability page. To prevent this manual step in the future, the system should be configured for automatic fallback. This is achieved by setting the "Automatic Fallback" parameter to 'True' within the Cisco Server Recovery Manager service parameters. This ensures that once a failed node recovers, it will automatically resume its primary role.

A. Advising users to re-login is a client-side action that will not change the server's "Failed Over" state or trigger the required fallback process.
B. The fact that failover occurred successfully implies that the Presence Redundancy Group is already correctly configured with both servers.
C. Restarting the server is not the standard procedure to initiate a fallback. The server has already recovered; a manual command is needed if automatic fallback is disabled.

1. Cisco Unified Communications Manager and IM and Presence Service System Guide

Release 14SU3

"High Availability for IM and Presence Service" chapter

"Fallback" section.

Reference for D: "If you configure manual fallback

you must manually initiate the fallback of users to their home cluster after the node recovers. You initiate manual fallback from the Server Recovery Manager user interface."

Reference for E: "If you configure automatic fallback

the system automatically initiates the fallback of users to their home cluster after the node recovers... You can configure automatic fallback in the Service Parameters Configuration window for the Cisco Server Recovery Manager service."

2. Configuration and Administration of IM and Presence Service on Cisco Unified Communications Manager

Release 12.5(1)SU1

"Configure High Availability" chapter

"Configure Server Recovery Manager" section.

Reference for D: This guide details the manual fallback procedure: "From Cisco Unified IM and Presence Serviceability

choose Tools > Server Recovery Manager. ... Click Fallback to begin the fallback process."

Reference for E: This guide details the automatic fallback configuration: "To enable automatic fallback

you must set the Automatic Fallback service parameter to True for the Cisco Server Recovery Manager service."

To troubleshoot Cisco Jabber service connectivity issues, such as the inability to control a desk phone, the engineer must first check the status of the client's connections to the backend Unified Communications services. The "Show Connection Status" window in the Jabber client provides a detailed, real-time view of all service connections, including CTI (for desk phone control), softphone, presence, directory, and voicemail. Accessing this tool via the Help menu is the standard, built-in procedure for diagnosing these types of problems directly from the client.

B. Click Help and dick XML settings: The Jabber client does not have a "XML settings" option under the Help menu for viewing live connection status; this relates to configuration files.
C. Click XML settings and click Help: This describes an illogical and non-existent menu path within the Cisco Jabber for Windows application.
D. Click TFTP settings and click Help: TFTP settings are part of the initial service discovery and configuration process, not a menu item for checking the current connection status.

1. Cisco Jabber 14.1 Deployment and Installation Guide: In the "Troubleshoot Cisco Jabber" chapter, section "Connection Status," the procedure is explicitly stated: "To check the connection status of your services, in the hub window, select Help > Show connection status." This window is identified as the primary tool for verifying service connectivity.

2. Troubleshooting Guide for Cisco Jabber 12.5: The section "Check Service Connection Status" details the process: "In the Jabber hub, click the gear icon, and then select Help > Show connection status. The Connection Status window opens. You can see the connection status for each service." This confirms the menu path and its purpose.

3. Cisco Unified Communications Manager (CUCM) Administration Guide, Release 12.5(1)SU1: In the "Cisco Jabber" chapter, under the "Troubleshooting Cisco Jabber" section, it references checking the client's status. It implicitly supports that client-side diagnostics, like checking connection status, are the first step before investigating server-side CTI Manager service issues. (Reference: Chapter on "Cisco Jabber", Section on Troubleshooting).

The Cisco Telephony Service Provider (TSP) is a client-side driver that enables TAPI-compliant applications, such as the Cisco Unified Attendant Console Advanced, to interact with Cisco Unified Communications Manager (UCM). The TSP instance on the attendant console server establishes a direct and persistent TCP/IP connection to the Cisco CTI (Computer Telephony Integration) Manager service running on a UCM server. The CTI Manager service acts as the dedicated gateway for all third-party CTI applications, authenticating them and brokering communication for call control and event monitoring with the core Cisco CallManager service.

B. Cisco DirSync Service: This service is responsible for synchronizing user data from an external LDAP directory into the UCM database, not for real-time call control.
C. Cisco CallManager Service: While this is the core call processing engine, the TSP does not communicate with it directly. The CTI Manager service is the intermediary for all CTI application traffic.
D. Cisco TAPS Service: The Tool for Auto-Registered Phones Support (TAPS) is used for bulk phone provisioning and has no role in CTI integration for attendant consoles.

1. Cisco Unified Communications Manager Administration Guide

Release 12.5(1)SU1

"Computer Telephony Integration" Chapter.

Reference: In the "CTI Manager" section

it states

"The Cisco CTI Manager contains the CTI components that interface with TAPI... applications. The CTI Manager service communicates with the Cisco CallManager service..." This establishes the CTI Manager as the direct interface for TAPI/TSP clients.

2. Cisco Unified TAPI Developer Guide for Cisco Unified Communications Manager

Release 12.5(1)

"Cisco TAPI Architecture" Chapter.

Reference: The section "Cisco TAPI and Cisco Unified Communications Manager" explicitly states

"The Cisco TAPI Service Provider (TSP) interfaces with the Cisco Unified Communications Manager by using the CTI Manager." An accompanying architectural diagram visually confirms that the TSP connects directly to the CTI Manager.

3. Cisco Unified Attendant Console Advanced - Administration and Installation Guide

Release 12.5

"Configure the Cisco TSP" section.

Reference: The configuration steps for the Cisco TSP require the administrator to enter the IP addresses of the UCM servers that are running the CTI Manager service. This demonstrates that the TSP is configured to connect directly to the CTI Manager.

In Cisco Unity Connection, the Caller Input settings define the actions that are executed when a caller presses a key (DTMF) while listening to a call handler's greeting. To specify whether callers can perform transfers from an automated attendant, the administrator must configure these key mappings. This includes setting a key to transfer to an operator, another call handler, or enabling the option to allow transfers to any extension. Disabling these specific key actions or the general transfer capability within this section effectively prevents callers from performing transfers.

B. call handler owners: This setting is for administrative purposes, defining which users can modify the call handler's greetings and settings, not for call routing.
C. message settings: This section configures the behavior for taking voice messages, such as the recipient and message urgency, not for live call transfers.
D. transfer rules: These rules determine how a call is routed before the call handler greeting is played, based on the called party's status, not on caller input during the greeting.

1. Cisco Unity Connection System Administration Guide

Release 14

"Call Handlers" chapter

"Caller Input" section.

This guide states

"The Caller Input page for a call handler lets you define the action that Unity Connection takes for each key that a caller can press." It lists actions such as "Call Handler

" "Interview Handler

" "Directory Handler

" and "Transfer to an alternate contact number

" confirming this is the correct location to configure caller-initiated transfers.

2. Cisco Unity Connection Design Guide

Release 12.5(1)

"Cisco Unity Connection" chapter

"Call Handlers" section.

This document describes the function of call handlers

explaining that they "can be configured to provide callers with a menu of options (for example

'For Sales

press 1; for Service

press 2')." The configuration of these menu options is done via the Caller Input settings.

3. Cisco Unity Connection Features and Services Guide

Release 14

"Call Routing and Restriction" chapter

"Call Routing in Unity Connection" section.

This guide differentiates between routing rules (which include transfer rules) and call handler actions. It clarifies that transfer rules are part of the initial call routing process

while caller input settings manage the interactive menu presented to the caller once they reach the handler.

Cisco Unity Connection evaluates the entire string of digits a user dials against the patterns in the applicable restriction table. To prevent toll fraud where a user dials a trunk access code (e.g., '9') followed by a restricted number (e.g., an international number), the restriction table pattern must include the trunk access code itself. For a system with two phone integrations, patterns must be created for each respective trunk access code (e.g., 9011 and 8011) to effectively block such calls. This ensures that any attempt to dial out using a known trunk access code is matched and subjected to the configured restrictions.

B. This is a general function of restriction tables but does not address the specific problem of handling trunk access codes in the dialed string.
C. This describes a specific blocking rule (a policy), not the fundamental configuration method required to make the rule effective when a trunk access code is used.
D. Similar to C, this is a common policy but fails to explain the mechanism needed to enforce it when calls are prefixed with a trunk access code.

1. Cisco Unity Connection System Administration Guide

Release 12.x

Chapter: "Managing Restriction Tables in Cisco Unity Connection

" Section: "Restriction Tables."

This guide states

"When a user attempts to transfer a call... Unity Connection compares the phone number that the user enters with the patterns in the restriction table..." This confirms that the entire dialed string

including any manually dialed trunk access code

is evaluated

necessitating patterns that match the code.

2. Cisco Unity Connection Security Guide

Release 12.x

Chapter: "Preventing Toll Fraud

" Section: "Configuring Restriction Tables to Prevent Toll Fraud."

This section details best practices for configuring restriction tables. The principle is to create patterns that match number sequences known to be associated with toll fraud. For this to be effective

the patterns must reflect the actual digits dialed by the user

which includes any trunk access codes. For example

to block international calls where the access code is '9'

a pattern like 9011# is required.

The core mechanism for Message Waiting Indication (MWI) in a SIP integration between Cisco Unity Connection and Cisco Unified Communications Manager (CUCM) relies on Unity Connection dialing specific MWI-On and MWI-Off directory numbers. When CUCM receives a call to one of these pre-configured numbers from the voicemail system, it triggers the corresponding MWI light on the user's phone. If these numbers are not configured in CUCM under Advanced Features > Voicemail > Message Waiting, CUCM has no way to process these requests. A failure to configure these numbers results in a complete, system-wide MWI failure, which matches the problem description. The exhibit specifically shows the page where this essential configuration is performed.

A. The SIP Trunk Security Profile is primarily for security settings. The MWI mechanism is an outbound call from Unity Connection, not an unsolicited notification to CUCM that this profile would block.
B. The Delay Between Requests timer is a performance tuning setting on Unity Connection. Adjusting it would affect the speed of MWI updates, not cause a complete functional failure.
C. While the SIP Trunk's Calling Search Space must be able to reach the MWI numbers, the existence of the MWI numbers themselves is the more fundamental prerequisite for the feature to work at all.

1. Cisco Unified Communications Manager Administration Guide

Release 14SU3

"Voicemail" chapter

"Message Waiting" section.

This guide states

"The message-waiting feature provides a lighted message-waiting lamp on the IP phone... When a caller leaves a message for a user

the voice-messaging system sends a signal to the Cisco Unified Communications Manager to light the lamp on the user phone. The voice-messaging system does this by dialing the appropriate message-waiting on/off directory number." This confirms the dependency on the configured DNs.

2. Integration Guide for Cisco Unity Connection with Cisco Unified Communications Manager Using SIP

Release 14

"Configuring Cisco Unified CM for the Integration" chapter

"Task List for the Integration" section.

This document lists "Configuring Message Waiting Indicators in Cisco Unified CM" as a mandatory step. It specifies that MWI on and MWI off directory numbers must be added under Advanced Features > Voicemail > Message Waiting

directly corresponding to the action in the correct answer.

3. Cisco Unified Communications Manager Features and Services Guide

Release 14SU3

"Message Waiting" chapter

"Message Waiting Configuration" section.

This guide provides the explicit procedure: "To configure the message-waiting on and off directory numbers

perform the following procedure... Step 1: Choose Advanced Features > Voicemail > Message Waiting." This highlights that configuring these numbers is the primary action to enable the feature.

In Cisco IM and Presence version 10.x, the default configuration for a high-availability redundancy group is Manual Fallback. This means that after a failed node recovers and becomes active, the system will not automatically move users back to their primary (homed) node. An administrator must explicitly initiate this process by navigating to the Redundancy Group configuration in Cisco Unified CM Administration and clicking the "Fallback" button. Since the system is configured with defaults, the user sessions remain on the backup node because this required manual action has not been performed.

B. The user accounts were moved to the redundant server. This describes the normal and expected behavior of a failover event; it is the result of the failure, not the cause of the subsequent fallback issue.
C. The failed service Of server was offline longer than the Client Re-Login upper Lint setting. This client-side timer determines how long a client attempts to reconnect before its session is terminated. It does not control the server-side Server Recovery Manager (SRM) fallback mechanism.
D. The failed service or server has not been active for at least 30 minutes. This refers to the "Server Recovery Delay" timer, which ensures a node is stable before allowing fallback. While this can delay the process, the root cause of a complete lack of automatic fallback is the manual default setting.

1. Cisco Unified Communications Manager and IM and Presence Service

System Configuration Guide

Release 10.5(2)

Chapter: Configure IM and Presence Service High Availability

Section: Configure Redundancy Groups

Quote: "By default

the IM and Presence Service is configured for manual fallback. You must manually initiate a fallback of users from the backup IM and Presence Service node to the home node after the home node recovers." This directly supports that manual intervention (clicking the Fallback button) is required with default settings.

2. Cisco Unified Communications Manager and IM and Presence Service

Administration Guide

Release 10.5(2)

Chapter: Configure IM and Presence Service High Availability

Section: Fallback of IM and Presence Service Nodes

Quote: "To manually initiate a fallback of users from the backup node to the home node

click Fallback." This specifies the exact action described in the correct answer. It also details the "Server Recovery Delay" timer

confirming its default is 30 minutes

which explains why option D is a temporary condition

not the root cause.

The IM and Presence Service High Availability feature includes a "Primary Re-Login Timer" to ensure a restored primary node is stable before it accepts user connections. By default, this timer is set to 30 minutes. After a primary node recovers from a failure and its state becomes RUNNING, the system waits for this timer to expire before automatically moving users from the secondary (standby) node back to the primary. The scenario describes a recently restored primary node, so the observed behavior of users remaining on the secondary node is expected until this stability timer elapses.

A. Reboot the primary node: The primary node is already in a RUNNING state. Rebooting it would only restart the 30-minute stability timer and delay the user fallback process further.
C. Modify the Client Re-Login Limits: This parameter controls client login rate-limiting to prevent login storms. It does not influence the server-side high-availability fallback mechanism for a restored node.
D. Set the Keep-Alive (Heartbeat) interval to 15: The heartbeat interval determines how quickly the system detects a node failure. It does not affect the process of moving users back to a primary node after it has been restored.

1. Cisco Unified Communications Manager IM and Presence Service Configuration and Administration Guide

Release 14SU3

"High Availability on IM and Presence Service" chapter

"Configure High Availability" section.

Reference: "Primary Re-Login Timer—This timer specifies the number of minutes that the system waits before it begins to move users back to the primary server after the primary has recovered from a failure. The default is 30 minutes." This directly confirms that a waiting period is the standard

expected behavior.

2. Cisco Live Presentation

BRKCCT-2025

"Troubleshooting Cisco IM & Presence"

2019.

Reference: Slide titled "IM&P HA Failover/Fallback

" describes the fallback process: "After Primary node is back online and stable for 30 minutes (default)

clients are moved back to the Primary node." This reinforces that the 30-minute wait is a critical part of the fallback design to ensure node stability.

The semi-attended transfer mode is the correct configuration because it instructs Cisco Unity Express (CUE) to complete the transfer as soon as it receives an alerting signal (like a SIP 180 Ringing message) from the destination. This means CUE releases the call from its control while the target phone is ringing, but after confirming the destination is reachable. This behavior precisely matches the administrator's requirement for the transfer to finish while the target is ringing, which is more resource-efficient than an attended transfer but more reliable than a blind transfer.

A. attended: This mode requires CUE to wait until the destination party actually answers the call before the transfer is completed and the CUE port is released.
B. blind refer: A blind transfer releases the call immediately after dialing, without waiting for any signal (ringing or answer) from the destination, which can lead to failed transfers if the destination is busy or unavailable.
D. blind bye-also: This is not a valid command option for the transfer-mode in the Cisco Unity Express call handler configuration. ---

1. Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions

Reference: In the "Call-Handler Commands" chapter

under the transfer-mode command description.

Details: The guide specifies the behavior of each mode:

semi-attended: "The system waits for an alerting signal from the telephone system

which indicates that the called party's telephone is ringing

before transferring the call." (This directly supports the correct answer).

attended: "The system waits for the called party to answer the telephone before transferring the call." (This supports why option A is incorrect).

blind: "The system transfers the call without waiting for an answer or for an alerting signal." (This supports why option B is less precise and potentially less reliable than C for the stated goal).

The Cisco Jabber client uses a DNS-based service discovery process to automatically locate its home Cisco Unified Communications Manager (CUCM) cluster. The error "cannot locate server" indicates this discovery process is failing. For internal clients, Jabber queries DNS for an SRV record named cisco-uds.tcp.. This record points to the CUCM servers that provide the User Data Service (UDS), which is the first step for the client to download its configuration. Since manual configuration works, connectivity to the servers is fine. The issue is specific to a new branch, which strongly implies a localized DNS misconfiguration. Adding the cisco-uds.tcp SRV record to the branch DNS server will allow clients to automatically discover the CUCM servers and log in successfully.

A. Reinstall the Jabber clients with UPNDISCOVERYENABLED=false: This parameter alters which domain Jabber uses for its DNS query (email vs. User Principal Name). It does not fix the underlying issue of a missing SRV record in the DNS server.
B. Add a firewall rule to allow TCP/8443 from the branch to HQ: The fact that manual configuration works proves that connectivity on required ports, such as TCP/8443 for UDS, is already established. The error occurs before this connection is attempted.
C. Add a collab-edge Us.company com SRV record to the branch DNS server: The collab-edge SRV record is used exclusively for Mobile and Remote Access (MRA) discovery via Expressway for external clients, not for internal clients on the corporate WAN.

1. Cisco Collaboration System 12.x Solution Reference Network Designs (SRND)

Chapter 10: Collaboration Edge and Mobile and Remote Access.

Section: DNS for Service Discovery

Content: "For automatic service discovery on the internal corporate network

Cisco Jabber clients query for the SRV record cisco-uds.tcp.... This SRV record should point to the CUCM nodes that run the UDS service." This directly supports option D as the correct mechanism for internal discovery. The same section also specifies that collab-edge is for MRA

invalidating option C.

2. On-Premises Deployment for Cisco Jabber 12.9

DNS Configuration.

Section: Create SRV Records for Service Discovery

Content: "To enable automatic service discovery for Cisco Jabber clients on the corporate network

you must configure a Service Location (SRV) record in your DNS server for each of your user's email domains. The SRV record maps the user's email domain to the Cisco Unified Communications Manager servers that are used for service discovery... Format: cisco-uds.tcp.example.com." This confirms the exact SRV record needed.

3. Cisco Unified Communications Manager Administration Guide

Release 12.5(1)SU1

Chapter: User Data Service.

Section: User Data Service

Content: This chapter describes the UDS API

which Jabber uses to access the user's home cluster and contact information. The service discovery process (cisco-uds SRV record) is the mechanism by which clients find the servers providing this essential service. This explains the central role of UDS in the login process.