350-801 Practice Questions

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).

The provided Session Description Protocol (SDP) snippet from the SIP INVITE packet shows that the client is offering to send DTMF tones using the RFC 2833 method, as indicated by the attribute a=rtpmap:101 telephone-event/8000. The problem states that employees cannot select IVR options, which is a classic symptom of a DTMF negotiation failure or mismatch between the endpoint and the IVR server. Since the currently configured method (RFC 2833) is not working, the most probable cause is that the IVR system does not support it. To resolve this interoperability issue, the DTMF signaling method should be changed to one that the IVR supports. KPML (Key Press Markup Language) is another standard out-of-band DTMF relay mechanism for SIP, and configuring it is a valid step to resolve the mismatch.

A. Configure CODEC for G.729: This addresses audio encoding, not the signaling of key presses. DTMF failure with an out-of-band method like RFC 2833 is independent of the audio codec.

C. Configure CODEC for G.722: The SDP already indicates that the G.722 codec is being offered (a=rtpmap:9 G722/8000), so this is not a change or a solution.

D. Configure DTMF for RFC 2833: The SDP trace confirms that RFC 2833 is already being offered. Re-configuring the same failing method will not resolve the issue.

1. Cisco Unified Communications Manager Administration Guide, Release 14SU3, "SIP Profile configuration settings": This guide details the "DTMF Signaling Method" parameter within a SIP Profile. It lists options including "RFC 2833" and "SIP-KPML", explaining that these different methods are used to ensure interoperability between devices that may not support the same DTMF relay mechanism. This supports the rationale that changing from a failing method (RFC 2833) to an alternative (KPML) is a valid troubleshooting step.

2. Cisco Collaboration System 12.x Solution Reference Network Designs (SRND), Chapter: "Unified CM Trunks", Section: "SIP Trunks": This document discusses DTMF relay mechanisms for SIP trunks. It states, "Cisco recommends using RFC 2833 for DTMF relay over SIP trunks," but also acknowledges that for interoperability with third-party systems, other methods like KPML or SIP INFO might be required. This confirms that a mismatch is a common issue requiring a configuration change.

3. IETF RFC 4730, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)": This official RFC defines the KPML standard as a mechanism for transporting DTMF tones, establishing it as a valid alternative to RFC 2833/4733. (See Abstract and Section 1).

4. IETF RFC 4733, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals": This RFC defines the telephone-event RTP payload type seen in the SDP snippet, which is the technical standard for what is commonly called RFC 2833 DTMF relay. (See Section 2.1).

Toll-fraud protection on a Cisco Unified Border Element is achieved by permitting only the call-control protocol that is expected and blocking every other protocol. In IOS/IOS-XE this is done under voice service voip with the command

allow-connections sip to sip

and by omitting any allow-connections statements for H.323, MGCP, SCCP, or T.38.

The configuration shown in Option B is the only one that contains exactly that single line (and no additional protocol pairs), therefore it guarantees that every call traversing the CUBE must be SIP and prevents fraudulent calls that could otherwise arrive via another protocol.

A. Contains allow-connections h323-to-sip/sip-to-h323, so H.323 calls are still accepted—non-SIP traffic is not blocked.

C. Lists multiple allow-connections (h323-h323, sip-h323, etc.); therefore other protocols remain enabled, defeating the SIP-only requirement.

D. Shows no allow-connections commands; default permits none, so legitimate SIP calls would also be rejected, breaking service rather than implementing selective blocking.

1. Cisco Unified Border Element Configuration Guide, “Configuring Protocol Interworking – allow-connections”, IOS XE 17.x, Section “SIP-to-SIP Only” (example 3).

2. Cisco IOS Voice Command Reference, allow-connections (CUBE), Table 2, “Permits only the specified protocol pair”; page 3.

3. Cisco Collaboration SRND 12.x, Chapter “Security and Toll Fraud Prevention”, Section “Restricting CUBE to SIP-to-SIP”; p. 12-14.

4. Cisco Unified Border Element Security Guide, “Toll-Fraud Best Practices”, p. 5-6.

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.