VLAN and Inter-VLAN Routing Scenarios

Set the Route List's distribution algorithm to Broadcast and ensure the Route Group for Provider A is listed first.

Why it fails: The Broadcast distribution algorithm sends the call to all Route Groups simultaneously, which is used for features like simultaneous ring. It is not appropriate for routing to SIP trunks where you want a sequential failover. Broadcasting to two providers would cause the call to be sent to both, potentially resulting in multiple call legs and billing issues. This does not achieve the desired primary/secondary behavior.

Set the Route List's distribution algorithm to Circular and ensure the Route Group for Provider A is listed first.

Why it fails: The Circular distribution algorithm rotates through the Route Groups, starting with the first one and then moving to the next for subsequent calls. It does not provide a strict primary/secondary failover for a single call; instead, it load-balances across Route Groups. This would cause some calls to go to Provider B even when Provider A is available, which is not the desired behavior.

Set the Route List's distribution algorithm to Longest Idle and ensure the Route Group for Provider A is listed first.

Why it fails: The Longest Idle distribution algorithm is used for hunting to the member that has been idle the longest. It is typically used for line groups or hunt pilots, not for Route Lists to SIP trunks. Applying this algorithm to a Route List would not provide the simple primary/secondary failover; it would select the trunk based on idle time, which is not relevant here.

Neither dial peer is selected; the gateway rejects the call because two POTS peers cannot share the same voice port.

Why it fails: Multiple POTS dial peers can reference the same voice port; this is a common design for separating emergency and non-emergency traffic. The gateway does not reject the call. It performs normal dial-peer matching and will select the most specific peer, so the call proceeds using the appropriate outbound POTS peer.

Dial peer 20, because the gateway selects the peer with the lowest preference value configured under the dial peer.

Why it fails: Preference is used only as a tiebreaker when two dial peers have equally specific destination patterns. In this scenario, the patterns differ in specificity, so preference is not consulted. Dial peer 20 is not chosen simply because it might have a lower preference number; specificity is evaluated first.

Dial peer 20, because wildcard patterns always take precedence over literal patterns to allow flexible routing.

Why it fails: Wildcard patterns are less specific, not more. Cisco IOS dial-peer matching evaluates specificity, and a literal pattern such as 911 outranks the wildcard 9T. The gateway does not prefer T because it is a wildcard; it would only select dial peer 20 if no more specific match existed for the dialed digits.

Translation pattern that rewrites the called number to CUBE's IP address

Why it fails: A translation pattern is used to manipulate digits, not to route calls to a specific destination. You cannot rewrite a called number to an IP address. Routing to CUBE is done via a SIP trunk that has CUBE's address configured. Therefore, this option is technically invalid and does not achieve the goal.

H.323 gateway configured on CUCM with destination address of CUBE

Why it fails: An H.323 gateway is used for H.323 signaling, not SIP. If CUBE is deployed as a SIP border element, CUCM should use a SIP trunk to communicate with it. Configuring an H.323 gateway would result in protocol mismatch and calls would fail. Therefore, this is incorrect for a SIP trunk scenario.

Route group with CUBE as the only member

Why it fails: A route group is a list of gateways or trunks that can be used for routing. However, a route group alone does not point to CUBE; it must be associated with a route list and route pattern. While a route group containing the SIP trunk to CUBE is part of the configuration, the question asks for the element that points to CUBE as the next hop. The SIP trunk itself is the element that specifies the destination address.

The remote cluster is not configured with a route pattern for the local cluster, so the call is rejected.

Why it fails: The failure occurs on the local cluster before the call is sent to the remote cluster. The 'No Route to Destination' cause code is generated locally when no route pattern matches. The remote cluster's configuration is irrelevant if the call never reaches it due to local digit analysis failure.

The SIP trunk is not configured with a calling search space that includes the partition of the route pattern.

Why it fails: The calling search space on the SIP trunk affects the trunk's ability to place calls, but the route pattern is used by the originating device's CSS. The device's CSS must include the partition of the route pattern. The trunk's CSS is used for inbound calls or when the trunk initiates a call, not for outbound calls from a phone.

The SIP trunk is not registered to the remote cluster, so the call cannot be routed.

Why it fails: SIP trunks in Cisco Unified CM do not register to remote clusters; they are statically configured with a destination address. Registration is not required for SIP trunk operation. The failure is more likely due to dial plan mismatch, not registration.

Enterprise Parameters

Why it fails: Enterprise Parameters configure cluster-wide defaults such as URLs and phone settings, not per-trunk SIP signalling encryption. It is tempting because they govern broad CUCM behaviour, but TLS for SIP signalling is enabled on the SIP trunk's security profile and associated trunk settings, not here.

Device Pool

Why it fails: Device Pools group phones and gateways for region, location, and date/time settings, not SIP trunk encryption. It is tempting because Device Pools carry many device-level defaults, but signalling encryption depends on the SIP trunk security profile and the trunk's TLS security mode.

SIP Profile

Why it fails: A SIP Profile controls timers, headers, and transport preferences for SIP messages, but does not itself enable signalling encryption. It is tempting because it directly governs SIP behaviour, yet TLS encryption for the trunk is configured via the SIP trunk security profile and the trunk's security mode.

SIP Trunk Security Profile

Why it fails: The SIP Trunk Security Profile governs transport, authentication, and TLS/cipher settings for the trunk, not offer/answer negotiation. Early Offer is configured on the SIP profile itself. This security profile would be the right location when the requirement concerns digest authentication, incoming port, or transport security.

Device Pool

Why it fails: A device pool groups phones for region, date/time, and softkey template assignment; it carries no SIP signalling negotiation parameters. Early Offer is set on the SIP profile attached to the trunk. Device pools would be correct when assigning firmware load, region, or location settings to endpoints.

Route List

Why it fails: A route list defines call routing and path selection between route groups and trunks; it holds no SIP offer/answer negotiation setting. Early Offer is configured on the SIP profile, which the trunk references. Route lists would be the right place when the requirement concerns digit manipulation or path selection.

Use the default VLAN 1 for all voice and data.

Why it fails: VLAN 1 carries control-plane traffic and is untagged by default, so mixing voice and data there exposes calls to broadcast storms and QoS contention. It is tempting as a zero-configuration default, but best practice is a dedicated voice VLAN with data on a separate access VLAN.

Use a separate physical switch for phones.

Why it fails: Dedicating separate physical switches duplicates hardware and cabling without providing the logical traffic separation that voice QoS and security require. It is tempting when isolation is the goal, but a voice VLAN on the same switch achieves that separation at far lower cost.

Do not use VLANs; use static routing.

Why it fails: Static routing does not segment broadcast domains, so voice and data traffic still share one flat network with no QoS boundary. It is tempting when VLAN configuration is considered troublesome, but VLANs are the mechanism that separates voice from data traffic.

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.

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.

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.

The SIP trunk's Inbound Calls > Significant Digits setting.

Why it fails: Significant Digits affects how many digits are sent to the called party, not media negotiation. A 488 error is related to SDP and codec offer/answer, not digit manipulation. While significant digits can cause call failures, they typically result in 404 or 503 errors, not 488 Not Acceptable Here.

The route group's distribution algorithm.

Why it fails: The route group distribution algorithm determines which gateway or trunk is selected from a route list. It does not influence codec negotiation or media capabilities. Since the call reaches CUBE and is rejected with 488, the issue is not with route group selection but with the media parameters offered by CUCM.

The SIP trunk's Outbound Calls > Calling Party Selection setting.

Why it fails: Calling Party Selection controls the calling number presented to the PSTN, which typically affects caller ID, not media negotiation. A 488 Not Acceptable Here indicates a media or SDP issue, not a calling party problem. Changing Calling Party Selection would not resolve the codec mismatch or media negotiation failure that causes a 488.

Modify the SIP Profile assigned to the trunk to enable 'Use Fully Qualified E.164 Number'.

Why it fails: The 'Use Fully Qualified E.164 Number' option in a SIP Profile affects how the calling number is presented in the From header, but it does not add a country code. It typically uses the number as configured, and if the number is already in 10-digit format, it will remain so. This option does not perform digit manipulation; it only changes formatting for certain headers, and is not a substitute for a transformation pattern.

Create a Translation Pattern that matches the 10-digit number and adds the +1 prefix, then apply it to the trunk's inbound CSS.

Why it fails: A Translation Pattern could add the +1, but it would affect the called number or calling number during digit analysis, not necessarily the From header on outbound SIP messages. Translation patterns are typically used for inbound call routing and digit manipulation within the dial plan. For outbound SIP header manipulation, transformation patterns on the trunk are the correct tool. Using a translation pattern here would not reliably rewrite the From header.

Create a SIP Normalization Script that adds the +1 to the From header on the SIP trunk.

Why it fails: SIP Normalization Scripts are intended for interoperability fixes, such as modifying headers for specific vendor quirks. While a script could rewrite the From header, it is a complex and less maintainable solution for a standard digit manipulation requirement. CUCM provides native transformation patterns that can manipulate the calling number before it is placed into the From header, making scripts unnecessary for this purpose.

A Route Pattern for 911 with the 'Route This Pattern' option and a 'Calling Search Space' that includes the PSAP partition

Why it fails: The calling search space on a route pattern is used to determine what numbers the route pattern itself can dial for functions like forwarding or translation. It does not control which devices can use the route pattern. To control device access, the device's CSS must include the partition of the route pattern. This option misconfigures the CSS on the route pattern, which is not the correct place.

A dedicated Route Pattern for 911 that points to a Route List containing only the PSAP gateway SIP trunk

Why it fails: A dedicated route pattern for 911 pointing to a route list with only the PSAP trunk is a valid approach, but it does not guarantee that all devices will use it unless the pattern is in a partition included in every device's calling search space. This requires additional configuration to ensure universal access, and it may not override other route patterns if the CSS is not properly set.

A Transformation Pattern that modifies the dialed number to a unique prefix and routes based on that prefix

Why it fails: Transformation patterns are used to manipulate calling or called numbers, not to enforce routing to a specific trunk. While you could transform 911 to a unique number and then route that, it adds complexity and does not inherently guarantee routing to the PSAP trunk unless the transformed number is matched by a route pattern pointing to that trunk. This is an indirect method and not the primary recommended approach.

H.323

Why it fails: H.323 is a peer-to-peer ITU conferencing suite that Cisco gateways support for legacy call control, not for Webex Calling cloud trunks. It is tempting because CUBE historically interworked H.323 endpoints, but Webex Calling's Local Gateway interface is SIP-based, so H.323 cannot register or carry the trunk.

SCCP

Why it fails: SCCP is a Cisco proprietary signalling protocol for endpoints controlled by CUCM, carrying no SIP trunking capability. It is tempting because SCCP appears in Cisco voice deployments alongside gateways, but the CUBE-to-Webex Calling cloud trunk requires SIP, since Webex Calling registers and routes via SIP signalling only.

MGCP

Why it fails: MGCP is a controller-slave protocol where a call agent directs gateway endpoints; it does not establish gateway-to-cloud SIP trunks. It is tempting because MGCP appears in Cisco gateway configurations for analog and PRI endpoints, but Webex Calling's Local Gateway requires SIP signalling between CUBE and the cloud.

Create a Translation Pattern in the Calling Search Space applied to the SIP trunk's incoming calls.

Why it fails: A Translation Pattern is used for digit manipulation on dialed digits within a partition, but for incoming calls from a SIP trunk the recommended and more granular approach is to apply a Transformation Pattern directly to the trunk's inbound calling and called number settings. A Translation Pattern can work but is less precise because it requires a partition and CSS relationship and doesn't natively distinguish calling vs. called number presentation on the trunk.

Modify the Route Group's distribution algorithm to remove the prefix during digit analysis.

Why it fails: Route Groups control the order in which gateways or trunks are selected for outbound calls; they do not perform digit manipulation. The distribution algorithm only determines which member is tried first, and there is no digit-stripping capability within a Route Group. Using Route Groups for prefix removal would not affect inbound calls and would not achieve the required translation.

Create a SIP Normalization Script that rewrites the SIP INVITE headers on the trunk.

Why it fails: SIP Normalization Scripts are used to modify SIP messages at the protocol level for interoperability, not for routine dial-plan digit manipulation. While a script could technically alter headers, it is an overcomplicated and unsupported method for stripping a country code from calling and called numbers. The intended tool for number translation on a trunk is the transformation pattern.

Create a Route Filter

Why it fails: Route filters strip or manipulate specific dialled digits on a SIP trunk and are optional for basic trunk setup; the required tasks are creating the trunk, route group and route list. It is tempting because route filters are genuinely needed when the provider requires digit manipulation.

Create a Translation Pattern

Why it fails: A translation pattern rewrites dialled digits for call routing and numbering plans; a basic SIP trunk needs device pool, route group, route list and trunk configuration instead. It is tempting because translation patterns are genuinely required when overlapping dial plans or dial-plan manipulation must be resolved.

sip-header insert

Why it fails: The command sip-header insert is not a valid Cisco IOS XE command. SIP header manipulation is achieved through voice class sip-profiles, where you define rules using the header command. This option would result in a syntax error and would not add the required header, so it is incorrect.

header-manipulation

Why it fails: The command header-manipulation does not exist in Cisco IOS XE. While header manipulation is possible, it is done via SIP profiles (voice class sip-profiles). This option is invalid and would not achieve the desired outcome, making it an incorrect choice for this scenario.

sip-header profile

Why it fails: The command sip-header profile is not a valid configuration in Cisco IOS XE for header manipulation. While SIP profiles exist, they are configured using voice class sip-profiles, not sip-header profile. This option is invalid and would not insert the custom header, making it incorrect.