ILS call doesn't work from Spoke to hub cluster

[ravi.kumar1]

am trying ILS in my lab with a simple setup, cucm 12.5

calls work from hub to spoke cluster i.e. 5001 to 1300 but not from 1300 to 5001

cluster id:londonccmlab01 this is hub cluster, edgeccmlab01 is spoke

[Roger Kallberg]

With the limited information provided it’s not all that easy to give a specific answer.

A few things to check is that the partition of the SIP route pattern  is seen by the CSS of the calling party and that the inbound CSS on the trunk on the receiving cluster sees the partition of the called directory number.

To really know what is causing this you would need to collect the CallManager traces from both CMs.

[ravi.kumar1]

yeah those basic things i had already verified.

when i make a call to 5001 from CIPC i see it translate to just '5'. see the image

[Roger Kallberg]

If you do a DNA for the calling device what is the result of the call routing? Also please check DNA for the trunk in the receiving cluster and share the result.

[ravi.kumar1]

this is the trunk DNA from the receiving cluster. PFA

[ravi.kumar1]

and this is from the spoke cluster, from where the call is initiated.PFA

[Roger Kallberg]

Had a look at them this morning and it dawn on me that DNA unfortunately doesn't understand routing via GDPR learned patterns or directory numbers. To figure out what is going on with this you would need to collect the CM traces from both systems and start with checking from the calling side. If you can't find what is causing this there look at the receiving end. It's a matter of following that call as it moves through the call path. The fact that you see just a "5" on the calling side would indicate that somewhere along the line your modifying the called number and this could be what is causing your call to fail.

[ravi.kumar1]

So, i did another test, this time i made a call fr jabber instsad of cipc and i can see the call reaching receiving cluster since it shows me the alerting name of the called number.
The only difference i see right now is 2 days back i uploaded CA certs on the receiving cluster.

[ravi.kumar1]

i can see the ascii alerting name when i make the call. see the below picture and i changed the alerting name to Ravi Pandey1 and made another call, so the call is going through it is just not ringing.

Also to test i made a route pattern of 5001 and used the same trunk under SIP route patter and the call went trough successfully.

[ravi.kumar1]

ok, i found it, calls to 1300 was possible because 1300 was under advertised pattern, so my next question is ILS helps in exchanging directory URI, is there a way i can do inter cluster dialing without dialing the actual URI,

for example dial 5001 from other cluster phone and 1300 from other cluster

i know :Cisco Unified Communications Manager checks if the dial string is numeric according to the Dial String Interpretation policy. If the dial string is numeric, Cisco Unified Communications Managerroutes the call as a directory number, so how can i make intercluster call using ILS, will i have to advertise the patterns? is that the only way.

[Roger Kallberg]

Directory number information is replicated by Global Dial Plan Replication, GDPR in short. It’s a service that uses ILS to propagate information. You can either advertise individual directory number or a group of numbers. For more information about this see this document. https://community.cisco.com/t5/collaboration-voice-and-video/global-dial-plan-replication-gdpr-notes/ta-p/3163817

[ravi.kumar1]

Yea, i saw that, but the problem is you would need to setup an alternate number in a different partition.

Is there no way we can just make inter cluster calls in an ILS network without setting up the alternate numbers , i wanna reach the extensions in a cluster from a cluster part of ILS on the same partition the DNs are setup.

[Roger Kallberg · Accepted solution]

There is no need to setup an alternate extension. You setup GDPR to advertise individual directory numbers on the directory number itself or you set it up to advertise blocks of numbers under Call Routing > Global Dial Plan Replication > Advertised Pattern. These are then learned by the remote cluster and put into the partition(s) that is defined under Call Routing > Global Dial Plan Replication > Partitions for Learned Numbers and Patterns. This/these partition(s) needs to be visible to the calling party. Worth knowing is that GDPR will always use the original CSS to find the SIP route pattern that is used to route the call to the learned destination.

If you'd want to know more about the details about Global Dial Plan Replication I strongly advice you to look at Johannes Krohn's excellent BRKUCC-3000 presentations from Cisco Live. One of them can be found at this link, https://www.ciscolive.com/global/on-demand-library.html?search=brkucc-3000#/session/14528016321950017hXf