Exam 300-815 topic 1 question 21 discussion

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

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.

Sorry D is the correct answer, there others are wrong

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

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 ."

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)

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.

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

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

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.

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.

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

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

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.

I think that correct is B

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

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.