For starters, port based routing is bad. CM can have a maximum of 16 TLS connections for SIP signaling, and different ports use those up. That's to say 1 of those 16 connections per unique pair of source/dest IP/port
So, 1 CM, 1 SM, 16 TLS SIP signaling groups on ports 6061-6076 would max out your CM and you couldn't add any more SIP signaling groups UNLESS they were to that 1 SM and on the same pair of ports on both sides like 6061-6076. Conversely, 100 sig groups from 1 CM to 1 SM on port 5061 with subdomain tenant1.customer.com, tenant2.customer.com, etc would use 1 of the 16 connections. Also, bear in mind that SM doesn't care about your entity links. Look at a dial pattern and routing policy in there. It says "sip entity as destination" not "SIP entity link as destination" You don't get to tell SM to use TCP or TLS if for the 1 SIP entity you have both as entity links.
Is there any particular reason you'd want certain calls to go to trunk 25 in CM? Thinking out loud, it might sound like you've migrated from PRI to core SIP and are looking to keep that logical separation like you'd had before. Depending on your needs and how you want to subdivide your resources, that might make sense. Say, 25 locations used to have 100 trunks each and your SBC has 2500 now for them all and you want to to keep each location to no more than the 100 they're budgeted for.
The SBC can do that too if you look into URI groups and application rules. Basically, you can have a number map to server flow (go to SM) with an application rule (that defines max 10 or 20 sessions) and make different URIs for location 25 map to it. Maybe you want to go down that road, maybe you don't.
Still, that won't change the domain of incoming calls from the SBC. Your SBC has "server interworking profiles" that let you swap domain on the way out to the carrier or SM. But that won't subvdivide 25 ways either. Maybe having 25 internal subinterfaces on the SBC to SM and having SM use an adaptation for each. An adaptation can do a few things - like digit or domain manipulation like the SBCs interworking profile, but again, it's global to "everything from that SIP link" - so, no granularity to apply tenant1@customer.com if digits are 101xxxx.
As far as I know, CM's the only thing that can send a number to something at the same IP and port AND use a different domain based on what the dialed number was - to say, have 25 SIP sig groups to the same SM but with far-end domain tenant1.customer.com for the 101s, and tenant2.xxx for the 102s. I'm sure Breeze has a sequenced application that'd be trivial enough to write so that your calls would go SBC-->SM-->Breeze-->back to SM with the appropriate domain based on the numbering-->CM. But I don't think you have special Breeze applications.
So, you could (though I'm not sure I'd recommend rejigging your network this way) have all your incoming DIDs go through SM to CM to SM back to CM to work your domain in. CM could have (for our example of 25 locations x 100 trunks) 10 sig/trunk groups of 250 members at customer.com receive those numbers and insert a steering digit.
That steering digit could map to ARS and based on the ranges, send out to SM on each of 25 sig/trunk groups of 100 channels with domain tenant1.customer.com etc.
SM could have those domains set up and 25 dial patterns like this: "x" of min/max whatever your length is, @domain tenant1.customer.com, go to CM.
On CM, you'd have trunk 25 be tenant25.customer.com get the call.
Now, for this example, a rough trunk design would look like: sig/trunk 801-810 - the 255 member groups @customer.com.
Sig/trunk 701-725 each with 100 members to tenant1.customer.com all the way up. These trunks would never be in route patterns to send users calls out on, they'd just be for bouncing calls back to SM. That's why a steering digit would lead to them and why people wouldn't be dialing them normally.
Sig/trunk 601-625 would look exactly like 701-725 and those are the trunks the calls would come in on.
Now, it's important to know how CM picks which sig group to answer an incoming call on when it has many sig groups to the same SM. CM will use the lowest numbered signaling group that matches source/dest IP/port AND where the entirety of far-end domain fits in the invite it received. That means if all your subdomains end with customer.com and sig 1 is customer.com that CM would have sig group 1 steal everything because "customer.com" in sig 1's far end domain would match voicemail.tenant14.customer.com. That's why your most specific subdomains need the lowest numbered sig groups and your least specific the highest numbered.
So, my idea would satisfy your requirements until a site uses their 100 trunks. Once that happened, SM would still offer the call to CM, but 601 would be full, so the next available candidate is 701 which is the trunk you'd send out on to do the whole idea in the first place and you've mave a routing loop.
I suppose having 701-725 be outgoing only and not accept traffic would get around that, but 801-810 would still accept them afterwards.
You'd still need some high level steering digits to not break things. Say, on 10 digit DIDs SM pitches to CM the first time, have an adaptation that matches x min/max10 and insert 222 and send to CM. Trunk 801-810 have incoming call handling treatment match 222 min/max 13 and insert the AAR code. AAR 222 min/max 13 goes to your routes to 701-725 and those routes swap 222 for 333.
SM sends back to CM now. If 601-625 match 333 min/max13 and drop the 333 and 701-725 are outgoing only and 801-810 match 333 min/max 13 but replace to an announcement of a busy signal.
But, in the end, all of that is really gross to do and something I'd never recommend. I was just a little bored and figured I'd think the idea through to wherever it wound up. There are no shortage of poor design decisions out there based on people using CM because they know it best to make a solution do things that are handled more nicely at other layers. You've got call admission control in CM and SM and you've got the URI groups and application rules where you can easily manage "no more than X calls to this list of numbers". So, DON'T DO THIS but I hope you got something out of it as far as an understanding of what domain based routing can do.
So, what type of granular control are you looking to achieve across which applications? If you manage that many PBXs, careful with whatever you do because you will live with it forever!
