Cisco
Expert
350-801
Implementing and Operating Cisco Collaboration Core Technologies
The Cisco 350-801 CLCOR (Implementing and Operating Cisco Collaboration Core Technologies) exam is the core requirement for the CCNP Collaboration certification. This expert-level exam validates the knowledge and skills required to implement and operate Cisco collaboration technologies including infrastructure, protocols, codecs, endpoints, call control, QoS, and collaboration applications.
The exam covers six comprehensive domains: Infrastructure and Design (20%), Protocols, Codecs, and Endpoints (20%), Cisco Unified Communications Manager (UCM) (30%), Call Control (20%), Quality of Service (QoS) (10%), and Collaboration Applications (10%). Candidates must demonstrate proficiency with Cisco UCM, Cisco Unity Connection, Cisco Expressway, Cisco Jabber, Webex, and integration with LDAP and other enterprise systems.
Key skills tested include configuring dial plans and digit manipulation, implementing media resources such as conferencing bridges and transcoders, troubleshooting call routing issues, implementing QoS policies for voice and video traffic, configuring endpoints including phones and video devices, and integrating collaboration applications. This certification is essential for collaboration engineers responsible for designing, implementing, and maintaining enterprise unified communications solutions.
Updated 2024
Networking
90
Questions
6
Practice Tests
83%
Pass Score
35
Views
0
Total Attempts
0%
Avg. Score
0%
Pass Rate
0
Discussions
350-801 Practice Exam 1
Comprehensive CLCOR practice exam covering infrastructure and design, protocols codecs and endpoints, Cisco Unified Communications Manager, call control, and quality of service across 65 collaboration core questions.
65 Q
120 minutes
70%
350-801 Practice Exam 2
Comprehensive CLCOR practice exam covering infrastructure and design, protocols codecs and endpoints, Cisco Unified Communications Manager, call control, and quality of service across 65 collaboration core questions.
65 Q
120 minutes
70%
350-801 Practice Exam 3
Comprehensive CLCOR practice exam covering infrastructure and design, protocols codecs and endpoints, Cisco Unified Communications Manager, call control, and quality of service across 65 collaboration core questions.
65 Q
120 minutes
70%
350-801 Practice Exam 4
Comprehensive CLCOR practice exam covering infrastructure and design, protocols codecs and endpoints, Cisco Unified Communications Manager, call control, and quality of service across 65 collaboration core questions.
65 Q
120 minutes
70%
350-801 Practice Exam 5
Comprehensive CLCOR practice exam covering infrastructure and design, protocols codecs and endpoints, Cisco Unified Communications Manager, call control, and quality of service across 65 collaboration core questions.
65 Q
120 minutes
70%
350-801 Practice Exam 6
Comprehensive CLCOR practice exam covering infrastructure and design, protocols codecs and endpoints, Cisco Unified Communications Manager, call control, and quality of service across 65 collaboration core questions.
65 Q
120 minutes
70%
Unlock All Content for 350-801
6 Practice Test(s) + Flash Cards — 3 months access
€39.99
€26.99
Save 30%
or included with Monthly subscription / Content Bundle
Preview (10 / 150)
What is the role of CUCM in a collaboration network?
Cisco Unified Communications Manager is the call processing engine that handles call routing, signaling, device registration, and feature management for IP phones and endpoints.
What does Cisco Expressway provide?
Expressway provides firewall traversal for remote and mobile users, enabling secure collaboration access without requiring a VPN connection to the enterprise network.
What is the purpose of Cisco Unity Connection?
Unity Connection provides voicemail and unified messaging services, integrating voice messages with email and allowing users to access messages from multiple devices.
What does a SIP trunk connect?
A SIP trunk connects a CUCM cluster to an ITSP or another call control system over an IP network, replacing traditional PRI or analog trunks for PSTN access.
What is the function of a voice gateway?
A voice gateway converts voice traffic between IP-based and traditional telephony networks such as PSTN, handling protocol and media conversion at the network edge.
What is the CUCM Publisher role?
The Publisher is the primary database node in a CUCM cluster. It holds the writable copy of the database and replicates configuration changes to all Subscriber nodes.
What is a CUCM Subscriber role?
Subscribers are secondary servers that handle call processing and provide redundancy. They receive a read-only database replica from the Publisher node.
What is the purpose of IMP in Cisco collaboration?
Cisco IM and Presence (IMP) provides instant messaging and availability status for Jabber clients, integrated with CUCM for unified communication services.
How does CUCM clustering provide redundancy?
A CUCM cluster uses multiple servers with database replication and device failover. Phones register to a primary and backup server using the CM Group configuration.
What is Cisco Webex Edge Connect?
Edge Connect provides a dedicated, private link from an enterprise network to the Webex cloud, bypassing the public internet for improved quality and security.
Flash Cards
cards covering key 150 concepts 350-801
or included with Monthly subscription / Content Bundle
140 more cards available after unlock
Available Languages
English
Exam Topics
1
18 Q
Infrastructure and Design
Design collaboration infrastructure, configure high availability, and implement network integration for voice and video.
2
18 Q
Protocols, Codecs, and Endpoints
Configure SIP, H.323, and SCCP protocols, select appropriate codecs, and deploy endpoints and gateways.
3
27 Q
Cisco Unified Communications Manager
Configure UCM components, implement dial plans, configure media resources, and integrate with LDAP and other systems.
4
18 Q
Call Control
Configure call routing, digit manipulation, translation patterns, and call admission control mechanisms.
5
9 Q
Quality of Service
Implement QoS policies for voice and video traffic, configure DSCP markings, and troubleshoot QoS issues.
350-801 Cheat Sheet
Quick reference guide - 6 sections
Implementing and Operating Cisco Collaboration Core Technologies (350-801 CLCOR)
The Cisco 350-801 CLCOR exam validates your ability to implement and operate core collaboration technologies including SIP, H.323, MGCP, and other signaling protocols, Cisco Unified Communications Manager (CUCM), QoS, and collaboration infrastructure. This is the core exam required for the CCNP Collaboration and CCIE Collaboration certifications. The CLCOR exam covers a broad range of Cisco Unified Communications technologies, from foundational protocols and codecs to advanced call routing, globalized dial plans, SRST/MGCP failover, and end-to-end QoS implementation. Candidates must demonstrate practical knowledge of deploying and maintaining collaboration solutions including IP telephony, video, messaging, and presence services. The exam tests both theoretical understanding and hands-on implementation skills across infrastructure design, protocol operations, CUCM administration, call control features, and quality of service mechanisms. A strong understanding of TCP/IP networking fundamentals is assumed, and candidates should be comfortable configuring Cisco IOS voice gateways, CUCM route patterns, and QoS policies. Passing the 350-801 along with one concentration exam earns the CCNP Collaboration certification, which demonstrates professional-level competence in designing, implementing, and troubleshooting Cisco Collaboration solutions in enterprise environments.
Exam Details
| Exam Code | 350-801 CLCOR |
| Duration | 120 minutes |
| Number of Questions | 55-65 questions |
| Passing Score | Cisco does not publish (scaled 300-1000) |
| Cost | $400 USD |
| Validity | 3 years (renewable via CE credits or re-exam) |
| Question Types | Multiple choice, multiple select, drag-and-drop, fill-in-the-blank |
| Certification Level | Professional (CCNP Collaboration core exam / CCIE Collaboration qualifying exam) |
Domain Weights
| Domain | Weight |
|---|---|
| Infrastructure and Design | 20% |
| Protocols, Codecs, and Endpoints | 20% |
| Cisco Unified Communications Manager | 20% |
| Call Control | 20% |
| Quality of Service | 20% |
Study Tips
- All five domains carry equal weight at 20% each, so you cannot afford to neglect any domain; a balanced study approach across all areas is essential for passing the exam
- SIP message flows are heavily tested; memorize the differences between SIP INVITE, ACK, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, and UPDATE methods along with common response codes (1xx provisional, 2xx success, 3xx redirect, 4xx client error, 5xx server error, 6xx global failure)
- CUCM administration is a major focus; practice configuring calling search spaces, partitions, route patterns, route groups, route lists, translation patterns, and transformation masks in a lab environment
- QoS is critical for collaboration; understand DSCP markings (EF for voice, AF41 for video, CS3 for call signaling), trust boundaries, classification and marking at the access layer, queuing mechanisms (LLQ, CBWFQ), and shaping vs policing
- Understand SRST and MGCP fallback scenarios thoroughly; know what happens when a branch router loses WAN connectivity to CUCM and how phones register to the local SRST gateway
- Codec selection and bandwidth calculations are frequently tested; know the bandwidth requirements for G.711, G.729, iLBC, and common video codecs including H.264 and H.265, and how to calculate bandwidth with Layer 2/3 overhead
- Set up a home lab using Cisco Modeling Labs or GNS3 with CUCM virtual machines for hands-on practice; configuration-based questions are common and difficult to answer from theory alone
Collaboration Deployment Models
| Deployment Model | Description |
|---|---|
| Single Site | All collaboration components (CUCM, voicemail, gateways, endpoints) are at a single location; simplest deployment model with no WAN considerations; all call processing is local with no bandwidth concerns between sites; suitable for small to medium organizations with one office; PSTN access through local gateways or SIP trunks |
| Multisite with Centralized Call Processing | CUCM cluster at the central site processes calls for all remote sites; remote sites connect over the WAN; requires Call Admission Control (CAC) to prevent WAN oversubscription; SRST provides backup call processing when WAN fails; most common enterprise deployment model; requires careful bandwidth planning and QoS implementation across the WAN |
| Multisite with Distributed Call Processing | Each site has its own CUCM cluster for local call processing; intercluster trunks (ICT) or SIP trunks connect the clusters; Cisco Unified Communications Manager Session Management Edition (CUCM SME) provides centralized dial plan management; no WAN dependency for local calls; more complex but more resilient; suitable for large enterprises with autonomous branch offices |
| Clustering Over the WAN (CoW) | A single CUCM cluster spans across WAN links between two or more sites; subscribers at different sites within the same cluster; requires high-bandwidth, low-latency WAN (maximum 80ms round-trip time between CUCM nodes); provides transparent failover between sites; limited to eight sites maximum per cluster; WAN link must maintain at least 1.544 Mbps between cluster nodes |
Exam Tip: Centralized call processing is the most commonly tested deployment model because it introduces WAN dependencies, requiring knowledge of CAC, SRST, AAR, and QoS. Remember that Clustering Over the WAN requires RTT under 80ms and at least 1.544 Mbps between nodes. For the exam, always consider WAN failure scenarios and how the design handles them.
CUCM Cluster Architecture
| Component | Description |
|---|---|
| Publisher | Primary database server in the cluster; holds the master read-write copy of the CUCM database (IDB); all configuration changes must be made on the Publisher; replicates database changes to all Subscribers via intra-cluster communication; there is exactly one Publisher per cluster; hosts TFTP service for configuration file distribution |
| Subscriber | Secondary servers that hold read-only copies of the database; provide call processing for registered phones; a cluster supports up to 21 servers (1 Publisher + up to 20 Subscribers); phones register to their primary Subscriber and fail over to backup call processing nodes; Subscribers can be dedicated to specific functions (call processing, TFTP, music on hold) |
| Device Registration | Phones obtain IP via DHCP (Option 150 provides TFTP server address); phone downloads configuration file from TFTP server (SEP<MAC>.cnf.xml); configuration file contains the ordered list of CUCM nodes for registration; phone registers with the first available CUCM node from the list using SCCP or SIP; maximum 40,000 devices per CUCM server (varies by OVA template) |
| Database Replication | Intra-cluster replication keeps all nodes synchronized; uses Informix Dynamic Server (IDB) for real-time replication; verify replication status with CLI command "utils dbreplication runtimestate"; replication states: 0 (initializing), 1 (replication setup script not run), 2 (good replication); if replication fails, run "utils dbreplication repair" or "utils dbreplication reset" for severe issues |
SRST and MGCP Fallback
| Feature | Description |
|---|---|
| Survivable Remote Site Telephony (SRST) | Provides basic call processing at a branch router when WAN connectivity to CUCM is lost; phones re-register to the local SRST gateway using SIP or SCCP; supports basic features like call transfer, hold, forward, conference, and speed dial; configured via "call-manager-fallback" (SCCP) or "voice register global" (SIP) on the IOS gateway; SRST reference is configured in CUCM and included in phone configuration files; phones detect CUCM failure via keepalive timeout and automatically register to the SRST IP |
| Enhanced SRST (E-SRST) | Extends basic SRST with additional features; supports shared lines, hunt groups, and Cisco Unity Connection voicemail integration during failover; preserves more of the normal operating feature set compared to basic SRST; requires Cisco Unified SRST license and IOS version support; phones maintain call features more transparently during WAN outages |
| MGCP Fallback | When CUCM controls MGCP gateways and the WAN link fails, the gateway automatically falls back to local H.323 or SIP call routing; configured with "ccm-manager fallback-mgcp" and "mgcp fallback" commands on the gateway; the gateway uses locally configured dial peers for PSTN routing during fallback; when CUCM connectivity is restored, the gateway returns to MGCP control automatically |
| Automated Alternate Routing (AAR) | Provides an alternate route when CAC denies a call due to insufficient bandwidth; typically reroutes calls through the PSTN when the WAN is congested; each phone is assigned an AAR group and an AAR calling search space; when locations-based CAC blocks a call, CUCM automatically prepends AAR digits and reroutes via the PSTN; ensures calls complete even when WAN bandwidth is exhausted |
Exam Tip: SRST is for phone registration failover when CUCM is unreachable, while MGCP fallback is for gateway failover to local call routing. AAR handles call rerouting when CAC blocks a call due to bandwidth constraints. These three mechanisms address different failure scenarios and are frequently tested together in scenario questions. Know the CLI commands: "call-manager-fallback" for SCCP SRST, "voice register global" for SIP SRST.
Network Infrastructure Requirements
- DHCP Option 150: Provides the IP address of the TFTP server to IP phones during DHCP negotiation; essential for phone auto-provisioning; Option 150 supports multiple TFTP server addresses (Cisco-specific) while Option 66 supports only a single TFTP server address; configure on the DHCP server or IOS router with "option 150 ip <TFTP_IP>"
- DNS Requirements: CUCM nodes should have forward and reverse DNS entries; SIP trunks may use DNS SRV records for redundancy and load balancing; DNS SRV records allow phones and trunks to discover available servers with priority and weight values; format: _sip._tcp.domain.com with priority, weight, port, and target host
- NTP Synchronization: All collaboration components must be time-synchronized; CUCM Publisher acts as the NTP reference for the cluster; phones synchronize time from CUCM; gateways should synchronize to the same NTP source; certificate validation and CDR timestamps depend on accurate time; configure with "ntp server <IP>" on IOS devices
- Voice VLAN: Separate VLAN for IP phones isolates voice traffic from data; configured on access switches with "switchport voice vlan <ID>"; phones tag voice packets with 802.1Q using the voice VLAN ID; CDP or LLDP-MED communicates the voice VLAN to the phone; provides security segmentation, QoS prioritization, and simplified network management
SIP (Session Initiation Protocol)
| SIP Method | Description |
|---|---|
| INVITE | Initiates a session (call setup); carries the SDP offer describing media capabilities (codecs, IP addresses, ports); creates a dialog identified by Call-ID, From tag, and To tag; a re-INVITE modifies an existing session (codec change, hold, transfer); the three-way handshake for call setup is INVITE -> 200 OK -> ACK |
| REGISTER | Binds the user's AOR (Address of Record) to a contact address (device IP and port); sent to the SIP registrar server (CUCM); registration expires after a configurable interval and must be refreshed; phones send periodic re-REGISTER messages before expiry; authentication uses digest authentication with username and password challenge-response |
| BYE | Terminates an established session; sent by either party in the dialog; only valid after the dialog is established (after 200 OK and ACK exchange); CUCM may generate BYE on behalf of endpoints for call features like transfer or maximum call duration enforcement |
| CANCEL | Cancels a pending INVITE before the final response; used when the caller hangs up before the callee answers; only works for pending transactions (before 200 OK); generates a 487 Request Terminated response to the original INVITE; cannot cancel an already-established call (use BYE instead) |
| REFER | Instructs the recipient to send a new request to a third party; used for call transfers; contains a Refer-To header with the target URI; the recipient sends a new INVITE to the Refer-To target; NOTIFY messages report the status of the referred transfer back to the sender; CUCM uses REFER for attended and blind transfers |
| SUBSCRIBE / NOTIFY | SUBSCRIBE requests event notifications from a resource; NOTIFY delivers event state information; used for presence (user online/offline/busy/away status), message waiting indicator (MWI), BLF (Busy Lamp Field) monitoring; event packages include: dialog (call state), presence (user state), message-summary (voicemail); subscriptions expire and must be refreshed |
| OPTIONS | Queries the capabilities of a SIP endpoint or server; used by CUCM as a SIP trunk keepalive mechanism (SIP OPTIONS Ping); the response includes supported methods, codecs, and features; does not establish a session; commonly used for monitoring SIP trunk status between CUCM and service providers or CUBE |
SIP Response Codes
| Code Range | Category | Key Codes |
|---|---|---|
| 1xx | Provisional | 100 Trying (request received, processing), 180 Ringing (callee is being alerted), 183 Session Progress (early media, ringback tone from SDP) |
| 2xx | Success | 200 OK (request succeeded, call answered for INVITE, registration accepted for REGISTER), 202 Accepted (REFER accepted) |
| 3xx | Redirection | 301 Moved Permanently (user relocated), 302 Moved Temporarily (call forwarding), 305 Use Proxy |
| 4xx | Client Error | 401 Unauthorized (authentication required), 403 Forbidden, 404 Not Found (number not in route plan), 408 Request Timeout, 480 Temporarily Unavailable, 486 Busy Here, 487 Request Terminated (CANCEL received), 488 Not Acceptable Here (codec mismatch) |
| 5xx | Server Error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable (CUCM overloaded or out of resources) |
| 6xx | Global Failure | 600 Busy Everywhere (callee busy at all locations), 603 Decline (callee explicitly rejected the call) |
Exam Tip: Memorize the SIP call flow: INVITE -> 100 Trying -> 180 Ringing -> 200 OK -> ACK -> (media flows via RTP) -> BYE -> 200 OK. The difference between 486 Busy Here and 600 Busy Everywhere is that 486 means busy at this contact but reachable at another, while 600 means busy at all registered contacts. Response 488 indicates a codec or media negotiation failure in SDP.
H.323 Protocol Suite
| Protocol | Function | Transport |
|---|---|---|
| H.225 RAS | Registration, Admission, Status; endpoint-to-gatekeeper communication for registration (RRQ/RCF/RRJ), admission control (ARQ/ACF/ARJ), and bandwidth management (BRQ/BCF/BRJ) | UDP 1719 |
| H.225 Call Signaling | Call setup and teardown messages (Setup, Alerting, Connect, Release Complete); based on Q.931 adapted for packet networks; establishes the call and negotiates capabilities | TCP 1720 |
| H.245 | Media control; negotiates media capabilities including codec selection, logical channel parameters, and master-slave determination; opens and closes logical channels for audio and video streams | TCP (dynamic port) |
| RTP / RTCP | RTP carries the actual voice and video media payload; RTCP provides quality statistics (jitter, packet loss, round-trip delay); RTP uses even-numbered UDP ports, RTCP uses the next odd port; RTP port range typically 16384-32767 on Cisco devices | UDP (dynamic ports) |
Audio Codecs Comparison
| Codec | Bit Rate | Sample Size | Bandwidth (with L2/L3) | MOS Score |
|---|---|---|---|---|
| G.711 (u-law/a-law) | 64 kbps | 20ms | ~87.2 kbps (Ethernet) | 4.1 |
| G.729 | 8 kbps | 20ms | ~31.2 kbps (Ethernet) | 3.92 |
| G.722 | 64 kbps | 20ms | ~87.2 kbps (Ethernet) | 4.5 (wideband) |
| iLBC | 13.3 / 15.2 kbps | 30ms / 20ms | ~29-37 kbps (Ethernet) | 4.14 |
| Opus | 6-510 kbps | 2.5-60ms | Variable | 4.5+ (adaptive) |
Exam Tip: Bandwidth calculation formula: Total bandwidth = (codec bit rate + IP/UDP/RTP headers) x packets per second. IP/UDP/RTP header overhead is 40 bytes (20 IP + 8 UDP + 12 RTP). For G.711 with 20ms samples: payload = 160 bytes, total packet = 200 bytes, PPS = 50, bandwidth = 80 kbps + Layer 2 overhead. G.711 u-law is used in North America and Japan, G.711 a-law is used in Europe and the rest of the world. G.729 requires a DSP license on gateways.
Video Codecs and Signaling Protocols
- H.264 (AVC): Most widely deployed video codec in Cisco collaboration; supports resolutions from QCIF (176x144) to full HD 1080p (1920x1080); uses profiles (Baseline, Main, High) to define feature sets; bandwidth ranges from 384 kbps to 6+ Mbps depending on resolution and frame rate; required for interoperability with most video conferencing systems
- H.265 (HEVC): Next-generation video codec offering approximately 50% better compression than H.264 at equivalent quality; requires more CPU for encoding and decoding; supported on newer Cisco endpoints (Webex Room series, Board series); ideal for bandwidth-constrained environments and 4K video
- SCCP (Skinny Client Control Protocol): Cisco proprietary signaling protocol between IP phones and CUCM; lightweight stimulus-based protocol where the phone sends key presses and CUCM provides instructions; uses TCP port 2000 (non-secure) or TCP 2443 (TLS secure); being gradually replaced by SIP in modern deployments but still widely used on older phone models
- MGCP (Media Gateway Control Protocol): Master-slave protocol where CUCM (call agent) controls the voice gateway; gateway has minimal intelligence; uses UDP port 2427 (gateway) and 2727 (call agent); commands include CRCX (Create Connection), MDCX (Modify Connection), DLCX (Delete Connection), RQNT (Notification Request), NTFY (Notify); preferred for centralized gateway management from CUCM
- RTCP (RTP Control Protocol): Provides statistics for RTP media streams including sender reports (SR) and receiver reports (RR); reports jitter, packet loss, delay, and packets sent/received; used by CUCM for quality monitoring and MOS score calculation; RTCP Extended Reports (XR) provide additional metrics for voice quality assessment
CUCM Call Routing Components
| Component | Description |
|---|---|
| Route Pattern | Defines a digit pattern that CUCM matches against dialed digits; uses wildcards: X (single digit 0-9), ! (one or more digits), @ (national numbering plan), [range] (digit range like [2-9]), . (optional, used after ! or @); route patterns point to either a gateway/trunk directly, a route list, or a SIP trunk; example: 9.1[2-9]XX[2-9]XXXXXX matches 10-digit dialing with a 9 access code; partition controls which callers can reach this pattern |
| Route Group | An ordered list of gateways and/or trunks for routing calls; provides redundancy through ordered failover; if the first device in the list is unavailable, CUCM tries the next; distribution algorithm options: top-down (ordered failover) or circular (load balancing); each route group can contain multiple gateways for high availability |
| Route List | An ordered list of route groups; provides an additional layer of redundancy and flexibility; a route pattern points to a route list, which contains route groups, which contain gateways; enables complex routing scenarios like try local PSTN first, then overflow to SIP trunk; called party transformations can modify digits differently for each route group within the list |
| Translation Pattern | Manipulates dialed digits before routing; does not route calls directly; transforms the calling or called number using masks and prefix/strip operations; commonly used for abbreviated dialing (4-digit to 10-digit expansion), E.164 normalization, and applying site codes; the call is re-evaluated against route patterns after translation; placed in partitions and reachable via calling search spaces |
| Transformation Pattern | Modifies calling and called party numbers for PSTN presentation; called party transformation: adjusts the called number sent to the PSTN (e.g., strip internal site code); calling party transformation: adjusts the caller ID presented to the PSTN (e.g., set the correct DID as caller ID); applied at the route pattern, route list, route group, gateway, or trunk level |
Exam Tip: The routing hierarchy is: Route Pattern -> Route List -> Route Group -> Gateway/Trunk. Remember the call routing order: CUCM first evaluates urgently matched patterns, then uses Closest Match / Best Match routing logic. Interdigit timeout (T302 timer, default 15 seconds) determines how long CUCM waits after the last digit before routing. The # key can be used as an end-of-dialing indicator to bypass the interdigit timeout.
Calling Search Spaces and Partitions
| Concept | Description |
|---|---|
| Partition | A logical grouping of route patterns, directory numbers, and translation patterns that share the same reachability characteristics; similar to a route table or access list; examples: PT_Internal (internal extensions), PT_Local (local PSTN), PT_LongDistance (long distance), PT_International (international), PT_Emergency (911/emergency); patterns in different partitions can overlap without conflict because each partition is a separate namespace |
| Calling Search Space (CSS) | An ordered list of partitions that defines what a device or line can call; determines call routing scope for a phone, line, gateway, or trunk; CUCM searches partitions from top to bottom and routes to the first match found; effective CSS is the combination of line CSS plus device CSS (line CSS partitions searched first, then device CSS partitions); maximum partitions per CSS is configurable but keep it manageable for troubleshooting |
| CSS Design Strategy | Common approach: Line CSS for calling privileges (internal, local, long distance, international) and Device CSS for site-specific routing (which gateway or trunk to use); this separates the calling privilege decision from the routing decision; example: lobby phone gets CSS_Internal (PT_Internal only), executive gets CSS_International (PT_Internal + PT_Local + PT_LD + PT_International + PT_Emergency) |
| Effective CSS Combination | When both line CSS and device CSS are configured, CUCM combines them; line CSS partitions take priority over device CSS partitions; if a pattern matches in the line CSS, it is used; if no match is found in the line CSS, CUCM searches the device CSS partitions; this allows the line CSS to handle privilege-based routing while the device CSS adds location-aware routing for gateways |
CUCM Device Configuration
| Configuration | Description |
|---|---|
| Device Pool | Groups common device settings: CUCM group (ordered list of call processing nodes), date/time group, region, SRST reference, media resource group list, location, calling search space for auto-registration, device mobility group; simplifies device configuration by applying a standardized set of parameters to all phones at a site |
| Region | Controls the audio and video codec selection between endpoints; defines a codec preference matrix: which codecs to use when two devices in different regions communicate; example: within the same site use G.711 (high quality), across the WAN use G.729 (low bandwidth); configured as a matrix with region pairs; also controls maximum video call bandwidth between regions |
| Location | Used for Call Admission Control (CAC); defines the available bandwidth for audio and video calls to and from a site; links between locations specify the maximum bandwidth; when a call would exceed the available bandwidth, CUCM blocks the call (or triggers AAR if configured); deducts bandwidth when a call is established and returns it when the call ends; Hub_None location has unlimited bandwidth by default |
| SIP Trunk Configuration | Connects CUCM to external SIP entities: CUBE, SIP providers, Expressway, Webex; key settings include SIP trunk security profile (TLS or non-secure), SIP profile (SIP timer values, early offer/delayed offer), destination address/port, calling/called party transformations, and calling search space; SIP trunk keepalive uses OPTIONS ping to monitor trunk status; MTP (Media Termination Point) may be needed for features requiring media hairpinning |
Globalized Call Routing (E.164 Dial Plan)
- E.164 Normalization: Convert all directory numbers and incoming called/calling numbers to full E.164 format (+country code + national number); store all DNs in +E.164 format internally; this enables a single global dial plan across all sites; incoming calls from the PSTN are globalized using calling/called party transformation patterns at the gateway or trunk level
- Localization: Transform +E.164 numbers back to local dialing format for PSTN presentation; add or remove access codes, country codes, and area codes as needed per site; apply localization at the outbound gateway or trunk using called party transformation CSS and patterns; users can dial in their local format while the system routes using the globalized +E.164 number internally
- Digit Manipulation Tools: Called Party Transformation Mask (replace digits with a mask), Prefix Digits (prepend digits), Strip Digits (remove leading digits from the pattern), Discard Digits Instruction (DDI, removes access codes like 9 before sending to PSTN); transformations can be applied at multiple levels: route pattern, route list, route group, gateway, or trunk; the most specific level wins
- Intercluster Lookup Service (ILS): Enables automatic dial plan replication between CUCM clusters in a distributed deployment; clusters exchange +E.164 directory URI and alternate number information; eliminates the need for manual route pattern configuration between clusters; ILS uses TCP connections between cluster publishers; works with GDPR (Global Dial Plan Replication) to maintain a unified dial plan across the enterprise
Exam Tip: In a globalized dial plan, the three-step process is: Globalize (convert incoming numbers to +E.164 at the ingress point), Route (match route patterns in +E.164 format), Localize (convert back to local format at the egress point). This approach simplifies multi-site and multi-country deployments dramatically. Remember that the + character in route patterns requires the escape character to be enabled in the CUCM service parameter.
Cisco Unified Border Element (CUBE)
| Feature | Description |
|---|---|
| Session Border Controller | CUBE acts as a SIP Session Border Controller (SBC) between the enterprise and the service provider; provides demarcation, security, interoperability, and protocol normalization; runs on Cisco IOS/IOS-XE routers (ISR 4000, CSR 1000v, Catalyst 8000); requires a CUBE license; acts as a SIP back-to-back user agent (B2BUA) that terminates one SIP session and creates a new one |
| SIP Trunk Interworking | Normalizes SIP signaling between different implementations; handles differences in SIP headers, SDP formats, codec negotiation, and DTMF methods between CUCM and the ITSP; performs protocol-to-protocol conversion (SIP to SIP, SIP to H.323); supports SIP profiles for header manipulation; manages early offer/delayed offer conversion for codec negotiation compatibility |
| Media and Security | Provides media anchoring (all RTP flows through CUBE for NAT traversal and recording); supports SRTP-to-RTP interworking (secure internal, non-secure external); TLS for SIP signaling encryption; performs transcoding between incompatible codecs when media resources are available; topology hiding prevents internal network information from being exposed to external parties through SIP headers and SDP |
| Dial Peer Configuration | CUBE uses dial peers to match and route calls; inbound dial peer matches incoming calls based on called number (incoming called-number), calling number, or VoIP interface; outbound dial peer routes calls based on destination pattern; dial-peer groups provide ordered failover; key commands: "dial-peer voice [tag] voip", "destination-pattern", "session target", "session protocol sipv2", "voice-class codec", "voice-class sip bind" |
Exam Tip: CUBE is a B2BUA, not a proxy; it completely terminates and re-originates SIP sessions. This allows CUBE to perform header manipulation, topology hiding, and protocol normalization. The "voice service voip" and "sip" configuration mode enables global SIP settings. Know the difference between dial-peer matching for inbound (incoming called-number, answer-address) and outbound (destination-pattern) call legs.
CUCM Call Features
| Feature | Description |
|---|---|
| Call Forward | Forward All (CFA): redirects all calls to another number regardless of status; Forward Busy (CFB): activates when the line is busy; Forward No Answer (CFNA): activates after the no-answer ring duration (configurable timer); Forward Unregistered: activates when the phone is offline; each forward type has its own CSS that determines reachable destinations; CFA can be activated by the user via softkey or self-care portal |
| Call Park and Pickup | Call Park: places a call on hold at a park number that another user can retrieve by dialing; configured with call park numbers and a reversion timer (call reverts to parker if not picked up); Directed Call Park: parks to a specific number; Call Pickup: answers a ringing call in the same pickup group; Group Call Pickup: answers a call in a different pickup group using the group number; Other Group Pickup: answers a ringing call in any associated group |
| Hunt Groups and Line Groups | Hunt Pilot: the number dialed to reach the hunt group; Hunt List: ordered list of line groups; Line Group: a set of directory numbers with a distribution algorithm (top-down, circular, longest idle, broadcast); hunt behavior when no answer: try next member or next line group; RNA reversion timeout configures how long to ring before moving on; allows calls to be distributed across multiple agents or phones |
| Shared Lines and Barge | Shared line: same DN on multiple devices; when one device answers, others stop ringing; all devices can see the line state (idle, ringing, in-use via remote-in-use indication); Barge: allows a third party to join an active call on a shared line creating an ad-hoc conference; cBarge: uses the built-in conference bridge; Privacy: prevents barge on shared lines when enabled; configured at the phone configuration page |
Media Resources
| Resource | Description |
|---|---|
| Conference Bridge (CFB) | Provides multi-party conferencing; software-based (Cisco IOS Enhanced Conference Bridge or CUCM-based) or hardware-based (DSP on ISR); supports ad-hoc and Meet-Me conferences; ad-hoc is created by pressing the Confrn softkey during a call; Meet-Me uses a preconfigured number that participants dial into; hardware bridges support more simultaneous sessions with better performance |
| Media Termination Point (MTP) | Terminates and re-originates media streams; required when SIP endpoints do not support features like hold (re-INVITE with a=sendonly) or transfer (REFER); software MTP on CUCM server or hardware MTP on DSP; used when connecting to legacy or non-compliant SIP devices; SIP trunk option "Media Termination Point Required" forces MTP allocation for all calls on that trunk |
| Transcoder | Converts media between incompatible codecs; required when two endpoints cannot negotiate a common codec (e.g., G.711 to G.729 conversion); hardware-based using DSP resources on ISR routers (PVDM modules); configured as a media resource in CUCM; assigned via Media Resource Group (MRG) and Media Resource Group List (MRGL); CUCM automatically invokes transcoders when codec mismatch is detected |
| Music on Hold (MOH) | Provides audio (music or announcements) to callers placed on hold; unicast MOH (dedicated stream per held call) and multicast MOH (single stream shared by all held calls in a subnet); audio source files uploaded as .wav format (G.711 u-law, 8kHz, 16-bit mono); up to 51 audio sources; multicast reduces bandwidth but requires multicast-enabled network infrastructure; MOH server runs on a CUCM subscriber |
| Annunciator | Plays pre-recorded announcements and tones; used for intercept recordings, ring-back tones, and feature notifications; software-based running on CUCM; plays messages like "The number you have dialed is not in service" or "Your call is being forwarded"; assigned via MRGL just like other media resources |
Exam Tip: Media Resource Group (MRG) bundles related media resources together, and the Media Resource Group List (MRGL) provides an ordered preference of MRGs. Devices use the MRGL assigned at the device level first, then the device pool MRGL, then the default CUCM resources. Transcoders always require hardware DSP resources; software transcoders are not available on CUCM. Know when MTP is required: SIP trunks that need supplementary services but the far end does not support re-INVITE or REFER.
Collaboration Security
- TLS for Signaling: Encrypts SIP signaling using Transport Layer Security; CUCM uses certificates to authenticate with endpoints and trunks; Certificate Authority Proxy Function (CAPF) enrolls phone certificates for authenticated and encrypted phone connections; phone security profiles define whether a device uses non-secure (TCP), authenticated (TLS with certificate verification), or encrypted (TLS + SRTP) mode
- SRTP for Media: Encrypts RTP media streams using AES-128 or AES-256; requires TLS signaling as a prerequisite (encryption keys exchanged in SDP via SDES); provides confidentiality, message authentication, and replay protection for voice and video media; CUCM phone security mode must be set to "encrypted" for SRTP to be negotiated; interworking between SRTP and RTP is handled by CUBE
- Digest Authentication: SIP phones authenticate to CUCM using digest authentication with a username and password hash; prevents unauthorized device registration; end user credentials are configured in CUCM user pages; the phone challenges with 401 Unauthorized, and the endpoint responds with a hashed credential in the Authorization header
- Certificate Trust List (CTL): A signed file that contains certificates of trusted CUCM servers and TFTP servers; phones download the CTL to verify the identity of CUCM and TFTP servers; prevents man-in-the-middle attacks on phone provisioning; configured using the CTL Client or tokenless CTL with the CLI command "utils ctl set-cluster mixed-mode"; mixed mode enables security for capable devices while allowing non-secure devices to continue operating
QoS Fundamentals for Collaboration
| Impairment | Description | Voice Threshold |
|---|---|---|
| Latency (Delay) | End-to-end delay from speaker to listener; includes propagation, serialization, processing, and queuing delays; codec processing adds algorithmic delay (G.729 = 25ms lookahead) | < 150ms one-way (acceptable), < 300ms (degraded), > 300ms (unacceptable) |
| Jitter | Variation in packet arrival times; caused by queuing delays varying per packet; the de-jitter buffer at the receiver smooths out arrival time variations by buffering packets before playback; excessive jitter causes buffer overflows or underflows resulting in audible artifacts | < 30ms (recommended by Cisco for voice) |
| Packet Loss | Packets dropped due to congestion, buffer overflow, or transmission errors; voice is sensitive to even small amounts of loss; G.729 with its lower bit rate is more sensitive to consecutive packet loss than G.711; concealment algorithms (PLC) mask individual lost packets but cannot compensate for burst loss | < 1% (recommended by Cisco for voice) |
Exam Tip: The Cisco recommendation for voice quality is: one-way latency under 150ms, jitter under 30ms, and packet loss under 1%. Video is more tolerant of latency (up to 200ms) but less tolerant of packet loss (under 0.5% for high-quality video). QoS does not create bandwidth; it manages existing bandwidth by prioritizing collaboration traffic during congestion. QoS is only effective when there is congestion on the link.
DSCP Markings and Per-Hop Behaviors
| Traffic Type | DSCP Value | PHB | Decimal | Description |
|---|---|---|---|---|
| Voice RTP | EF | Expedited Forwarding | 46 | Low latency, low jitter, low loss; strict priority queuing; limited to 33% of link bandwidth to prevent starvation |
| Interactive Video | AF41 | Assured Forwarding 41 | 34 | Bidirectional video conferencing; guaranteed bandwidth with priority treatment; typically allocated 15-30% of link bandwidth |
| Streaming Video | CS4 | Class Selector 4 | 32 | Unidirectional video (surveillance, broadcast); less latency-sensitive than interactive video |
| Voice/Video Signaling | CS3 | Class Selector 3 | 24 | SIP, SCCP, H.323 call signaling; must be delivered reliably for call setup; not as latency-sensitive as media but loss causes call failures |
| Transactional Data | AF21 | Assured Forwarding 21 | 18 | Business-critical applications (ERP, CRM, database); guaranteed minimum bandwidth allocation |
| Bulk Data | AF11 | Assured Forwarding 11 | 10 | Non-real-time transfers (backups, file copies, email); minimum bandwidth guarantee but lower priority than transactional |
| Best Effort | DF (Default) | Default Forwarding | 0 | Standard internet traffic; no guaranteed bandwidth; gets remaining bandwidth after all other classes are serviced; minimum 25% allocation recommended |
| Scavenger | CS1 | Class Selector 1 | 8 | Non-business traffic (gaming, personal streaming); receives bandwidth only when no other class needs it; first to be starved during congestion |
QoS Mechanisms
| Mechanism | Description |
|---|---|
| Classification and Marking | Classification identifies traffic types using DSCP, CoS (802.1p), NBAR (deep packet inspection), or ACLs; marking sets the appropriate DSCP or CoS value in the packet header; should occur as close to the source as possible (at the access layer switch); trust boundary defines where markings from endpoints are trusted; Cisco phones mark voice RTP as EF and signaling as CS3 by default; access switches should trust phone markings (mls qos trust dscp/cos) but re-mark PC traffic to DF |
| LLQ (Low Latency Queuing) | Provides a strict priority queue for voice and other latency-sensitive traffic; voice packets in the priority queue are always serviced first; configured with "priority" keyword in MQC policy-map; must be policed to prevent priority queue starvation of other queues; recommended allocation: voice 10-33% of link bandwidth; a single LLQ or multiple priority levels (priority level 1, level 2) can be configured |
| CBWFQ (Class-Based Weighted Fair Queuing) | Guarantees minimum bandwidth per traffic class during congestion; configured with "bandwidth" or "bandwidth percent" in MQC policy-map; each class gets its guaranteed share plus can borrow unused bandwidth from other classes; used for video, signaling, transactional data, and bulk data classes; the class-default class should receive at least 25% of the link bandwidth for best-effort traffic |
| WRED (Weighted Random Early Detection) | Proactive congestion avoidance mechanism; begins randomly dropping packets before queue is full; drop probability increases as queue depth grows; DSCP-based WRED uses different drop thresholds per DSCP value; lower priority packets are dropped earlier; never apply WRED to the LLQ priority queue (voice must never be randomly dropped); appropriate for TCP-based data classes where senders can back off and retransmit |
| Shaping vs Policing | Shaping: buffers excess traffic and releases it at the configured rate; smooths traffic bursts; adds delay but reduces drops; configured with "shape average" in MQC; recommended on egress toward WAN links where the physical interface speed exceeds the subscribed CIR; Policing: drops or re-marks excess traffic immediately; no buffering; lower latency but can cause drops; configured with "police" in MQC; used at trust boundaries and for traffic contracts |
Exam Tip: The MQC (Modular QoS CLI) framework has three steps: 1) class-map (classify traffic), 2) policy-map (apply actions: police, shape, priority, bandwidth, WRED), 3) service-policy (attach to interface). Voice always gets LLQ (strict priority). Video gets CBWFQ with optional priority (AF41 for interactive). Signaling gets CBWFQ (CS3). Never apply WRED to the voice priority queue. Shaping is for outbound WAN sub-rate interfaces; policing is for trust boundaries.
QoS Trust and Layer 2 Markings
- Trust Boundary: The point in the network where QoS markings from endpoints are trusted; should be at the access layer switch port connected to the IP phone; switch trusts the phone's CoS/DSCP markings for voice traffic but re-marks or sets to zero for traffic from the PC port behind the phone; configured with "mls qos trust cos" or "mls qos trust dscp" and "switchport priority extend trust/cos" on the access port
- CoS to DSCP Mapping: Layer 2 CoS (802.1p, 3-bit field in 802.1Q tag, values 0-7) must be mapped to Layer 3 DSCP (6-bit field in IP header, values 0-63) at Layer 3 boundaries; default mapping: CoS 5 -> DSCP 40 (CS5) but voice should map to DSCP 46 (EF); Cisco phones set CoS 5 for voice RTP and CoS 3 for signaling; custom CoS-to-DSCP maps can be configured on switches when defaults are insufficient
- Auto-QoS: Cisco feature that automatically configures QoS for voice and video; "auto qos voip cisco-phone" trusts CoS from Cisco phones and applies recommended QoS policies; "auto qos voip trust" trusts DSCP from connected devices; "auto qos video" adds video-optimized configurations; auto-QoS generates the equivalent MQC configuration (class-maps, policy-maps, service-policies) automatically; useful as a starting point but may need manual tuning for specific environments
- WAN QoS Design: WAN links are typically the congestion points requiring QoS; recommended allocation: LLQ priority 10-33% for voice, CBWFQ 15-30% for interactive video, CBWFQ 5% for signaling, CBWFQ for transactional and bulk data, minimum 25% for best-effort class-default; total configured bandwidth should not exceed the subscribed WAN rate; use shaping on the LAN interface facing the WAN to match the provider's CIR
Collaboration Quick Reference
| Scenario | Solution |
|---|---|
| Branch loses WAN to CUCM | SRST on local IOS router for phone registration failover + MGCP fallback for local PSTN routing |
| WAN bandwidth exhausted for voice | Locations-based CAC blocks the call + AAR reroutes via PSTN automatically |
| Connect enterprise to SIP provider | CUBE as SBC for demarcation, topology hiding, and SIP normalization |
| Endpoints use incompatible codecs | Hardware transcoder (DSP) registered to CUCM via MRG/MRGL |
| Restrict calling privileges per user | Partitions + Calling Search Spaces (Line CSS for privileges, Device CSS for routing) |
| Multi-country unified dial plan | Globalized +E.164 routing with ingress normalization and egress localization |
| Ensure voice quality over congested WAN | LLQ for voice (EF), CBWFQ for video (AF41) and signaling (CS3), shaping to match WAN CIR |
| Secure voice and signaling | TLS for SIP signaling + SRTP for media encryption + CTL for device authentication |
| Monitor SIP trunk status | SIP OPTIONS Ping keepalive between CUCM and CUBE/provider |