Showing results for 
Search instead for 
Did you mean: 

Marco Szablewski

DID translations for SIP SRST

Hello All,


For a while I have been trying to figure out the best way to translate DIDs to extensions in SRST mode.


For simplified management we are using translation patterns in CUCM to translate DIDs to extensions (I know we could translate all DIDs on the VGW / CUBE, but that would complicate things for folks not so confident on the CLI).


I wish the alias command under voice register pool would allow more than 5 entries - but that's not the case, even in the latest IOS releases. The best way I found to make this work is using voice hunt-groups (with a low preference) together with the dial-peer hunt 2 command to still have the general CUCM dial-peer take precedence when CUCM is available. Obviously voice hunt-groups aren't meant to be used for this, but I find it works (the second DN in the list is just any dummy DN that will never register to SRST).


Please find configuration samples for each method attached.


Afaik I can't make this work with the alias command when I have more than 5 non-consecutive DIDs.


I'd like to see the following translations:

4165551234 to 1001
4165552345 to 1002
4165553456 to 1003
4165554567 to 1004
4165555678 to 1005
4165556789 to 1006


How is everybody else doing this?


Thanks in advance for any and all suggestions,


Roger Kallberg
VIP Advisor

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.

Response Signature

Thank you for your insight. It makes sense.

Unfortunately it's not always possible to map the DN to any of the digits in the DID, but obviously that's the ideal scenario.

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.

Response Signature

Elliot Dierksen

This has the potential to make your configuration HUGE, but you could always create a separate inbound dial peer (incoming called-number) for each number or perhaps a block of numbers. The problem there is you have to do the translation outbound, so I think @Roger Kallberg  has the right idea with getting the +E.164 assigned to as an alternate on the DN. Otherwise this is awfully unmanageable. It would be easier if you had the CUBE functionality separated from the SRST functionality. I guess the next question would be how hard is it to get an additional subscriber for this location? Then most of the SRST stuff becomes moot.

@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.

Response Signature

I was thinking out loud while posting. Probably not a good combination. I don't think it would be applicable if the CUBE and SRST are in the same router. If they were different, you could do multiple outbound peers based on pattern to translate it. It has been a long and tiring week....

Content for Community-Ad