Cisco Certified Internetwork Expert (CCIE) Collaboration — Practice Set 1

Question 1

A multinational company has CUCM clusters in New York (CUCM-NY) and London (CUCM-LON) with an inter-cluster SIP trunk between them. The company uses a globalized dial plan. A user in London (DN +442071234567) calls a user in New York (+12125559876). The SIP trunk between clusters uses E.164 addressing. CUCM-LON must route the call. Which CUCM-LON configuration elements are required to correctly route this inter-cluster call? (Choose 2)

Accepted Answer

For inter-cluster routing in a globalized dial plan: Option A — a route pattern +1.! (the period-exclamation wildcard matching any number after +1) in the appropriate partition gives CUCM-LON a dial plan entry for North American numbers, pointing to the inter-cluster SIP trunk via a route list. Option C — a CUCM SIP Route Pattern (configured under Call Routing > SIP Route Pattern) matching the +1 domain (or a specific subdomain) provides URI-based routing for SIP inter-cluster trunks. Both mechanisms are valid; in a fully globalized dial plan, SIP Route Patterns are preferred for inter-cluster URI routing. A translation pattern stripping the + is not required on a SIP trunk that natively carries E.164. The inter-cluster trunk's CSS controls which partitions are accessible on the receiving cluster, not the originating cluster's routing.

Question 2

A CUCM cluster has the following route patterns for PSTN access:
  - 9.1[2-9]XX[2-9]XXXXXX (partition PSTN-PT, Route List RL-PSTN-GW1)
  - 9.[2-9]XXXXXX (partition PSTN-PT, Route List RL-PSTN-GW1)
  - 9.011! (partition INTL-PT, Route List RL-PSTN-GW2)
A call is placed from a phone with CSS containing PSTN-PT and INTL-PT to the digits 9-1-408-555-1234. Which route pattern does CUCM select and why?

Accepted Answer

CUCM route pattern matching uses the most-specific (longest) match algorithm, similar to the IP routing longest-prefix match. The digits dialed are 9-1-408-555-1234. Pattern 9.1[2-9]XX[2-9]XXXXXX matches specifically: '9' + '1' + area code 408 (matching [2-9]XX) + exchange 555 (matching [2-9]XXX portion) + subscriber 1234. Pattern 9.[2-9]XXXXXX would match only 9 + 7 digits (local format) — the leading '1' after '9.' does not match [2-9], so this pattern actually does NOT match this 11-digit number at all. 9.011! requires the international exit code 011 prefix. Therefore only 9.1[2-9]XX[2-9]XXXXXX matches. CUCM never selects multiple patterns for a single call.

Question 3

A company is migrating from on-premises CUCM to a hybrid deployment where some sites use Webex Calling and others remain on CUCM. The architect must ensure that calls between CUCM users and Webex Calling users use an internal IP path (not the PSTN) with 4-digit dialing. Which CUCM design element allows CUCM to route 8XXX calls (Webex user extensions) to the CUBE LGW without consuming a PSTN route?

Accepted Answer

The correct hybrid dial plan design creates a new partition (WEBEX-PT) containing a route pattern 8XXX that routes to a route list pointing to a SIP trunk between CUCM and the CUBE LGW. This SIP trunk connects CUCM to the Webex Calling LGW CUBE. WEBEX-PT is added to the CSS of CUCM phones so they can match the 8XXX range. The CUBE normalizes the short-code dialing to E.164 and routes via the registered Webex trunk to the cloud. No PSTN trunk is used, no charges are incurred, and the path is entirely over the IP network. The route pattern 8XXX is separate from any PSTN route patterns.

Question 4

An engineer captures the following SIP ladder for a failed call: Caller (10.1.1.10) CUBE (10.1.1.1) PSTN SP (10.2.2.1) |--INVITE-------->| | | |--INVITE----------------->| | |<--100 Trying-------------| | |<--183 Session Progress---| |<--183 Sess Prog-| | |--PRACK--------->| | | |--PRACK------------------>| | |<--200 OK (PRACK)---------| |<--200 (PRACK)---| | | |<--200 OK (INVITE)--------| |<--200 OK--------| | |--ACK----------->| | | | (no ACK forwarded) | | |<--BYE--------------------| (SP tears down after T1 timer) |<--BYE-----------| | The PSTN SP sends BYE after approximately 32 seconds. Why is the ACK not forwarded from CUBE to the PSTN SP, and what configuration on CUBE would fix this?

Accepted Answer

Cisco CUBE operates as a SIP B2BUA (Back-to-Back User Agent) — it terminates each SIP leg independently and generates new SIP messages on the far-side leg. CUBE must generate the ACK toward the PSTN SP after receiving the 200 OK on the PSTN leg. If the 200 OK arrives from a Contact header IP address different from the dial-peer's 'session target' IP, CUBE may fail to match the dialog and not send the ACK. The PSTN SP retransmits the 200 OK per RFC 3261 T1 timer (doubles every retransmit up to 64*T1 ≈ 32 seconds) before sending BYE to tear down the unanswered call. The fix is to ensure CUBE's outbound interface binding matches the source IP expected by the SP, using 'voice class sip bind control source-interface'. The 'options-keepalive' is a separate issue (SIP OPTIONS health checks), not ACK routing.

Question 5

A CUBE is configured for early offer (EO) on the dial-peer toward CUCM. The SDP in the INVITE sent to CUCM contains 'm=audio 0 RTP/AVP 0' (port 0). CUCM rejects the call with '488 Not Acceptable Here'. What does port 0 in the SDP media line indicate, and what CUBE configuration causes this?

Accepted Answer

In SDP, a port value of 0 in an m= line indicates that the media stream is inactive/declined. When CUBE receives a delayed offer SIP INVITE (no SDP), it must generate an SDP in the early offer mode for the onward CUCM leg. If the CUBE's CUCM-facing dial-peer has 'early-offer forced' but no explicit codec preference, CUBE cannot determine which codecs to offer and may generate an empty or port-0 SDP offer. CUCM receives 'm=audio 0 ...' which it interprets as a declined audio stream and responds with 488 Not Acceptable Here. The resolution is to explicitly configure codec preferences on the CUBE's CUCM-facing dial-peer so CUBE can construct a valid SDP offer when no SDP was received from the originating side. RFC 3264 confirms that a port value of 0 rejects/deactivates the stream.

Question 6

An engineer observes that DTMF digits are not being passed correctly through a CUBE between a Cisco IP phone (using RFC 2833 / RTP-NTE) and a legacy IVR system (using SIP INFO DTMF). Which CUBE configuration resolves the DTMF interworking?

Accepted Answer

Cisco CUBE can perform DTMF interworking between different DTMF methods on each call leg. By configuring 'dtmf-relay rtp-nte' on the phone-side dial-peer (matching the phone's RFC 2833 capability) and 'dtmf-relay sip-info' on the IVR-side dial-peer, CUBE receives RFC 2833 RTP Named Telephone Events from the phone and translates them into SIP INFO messages toward the IVR. This is a fundamental CUBE feature. Configuring only RTP-NTE on both sides would cause CUBE to pass RFC 2833 events which the SIP INFO-only IVR cannot process. 'No dtmf-relay' enables in-band DTMF, but this only works with G.711 (not G.729 which compresses and distorts DTMF tones) and requires the IVR to decode in-band tones — not guaranteed for a legacy IVR.

Question 7

A Cisco IP phone sends a SIP REGISTER with an Expires header value of 3600 seconds to CUCM. CUCM responds with a 200 OK with Expires: 3600. Which statement about phone re-registration is correct?

Accepted Answer

Per RFC 3261, SIP UAs typically re-register at approximately half the registration expiry interval to proactively refresh the registration before it expires. With a 3600-second expiry, the phone re-registers at approximately 1800 seconds. This prevents the registration from expiring due to network delays or retransmission. If the re-REGISTER fails (network outage), the phone still has 1800 seconds of remaining registration before CUCM removes the binding, during which recovery can occur. Re-registering exactly at T=3600 risks expiry if the REGISTER message is delayed. SIP REGISTER renewal is client-initiated; CUCM does not send notifications to trigger renewal.

Question 8

The following SIP INVITE SDP offer is received by a CUBE from a PSTN SP:

v=0
  o=- 3623 3623 IN IP4 10.2.2.1
  s=-
  c=IN IP4 10.2.2.1
  t=0 0
  m=audio 20000 RTP/AVP 8 0 18 101
  a=rtpmap:8 PCMA/8000
  a=rtpmap:0 PCMU/8000
  a=rtpmap:18 G729/8000
  a=rtpmap:101 telephone-event/8000
  a=fmtp:101 0-15
  a=sendrecv

The CUBE's dial-peer toward CUCM has 'codec preference 1 g711ulaw'. CUCM has a region configuration restricting the CUBE-facing SIP trunk to G.729 only. What codec will be used for this call, and what will happen during SDP negotiation?

Accepted Answer

CUCM Region configuration enforces maximum codec bandwidth between devices. The CUBE trunk is in a region configured for G.729 only (8 kbps). When CUCM receives the INVITE (forwarded by CUBE) containing G.711 and G.729 options, CUCM's SDP answer in the 200 OK includes only G.729 (payload 18), rejecting G.711 codecs. CUBE, as a B2BUA, receives the CUCM 200 OK with G.729 and generates an SDP answer back to the PSTN SP selecting G.729 (payload type 18 was present in the SP's original offer). Since G.729 was in the SP's offer, both endpoints accept G.729 and no transcoder is required. The CUBE's dial-peer 'codec preference' provides a preference hint but CUCM's region restriction takes precedence during SDP negotiation.

Question 9

A CUBE administrator runs 'show sip-ua calls' and sees an active call with state 'STATE_ACTIVE' but no RTP packets are being transmitted. 'Show voip rtp connections' shows the call with 0 Rx packets. The call has been active for 2 minutes. Which CUBE feature can detect and clear stale RTP-less calls automatically?

Accepted Answer

Cisco CUBE's media inactivity detection feature monitors active RTP streams. When no RTP packets are received on an established call leg for longer than the configured threshold (configured via 'voice service voip / media inactivity-criteria / timer <seconds>'), CUBE generates a SIP BYE to clear the stale call. This prevents zombie calls from consuming resources when media has silently stopped flowing (e.g., due to firewall blocking RTP, NAT timeout, or endpoint crash). The feature is configured globally under 'voice service voip'. Call-duration limits disconnect calls based on total duration, not media inactivity. CDP is a Layer 2 discovery protocol unrelated to RTP detection.

Question 10

A CUBE (IOS XE 17.9) configuration has the following dial-peer:

dial-peer voice 100 voip
   session protocol sipv2
   session target ipv4:10.2.2.50
   incoming called-number .
   voice-class codec 10
   voice-class sip options-keepalive profile 5
   no vad

An incoming call from 10.2.2.50 to DID +14085551000 arrives. The call matches dial-peer 100 as the inbound dial-peer. Which outbound dial-peer matching sequence does CUBE use to route the call onward to CUCM?

Accepted Answer

For CUBE outbound dial-peer matching, Cisco IOS XE evaluates dial-peers in the following order: (1) destination-pattern matching the called number (after any translation); (2) answer-address matching the calling number; (3) the default dial-peer 0 (if no explicit match found). The most specific match wins. In this scenario, CUBE received the call with called number +14085551000 and will search all configured outbound VoIP dial-peers for a 'destination-pattern' matching +14085551000 (or the translated version if a voice translation profile is applied). The outbound CUCM-facing dial-peer should have 'destination-pattern +1408555....' or a similar globalized pattern. The inbound dial-peer's session target is not re-used for outbound routing — the inbound and outbound dial-peers are independent in a B2BUA.

Question 11

A collaboration engineer needs to configure an MTP (Media Termination Point) on IOS XE for calls between CUCM and a third-party SIP endpoint that does not support RFC 2833 DTMF relay. Why is an MTP needed in this scenario?

Accepted Answer

A Media Termination Point (MTP) anchors the RTP media stream through a controlled media relay point without performing codec conversion (that is the transcoder's role). CUCM uses an MTP when it needs to perform supplementary service features (hold, transfer, conference) with endpoints that are not compliant with Cisco's SIP implementation for mid-call re-INVITEs. The MTP also enables CUCM to perform DTMF relay interworking: CUCM sends RFC 2833 DTMF events to the MTP, which converts them to in-band DTMF tones for the third-party endpoint, or vice versa. MTP is not a codec converter, SIP TLS enabler, or protocol converter.

Question 12

A CUCM administrator is troubleshooting a call routing failure. A user dials 91408555XXXX and the call fails with reorder tone. The user's CSS includes partitions INTERNAL-PT, PSTN-PT, and INTL-PT. The route pattern 9.1[2-9]XX[2-9]XXXXXX exists in PSTN-PT pointing to Route List RL-PRIMARY. RL-PRIMARY contains Route Group RG-CUBE with CUBE as the only gateway. 'Show route group status' in CUCM shows RG-CUBE is 'Out of Service'. What is the MOST likely reason and resolution?

Accepted Answer

CUCM monitors registered SIP trunks and gateways for availability using SIP OPTIONS keepalive probes (when configured) or SIP registration state. When CUCM cannot reach the CUBE (OPTIONS probe times out or is rejected), CUCM marks the route group as Out of Service. Calls that match the route pattern are routed to the route list, which contains only the Out-of-Service route group — CUCM cannot find an available gateway and returns reorder tone. The resolution is to investigate CUBE reachability (ping, 'show sip-ua status'), verify the SIP trunk configuration on both CUCM and CUBE, and ensure CUBE is responding to SIP OPTIONS. If RL-PRIMARY had a backup route group, calls could overflow, but with only one route group, the failure causes a busy/reorder condition.

Question 13

A CUCM administrator configures Forced Authorization Codes (FAC) for international calls. A user dials 9-011-44-20-7946-0958 (an international number) and is prompted to enter a code. The user enters the correct code, but the call still fails. CUCM CDR shows the call was rejected after code entry. Which CUCM configuration is MOST likely misconfigured?

Accepted Answer

After a user successfully enters a valid Forced Authorization Code in CUCM, CUCM re-evaluates the call routing. The call must match a route pattern accessible via the phone's Calling Search Space (CSS). If the international route pattern 9.011! is in partition INTL-PT and INTL-PT is not included in the phone's CSS, the call fails even with a correct FAC. FAC validation occurs before the final routing decision — the FAC gates whether the call attempt proceeds, but the route pattern must still be reachable within the CSS. Common misconfiguration is creating the FAC requirement on the route pattern but forgetting to ensure the INTL-PT partition is in the phones' CSS.

Question 14

A CUCM administrator reviews CDR records and sees that all calls from extension 1001 to extension 2001 are being recorded with a 'finalCalledPartyNumber' different from 2001. The 'finalCalledPartyNumber' shows 2099, which is a call forward destination. The administrator needs to prevent call forward from 2001 to 2099 for specific calling parties. Which CUCM feature provides per-calling-party call forward override?

Accepted Answer

CUCM Call Forward features include a 'Forwarding Calling Search Space' (also called CSS for Call Forward). When a call forward is attempted, CUCM evaluates whether the forwarded call can be completed using this CSS. If the CSS does not include the partition of the forwarding destination (2099's partition), the forward fails. Additionally, some CUCM versions support preventing certain calling parties from being forwarded by using a dedicated Calling CSS on the forward that excludes certain partitions. This provides class-of-service control over which calls can be forwarded. The External Call Transfer Restriction applies only to PSTN destinations. CFA override allows supervisors to block forwarding on specific lines, not per-calling-party control.

Question 15

A CUCM subscriber node is running at 95% CPU utilization during business hours due to high call volume. The administrator wants to add call processing capacity. Which CUCM action adds processing capacity without requiring a new cluster?

Accepted Answer

A CUCM cluster supports multiple Subscriber nodes, each capable of independent call processing. To add call processing capacity, a new Subscriber VM is added to the existing cluster (using CUCM installation and cluster configuration). Phones are redistributed across Subscribers by modifying Device Pools to use an updated CUCM Group that includes the new Subscriber. The Publisher does not perform call processing — it is the database master only. Unity Connection is a voicemail/unified messaging application, not a CUCM call processing replacement. SRST handles branch survivability but doesn't reduce central CUCM load for active calls.

Question 16

A company's Webex Calling LGW (IOS XE 17.9 CUBE) is registered to Webex Calling. An inbound PSTN call arrives at the LGW on a SIP trunk from the PSTN carrier. The call should be routed to a Webex Calling user. The engineer reviews the LGW configuration and finds the following inbound dial-peer:

dial-peer voice 200 voip
   session protocol sipv2
   session target ipv4:203.0.113.10
   incoming called-number +1408555....
   voice-class codec 10
   voice-class stun-usage 10
   no supplementary-service sip refer

However, inbound PSTN calls fail with '404 Not Found' from Webex Calling. What is the MOST likely missing configuration element?

Accepted Answer

On a Webex Calling LGW, the inbound dial-peer from the PSTN carrier matches and terminates the inbound SIP leg. A separate outbound dial-peer is required to route the call to Webex Calling. This outbound dial-peer must have: 'session target dns:<webex-calling-sbc-fqdn>' or the Webex Calling IP, 'voice-class sip registration 10' (associating the dial-peer with the registered Webex trunk), and 'voice-class stun-usage 10'. Without a properly configured outbound dial-peer toward Webex, the LGW cannot determine where to send the call and returns 404 Not Found. The inbound dial-peer config shown is correct for the PSTN side; the missing piece is the Webex-facing outbound dial-peer.

Question 17

A Webex Calling administrator needs to configure a call queue in Control Hub so that incoming calls to +1-408-555-0100 are distributed to 10 agents using a round-robin distribution. Agents should not receive more than one simultaneous call. Which Control Hub feature provides this functionality?

Accepted Answer

Webex Calling Call Queue (configurable in Control Hub under Calling > Call Queues) supports multiple routing policies including Circular (round-robin), which assigns each new call to the next available agent in sequence, ensuring even distribution. The Call Queue is assigned the pilot DID (+1-408-555-0100), agents are added as queue members, and queue parameters (overflow, wait time, announcements) are configured. Hunt Groups also support Circular distribution but lack the queue/overflow/hold-in-queue capabilities of a Call Queue. Auto Attendant is for DTMF menu navigation. Webex Contact Center is a separate product required for advanced ACD features like skill-based routing and workforce management — not required for basic call distribution.

Question 18

A company has Webex Calling with Dedicated Instance. A Cisco IP phone at a branch registers to the Dedicated Instance CUCM via the internet. The branch has no CUBE LGW. The phone needs to make PSTN calls. Which PSTN connectivity option is compatible with Webex Calling Dedicated Instance for this branch?

Accepted Answer

Webex Calling Dedicated Instance supports multiple PSTN connectivity options without requiring an on-premises gateway: (1) Cisco Calling Plans — Cisco provides cloud PSTN SIP trunks directly into the Dedicated Instance tenant; (2) Cloud-Connected PSTN (CCP) — a certified third-party PSTN provider connects their SIP trunks to the Dedicated Instance via a cloud interconnect. Both options allow all registered phones (including physical Cisco IP phones) to make and receive PSTN calls through the cloud PSTN trunks. An LGW CUBE is only required when the customer wants to use their own local PSTN circuits (Premises-Based PSTN). MGCP gateways are a legacy technology; Dedicated Instance uses SIP trunks.

Question 19

A network engineer is implementing LLQ (Low Latency Queuing) for voice on a 10 Mbps WAN interface. Voice calls are estimated to consume a maximum of 2 Mbps. Which MQC policy-map configuration correctly applies strict-priority queuing for voice?

Accepted Answer

The IOS XE 'priority' command within an MQC policy-map class creates a Low Latency Queue (LLQ) — a strict-priority queue that is always serviced before all other queues. 'priority 2000' allocates a 2000 kbps (2 Mbps) guaranteed strict-priority bandwidth for voice. LLQ provides the low latency, low jitter, and low loss required for voice RTP. The 'bandwidth' command (option A) creates a Weighted Fair Queue (CBWFQ) class with guaranteed minimum bandwidth but NOT strict priority — it does not provide the same low-latency guarantee as LLQ. 'Shape average' applies traffic shaping. 'queue-limit' sets maximum queue depth, not priority treatment.

Question 20

A collaboration security engineer is auditing a CUCM 14.x cluster. The engineer runs 'show security token list' from the CUCM CLI and observes that the ITL (Initial Trust List) file has not been updated after a recent publisher hostname change. Cisco IP phones are showing 'ITL Error' on their screens and cannot re-register. What is the correct remediation?

Accepted Answer

When a CUCM Publisher's hostname or IP changes, the certificate embedded in the ITL file (signed by the old hostname) becomes invalid. Phones verify the ITL on every TFTP download and reject configurations signed by an untrusted certificate. The resolution is to run 'utils itl reset localkey' from the CUCM CLI (on the Publisher), which regenerates the ITL file using the current CallManager certificate. The updated ITL is placed on the TFTP server. Phones must be reset (power cycle or remote restart via CUCM) to download the new ITL — phones in ITL error state need to download a fresh ITL to clear the error. Disabling Mixed Mode removes security features and is not the appropriate resolution. Manual per-phone deletion is not scalable.

Question 21

A dial plan architect needs to implement Automated Alternate Routing (AAR) in CUCM. When a call is placed over a restricted WAN link (due to call admission control / CAC rejection), AAR should reroute the call via the PSTN. Which CUCM components work together to trigger AAR?

Accepted Answer

CUCM Automated Alternate Routing (AAR) works with Locations-based Call Admission Control. Each CUCM location has a configured bandwidth pool. When a new call is attempted that would exceed the location's available bandwidth, CUCM rejects the call with the 'insufficient bandwidth' cause. If AAR is enabled, CUCM immediately re-attempts the call using the AAR Calling Search Space (which includes access to PSTN route patterns) and prepends the AAR group's PSTN prefix (which transforms the destination DN into an E.164 PSTN number). This allows the call to reach the remote party via the PSTN instead of the congested WAN. AAR CSS and AAR Groups must be configured on both the device and line/DN level.

Question 22

A video collaboration engineer is evaluating H.264 versus H.265 (HEVC) for a Cisco video infrastructure upgrade. Which statement CORRECTLY describes the bandwidth advantage of H.265 over H.264?

Accepted Answer

H.265 (HEVC, High Efficiency Video Coding) provides approximately 40–50% better compression efficiency compared to H.264 (AVC) at the same visual quality level. This means a 1080p30 video stream that requires approximately 4 Mbps with H.264 can be delivered at approximately 2 Mbps with H.265 at equivalent perceptual quality. This is significant for Cisco video infrastructure (Webex, Cisco Room devices) as it reduces WAN bandwidth requirements for video calls. The trade-off is higher encoder computational complexity. H.265 benefits apply at all resolutions, not only above 4K.

Question 23

A CUCM administrator has configured a translation pattern +1408555.... (in partition NORMALIZE-PT) to strip the leading +1 and add a 9 prefix for outbound PSTN calls. A user's phone has CSS: [INTERNAL-PT, NORMALIZE-PT, PSTN-PT]. The user dials 4085551234. No route pattern matches 4085551234 in PSTN-PT. There IS a route pattern 9.1[2-9]XX[2-9]XXXXXX in PSTN-PT. What must the administrator configure so that calls to 4085551234 route correctly via the translation pattern to the PSTN?

Accepted Answer

In a globalized CUCM dial plan, the translation pattern is configured in E.164 format (+1408555....) and the phone's CSS must include the NORMALIZE-PT partition. However, if the user is dialing 10 digits (4085551234) without a + or country code, the translation pattern +1408555.... will not match because the leading +1 is missing from the dialed string. The resolution is to configure a 'Called Party Transformation CSS' or an 'Incoming Calling Party Settings' transformation on the device/device pool that prepends +1 to 10-digit numbers (via a normalization translation pattern). This transforms 4085551234 → +14085551234, which then matches the +1408555.... translation pattern, which in turn transforms it to 914085551234 for the PSTN route pattern 9.1[2-9]XX[2-9]XXXXXX. This is the standard globalized dial plan normalization approach.

Question 24

A CUBE IOS XE 17.x configuration shows the following under 'voice service voip':

voice service voip
   ip address trusted list
    ipv4 10.1.1.0 255.255.255.0
    ipv4 10.2.2.50 255.255.255.255
   allow-connections sip to sip
   no supplementary-service sip moved-temporarily
   sip
    session-refresh
    header-passing

An inbound SIP call arrives from 10.3.3.100 and CUBE drops it with 'call rejected (403)'. What is the reason?

Accepted Answer

Cisco CUBE's IP address trusted list (configured under 'voice service voip / ip address trusted list') is a security feature that explicitly whitelists IP addresses or subnets from which CUBE will accept SIP signaling. Any SIP INVITE or REGISTER arriving from an IP address not on the trusted list is rejected with a 403 Forbidden response. In this configuration, only 10.1.1.0/24 and 10.2.2.50/32 are trusted. The call from 10.3.3.100 is not in either trusted range, so CUBE rejects it. Resolution: add 'ipv4 10.3.3.100 255.255.255.255' to the trusted list, or add the appropriate subnet covering 10.3.3.x.

Question 25

An enterprise is deploying CUCM in Mixed Mode to enable SRTP. An administrator notices that after enabling Mixed Mode via the CTL client, some Cisco IP phones show 'Security Error' instead of the lock icon. The phones are downloading configurations from the TFTP server successfully. What is the MOST likely cause?

Accepted Answer

Simply enabling CUCM Mixed Mode (by installing the CTL file) enables the cluster to support security features, but each individual phone must also be assigned an appropriate Device Security Profile that enables security. The Device Security Profile controls whether the phone uses SIP TLS for signaling and SRTP for media. Profiles set to 'Non Secure SIP' or 'Non Secure SCCP' result in the phone operating in unsecured mode even in a Mixed Mode cluster. To enable SRTP and SIP TLS on a phone, the administrator must change its Device Security Profile in CUCM Administration to an 'Encrypted' or 'Authenticated' profile, then reset the phone to apply the new security configuration. The Security Error typically indicates the phone's security profile is mismatched or the ITL/CTL is not trusted.

350-801 CLCOR — Cisco Certified Internetwork Expert (CCIE) Collaboration