Call Screening, Call blocking based on ANI calling number

[Dennis Mink]

Like to get some feedback on this, trying to get call screening/blocking to work on MGCP gateway inbound calls, based on Caller ID/ANI

I have found some excellent documentation on this forum on how to set it up, but even when following this, I can't seem to get it to work. 

when I make an inbound call on a MGCP gateway with call blocking configured, no calls are coming trough (get disconnected)

here is what I got:

A ! translation pattern with the "route next hop by calling party number ticked"

Using the PerthAirport_PSTN_SCREEN CSS, in this CSS I have my translation patterns that either block an ANI and another ! translation pattern that allows all else, :

this translation pattern uses a CSS AU_ONNET_CSS that contains all phone extensions, and can route to the end destination.

running the traces I can see that the following:

15005646.002 |11:59:11.486 |AppInfo |Digit Analysis: star_DaReq: Matching Legacy Numeric, digits=+61812345678
15005646.003 |11:59:11.486 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
15005646.004 |11:59:11.486 |AppInfo |Digit Analysis: getDaRes - Remote Destination [] isURI[1]
15005646.005 |11:59:11.486 |AppInfo |Digit analysis: patternUsage=2
15005646.006 |11:59:11.486 |AppInfo |Digit analysis: match(pi="2",fqcn="", cn="4123456782", plv="5", pss="AU_PerthAirport_PSTN_In", TodFilteredPss="AU_PerthAirport_PSTN_In", dd="+618123456785",dac="0")
15005646.007 |11:59:11.486 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist

the MGCP gateway has the correct AU_PerthAirport_PSTN_In CSS, yet somehow does not process the first "route next hop by calling number "!" translation pattern".

And throws out a NOpotential matches exist error

Is there a service parameter of enterprise wide setting that needs to be set to get this to work?  anyone have any working examples?

CUCM version: 10.5.2

cheers peeps

[csmith5660]

I'm wondering if you've found a solution to this, I have the same issue but can't verify the debugs right now.  I've set this up before and I know it works on 11.5.  This cluster is on 10.5.2.11900-3 and even though it's setup correctly there's just dead air and then a disconnect.  Probably a bug in this version.

I suspect it's either MGCP or the CUCM version my customer on 10.5 is using MGCP/PRI while my 11.5 customer is on SIP.

[Dennis Mink]

Yeah mate, we are running 10.5.2.14900-16

and yeah, dead air disconnect.  I currently have blocking configured on an MGCP gateway. If the concept is configured correctly then I might go a try to apply it to a SIP trunk and see if that works.

or TAC it.

[csmith5660]

I got mine to work.

On the translation pattern that you enable the option to route next hop by calling number, I had to replace the ! with XXXX (customer only receives 4 digits, you may need to adjust).  It doesn't like the wildcard.  Cisco TAC can't explain it, but it did fix my issue.

Hope this helps!

Craig

[csmith5660]

I found this and it may pertain to your situation, but I don't think it does to mine.

https://supportforums.cisco.com/document/71966/blocking-calls-based-calling-party-id

Scroll down to the comments and look for the user "IT Department" read about his SR and the issue with receiving NULL in the caller ID, the error matches yours see dakeller's response.  I noticed you're getting an E164 inbound number - your issue maybe the + in front of the caller ID.  Not sure you can do anything about it with MGCP so you may have to switch to H323.