Refer to the exhibit. Calls incoming from the provider are not working through newly set up Cisco Unified Border Element. Provider engineers get the 404 Not Found SIP message. Incoming calls are comin

Question

Exhibit

Options

• AChange the destination-pattern on the outgoing dial peer to match "444333222".
• BSet up translation-profile on the incoming dial peer to match incoming traffic.
• CCreate specific matching for "222333444" on the incoming dial peer.
• DFix the voice translation-rule to match specifically number "222333444" and change it to "444333222".

• A
  3% (1)
• B
  73% (22)
• C
  7% (2)
• D
  17% (5)

Explanation

Option B is correct because the called number must be transformed from "222333444" to "444333222" before CUBE forwards the call to CUCM - a voice translation-profile applied to the incoming dial peer with a translate called directive is exactly how CUBE intercepts and rewrites the called number at the point of ingress. Without this, CUCM receives an unrecognized number and returns 404.

A is wrong because changing the destination-pattern on the outgoing dial peer affects which calls match that peer, not the called number value that gets delivered to CUCM - the digit mismatch remains.

C is wrong because adding a specific match pattern on the incoming dial peer improves call selection/routing, but does nothing to translate the digits; CUCM still receives "222333444."

D is wrong because even a perfectly written voice translation-rule is completely inert until it is assigned to a voice translation-profile and that profile is applied to a dial peer - the rule alone cannot fire.

Memory tip: Think of it as a pipeline - translation-rule defines the substitution logic, translation-profile packages it, and the dial peer application (translation-profile incoming/outgoing) pulls the trigger. If any link is missing, no translation happens. The incoming dial peer is the right attachment point when the provider is sending the wrong format inbound.

No community discussion yet for this question.