CUCM SIP Trunk 404 not found for incoming calls

[allahverdiyev]

I have strange issue on CUCM. SIP Trunk has been setup for ISTP, outgoing calls work. But CUCM send 404 not found to SBC. SBC is not under my control.

Receving called number is full range starts with +994XXXXXXXXX ( "X" are numbers).

I have setup Translation Pattern and Incoming Called Number Translation to translate +994XXXXXXXXX to internal DN (on registered phone). Significant digits is ALL. Inbound CSS has the all partitions exist in CUCM, including the partitions of TP and Inbound CNT. 

CUCM still send 404 not found. 

Here are other logs from SDL:
appendRPIDHdrForOriginalCalledParty: SIP device does not Support Orig Dialled Phone nego: 0

Digit Analysis: Host Address=cw7.local DOES NOT MATCH any active CUCM node in this cluster.

Digit Analysis: Host Address=cw7.local DOES NOT MATCH top level org domain.

Digit analysis: potentialMatches=NoPotentialMatchesExist

Any idea?

[Mohammed al Baqari]

Check that css has access to destination

[allahverdiyev]

I have almost checked 100s of time..yes

[TONY SMITH]

Check that the IP address actually being used for the SIP signalling matches the IP address in the CUCM trunk configuration.  Also check that the destination IP that the SBC is sending to is a valid CUCM server associated with that trunk (check Device Pool and CMG).  Have you ticked the “Run on all active unified CM nodes” option?

Finally to triple check your CSS configuration, do a quick check with dialled number analyser.  And reset the SIP trunk in CUCM just for luck.

[allahverdiyev]

What is CMG?

"Also check that the destination IP that the SBC is sending to is a valid CUCM server associated with that trunk (check Device Pool and CMG)." Could you please elaborate in this?

Yes, “Run on all active unified CM nodes” .

They are sending from different ip address than we setup in sip trunk.

[TONY SMITH]

I think this may be the key ... "They are sending from different ip address than we setup in sip trunk." CUCM will look at the originating IP address and match that with any trunks that it has configured.  If it matches then it uses the trunk configuration to process the call.  If it doesn't match, how is CUCM supposed to know what call handling to apply?  I think you have two options.  You could either add this incoming IP address as a second address on your existing trunk.  Or copy the trunk but give it this IP address, meaning you effectively have one trunk used for outbound and one for inbound.

One slight reservation is that I think I've seen CUCM return a 503 service unavailable error, rather than 404 not found when the source address didn't match.  However that might be version specific.

CMG = "Callmanager Group", the list of CUCM servers that a device will register with.  There can be issues if an incoming call is addressed to a CUCM server that is not in the trunk's CMG.

If you're still having issues, post up the SIP decodes from an inbound call attempt. 

[Victory007]

Hi allahverdiyev, Any solution for this issue?

[Maren Mahoney]

@Victory007 - I encourage you to create a new post describing your environment and your issue. We are happy to help!

Maren

[Victory007]

@Maren Mahoney 

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

[Steven L]

as @Maren Mahoney suggested (she was being generous), please create your own thread and the community would be happy to help. This thread is 5 years old.

[Maren Mahoney]

I did mean a brand new post, rather than adding to this old thread. -- Maren

[Victory007]

https://community.cisco.com/t5/ip-telephony-and-phones/cucmresponds-404-not-found-for-incoming-calls-digit-analysis/td-p/5082956

[Simran S]

I assume you have setup the translation rules on the SBC. Is that SBC a CUBE ? If yes then can you test the translation rule to see if the rule is even working and is successfully translating that incoming called number to an extension ? 

If you are accepting everything from SBC as is and then using the Translation Pattern in CUCM then does this Translation Pattern CSS include the partition of the internal extension because this is what will be used for the second destination match ?