Select Two (Multi-Select) Questions

Interface description

Why it fails: An interface description is administrative labelling text on a router or switch port; it carries no bearing on jitter, latency, packet loss or bandwidth, so it cannot degrade call quality. It is tempting because interface configuration is familiar, but descriptions exist purely for documentation and troubleshooting reference, never as a transport-quality factor.

Router uptime

Why it fails: Router uptime measures how long a device has run since its last reload; a long uptime does not itself affect jitter, latency, loss or available bandwidth, so it does not influence call quality. It is tempting because unstable routers cause outages, but uptime is a stability metric, not a real-time transport-quality factor.

Change voice codec

Why it fails: Codec selection is negotiated in the SDP body and controlled by dial peers and voice-class codec configuration, not SIP profiles. SIP profiles suit header manipulation, such as adding or stripping custom headers, not media attribute changes.

Route calls to PSTN

Why it fails: PSTN routing is determined by dial-peer destination patterns and translation rules, not SIP profiles. SIP profiles manipulate SIP signalling headers; they would be the correct tool for normalising or inserting headers between dissimilar SIP trunks.

Cisco Webex Meetings Server

Why it fails: Cisco Webex Meetings Server is an on-premises meeting solution, not required for Hybrid Message Service. Hybrid Message Service focuses on instant messaging and presence, not meetings. Deploying Webex Meetings Server would not enable IM and presence federation and is unrelated to the requirement.

Cisco Unified Border Element (CUBE)

Why it fails: CUBE is a session border controller for voice and video, not for instant messaging and presence. Hybrid Message Service does not use CUBE; it uses the Expressway-C connector. CUBE would not provide the necessary integration for IM and presence federation with Webex.

Cisco TelePresence Video Communication Server (VCS)

Why it fails: Cisco VCS is used for video interoperability but is not part of the Hybrid Message Service architecture. The Expressway-C (which is based on VCS technology) is used, but a separate VCS is not required. Including VCS would add unnecessary complexity and does not fulfill the IM and presence requirement.

High MTU

Why it fails: Usually beneficial or neutral.

Fast switching

Why it fails: Usually beneficial.

All traffic from a PC connected to an IP Phone should be trusted by default.

Why it fails: Traffic from a PC connected to an IP Phone should not be trusted by default. PCs can send malicious or misconfigured packets with high-priority markings. The switch port should trust only the phone's traffic, often by using a conditional trust or by trusting CoS and re-marking PC traffic to a lower priority.

The trust boundary should be placed at the core layer to centralize QoS marking.

Why it fails: Placing the trust boundary at the core layer is not recommended because traffic from untrusted sources could enter the network and be marked incorrectly before reaching the core. The core should trust the markings already applied at the edge. Centralizing at the core can lead to inefficient QoS and potential security risks.

The trust boundary is only necessary for voice media, not for call signaling.

Why it fails: The trust boundary applies to all types of traffic that require QoS, including call signaling. Signaling needs to be marked with CS3 and trusted to ensure reliable call setup. Ignoring signaling in the trust boundary could lead to delayed call establishment during congestion.

Create a dedicated DNS zone for Exchange

Why it fails: Hybrid Calendar with Exchange requires configuring the OAuth connection and service account, plus adding the Webex host to the Exchange allowed domains; a separate DNS zone is not part of that setup. A dedicated DNS zone would be relevant when splitting internal and external name resolution for a mail namespace, not for calendar integration.

Configure a SIP trunk between Exchange and Webex

Why it fails: Hybrid Calendar uses REST-based calendar connectors and OAuth authorisation, not SIP signalling, so no SIP trunk between Exchange and Webex is required. A SIP trunk would be correct when connecting Webex Calling or a Unified CM environment to the Webex cloud for voice calls, which is a separate deployment.

Install an H.323 gateway in the DMZ

Why it fails: Hybrid Calendar integrates via REST APIs and OAuth with Exchange or Office 365; H.323 is a call-signalling protocol for voice and video gateways, unrelated to calendar event synchronisation. An H.323 gateway would be deployed in the DMZ when connecting on-premises video endpoints to Webex meetings, not for calendar service.

Call routing in CUCM

Why it fails: Call routing in CUCM is performed by the CUCM itself through route patterns, partitions and calling search spaces; CUBE routes only between its own dial peers at the edge. It tempts because CUBE does route calls externally, but that answer would be correct only if the question asked about the enterprise call-control cluster.

IP phone registration

Why it fails: IP phone registration is handled by CUCM's TFTP and CallManager services; CUBE never registers endpoints, it only interconnects signalling and media between domains. It tempts because CUBE sits in the call path, but it would be correct only if the question concerned the call-control server managing SCCP or SIP endpoints.

Voice mail storage

Why it fails: CUBE handles signalling and media interworking at the network edge, including SIP normalisation, TLS/SRTP termination and dial-peer routing; voicemail storage belongs to Cisco Unity Connection. It tempts because voicemail traverses the CUBE as SIP signalling, but voicemail would be correct only if the question asked about a messaging application server.

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.

Route Filter

Why it fails: Route Filter is not a digit-manipulation method; it filters which route patterns or translation patterns a device can use, controlling call routing permissions rather than transforming dialled digits. It is tempting because route filters appear alongside translation patterns in call-routing configuration, so they look related to digit handling.

Region Matrix

Why it fails: Region Matrix governs codec selection between regions for calls, not digit manipulation; it has no mechanism to add, strip or transform dialled digits. It is tempting because regions and locations sit in the same CUCM call-routing configuration area as translation patterns, so they appear relevant to dial-plan work.

Location Configuration

Why it fails: Location Configuration controls bandwidth allocation and call admission across locations, not digit transformation; it cannot add, strip or rewrite dialled digits. It is tempting because locations are configured alongside regions and device pools in CUCM, so they seem part of the same dial-plan toolset.

Configuring multiple TFTP servers in Option 150

Why it fails: Multiple Option 150 TFTP servers give phones redundant configuration file sources, not redundant call processing; if the registered subscriber fails, the phone cannot place calls. It is tempting because it genuinely removes the TFTP server as a single point of failure, which would be correct when the requirement is resilient phone provisioning.

IP address redundancy via DHCP

Why it fails: DHCP supplies a single IP address per phone; it cannot deliver a secondary address for failover to another CUCM node. It is tempting because DHCP Option 150 is central to phone provisioning, and it would be correct when the requirement is delivering TFTP server addresses or basic network configuration to endpoints.

Load balancing via round-robin

Why it fails: Round-robin load balancing spreads registrations across subscribers but provides no failover; if one node fails, phones assigned to it lose service. It is tempting because round-robin is a genuine distribution mechanism, and it would be correct when the goal is balancing load across multiple healthy servers, not surviving a node outage.

TFTP service hosting

Why it fails: TFTP hosting delivers configuration files to IP phones during boot; the Webex App softphone registers directly to Cisco Unified Communications Manager and needs no TFTP provisioning. It is tempting because TFTP is central to traditional desk phone deployment, but that role belongs to the CUCM server, not the softphone client.

DNS root server

Why it fails: A DNS root server resolves top-level domains for internet name resolution; the Webex App softphone registers to Cisco call control and provides calling features, not DNS infrastructure. It is tempting because softphones rely on DNS for service discovery, but that lookup is a client function, not a feature the app supplies.

DHCP server functionality

Why it fails: DHCP assigns IP addresses and option 150 parameters to endpoints; the Webex App softphone consumes network configuration rather than serving leases to other devices. It is tempting because softphone registration depends on DHCP-supplied TFTP and NTP options, but the app is a DHCP client, never a server.

Providing transcoding for G.711 to G.729

Why it fails: Codec conversion between G.711 and G.729 requires a transcoder resource, which decodes and re-encodes the media stream; an MTP relays packets without altering their codec. MTP is tempting because it also sits in the media path, but it exists for DTMF interworking and protocol interworking, not transcoding.

Increasing voice bandwidth

Why it fails: Bandwidth is governed by codec choice and the RTP stream itself, not by MTP, which neither compresses nor expands media payloads. MTP is tempting because it manipulates the media path, but its purpose is relaying DTMF or converting between SIP and H.323 signalling, not altering bitrate.

A local SIP trunk

Why it fails: Webex room device registration requires a workspace licence, activation code and network access to Webex cloud services; a local SIP trunk is unnecessary because Webex handles call routing in its cloud. SIP trunks suit on-premises CUCM deployments connecting to PSTN providers, not cloud-registered devices.

An existing CUCM registration

Why it fails: Webex room devices register to the Webex cloud, not to CUCM; an existing CUCM registration is not a prerequisite and is irrelevant to cloud registration. It tempts because CUCM is a familiar call-control platform, but Webex device onboarding requires cloud-based activation and licensing instead.

Use broadcast mode

Why it fails: CUCM requires NTP servers configured in unicast client mode, not broadcast, because broadcast NTP is not supported for cluster time synchronisation. Broadcast mode tempts administrators familiar with legacy LAN time distribution, yet it fails CUCM's requirement for explicit, authenticated unicast server references on each node.

Enable NTP on the local voice gateway

Why it fails: NTP synchronisation is required on CUCM nodes and the network infrastructure they reference, not on the voice gateway itself, which merely registers endpoints. Enabling NTP there is tempting because gateways are cluster-adjacent devices, but it satisfies no CUCM time-source requirement; the correct choices name CUCM servers and their upstream NTP sources.

SIP Profile with Outbound Proxy

Why it fails: A SIP Profile with Outbound Proxy is used to direct SIP signaling to a specific proxy server, often for firewall traversal or service provider integration. While it can be useful, it is not required for basic external dialing from a Room Kit Pro registered to CUCM. The SIP Profile on CUCM does not control dial plan routing; that is handled by Route Patterns and Translation Patterns. Thus, it is not a mandatory element for external dialing.

Device Pool with Region settings

Why it fails: A Device Pool with Region settings controls codec selection and bandwidth management between devices. While important for call quality, it does not enable external dialing. The Region settings determine which codecs are used for calls within and between regions, but they do not route calls to external numbers. Therefore, this is not one of the two required elements for external dialing.

Translation Pattern

Why it fails: Translation Patterns are used to manipulate dialed digits before routing, such as adding or removing prefixes. They are not always required for external dialing; they are used for specific dial plan transformations. While they can be part of a dial plan, they are not mandatory to enable basic external dialing. The essential element is the Route Pattern, which actually routes the call. Therefore, this is not one of the two required elements.

JPEG

Why it fails: JPEG is a still-image compression format, carrying no audio samples, so it cannot encode a voice stream. It is tempting because it is a widely used media codec, and codec lists often mix audio and video, but it belongs to video and image transport, not Cisco audio negotiation.

H.264

Why it fails: H.264 is a video compression standard, encoding picture frames rather than audio samples, so it cannot serve as an audio codec. It is tempting because it appears in the same media negotiation and is often listed alongside audio codecs, but it belongs to video streams.

MP3

Why it fails: MP3 is a lossy music storage and playback format, not a codec negotiated in Cisco call signalling; collaboration endpoints use G.711, G.729, G.722 and Opus. It is tempting because it is a familiar audio codec, but its purpose is file-based music distribution, not real-time RTP voice.

Disable SIP digest authentication

Why it fails: Digest authentication challenges SIP messages, so disabling it removes verification of peer identity and exposes the signalling path to spoofing. It tempts because digest adds configuration and troubleshooting overhead, but that is not a security reason; the recommended design keeps authentication enabled between CUCM and CUBE.

Enable H.323 Fast Start

Why it fails: H.323 Fast Start speeds call setup by carrying media channel information in the initial Q.931 message; it is unrelated to SIP signalling security between CUCM and CUBE. It tempts because it is a legitimate CUBE dial-peer setting, but the stem asks for secure SIP signalling steps, not call-establishment tuning.

Cisco Unity Connection.

Why it fails: Cisco Unity Connection is a voicemail application reached through a SIP trunk or route pattern, not a media resource an MRGL can order. It tempts because it registers with Cisco Unified Communications Manager, yet MRGLs govern only transcoders, conference bridges and MTPs.

SIP Trunk.

Why it fails: An MRGL orders media resource groups containing transcoders, conference bridges and MTPs; SIP trunks are routed by route groups and route lists instead. It tempts because trunks carry the calls those resources serve, but dial-plan routing, not resource allocation, is their domain.

The publisher must be included in the CUCM Group to ensure that phones can register if all subscribers fail.

Why it fails: The publisher should not be used for call processing in a production cluster because it can become overloaded, affecting database replication and other critical services. While the publisher can run the Cisco CallManager service, best practice is to exclude it from CUCM Groups for device registration. Subscribers are designed to handle call processing, and redundancy is achieved by having multiple subscribers in the CUCM Group.

The maximum number of CUCM servers in a CUCM Group is five, allowing for greater redundancy.

Why it fails: A CUCM Group can contain a maximum of three CUCM servers. This limit ensures that devices do not spend excessive time trying to register to unavailable servers. While five might seem beneficial, the three-server limit is a design constraint in CUCM. Additional redundancy is achieved by having multiple CUCM Groups and Device Pools, but each group is limited to three servers.

CUCM Groups are assigned to phones directly on each phone configuration page, not via Device Pool.

Why it fails: CUCM Groups are not assigned directly to phones. Instead, they are referenced in a Device Pool, which is then assigned to phones. The Device Pool contains settings like CUCM Group, Region, Location, and Date/Time Group. This hierarchical approach simplifies management and ensures consistent configuration across many devices.

Codec

Why it fails: Route patterns define number patterns and destination route lists or gateways; codec selection occurs on regions, device pools or SIP profiles. It is tempting because codecs govern call quality across the dial plan, and choosing one is correct when configuring regions or device pool audio settings.

Bandwidth Limit

Why it fails: A route pattern requires the dialled number pattern plus route list, gateway or route group; bandwidth limit is set on the location or call admission control configuration. It is tempting because CAC does police call volume, and bandwidth limits would be entered when defining locations for call admission control.

Softkey Template

Why it fails: Route patterns require the dialled pattern and a destination route list, gateway or route group; softkey templates are assigned to devices or device profiles. It is tempting because templates control user-facing call features, and selecting one is correct when configuring phone button or softkey layouts.