I would definitely recommend you to use a voice translation profile with rules and use that on the SRST configuration, this is for the endpoints to be able to call each other in SRST mode with either of the number formats. I also recommend you to do the ingress/egress translation on the gateway. Don’t do it in CM as you do as that is IMHO to do yourself an disfavour for the use case that you ask about, aka when the site go into SRST mode as what you have in CM has no relevance for this. Use the thinking that you would need to take care of both states, operational CM connectivity and faulty where the phones goes into SRST. Best for this is to do all manipulations of numbers as close as possible to the source and this would be in the gateway.
Another thing for you to think on is that IMO you should go for a solution where you have the directory numbers setup in +E.164 and then you use translations to handle any internal number format that you might have. This would get you a more manageable system landscape. One more thing, your setup with internal numbers being totally disconnected from any specific digits in the DIDs is not very manageable IMHO. If I where you I would seriously consider redesigning that.
It’s somewhat of a matter of design of the number plan. Clearly it’s not often possible to simply use the last four digits of the DID. As an example we have 165 sites all over the world and we manage to do this.
Our approach is to form the internal proprietary dialling number format from the country code and a site code, to this we add the last four from the DID. An example of this is 46 for Sweden and 6 for the site and 1541 that is the last digits in my DID number. Our directory numbers are all in E.164 format, so the internal 7-digit number format is just to facilitate users to dial with shorter numbers.
@Elliot Dierksen I don’t see the reason for why there would be a need to match on number specific inbound dial peers? I might be missing something here.
