cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
513
Views
6
Helpful
19
Replies

CUCMresponds 404 not found for incoming calls - Digit analysis fails

Victory007
Level 1
Level 1

We have a cluster of 6 Sub+ 1 Pub.

Encountering 404 not found with Digit analysis failing in 3 nodes which are in DR site but calls are routing successfully in DC nodes. Adding to this, Dialed Number Analyzer gives "Block this pattern" in DR site nodes and "Route this Pattern" in DC site nodes

Below are SDL Logs of DR site (Not Working),

AppInfo |Digit Analysis: Host Address=cucm.abc.com MATCHES Cluster FQDN.
AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=11111
AppInfo |Digit Analysis: Host Address=cucm.abc.com DOES NOT MATCH top level org domain.
AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
AppInfo |Digit Analysis: getDaRes - Remote Destination [] isURI[1]
AppInfo |Digit analysis: patternUsage=2
AppInfo |Digit analysis: match(pi="2",fqcn="", cn="1234", plv="5", pss="test-PT", TodFilteredPss="test-PT",dac="0")
AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist

Below are SDL Logs of DC Site (Working):

AppInfo |Digit Analysis: Host Address=cucm.abc.com MATCHES Cluster FQDN.
AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=11111
AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
AppInfo |Digit Analysis: getDaRes - Remote Destination [] isURI[1]
AppInfo |Digit analysis: patternUsage=2
AppInfo |Digit analysis: match(pi="2",fqcn="", cn="1234", plv="5", pss="test-PT", TodFilteredPss="test-PT",dac="0")
|AppInfo |Digit analysis: analysis results

1 Accepted Solution

Accepted Solutions

Victory007
Level 1
Level 1

Hi, a quick update,  I try resetting the extensions now (non peak hours) which are having the issues, it started working for DR nodes and DNA looks good as well for DR. 

View solution in original post

19 Replies 19

In the working scenario you have this “Digit Analysis: Host Address=cucm.abc.com MATCHES Cluster FQDN” and in the non working scenario you have this “Digit Analysis: Host Address=cucm.abc.com MATCHES Cluster FQDN” and then “Digit Analysis: Host Address=cucm.abc.com DOES NOT MATCH top level org domain”. This is somewhat confusing as it’s a cluster wide setting and therefore should not be different between the nodes in the cluster. Have you verified that the database replication is in working order?



Response Signature


I was thinking the same thing as @Roger Kallberg when reading that nodes at one site in a cluster were processing calls one way, but nodes at a different site were processing nodes a different way.

If you have not done database replication troubleshooting, here are the instructions you want to work from:

Troubleshoot CUCM Database Replication Issues 

Let us know how it goes!

Maren

Replication looks good in both CLI and Reporting view

Steven L
Spotlight
Spotlight

what are the FQDN hostnames of the servers? are they different for working vs not?

cluster wide domain config same for all

 

VenkkateshL_0-1714420163639.png

 

you MUST populate org top level domain if you define the cluster FQDN

 

put "abc.com" there and try again

the message is actually pretty clear what the problem is

 

Host Address=cucm.abc.com DOES NOT MATCH top level org domain.

top level domain is not mandatory for configuring cluster FQDN.

maybe not...in my mind i think of it as mandatory because not populating it has always had issues for me.

You have incorrect configuration in the cluster fully qualified domain name, it cannot be *.abc.com, it should be a unique name like cluster1.abc.com and the top level domain should be abc.com.



Response Signature


Cluster FQDN can have wildcard as mentioned below and this is a simple numeric (extension) call routing and i don't need for a Org top level config.

VenkkateshL_0-1714423327928.png

 

It can be set as you have it, but it is not recommended and would not work if you ever want to use GDPR for replication of number information between multiple CM clusters over an ILS network. So yes I’m incorrect in saying that you have it set incorrectly, but it is absolutely not recommended to have it set like you have.

Is there any specific reason for why you don’t want to set the top level domain in your CM cluster and also why you have the cluster fully qualified domain name set as you have? Top level domain is listed as one of the recommended enterprise parameters to set when you initially setup the system. System Configuration Guide for Cisco Unified Communications Manager, Release 12.0(1) 



Response Signature


Question: When you wrote "Adding to this, Dialed Number Analyzer gives "Block this pattern" in DR site nodes and "Route this Pattern" in DC site nodes", are you saying that you are somehow specifying the processing node in the DNA? How are you doing that?

Maren

We have enabled the DNA services in all the 6 nodes. If i try the DC nodes DNA URLS, it says route this pattern where as DR nodes says Block this Patter for the same number