Check Advertise Globally via ILS by default

[wabrown]

We are running CUCM 12.5 and would like to see if there is a way to have the "Advertise Globally via ILS" on the Directory Number configuration checked automatically as the default configuration for any new Directory Numbers built. I have a third-party application building the DNs via AXL and they don't have the option currently in their application to check this box. 

[b.winter]

No there is not.
Why don't they add this setting to the script / application, if there is already one?

[wabrown]

Much like Cisco, they can add an enhancement request, but it could take months. I was hoping for an immediate solution. Having that option in CUCM would be nice, so we wouldn't have to go back and check it after building any DNs manually as well, since it's not ian option in the initial configurations screen. Since the DNs used in this cluster are all specific to this cluster, for now, I've built a wildcard advertised pattern to accommodate us. 

[b.winter]

As @Roger Kallberg already wrote, in the case the DNs are specific to the cluster, a general advertised pattern would be "more efficient" anyway.

[Roger Kallberg]

Might I ask what your provisioning system is? We also have a system for this and in it we can have this set if we'd want to. See below for the setup of a site in the mentioned pre-production system we’re we do use the option to advertise the individual DNs.

[wabrown]

Man, I love Ziro! Used it at my last two jobs, but using Kurmi here. This is actually for third party Vocera Edge SIP devices. They have a tool now that manages their devices on their own application server, but also provisions them directly on to CUCM. 

[Roger Kallberg]

Not that I'm aware of. But that said it might be better if you where to use the option to advertise a pattern, with the entire number range, via GDPR from the leaf CMs instead of each individual DN. What I refer to is Call Routing > Global Dial Plan Replication > Advertised Pattern. This also have the added benefit limiting the load on the systems for the dial plan replication as you would have less items to replicate.

[wabrown]

Thanks, Roger. That's what I have done for now, creating a wildcard pattern in the cluster. But those DIDs may not stay on just that cluster, so it'd be beneficial to have a default. 99% of our DIDs on all of our clusters need replication and are shared between clusters, so it's better to have that as the rule, rather than the exception. It's a lot easier to remove it on the handful of DIDs that won't require replication than having to go back and add it to every one that does. 

[Roger Kallberg]

I'm not sure on how your system landscape looks like, but wouldn't it be for the most where you have numbers that belongs to a DID range, ie likely a site, being in one specific leaf CM? For sure there might be outliers to that, but those should be the odd few exceptions for the most. That's anyway how we have this setup with a few users being hosted on what we call a pre-production cluster that typically runs one version up of the UC systems than our GA production systems.

[wabrown]

You are correct, that would be ideal, however our clusters were all migrated from a legacy super cluster, which shared all of the DNs. Also, one of the clusters is specific for UCCE which also shares DNs. If it were a new build, that would be easy, but given the legacy infrastructure, which I'm sure is common, it's not possible.