Cisco 350-801 CLCOR common mistakes
Cisco 350-801 CLCOR · Understand the traps and how to avoid them.
Treating Regions and Locations as interchangeable bandwidth controls - configuring a Location for codec selection, or a Region when the goal is call admission control.
Both settings live on the device pool and both sound like 'where the phone is,' so candidates study them as one topic and then guess on scenario items.
What to do instead
Memorize the split: a Region defines which codec is negotiated between two device pools (intra-region vs inter-region relationships, default 64 kbps audio), while a Location enforces call admission control by limiting the total audio/video bandwidth consumed by calls to and from that site. When the question says 'codec,' pick Region; when it says 'too many concurrent calls / bandwidth exceeded,' pick Location (or Enhanced Location CAC).
Computing call bandwidth from the codec payload alone (e.g., answering '80 kbps' for G.711) or from ptime alone, ignoring encapsulation overhead.
The famous numbers 64 kbps and 8 kbps are payload rates, and candidates memorize them without building the full packet stack, so per-call bandwidth and WAN sizing answers come out low.
What to do instead
Always build the packet: payload at the codec rate, plus RTP/UDP/IP headers (roughly 40 bytes when cRTP is off), plus the Layer 2 header for the medium, then divide by ptime. G.711 at 20 ms is a 160-byte payload but about 200 bytes at Layer 3 (~80 kbps) and larger again with Ethernet framing - which is why the classic planning figure is nearer 80–90 kbps than 64. Also remember G.729 at 20 ms carries a 20-byte payload in a ~60-byte Layer 3 packet.
Assuming an early-offer SIP trunk can hand a call directly to an SCCP endpoint with no media resource, or assuming SIP and SCCP handle offer direction symmetrically.
SIP trunks deliver an offer immediately (early offer) while SCCP endpoints cannot accept a media offer before the call is set up, so an MTP is silently required - the design implication is easy to miss if you only study protocol message names.
What to do instead
Know the rule: a SIP early offer to an SCCP device requires a media termination point (the 'MTP Required' concept), while delayed offer lets CUCM wait and avoid the MTP. If the question involves supplementary services, DTMF interworking, or early offer into a legacy endpoint, expect to insert an MTP and make sure one is actually reachable through the device pool's media resource group list.
Assuming one calling search space governs everything - e.g., believing a phone's line CSS applies to the line's own outbound calls only, or that inbound calls from a gateway use the phone's CSS.
CUCM stores the CSS in several places (line, device, translation pattern, SIP trunk, gateway, device pool/Universal templates), and candidates learn the partition/CSS concept once and then apply it everywhere.
What to do instead
Learn the source per direction. Outbound from a phone: the union of the line CSS and the device CSS. Inbound from a gateway or trunk: the CSS configured on that gateway/trunk record, applied to the calling (and for translation patterns, the redirecting) side. A translation pattern only re-routes onward if its own CSS can reach the next target. On any 'the call is rejected/not routed' item, ask 'which CSS is in effect for this specific leg?' before guessing at partitions.
Diagnosing dial-plan failures by reading the route patterns instead of analyzing digit-by-digit matching, and forgetting that CUCM waits on an interdigit timeout (T302) when patterns overlap.
Route pattern matching is longest-match with explicit timer behaviour, not the simple prefix matching most people intuit; overlooked details include the blank 'Urgent Priority' behaviour, the '#' end-of-dialing terminator, and the '-' (discard digits) versus 'block' instructions.
What to do instead
Reach for Dialed Number Analyzer (DNA) in CUCM rather than reasoning in your head, and practice the classic cases: a shorter exact pattern versus a longer overlapping one (longest match wins), a pattern that needs immediate cut-through (Urgent Priority or '#' so the 15-second T302 wait is skipped), and a translation pattern that discards or blocks digits. Verify the call really is a routing problem and not a CSS problem before editing patterns.
Configuring a transcoder, MTP, or MOH server and then assuming it will be used by the phones, without placing it in a media resource group that is in a media resource group list assigned to the device pool.
The resource exists in the cluster but CUCM only allocates resources that are reachable through the device pool's MRGL; the MRG/MRGL indirection is easy to configure partially and easy to skip in a lab.
What to do instead
Follow the full chain every time: resource registered to a CUCM node → assigned to a media resource group → media resource group placed (in the intended order) in the media resource group list → MRGL assigned to the device pool → device pool assigned to the device. Also confirm the transcoder's own region can handle both codecs being bridged; an unreachable or wrong-region transcoder produces exactly the 'call fails or falls back to G.711' symptom the question describes.
Assuming secure endpoint onboarding is 'just enable security' - answering items as if the phone automatically gets a Locally Significant Certificate and trusts the cluster.
Secure onboarding is a chain of trust artefacts (manufacturer-installed certificate, ITL/CTL files, CAPF-issued LSC), and candidates remember only one link of it, usually the CAPF service itself.
What to do instead
Rehearse the chain in order: CAPF service running and activated on the appropriate node; a CTL file created and the phones trusting it (USB eToken in older releases, tokenless CTL via CLI in newer ones); phone security mode set to mixed/secure; then the LSC installed and the device shown as authenticated/encrypted. If a phone shows 'Not Trusted' or fails to register after a cluster change, the ITL/CTL is the first thing to check.
Deploying phones in bulk (auto-registration or BAT) without first verifying the prerequisites - DN range, auto-registration group pointing at a running node, templates, and CSV/field naming.
Auto-registration and BAT both look like a single toggle, but they depend on several objects already existing, and a missing prerequisite produces a generic failure that candidates then misattribute to a network problem.
What to do instead
Before auto-registration: enable it with a valid directory number range on System > Cisco Unified CM, confirm the auto-registration CUCM group points to an active node, and in newer releases confirm the Universal Device Template and Universal Line Template supply the right partition and CSS. Before BAT: build the file to the exact exported template headers, insert the device and line records in the right order, and run a small batch with 'Validate' before committing. When phones register but have no dial tone, check the line's partition/CSS, not the DHCP scope.
Assuming the publisher is required for normal call processing, or assuming any node in the cluster can run any service without design constraints.
Cluster design items mix node roles (publisher/subscriber), service activation, and redundancy groups, so a candidate who has only worked a single-node lab assumes services and registration are cluster-wide and always-on.
What to do instead
Separate the roles: the publisher holds the master database and replicates to subscribers, but subscribers serve call processing and can continue in a publisher outage (with configuration changes failing). Learn which services must be activated per node (TFTP, MOH, CAPF, Cisco CallManager) and which are cluster-wide. For endpoint boot problems, verify the phone's DHCP is returning Option 150 pointing at a node running the TFTP service, and that the phone is in a device pool whose CUCM group lists reachable subscribers.
Mixing up QoS markings and trust boundaries - putting voice bearer traffic at AF41, video at EF, or trusting DSCP at the wrong place in the network.
DSCP values are memorized as a list rather than as a model, and the trust-boundary concept (mark at the phone/access switch, then trust inward) is skipped because it feels like 'network stuff' on a collaboration exam.
What to do instead
Fix the model in memory: voice bearer EF (46), interactive video AF41 (34), call signaling CS3 (24), and set the trust boundary at the access layer (Cisco IP phone 'trusted' on the switch port, or the phone's own DSCP settings) so downstream devices trust rather than re-mark. On items describing one-way audio or degraded voice across a WAN, check both marking and whether the queue/LLQ configuration honours EF before blaming the codec.