Help with translation pattern

[gavinr98]

Hope someone can help. We are testing out a new Cloud PBX and have ported some of our DID's that we had to this new service and need some help with a translation pattern when the 4 digit DN is called. For example, the number that was ported out was (555)555-1234. If we call the full number, it will ring fine on the new PBX, however when we try and call the 4 digit ext (1234) it will still ring to the internal DN and not the10 digit number (I have also tried to add the number as a forwarding number, but that will ring busy). I just need some help in getting it to work when someone calls the 4 digit DN to send the full 10 digits so the call goes to the correct place.

[garry.engle]

You have a the 4-digit DN 1234 as a translation pattern into (555)555-1234? If there's a translation pattern for it, I don't believe there can be a DN for the same 1234. It's either or.

[Les Pruden]

Garry is correct. Extension 1234 cannot exist on both PBX's. You have to choose which PBX will have call control of that number. 

From the PSTN you are likely translating the 10 digit DID to a 4 digit extension with a translation pattern. So, if you create a route pattern for the 10 digit number that sends it over to the new PBX that will work - only one number exists in your PBX. For the 4 digit number you will have to remove it from the telephone and set up a 4 digit translation or route pattern that gets you to the new PBX.

[Roger Kallberg]

You can have the extension in both places if you put the translation pattern in a partition that is ordered higher than the partition where the directory number is in. With you should be able to call to the 4-digit number and it should match the translation pattern as it is a better match per the call routing logic as the order of partitions act as the tie breaker when there is an equal match. It should then translate into the 10 digit number, just make sure that the egress CSS on the translation pattern has visibility of the route pattern that sends the call to the cloud PBX. From the directory number it will be possible to make outbound calls, but not to receive any calls.

[Les Pruden]

Agreed - 

What I was getting at was that you cannot call 1234 and have both phones (CUCM and Cloud PBX) ring at the same time. If this is for testing then a better approach would be to pick an unused DID and set that up for both PSTN and internal calls. If the user is moving to a cloud PBX phone then their internal phone should get a new number or the DN should be put in a partition that users CSS cannot see.

I don't understand why you would leave 1234 on Cisco and also build it in the cloud.

[gavinr98]

I don't want it to ring in both places, only on the cloud PBX. I have no problem deleting the DN, as long as when someone calls 1234, it goes to (555)555-1234 and not the DN 1234.

[Roger Kallberg · Accepted solution]

You need to have this in place for what you ask about to work.

• A translation pattern that matches before your directory numbers.
• This TP need to translate from the short 4-digit number to the 10-digit number.
• The egress CSS on the TP needs to include the partition where the route pattern that sends 10-digit number to the cloud PBX.
• A RP that match the 10-digit number and sends it to a route list that contains the route group that has the gateway or trunk to the cloud PBX.
• If there is a SBC that connects to the cloud PBX you need to have a dial peer that matches the 10-digit number and sends it to the cloud PBX.

[gavinr98]

This is what I believe I need help with...

• This TP need to translate from the short 4-digit number to the 10-digit number.

[Roger Kallberg]

Create a Translation Pattern that matches 1234 and then under called number transformation set prefix to 555555, this will result in the called number being 5555551234 after it has passed through the TP. Lastly set the outbound CSS on the TP to something that has the partition where the route pattern for sending calls to the cloud PBX is placed in the list of included partitions.

[gavinr98]

Thank you very much, this worked!!

[Roger Kallberg]

Glad to hear that!

[Roger Kallberg]

Not saying that it would be best practice to keep the extension in both places, just that it is a technical possibility. It would even be possible to have it ring on both locations simultaneously if Mobile Connect functionality is used, or Single Number Reach (SNR) as it might be better known as. We used that methodology when we evaluated Microsoft Teams calling in parallel with our in place CM system landscape.