CLASSM Exam - Question 21

Question

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 coming from the provider with called number "222333444" and Cisco Unified Communications Manager is expecting the called number to be delivered as "444333222". The administrator already verified that the IP address of the Cisco Unified CM is set up correctly and there are no dial peers configured other than those shown in the exhibit. Which action must the administrator take to fix the issue?

Examice · Accepted Answer

To resolve the issue of the dial-peer not matching the incoming call pattern and thus not applying the translation rule, the administrator must set up the translation-profile to match the incoming traffic correctly by specifying it as an incoming translation profile. Currently, the translation-profile direction is set as 'outgoing' on the 'incoming' dial-peer, which does not properly translate the called number pattern for incoming calls. Adjusting this to ‘translation-profile incoming incoming’ aligns the translation direction with the incoming call scenario, ensuring proper number translation and subsequent call routing.

zeroblasted · Answer

Correct answer is C - 
The configuration is intentionally missing the incoming called-number. If you try to leave that blank on a router it will reject the command.
The dial peer group DOES NOT have to match the outgoing digits because it is associated.
And the translation rule was written correctly (minus the spaces). Verified on a 4331 -

voice translation-rule 999
 rule 1 /$^[1-2][1-2][1-2]$333$[4-5][4-5].$$/ /\2333\1/
#test voice translation-rule 999 222333444
Matched with rule 1
Original number: 222333444      Translated number: 444333222

jn4voip · Answer

The answer is A.  The destination pattern on the outgoing dial peer is 888, but the called number after the correct translation is 444333222. \2 takes the second group of 444 and adds 333, then \1 adds the first group of 222

FrankPic · Answer

In my opinion the best answer is B.
The incoming dial-peer is missing the "." parameter after the incoming called-number command. This is quite common to set up a match-any incoming dial-peer, both single digit o entire dial-string for en-block dialing like sip (https://community.cisco.com/t5/unified-communications-infrastructure/quot-incoming-called-number-quot-what-the-quot-dot-quot-stands/td-p/4435303)

Voice-translation rule 99 is correct but on the incoming dial-peer (voip dial-peer 999) you need to change the translation-profile direction to incoming, like following:
translation-profile incoming incoming

I also have some doubts about the outgoing dial (voip dial-peer 888) as destination-pattern 888 will never be matched by called number after voice translation-rule 99.

So also A, on a second step, can be right or anyway need to be applied.

Emil7 · Answer

Shouldn't this be D? Assuming " Cisco Unified Communications Manager is expecting the called number to be delivered as "444333222"." I don't see this happening in the configured Translation rule.

Marco74 · Answer

I think that correct is B

DoubleK · Answer

I think "B".

The translation rule is set for outbound but this is an inbound dial peer which only uses inbound translations. (The name of the translation rule is "inbound" but the name does not change the direction it is actually used in).

The incoming called-number command missing the dot is probably a typo. Even if you make it more specific and match 2223334444 the translation rule would not be applied because it is assigned the wrong direction.

This config uses Dial Peer Groups which ignores the outgoing destination pattern so changing 888 to 444333222 would do nothing.

Mert_kerna · Answer

I think we can all just assume there was a typo in the voice translation-rule, because it doesn't match correctly. However, there is not an answer that corresponds to the translation-rule being incorrect, or that would be the correct answer. The answer is B, because the translation-profile is being applied in the wrong direction. The name of the translation-profile is meant to trip you up in this question because it's "outgoing incoming" Outgoing is the name direction of the translation-profile and incoming is the name. It needs to be changed to become an incoming translation-profile. It's an incoming dial-peer as it doesn't have a session-target. So it needs to be translation-profile incoming incoming, where incoming represents the direction and name of the translation-profile

john_doe_9999 · Answer

This one is B. The translation works, but is being applied in the wrong direction on the incoming dial-peer.

b3532e4 · Answer

I think 2 have  problems:
1. voice translation-rule 999 ---> Original number: 222333444 Translated number:2333444
2. dial-peer voice 999 voip
    incoming called-number .  ( DOT)

basscov · Answer

Think here is a bunch of ssues.
Firstly, actual translation rule is setup incorrectly, this will not give you 444333222 in the output.
Secondly, translation profile is applied incorrectly ,in outbound direction.
And third, description says cucm is expecting called number 444333222 , but destination pattern 888 will not work for it, so it needs changed as well.
Should be a few answers here

7ArchAngel7 · Answer

It's obvious to anyone who has an intimate knowledge of CUBE/IOS Call Processing that information provided in the configuration output is either missing or omitted. It's sad but some assumptions have to be made here.  The incoming called-number is missing its matching parameter (IMO I assume this is unintentional as the command by itself is always rejected). I would also assume that the original question has the command as "incoming called-number 22233344.." or some type of extended matching, which would make B the Answer because the translation rule works as intended but it is obviously configured in the wrong direction and its name is made with the intention to confuse, which is a very Cisco-Like question. 
So you are left with a conundrum.... The answer is to either configure specific matching as there is no matching for the incoming called number 222333444 but either way you have to change the direction of the translation profile. I would assume the answer is B.

Afaik · Answer

There is so much wrong information, do we actually have a inbound dial-peer match here? translation is also not correct but doesn't work either assuming we hit the according dial-peer, basically reading the question it points towards CUCM and explaining detailed information what CUCM expect, D provides the best solution answer to that, ignoring this mess of configuration.

john_doe_9999 · Answer

This one is B. The translation works, but is being applied in the wrong direction on the incoming dial-peer.

Piji · Answer

The translation rule is correct and it translates 222333444 to 44433322.
The issue is "destination-pattern 888" which should be "destination-pattern 4443333222".
So the correct answer is the A.
Bear in your mind "incoming called-number" missing "." which that is the typo and should be "incoming called-number ."

decdca7 · Answer

None of the others are correct. The translation does not translate the number to 444333222

decdca7 · Answer

Sorry D is the correct answer, there others are wrong

729edae · Answer

rule 1 /|(^[1-2][1-2][1-2]\) 333\ ([4-5][4-5].\)$/ /\2333\1/
The translation pattern creates a Grouping so its right and it works:
rule 1 /| (^[1-2][1-2][1-2]\)  333 \  ([4-5][4-5].\)$ /       /\2333\1/
                         Group 1     then 333    Group 2                Group2, then 3333, then group So 2223334444 becomes 444333222
Regardless of the fact that the incoming called-number is missing, you will still have to change the direction of the aptly named translation-profile. Because you want to translate called 999 on calls incoming, not outgoing.

CLASSM Exam - Question 21

Discussion