07-27-2016 01:38 AM - edited 03-12-2019 10:23 AM
Concepts
Configuration
Thank you Mohammed for putting this together
Hi Mohammed
thanks for the note , but I have one question
if I have two clusters , All DNs on both cluster does not have URI, Alternate number or enterprise alternate number , but all DNs are in E164 formate
but I still want to enable AAR over intercluster trunk
Can I add summarized pattern of All DNs in each cluster as in below "step 5" and AAR will work ?
best regards,
Ahmed
==========
5-Navigate to Call Routing > Global Dial Plan Replication > Advertised Pattern > Add New
Excellent post and this is something I am looking at deploying now we have upgraded from CUCM 8.6 to 11.5.
I have a couple of questions regarding these new features :
1 - can this be used in place of "call forward unregistered". So for example, if we have a remote site in a CUCM cluster we currently use call forwarded unregistered if the site is disconnected and therefore as the phones unregistered and the call will route across the PSTN. Can you now make use of the alternate number and add to local route partition so if the primary extension cannot be reached CUCM will try to route the call across the PSTN or is this only applicable if it cannot route across the SIP ICT ?
2 - We have 50 plus global sites and people had a habit of dialling the office externally although they were on net so we force on-net calling via translation patterns and route-patterns if it was inter-cluster. Now GDPR is available I assume we should remove this config and add +E164 alternate number ?
Thanks, Carl Ratcliffe
Preston Lancashire England
Thx for your comments.
1. In the current scenario, I believe that you are using single cluster and the remote site is using CFU as you mentioned. To utilize GDPR PSTN failover you need to have two separate clusters with GDPR and ILS established. In this case the calls will be rerouting over PSTN if the SIP Trunk isn't reachable. Now if this is a new deployment I recommend you go with it. But if this is an existing setup, then migrating from single cluster to multiple cluster is good idea but you need thorough planning.
2. Using TPs to match dialing habits is the right approach. But you are right in the fact that with GDPR you can replace TPs for +E164 numbers with Enterprise Alternate or +E164 Alternate numbers. Just keep in mind that the local +E164 Alternate number isn't reachable within local cluster by default and you can change this behavior as I mentioned above.
Yes you can use Alternate Pattern even if you aren't configuring Enterprise Alternate or +E164 Alternate numbers.
Hi Mohammed
Thanks for your response
1 - We do have multi clusters and I will certainly be planning a new dial plan for GDPR but correct what I asked about was within a single cluster. We have clusters on each continent but within a cluster are many different countries which is what we use CFU. As these are the same cluster CFU seems like the only option to use as we cant use route groups to failover to PSTN when its on-net so I was hoping GDPR might be able to do something fancy for PSTN failover intra-cluster but doesn't look like that's the case yet.
2 - I'm certainly going to plan this in as using alternate numbers / patterns is going to be far easier than having to add translations for forced on-net to each cluster.
I've been testing in a lab as per your config guide and after seeing the results I'm going to plan this in very soon. Globalisation, Tail End Hop Off, Forced On-Net, PSTN Failover have just become a million times easier to configure when you have a multi cluster environment.
Thanks, Carl Ratcliffe
Preston Lancashire England
Carl,
I have recently design and deploy a multi cluster environment with ILS/GDPR. Here are a few things to note..
1. Forced onnet routing doesnt require any translation pattern or alternate number mask if you are using a globalized dial plan. ILS/GDPR makes this very smooth. Here is an example of a call flow
A--APAC
B--US
A user in APAC dials the DDI of a user in US. This matches the xlation pattern for international calls, the call is globalized.
Once globalized, this will match an advertised pattern from US via GDPR. Once the pattern is matched CUCM uses the sip route string attached to route the call to the remote cluster. No need for any additional translation pattern.
The only time you will need to create xlation pattern is if your users do not have access to international numbers since you need to match the xlation pattern first before the call is globalized.
For National numbers, this is pretty easy. The call is globalized and matches an advertised GDPR pattern.
I did this recently and it was flawless.
Secondly
A DN and associated E164/enterprise number is a single number as far as CUCM is concerned. They are not two different numbers. Bear in mind that the alternate number doesn't exist and hence why you must allocate it to a routable partition so that CUCM can insert in DA. If the main number is unavailable, I dont think the alternate number will be reachable
Hi Ayodeji
Thanks for the information I will make good use of it. The more I play about in the lab with GDPR it does seem like one of the best features Cisco have designed for CUCM when I think of the amount of time I spend with Tail End Hop Off, Forced On-Net etc.
I have 1 query about the learnt numbers/patterns from ILS. These are learnt and can be assigned a partition using "Partitions for Learned Numbers and Patterns". The calling device then needs a CSS that has access to this pattern, which makes sense.
However to be able to dial inter-cluster you need a SIP Route Pattern for the route string and the partition in this also has to be accessible from the calling device or the call fails. Should I just create a generic partition for example P_GDPR and as well as the learnt numbers/patterns partitions also add this generic one into the CSS of any device that should be able to use learnt patterns ?
Thanks, Carl Ratcliffe
Preston Lancashire England
Yes that is what I did. I created a partition Global-onNet_PT. All learned patterns, sip route patterns and enterprise number are assigned to it. Keep it simple.
Remember also to keep your configuration neat and tidy, advertise only patterns. Dont advertise E164 numbers vial ILS or enterprise numbers, just summarize your patterns and advertise only patterns
Hi Ayodeji
Thanks for your response. Summarising numbers to patterns is something I will do and it will work well in my setup.
If Cisco would now add something to GDPR which would allow PSTN failover intra-cluster it would make the feature complete. As I mentioned in my first comment, within each cluster I have up to 30 sites/countries so when one of these sites/countries loses connection to the WAN I can only use CFU to automatically route the call ( unless im missing something ? ) but I don't like doing this when I have Extension Mobility. You would think this would be quite a simple solution to design - if an extension is not reachable and it is logged into extension mobility from the database's perspective then route the call to the PSTN failover.
Thanks, Carl Ratcliffe
Preston Lancashire England
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: