We were doing the opposite. (Migrating away from our old PBX) But, we did want the same behavior. Also, we have 4 digit extensions with the first digit being 1 through 7.
So, our "Sys-Ext-PT" partition (usual internal DN partition) has a route pattern [1-7]XXX that sends to the CUBEs. And the CUBE has dial-plan setup mapping the 4-digit inbound to the old PBX. When a user is provisioned though, the DN is in "Sys-Holding-PT". This partition can dial out, but this DN does not match when other users try to dial it because it is not a part of any CSS. Then, every night, we had a script that moved everybody from this partition into the Sys-Ext-PT therefore cutting them over to the CUCM system. Maybe you just need a more specific pattern than "!"? Once you get that working, my recommendation would be to move users into a holding partition once it's time to cut them over into the new system. Therefore making their DN no longer match a user-to-user dial and hit your catch-all route pattern. But the set would still be able to dial out because the holding partition would have an outbound CSS that allowed that. -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Mon, Apr 4, 2022 at 10:25 AM Gary Parker <[email protected]> wrote: > > Hi folks, I’m in the process of planning a migration to MS Teams for voice. > Don’t hate me! The discussions have been long and the decision is made, I’m > just trying to lessen the pain now :-D > > We’re running CUCM 12.5 on-prem with a pair of CUBEs with SIP trunks to our > TSP, Gamma, for external calling. Our Direct Routing SBCs into Teams are > cloud hosted by Gamma, so calls between CUCM and Teams won’t cost me > anything, even though both consider them external calls. > > I’m trying to figure out the simplest way possible, that will eventually > scale to hopefully hundreds of users a day, to reroute calls made from a CUCM > endpoint, to a DN that /was/ on CUCM, to Gamma instead and then to MS via DR > as we migrate users from one system to the other. This is assuming I’ve > already had Gamma move the subscriber number from our SIP service to Direct > Routing, so all inbound PSTN calls hit Teams rather than CUCM. > > The simplest way, that I’ve already had working, is just to put a CFwdAll on > the line in question, say 635000 to 9015096350000. 9 is our outside line > prefix, and 01509 is the area code. That sends it out via the CUBE to Gamma, > they recognise it as a number on my Direct Routing endpoint and send it to > MS. The CUCM endpoint can still make internal and external calls, but any > internal calls to it from another CUCM endpoint are sent to Teams instead. > > What I’ve been trying to figure out is something along the lines of moving > the line into a different partition that’s not in a CSS available to other > users not migrated to Teams yet. The endpoint will still be able to make > calls but not receive them. This bit works okay. > > I then tried creating a partition at the bottom of the “internal” calling > search space so that six digit calls that don’t match anything else fall into > it, get a translation pattern applied to prefix the six digits with 901509, > and the partition has a CSS that allows external calls. But the calls to six > digit numbers never seem to match against this partition, which simply has a > translation pattern with “!” as the matching pattern. > > Is it possible to have a “catch all” partition match like this, or does it > have to be a more explicit match, meaning I’m back to building a list of > migrated numbers rather than moving to a different partition? > > If anyone has a more elegant solution feel free to make a suggestion. > > > --- > /-Gary Parker----------------------------------f--\ > | Unified Communications Service Manager | > n Loughborough University, IT Services | > | tel:+441509635635 sip:[email protected] o > | https://www.osx.ninja/pubkey.txt | > \r----------------------------------------------d-/ > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
