06-28-2024 10:14 AM
I have main site with CUCM cluster and its own voice gateway (PRIs). There is a small remote site with the voice gateway with a single PRI (for outbound calls only). Sites are connected with WAN link. Inbound calls for remote site comes to the main site gateway. Remote and main site uses the numbers from the same DID range which means remote site does not have its own separate DID range.
When there is a wan failure between the main and remote site, remote site phones go to SRST mode as expected and they can make outbound calls without issues. However, they cannot call the main site using the 4 digit because there is no dialplan for 4 digit dialing in that gateway. I am wondering how I can accomplish this with minimal effort. Is it just a matter of translating 4 digits to 10 digits (or e164 format in our case) or there is more to it? Again, since both sites use the numbers from the same DID pool, we may not be able to use the wildcards if we need to use translation profiles. My requirement is just to allow people from remote site to be able to call main site using 4 digit extensions while in srst mode.
Thanks
KhanalZ
Solved! Go to Solution.
07-27-2024 12:25 AM - edited 07-28-2024 12:45 PM
Change rule 2 to translate to +E.164 format by this.
voice translation-rule 50
rule 1 /9\([2-9]..[2-9]......$\)/ /91\1/
rule 2 /^\(11..\)$/ /+1202555\1/
Then create a new dial peer that matches +1202555T and also create a new translation rule and profile that translates from +E.164 format to the format required by your service provider to route the call on PSTN, then set that translation profile on the new dial peer as an outbound translation.
With this your router will when the phones are in SRST state see the dynamically created dial peers first and keep the call locally and if the +E.164 number isn’t available locally on the router it will use the new dial peer and send the call via PSTN to your other site.
Likely the translation rule and profile should be like this.
voice translation-rule 51
rule 1 /^\+\(.*\)/ /\1/
!
voice translation-profile E164-OUT
translate called 51
The key to this is that the outbound translation is done after the dial peers is matched and that the dynamic dial peers will have a more specific match than the new dial peer as they have the complete directory number, making them a better match than the new dial peer.
None of this will make any difference to your normal dial strings to PSTN. It will just create the possibility to route calls to your other site in +E.164 format and use the call routing logic in IOS to keep the call locally when there is a directory number registered on the router.
06-28-2024 11:00 AM
Create a voice translation profile/rule that you assign to your SRST configuration in the inbound direction. This will translate from the internal format to full E.163 format so that it can be routed via PSTN.
06-28-2024 11:42 AM
Thanks for the response. My question is, what happens if someone from that site with DN 1111 (DID 2025551111) calls someone at the main site who has 1112 (2025551112). My translation profile would look something like
voice translation-rule 1
rule 1 /^\(111[1-9]\)$/ /+1202555\1/
Now, what happens if that 1111 calls 1113 who is also in that remote site? Does it ring 1113 or translation kicks in forcing calls out through PSTN and back to the main site ?
06-28-2024 10:41 PM - edited 07-28-2024 12:31 PM
It depends on what format you have your directory number, if it’s in +E.164 it would but if it’s in 4 digits format it wouldn’t. Two comments on this. First off, it is not really good practice to have extensions assigned in an unstructured way as it sounds like you might have, what I mean is you should have a structured approach to what numbers that are assigned to each site so that there is a deterministic way to know where a specific number would be allocated. Secondly I would recommend you to use +E.164 format for your directory numbers. With that the call would stay on the router even after the translation from four digits to the full number as the longest match rule would be in effect as the router would “know” that there is a device that has +12025551113 and not send that call to the PSTN.
07-26-2024 12:12 PM
Firstly, after creating translation rules/profile and applying to voice register pool 1, we were able to call another site using their 4 digit extensions.
voice translation-rule 50
rule 1 /9\([2-9]..[2-9]......$\)/ /91\1/
rule 2 /^\(11..\)$/ /91202555\1/
voice translation-profile SRST
translate called 50
voice register pool 1
translation-profile incoming SRST
id network x.x.x.x mask x.x.x.x
dtmf-relay rtp-nte sip-kpml
voice-class codec 1
We use +E.164 format for extensions and they are not assigned in structured way, ie. +12025551111 belongs to someone at main site and +12024441112 belongs to someone at remote SRST site.
Now, if I dial the last 4 digit to reach someone at main site, it works in SRST mode with the help of translation rule 50 above. However, when a person in SRST site with the extension +12025551112 dials another person in the same site by dialing the 4 digit the call goes to remote site and ends up hitting Unity Connection. If I dial using +E.164 format call goes through fine.
I then removed the rule 2 under translation rule 50 and dialed 4 digit, call fails for obvious reason because there is no translation.
Is there a way I can fix this issue? Again my requirement is that I want to be able to call main as well as local site while in SRST mode using 4 digit extension. Any help would be much appreciated.
Thanks
07-26-2024 03:00 PM - edited 07-28-2024 12:23 PM
You need to translate the 4 digit pattern to +E.164 and then have a dial peer match calls to PSTN in +E.164. On the dial peer you then translate the called number to the format required by the service provider to successfully route the call on the PSTN. That way the call will match the local directory numbers that are registered in SRST first as that’s a more specific route and then match the dial peer to send it to the PSTN for anything else that is not matched locally.
07-26-2024 04:23 PM
Calls to PSTN as well as remote site are working fine and they don't use +E.164 format. Since it is PRI, we either forward 10 or 11 digits through the outbound dial peer. Internal phones in the other hand use +E.164 format DNs and I have no idea where I can further manipulate the digits and prefex +1. The translation profile applied under voice register pool 1 translates all 4 digit numbers to 91 followed by 10 digit number. Now, my requirement is to make a separate list of all local numbers of that site, remove 91 prefix and prefix +1. This will then match the e164-pattern-map applied to an existing dial peer and hopefully route to local phone numbers. Alternatively if I could create about 4 dozen translation rules and apply them under the single translation rule 50 as given above (that translates 4 digit to 91+10 digits), that would likely solve my problem but I doubt I can have that many rules under a single voice translation rule. I am sure there is a way to get it done but just can't think of one at the moment.
07-27-2024 12:25 AM - edited 07-28-2024 12:45 PM
Change rule 2 to translate to +E.164 format by this.
voice translation-rule 50
rule 1 /9\([2-9]..[2-9]......$\)/ /91\1/
rule 2 /^\(11..\)$/ /+1202555\1/
Then create a new dial peer that matches +1202555T and also create a new translation rule and profile that translates from +E.164 format to the format required by your service provider to route the call on PSTN, then set that translation profile on the new dial peer as an outbound translation.
With this your router will when the phones are in SRST state see the dynamically created dial peers first and keep the call locally and if the +E.164 number isn’t available locally on the router it will use the new dial peer and send the call via PSTN to your other site.
Likely the translation rule and profile should be like this.
voice translation-rule 51
rule 1 /^\+\(.*\)/ /\1/
!
voice translation-profile E164-OUT
translate called 51
The key to this is that the outbound translation is done after the dial peers is matched and that the dynamic dial peers will have a more specific match than the new dial peer as they have the complete directory number, making them a better match than the new dial peer.
None of this will make any difference to your normal dial strings to PSTN. It will just create the possibility to route calls to your other site in +E.164 format and use the call routing logic in IOS to keep the call locally when there is a directory number registered on the router.
07-30-2024 07:37 AM
@Roger Kallberg The solution that you provided makes perfect sense and I am sure it will solve all my issues. I am planning to implement it most likely this Friday and update here. For now, I just wanted to thank you so much for being so helpful all the time.
Khanal
08-02-2024 07:49 AM
Thank you @Roger Kallberg it worked like a charm. Greatly appreciated!
08-02-2024 11:25 AM
Glad to hear that!
07-28-2024 12:25 PM
@KhanalZ Where you able to get this to work according to my description? If you did I would appreciate if you could give helpful votes and set your question as solved.
06-28-2024 11:21 AM
This post has additional information that might be helpful. https://community.cisco.com/t5/ip-telephony-and-phones/srst-translation-profile-for-sip-phone/td-p/2814860
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide