After reading the post in its entirety I believe you’re asking about two SIP trunks between CUCM and the PSTN gateway. Not different SIP trunks to different carriers from the gateway. Please clarify if this is incorrect.
Normally you only need one trunk between CUCM and a gateway. There are corner case exceptions but nothing you said here obviated the need for that complexity. Just in case you’re wondering how it’s done: the trick is to configure discrete interfaces on the gateway, typically loopbacks, since CUCM only allows one trunk per-destination IP and port. IOS can’t run SIP on multiple ports so you have to use different interfaces. In the inverse direction you would create a SIP Trunk Security Profile on CUCM to listen on an non-standard port and assign that to one of the SIP trunks. Contrary to IOS, CUCM can listen on multiple ports but doesn’t support multiple IPs. Again, this doesn’t appear to be necessary here.
As for keeping the call local, by which I believe you mean on-net: keep the call on CUCM with proper +E.164 design in the first place. There is no reason to hairpin a call through a gateway - which would consume a CUBE session license - if CUCM is built properly. If for some reason you had to do this on the gateway a voice class e164-pattern-map with both ranges could be used to match both DID ranges. If you built your dial-peers correctly that should match before your generic off-net dial-peers to the provider.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/Lastly, you provably don’t need dial-peers per DID range. There are newer ways to match incoming VOIP dial-peers such as SIP URI (I prefer the host portion of the via header) that are less susceptible to problems and don’t require upkeep as you add DIDs.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.html
