ILS/GDPR

[Leonardo Santana]

Hello,

I running a CUCM Lab with CUCM version System version: 11.5.1.14900-11, i cannot dial the +E.164 Alternalte Number, at the learned numbers i see the DNs of the other cluster but i unable to dial them.

Regards

Leonardo Santana

[Mohammed al Baqari]

What happens when you look at RTMT traces

[Leonardo Santana]

I see the learned numbers, but when i dial i hear i busy tone.

I have 2 CUCM has Spoke Clusters and one as the HUB

There is something else to configure?

Regards

[Jaime Valencia]

Do you have the route patterns in place to call those numbers?

[Leonardo Santana]

Jaime,

Do i need to have route patterns to the alternate numbers?

The Spoke Cluster learned from the SME

Regards

Leonardo Santana

[Leonardo Santana]

The server learned this numbers

Why is necessary to create route pattern to them if we learnerd with ILS/GDPR?

[Anthony Holloway]

You need a SIP Route Pattern for the learned/advertised Route String.  Did you do that?

"To be able to reach destinations learned through GDPR, the calling device's calling search space has to include the partition that the GDPR learned pattern is residing in and also the partition that the SIP route pattern resides in, which matches the SIP route string associated with the GDPR learned destination."
Source: CUCM SRND

[Leonardo Santana]

Yes, the css has the partition of the learned numbers.

I created a SIP Route Pattern to the URI dial.

Do i need to create route pattern to the learned numbers?

Regards

[Anthony Holloway]

You need to create a SIP Route Pattern matching your advertised Route String. You shared your Route String in the screen shot. Do you have that created as a SIP Route Pattern, pointing at your SIP Trunk to that cluster?

[Leonardo Santana]

Hello,

[Anthony Holloway · Accepted solution]

That doesn't match your route string from your other screenshot

[Leonardo Santana]

Sorry wich one?

[Leonardo Santana]

The problem was that the Advertised Route String of the HUB CLUSTER and the SIP Route Pattern of the SPOKE CLUSTER were different and vice versa.

Now its working fine, dialing the advertised numbers and URI.

Thanks...

Regards

[Iptuser031516]

I have a similar issue. I've been testing the set up and it works but have questions regarding whether I need the advertise Ils under each DN vs advertise the whole pattern under call routing >global dial plan replication 

If I tick the alternative enterprise numbers, learn ils etc under each DN for say Site A  then the Hub and spokes- Site B, can see the learned numbers but a call fails. If I now add the numbers eg 555xxxx as advertised patterns on Site A under global dial plan replication . Both Hub and Site B can see the "new" learned patterns as well. Now I can call between site A and B it works. If I remove the system advertised patten but keep the config under the DN as before  it fails. Now if I remove the advertise ILS under each DN and keep the global dial plan in place  then it still  works - no specific alternative enterprise DN is advertised just the main DN due to being added as global dial plan replication patten. So from my testing the only factor is whether I advertise the DN's  pattern via global... rather then directly on each DN. Am I missing something, the advertise alternative enterprise number & adertise via ILS under each DN don't seem tondon nothing, it is only the advertise feature under the "call routing" tab which makes it work - writing this on mobile and from memory but I hope it makes sense

Thanks

[Mohammed al Baqari]

Can you go through this doc and see if everything is in place.

https://supportforums.cisco.com/t5/collaboration-voice-and-video/global-dial-plan-replication-gdpr-notes/ta-p/3163817