11-09-2022 06:12 AM
Afternoon all. I'm scaling up a migration from CUCM 12.5 to MS Teams Voice and want to route internal calls placed on the CUCM to existing DNs out via a CUBE to our ITSP (Gamma in the UK). At present I can manually call forward a line to its subscriber number with a 9 prefix, once it hits our ITSP it's then routed to Azure and a Teams client. So, for example, my DN, 635635 is forwarded to 901509635635. This works well, but must be done manually for each migrated user and will complicate matters as we scale up the roll out.
What I'd like to be able to do is simply move the DNs of migrated CUCM users to a new partition and apply a transformation or translation to calls to any numbers in that partition, prefixing the called number with the access code and area code (901509 in our case), which will then re-route using our existing route patterns via the CUBEs.
However, I've not been able to get this to work with a transformation or translation pattern. Does anyone know how I might achieve this?
Solved! Go to Solution.
11-09-2022 06:51 AM
First, move the DNs of the migrated users to a restricted PT that is not assigned to any CSS.
Next, create a translation pattern as below.
Pattern= XXXXXX
Partition= Internal_PT (Or you can use any partition that is reachable by all the intended phones)
Prefix Digits (Outgoing Calls) = 901509
Calling Search Space= Any CSS that can reach your Route Pattern which routes 901509XXXXXX calls to the CUBE.
Now, when a users dials an extension that has been migrated, the call won't match the phone extension because it is in a restricted partition, instead it will match the xlation pattern which prefixes the dialed number with 901509.
11-09-2022 06:51 AM
First, move the DNs of the migrated users to a restricted PT that is not assigned to any CSS.
Next, create a translation pattern as below.
Pattern= XXXXXX
Partition= Internal_PT (Or you can use any partition that is reachable by all the intended phones)
Prefix Digits (Outgoing Calls) = 901509
Calling Search Space= Any CSS that can reach your Route Pattern which routes 901509XXXXXX calls to the CUBE.
Now, when a users dials an extension that has been migrated, the call won't match the phone extension because it is in a restricted partition, instead it will match the xlation pattern which prefixes the dialed number with 901509.
11-09-2022 08:13 AM
Brilliant, thank you so much for the simple and well explained solution!
This will, of course, apply the translation to *any* six digit dial string that doesn't match a DN in an accessible partition. I have a regex for our DDI ranges, though, so I may finesse it (possibly on the CUBEs) to only forward calls to our ITSP that match numbers in those ranges.
11-09-2022 09:25 AM - edited 11-09-2022 09:27 AM
This absolutely needed more tweaking:
as the translation pattern was marked as urgent priority, it was matching any outbound call as the caller dialled it, so once they'd dialled 901509 (six digits, and not an internal DN in a routable PT), it was prefixing it with another 901509 and sending that to the CUBEs; no outbound dialling! This was, of course, only affecting SCCP handsets that pulse dial, not SIP clients that send the whole dialstring.
The quick fix was to clear the Urgent Priority tickbox on the translation pattern, but this introduced a delay (waiting for the interdigit timeout) in connecting calls. The better solution was to make the translation pattern a little more specific, I could've just prefixed it with ^[9] to not match against external calls, but instead I made the first digit more specific to our DDI ranges (which are large and varied, so can't be accurately represented easily in a simple CUCM wildcard pattern), [256]XXXXX matches six digit numbers starting a 2, 5 or 6.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide