Scenario practice questions

Which THREE actions are possible using SIP profiles on a CUBE?

Trap 1: Change voice codec

Codec selection is negotiated in the SDP body and controlled by dial peers and voice-class codec configuration, not SIP profiles. SIP profiles suit header manipulation, such as adding or stripping custom headers, not media attribute changes.

Trap 2: Route calls to PSTN

PSTN routing is determined by dial-peer destination patterns and translation rules, not SIP profiles. SIP profiles manipulate SIP signalling headers; they would be the correct tool for normalising or inserting headers between dissimilar SIP trunks.

A
Modify SIP headers
Used for header normalization.
B
Add SIP headers
Used to insert specific parameters.
C
Remove SIP headers
SIP profiles on CUBE allow header manipulation through rules that strip unwanted SIP headers before forwarding messages. This satisfies the requirement to remove SIP headers, since profiles can match specific headers and delete them, unlike dial peers which handle call routing rather than header editing.
D
Change voice codec
Why it fails: Codec selection is negotiated in the SDP body and controlled by dial peers and voice-class codec configuration, not SIP profiles. SIP profiles suit header manipulation, such as adding or stripping custom headers, not media attribute changes.
E
Route calls to PSTN
Why it fails: PSTN routing is determined by dial-peer destination patterns and translation rules, not SIP profiles. SIP profiles manipulate SIP signalling headers; they would be the correct tool for normalising or inserting headers between dissimilar SIP trunks.

Question 2mediummultiple choice

Which deployment model should be chosen for Cloud Connected PSTN (CCP) if the organization wants to leverage their existing carrier contracts?

Trap 1: Local Gateway PSTN

Local Gateway PSTN terminates calls through an on-premises gateway, requiring the organisation to manage its own gateway infrastructure rather than reusing existing carrier contracts through CCP. It is correct where premises-based PSTN termination and gateway control are required, not for carrier contract reuse.

Trap 2: Webex Calling PSTN via Cisco

PSTN via Cisco means Cisco supplies the PSTN connectivity and numbers, so the organisation's existing carrier contracts are bypassed entirely. It is the right model when an organisation wants Cisco to handle PSTN provisioning and billing, not when existing carrier agreements must be leveraged.

Trap 3: Webex Calling Dedicated Instance

Dedicated Instance delivers Webex Calling from a dedicated, non-shared environment, but PSTN connectivity still terminates through Cisco-provided CCP or a local gateway, so existing carrier contracts cannot be retained. It suits organisations needing dedicated infrastructure and data isolation, not carrier contract reuse.

A
Local Gateway PSTN
Why it fails: Local Gateway PSTN terminates calls through an on-premises gateway, requiring the organisation to manage its own gateway infrastructure rather than reusing existing carrier contracts through CCP. It is correct where premises-based PSTN termination and gateway control are required, not for carrier contract reuse.
B
Webex Calling PSTN via Cisco
Why it fails: PSTN via Cisco means Cisco supplies the PSTN connectivity and numbers, so the organisation's existing carrier contracts are bypassed entirely. It is the right model when an organisation wants Cisco to handle PSTN provisioning and billing, not when existing carrier agreements must be leveraged.
C
Cloud Connected PSTN (CCP)
Cloud Connected PSTN (CCP) lets an organisation pair Webex Calling with its existing PSTN carrier contracts and numbers, rather than mandating a Cisco-provided calling plan. This directly satisfies the requirement to leverage current carrier agreements.
D
Webex Calling Dedicated Instance
Why it fails: Dedicated Instance delivers Webex Calling from a dedicated, non-shared environment, but PSTN connectivity still terminates through Cisco-provided CCP or a local gateway, so existing carrier contracts cannot be retained. It suits organisations needing dedicated infrastructure and data isolation, not carrier contract reuse.

Question 3mediummultiple choice

You are troubleshooting a scenario where G.711 is being used instead of the expected Opus codec between two endpoints in the same region. What is the most likely cause in the CUCM configuration?

Trap 1: Phone NTP settings

NTP settings only synchronise phone clocks and have no bearing on codec negotiation, so they cannot force G.711. It is tempting because clock or timezone mismatches cause odd endpoint behaviour, and NTP would be the right area for registration or certificate time failures.

Trap 2: SIP Trunk Security Profile mismatch

SIP trunk security profiles govern TLS, digest authentication and encryption on trunk connections, not the codec chosen for an intra-region call between endpoints. It is tempting because trunk misconfigurations do break calls, and it would be correct when a SIP trunk fails to establish or authenticate.

Trap 3: Location-based bandwidth limit

Location bandwidth limits cause call admission control to deny or downgrade calls when the location's allocated bandwidth is exhausted; they do not silently substitute G.711 for Opus. It is tempting because locations influence codec selection, and it would be correct when calls are rejected across a constrained WAN link.

A
Audio Codec Preference List
The Audio Codec Preference List defines the ordered codecs an endpoint offers during negotiation. If G.711 ranks above Opus on that list, the endpoints select G.711 despite Opus being available, directly explaining the unexpected codec in the same region.
B
Phone NTP settings
Why it fails: NTP settings only synchronise phone clocks and have no bearing on codec negotiation, so they cannot force G.711. It is tempting because clock or timezone mismatches cause odd endpoint behaviour, and NTP would be the right area for registration or certificate time failures.
C
SIP Trunk Security Profile mismatch
Why it fails: SIP trunk security profiles govern TLS, digest authentication and encryption on trunk connections, not the codec chosen for an intra-region call between endpoints. It is tempting because trunk misconfigurations do break calls, and it would be correct when a SIP trunk fails to establish or authenticate.
D
Location-based bandwidth limit
Why it fails: Location bandwidth limits cause call admission control to deny or downgrade calls when the location's allocated bandwidth is exhausted; they do not silently substitute G.711 for Opus. It is tempting because locations influence codec selection, and it would be correct when calls are rejected across a constrained WAN link.

Question 4mediummultiple choice

You are troubleshooting a scenario where internal calls between two sites are failing. The call fails immediately when dialed. What is the most effective way to verify that the Calling Search Space (CSS) has access to the destination partition?

Trap 1: Check the 'Route Filter' list.

Route filters control which directory numbers or patterns a route pattern or translation permits; they do not reveal whether a CSS contains the destination partition. Checking the CSS partition membership directly is required. Route filters are tempting because they also restrict dialled-number reachability, and they would be correct when calls fail due to blocked number patterns.

Trap 2: Use the 'Route Pattern' report in Cisco Unified Reporting.

The Route Pattern report lists patterns and their partitions, not which CSSs contain those partitions, so it cannot confirm CSS-to-partition reachability. It is tempting because it inventories route patterns, and would suit auditing dial-plan pattern usage rather than tracing a specific CSS's partition membership.

Trap 3: Reset the SIP trunk.

Resetting the SIP trunk drops and re-establishes signalling without revealing CSS partition membership, so it cannot confirm why the call is rejected. It is tempting as a generic fix for trunk faults, and would be right when a SIP trunk is stuck or unregistered rather than when a CSS lacks partition access.

A
Check the 'Route Filter' list.
Why it fails: Route filters control which directory numbers or patterns a route pattern or translation permits; they do not reveal whether a CSS contains the destination partition. Checking the CSS partition membership directly is required. Route filters are tempting because they also restrict dialled-number reachability, and they would be correct when calls fail due to blocked number patterns.
B
Use the 'Route Pattern' report in Cisco Unified Reporting.
Why it fails: The Route Pattern report lists patterns and their partitions, not which CSSs contain those partitions, so it cannot confirm CSS-to-partition reachability. It is tempting because it inventories route patterns, and would suit auditing dial-plan pattern usage rather than tracing a specific CSS's partition membership.
C
Reset the SIP trunk.
Why it fails: Resetting the SIP trunk drops and re-establishes signalling without revealing CSS partition membership, so it cannot confirm why the call is rejected. It is tempting as a generic fix for trunk faults, and would be right when a SIP trunk is stuck or unregistered rather than when a CSS lacks partition access.
D
Use the Dialed Number Analyzer (DNA) tool.
Dialed Number Analyzer simulates the call routing path using the actual dial plan, showing precisely which partitions the CSS can reach and where the immediate failure occurs. It isolates CSS-to-partition mismatches faster than reading configuration or capturing traces.

Question 5mediummultiple choice

You are troubleshooting a scenario where internal calls between two offices are using the G.711 codec, but you want them to use G.729 to save bandwidth. Where should you change the codec setting?

Trap 1: Device > Device Settings > Common Device Configuration

Common Device Configuration holds device-level settings such as softkey templates and phone button templates, not region-pair codec policy. It would be the right place to apply a shared configuration profile across many phones of the same model.

Trap 2: System > Device Pool

A device pool groups phones for CallManager assignment, date/time and region settings, but codec selection between two sites is governed by the region pair, not the pool. Device pools suit bulk phone provisioning and firmware or cluster assignment.

Trap 3: System > Location

Locations define bandwidth and call admission control between sites, not which codec is negotiated; codec policy lives in regions and their pairwise links. Locations would be correct when limiting the number of calls across a constrained WAN link.

A
Device > Device Settings > Common Device Configuration
Why it fails: Common Device Configuration holds device-level settings such as softkey templates and phone button templates, not region-pair codec policy. It would be the right place to apply a shared configuration profile across many phones of the same model.
B
System > Region Information > Region
System > Region Information > Region sets the codec for calls within a region, which matches the inter-office internal call constraint. Regions define bandwidth management and codec policy per site, so assigning both offices to one region and selecting G.729 there forces internal calls to negotiate G.729 instead of G.711.
C
System > Device Pool
Why it fails: A device pool groups phones for CallManager assignment, date/time and region settings, but codec selection between two sites is governed by the region pair, not the pool. Device pools suit bulk phone provisioning and firmware or cluster assignment.
D
System > Location
Why it fails: Locations define bandwidth and call admission control between sites, not which codec is negotiated; codec policy lives in regions and their pairwise links. Locations would be correct when limiting the number of calls across a constrained WAN link.

Open the full VLAN trunking answer →

Question 6mediummultiple choice

What is the primary function of the CUBE in a SIP trunking scenario?

Trap 1: Call routing for internal phones

CUBE sits at the network edge between the enterprise and the SIP provider; internal phone call routing is handled by Cisco Unified Communications Manager's dial plan. CUBE would be correct where the requirement is normalising SIP signalling and media at the trunk boundary.

Trap 2: Voice messaging storage

CUBE terminates and interconnects SIP trunks; it holds no message store, so voicemail cannot reside there. Voice messaging storage belongs to Cisco Unity Connection, which would be the right answer if the question asked where recorded greetings and messages persist.

Trap 3: DHCP Server functionality

CUBE provides session border control, protocol interworking and call admission between SIP trunks and Cisco Unified Communications Manager. DHCP address assignment is a separate network service; CUBE handles signalling and media traversal, not IP lease allocation.

A
Call routing for internal phones
Why it fails: CUBE sits at the network edge between the enterprise and the SIP provider; internal phone call routing is handled by Cisco Unified Communications Manager's dial plan. CUBE would be correct where the requirement is normalising SIP signalling and media at the trunk boundary.
B
Demarcation and SIP normalization
CUBE sits at the network demarcation point, terminating the SIP trunk from the provider and normalising SIP signalling and media between disparate implementations. This satisfies the stem's requirement for the primary function: interworking vendor-specific SIP dialects, headers and codecs so the enterprise call control platform interoperates cleanly with the carrier.
C
Voice messaging storage
Why it fails: CUBE terminates and interconnects SIP trunks; it holds no message store, so voicemail cannot reside there. Voice messaging storage belongs to Cisco Unity Connection, which would be the right answer if the question asked where recorded greetings and messages persist.
D
DHCP Server functionality
Why it fails: CUBE provides session border control, protocol interworking and call admission between SIP trunks and Cisco Unified Communications Manager. DHCP address assignment is a separate network service; CUBE handles signalling and media traversal, not IP lease allocation.

Question 7hardmultiple choice

A Cisco Unified Border Element is deployed between Cisco Unified Communications Manager and a SIP provider. The provider requires that the gateway insert a Diversion header containing the original called number when a call is forwarded. The engineer plans to use a SIP profile to accomplish this. Which statement accurately describes the capability of SIP profiles in this scenario?

Trap 1: SIP profiles can insert a Diversion header by using the request URI…

Applying a SIP profile globally does not change its fundamental capabilities. SIP profiles cannot extract the original called number from the request URI and place it into a Diversion header. Global application only affects where the profile is applied, not what header manipulations it can perform. The Diversion header generation still requires other mechanisms.

Trap 2: SIP profiles can copy the original called number into a Diversion…

SIP profiles can manipulate headers with copy rules, but they cannot directly insert a Diversion header containing the original called number from the Request-URI. Diversion header insertion for forwarded calls typically requires other mechanisms such as SIP normalization scripts or CUBE's built-in diversion features. A copy rule alone would not create the required Diversion header in the forwarded INVITE.

Trap 3: SIP profiles can insert a Diversion header only if the dial peer is…

There is no 'diversion' command under voice-class sip that enables SIP profiles to insert a Diversion header. SIP profiles operate on generic header manipulation rules, not on call-forwarding semantics. The presence of a voice-class sip configuration does not grant the profile the ability to generate a Diversion header with the original called number.

A
SIP profiles can insert a Diversion header by using the request URI of the original call, provided the profile is applied globally with the sip-profiles command.
Why it fails: Applying a SIP profile globally does not change its fundamental capabilities. SIP profiles cannot extract the original called number from the request URI and place it into a Diversion header. Global application only affects where the profile is applied, not what header manipulations it can perform. The Diversion header generation still requires other mechanisms.
B
SIP profiles can copy the original called number into a Diversion header by using a copy rule that references the incoming Request-URI.
Why it fails: SIP profiles can manipulate headers with copy rules, but they cannot directly insert a Diversion header containing the original called number from the Request-URI. Diversion header insertion for forwarded calls typically requires other mechanisms such as SIP normalization scripts or CUBE's built-in diversion features. A copy rule alone would not create the required Diversion header in the forwarded INVITE.
C
SIP profiles can insert a Diversion header only if the dial peer is configured with the diversion command under voice-class sip.
Why it fails: There is no 'diversion' command under voice-class sip that enables SIP profiles to insert a Diversion header. SIP profiles operate on generic header manipulation rules, not on call-forwarding semantics. The presence of a voice-class sip configuration does not grant the profile the ability to generate a Diversion header with the original called number.
D
SIP profiles can modify existing SIP headers and add or remove headers, but they cannot by themselves generate a Diversion header with the original called number for a forwarded call.
SIP profiles provide header manipulation: adding, removing, or modifying headers on inbound and outbound messages. They do not automatically derive the original called number and place it into a Diversion header for forwarded calls. That task generally requires additional logic such as a normalization script or specific CUBE features designed for diversion handling.