Unknown calling party number in ISDN PRI

[khanalb]

Hello,

I have ISDN PRI trunks for PSTN calls and use a Cisco CUBE as voice gateway. CUBE to CUCM has SIP trunk in between. In CUCM, we route the calls based on Calling Number. The purpose is to block spam calls in CUCM using translation patterns.

However, with the above setup, Now I am running into an issue where every calls with missing calling numbers are rejected by my CUCM. I am sure not every calls of this type are spam calls. I wonder if there is a way to manipulate the ISDN call setup messages in the CUBE router and replace the calling number with some arbitrary number, similar to SIP profiles to manipulate SIP message headers. 

Calling Party Number i = 0x21A3, N/A
Plan:ISDN, Type:National

Thanks for your input.

Khanal

[Maren Mahoney]

It is possible using a SIP Profile to modify/populate the From field in INVITE messages.

Before you do, though, it may be the CUCM is rejecting the calls because of the interaction between two fields:

On the SIP Profile for your Trunk and for your Phones (which may be the same or may not) there is a field "Anonymous Call Block" which, if On, is on for all inbound calls. If it is Off, then CUCM looks at the DN checkbox for "Reject Anonymous Calls".  The defaults for these two setting are Off on the profile (which defers to the DN) and 'unchecked' on the DN. If your system is different that might solve your issue.

Maren

[Roger Kallberg]

Have a look at this excellent document. https://community.cisco.com/t5/collaboration-voice-and-video/blocking-calls-based-on-calling-party-id/ta-p/3113978
It is one of the most popular reads in the community. It has a section on how to handle what you asked about.

[khanalb]

Thank you Roger. I think it is worth a try and I will try for sure. I haven't read the entire article but I am not sure how the calls will be routed based on non-digits as calling number. Does the ! match digits as well as non digits?

[Roger Kallberg]

The document describes how to handle this with an empty translation pattern.

7)      Some calls may arrive without caller id or a restricted caller ID. If you wish to allow calls without caller ID, there will also need to be a <none> or blank Translation Pattern. If the administrator does not define a <none> Translation Pattern, then all calls without caller id will be rejected.

[khanalb]

Thanks a lot Roger. I didn't have to use the LUA script. All I needed to do was to add a blank TP and I am now getting unknown calls. I didn't know there existed a blank TP. Thought ! would match all. Anyway, it is such a relief now.

[Roger Kallberg]

Glad to hear that. As described in the article and in the header in the LUA script there are cases where the script is needed to properly handle calls with no caller id.

"Purpose:
This script is intended for customers that want to ALLOW or BLOCK anonymous calls into their system while blocking specific caller id's.
In CUCM 8.5 and previous, digit analysis did not handle non-numeric dial strings. So when routing based on calling party
number, and the calling party number was 'anonymous' or 'unavailable', CUCM could never accept the call. This script
removes the unroutable sting completely, thus allowing CUCM to route or block based on a <NULL> route pattern in the <Filter_List> partition."

May I ask why you put your own answer as the solution to your question? Wouldn’t you agree that one of my responses should be set as the solution to your question?

[khanalb]

Oops my bad. That was a mistake  

[Roger Kallberg]

If it was a mistake please change it.

[Roger Kallberg]

For information we’re using this setup since a few years on all our voice gateways, a mix of SBC and TDM GWs, and it works perfectly. We did one small alteration in the setup of the last CSS to have the TPs for what is blocked in one PT and the TPs for what is allowed in another, aka anything else than what is matched by the TPs that blocks. We did that to make the setup a little clearer to see what blocked, it had no technical reason at the time. However since we have also added the blocked PT into the devices CSS, to block calls made by a device to a blocked number, for the purpose of blocking calls being made to any numbers that is defined as being blocked in the inbound direction.

[Maren Mahoney]

@Roger Kallberg I think OP is saying that anonymous calls are being rejected, and they'd rather have them ring through. Although, if they are working with the technique you mention, it is possible they are inadvertently blocking anonymous calls.

Maren

[Roger Kallberg]

The article describes the use of a LUA script to allow the anonymous calls to go through together with a set of translation patterns.

[Maren Mahoney]

I didn't see the LUA Script part of that doc. Most excellent. Thanks @Roger Kallberg ! -- Maren

[khanalb]

The lua script at the end of the document, right before the comment section.