Blocking Calls Based on Calling Party ID

Document

Sep 7, 2011 12:29 PM
Sep 7th, 2011

Application Note:

Blocking Inbound calls to Cisco Unified Communications Manager based on Caller ID

1. Introduction:

The ability to block calls based on the calling party number is a feature required by many customers to prevent unwanted calls, whether from telemarketer, malicious callers, or others, from reaching their end users. This application note will describe and illustrate how to set up call blocking using Cisco Unified Communications Manager v8.0 and later.

2. Audience:

This document is targeted at administrators that are familiar with call routing in the Cisco Unified Communications Manager environment. To implement this feature, the administrator must have good knowledge of the existing dialplan, call routing and call flows to be able to implement the caller ID blocking feature. The administrator must understand Partitions, Calling Search Spaces and Translation Patterns.

3. Call flow:

Traditionally, when calls arrive in the Cisco Unified Communications Manager environment, the call is processed based on the called party with no routing decision made on the calling party number.  Starting in Cisco Unified Communications Manager v8.0, by using familiar call routing techniques, an administrator can now match and deny a call into their system based on the calling party number as well as the called number.

image1.png

In CUCM 8.0, there is a new parameter on Translation Patterns called “Route Next Hop By Calling Party Number”.   After matching an inbound Translation Pattern that has the “Route Next Hop by Calling Party Number” check box selected, CUCM will perform digit analysis on the calling party number and thus allow the administrator the ability to block the call if matched (in order for the restricted calling party feature to work, all target directory numbers must be contained in a partition reachable through a Calling Search Space. The called number cannot be in the <none> partition.)

If the calling party number does not match a Translation Pattern number to block, then CUCM will continue processing the call and route the call to the destination directory number.

4. Configuration:

Only a few Partitions and Calling Search Spaces are necessary to create a call blocking “Filter list” of calling numbers.  See Figure 1 above for call flow.

1)      Create two Partitions called ‘Inbound_Calls’ and ‘Filter_List’.

2)      Create two Calling Search Spaces called ‘Gateways’ and ‘To_Filter_List’.

3)      Add ‘Inbound_Calls’ partition into the ‘Gateways’ Calling Search Space.

NOTE: The ‘Gateways’ Calling Search Space must not contain any partitions that contain directory numbers, otherwise, calls will be routed directly rather than through the calling party filters.

4)      Add the ‘Filter_List’ partition to the ‘To_Filter_List’ Calling Search Space.

5)      Create a Translation Pattern ! in the ‘Inbound_Calls’ Partition. Set the Calling Search Space to ‘To_Filter_List’ and check the ‘Route Next Hop By Calling Party’.

NOTE: The ! pattern is used to match all incoming called parties in order to route the calls into the ‘Filter_List’ Partition for calling party matching.

image2.png

6)      Create a Translation Pattern ! in the ‘Filter_List’ Partition. Set the Calling Search Space to route non-blocked calls to their destination.
The ! in the ‘Filter_List’ Partition is used to route any calling party number that is not specifically defined as a blocked number . The Calling Search Space routes the call back to the phone’s partition for normal call routing

image3.png

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.

image4.png

8)      Using normal pattern matching, create Translation Patterns to match calling party numbers you want to block. To block all calls that have a calling party number beginning with 800, create a Translation Pattern of 800! in the Filter_List Partition. Set the Route Option to ‘Block this pattern’ with the desired reason code.

image5.png

Alternatively, instead of outright rejecting a call, the administrator can configure a directory number in the ‘Called party transform Mask’ field which will allow calls to be redirected to a specific DN.   For example, an administrator can send calls to an Auto Attendant with a message indicating their call has been blocked or rejected.

9)      The last step is to assign the ‘Gateways’ Calling Search Space to any ingress gateway that will be blocking inbound calls based on calling party identification (H323, MGCP or SIP trunk).

5. Adding Call Blocking Based on Calling Party ID to an existing system:

Customers that already have a dialplan in place that want to add Call Blocking based on Calling Party can easily do so. When a call arrives in Communication Manager from a gateway or trunk, the call is routed based on the Calling Search Space assigned to that gateway or trunk.   Following the configuration steps above, an administrator can set up the global translate and blocked number Partitions through step 8 without affecting call processing in the system. But the last step should be done after hours or during a maintenance window because after the change to a Calling Search Space, the trunk or gateway must be reset to have the changes take effect.

Blocking "anonymous" calls over a SIP trunk:

With the rapid adoption of SIP trunks, an anonymosu caller will actually have the words "anonymous" or "unavailabe" in the From: header.  Cisco Unified Communications Manager digit analysis engine is not designed to match on non-numeric strings, so the name anonymous would be passed as a valid string.  To correctly identify and block anonymous or unavailable callers, apply the anonymous_clid.lua script to any SIP trunk that recieves call that you want to block anonymous calls.  Instructions for use are included in the script itself.

Average Rating: 5 (10 ratings)

Comments

kasiva_1987 Mon, 01/23/2012 - 06:24

Hi,

Nice doc. Thanks for the explanation. I would like to understand the below point and I do not think it is necessary for the called number to have a partion . Please explain me if I'm wrong.

"(in order for the restricted calling party feature to work, all target directory numbers must be contained in a partition reachable through a Calling Search Space. The called number cannot be in the <none> partition.)"

Thx!

dakeller Mon, 01/23/2012 - 10:02 (reply to kasiva_1987)

Kasiraman,

This comment was added after the intial publishing of this document, but I can still explain. Becaues the <none> partition is available to all calling devices, if the called party numbers are reachable in the <none> partition this will lead to unepxected call routing.   So when a call comes in over a PRI for a number that is defined on a phone, DA will return the number on the phone as the destination since it is a better match than the ! pattern.  So the phone will ring.  In order to use the blocking feature in this document, all phone DN's must be in a partition that is accessible after going through the blocked number partition to prevent direct call routing.  

If you need more informaiton or this does not answer your specific question, please ask your question again and I will respond. 

Thanks,

Dan Keller

Technical Marketing Engineer

evangaever Mon, 03/12/2012 - 07:51

Hi,

If I'm not mistaking, a translation pattern is always checking the "Called number" and not the "Calling number". In that sence the procedure would not work when you are trying to block incomming caller IDs. Or am I missing something?

Thanks for explaining this,

Erik

dakeller Mon, 03/12/2012 - 09:34 (reply to evangaever)

Erik,

In CUCM, there was a new parameter added to a translation pattern that would allow you to 'route next hop by calling party number' box.  This parameter was added to identify secure endpoint calling, but after testing, the implementation of this feature allowed it to be used to block calls based on calling party number.  From the call processing standpoint, CUCM send the calling party number to digit analysis for a match instead of the called party.  The returned match will be a translation pattern that is set to 'block' the call.  What's nice about this new parameter is that instead of forcing the block to occur on an H323 gateway, the blocking logic can be done on the CUCM itself.  So the docs title is accurate for the function it provides.

Thanks,

Dan Keller

Technical Marketing Engineer

troyputnam Fri, 03/23/2012 - 12:38

Hi,

I tried this setup on a POTS line to a FXO card on the router.  I followed the setup steps and assigned the "gateways" CSS to my FXO port config.  I reset the FXO port and tested.  The translation pattern I configured to be blocked was my cell phone number.  When I call the number assigned to the FXO port from my cell the call go's thru and show a caller ID number of 0. 

Any idea where I am in error or does this not work on an FXO (mgcp) port. 

dakeller Fri, 03/23/2012 - 13:49 (reply to troyputnam)

Troy,

First off, does the FXO port accept CLID?  Were you were getting caller ID in the past?  If yes to both, what I will need from you is to turn on the tracing on the CUCM, recieve a call on the port, then send me the SDI trace output from the CUCM.  Include time of day, calling/called party and the block pattern you have defined and I will see if I can determine why it's not working the way you expect it to be working.

Thasnks,

Dan Keller

Technical Marketing Engineer

troyputnam Mon, 03/26/2012 - 06:27 (reply to dakeller)

Yes, with CUCM 8 and above, there is now a "enable Caller ID" check box for the FXO port.  I have that checked and reset the port.  I also have it enabled on the CLID for that port.  I will work on providing you the SDI trace information sometime today.  Thank you for your help!

chryuen Wed, 03/28/2012 - 10:33

Ran into an issue with this while trying to implement e164 calling party transformations.  Calling party ID based blocking would not work if I prefixed +1 or + to inbound calls.  And it didn't matter whether I prefixed it using calling party transformation patterns or using IOS voice translation rules.

Found that you need to have \+! translations patterns in the 'Inbound_Calls' and 'Filter_List' partitions.  And blocked calls would need to start with \+.  If you don't include that, then those calls will not get blocked.

juniper76_2 Wed, 05/16/2012 - 06:47

Hi,

I need to implement this for my contact centre which has calls delivered via an MGCP gateway. To complicate matters i also have 2 H323 gateways within the cluster! By configuring this in Call Manager for the MGCP gateway am i likely to cause any issues on the H323 side of the fence?!

I don't need to block calls based on the the ANI for devices that receive calls via the H323 gateways, just the contact centre!

dakeller Wed, 05/16/2012 - 07:20 (reply to juniper76_2)

I'm not sure I understand the concern.  You would create the partition for the numbers you want to block, then change the CSS on the gateways you want to block calls on.  So in your case, just change the CSS of the MGCP GW to route through the caller id blocking partition, but leave the H323 GW's with the CSS to reach phones directly. 

Thanks,

Dan Keller

Technical Marketing Engineer

Onojetathekid Wed, 08/15/2012 - 10:26

This solution works great, my customer is very pleased with the ability to block incoming calls now.

Bryant

Systems Support Engineer

chryuen Fri, 11/16/2012 - 07:05

I ran into an issue the other day where inbound 'anonymous' calls are being rejected.  I don't have any translation patterns to block, and I have the blank translation pattern that, if I understand it correctly, should've matched this and allowed it through.

Has anyone seen this or can anyone confirm if they've successfully received inbound 'anonymous' calls?

Thanks in advance!

dakeller Fri, 11/16/2012 - 07:18 (reply to chryuen)

Christopher,

I ran into this very early on and I do have a solution.  I will send you a LUA script that will allow you to identify and deny anonymous callers.  I expect to include the LUA script as part of this app note after a bit more field exposure. 

Thanks,

Dan Keller

Technical Marketing Engineer

chryuen Fri, 11/16/2012 - 07:21 (reply to dakeller)

Dan,

Thanks...I appreciate that.

One thing though...the issue I'm seeing is that 'anonymous' calls are being blocked but I don't want them to be.  I don't have any block patterns at all, yet these calls are being blocked.

dakeller Fri, 11/16/2012 - 07:48 (reply to chryuen)

Christopher,

I read it the other way around.  What patterns do you have defined that you are blocking?  In the configuraiton above where you have the <NULL> and ! patterns as allowed, the anonymous tag will actually match the ! and continue throught for call routing.  Unless you have something different set up, anonymous will work out of the box.  Please email me directly so I can get some specifics on what you are seeing.

Thanks,

Dan Keller

Technical Marketing Engineer

dakeller Fri, 11/16/2012 - 07:36 (reply to dakeller)

Christopher,

Actually, I've had enough feedback that the lua script works and does not cause any adverse affects to call processing.   I have added the lua script to this posting. Just download and deploy.  Please let me know how how effective this solution is for you.

Thanks,

Dan Keller

Technical Marketing Engineer

JMistrot1 Thu, 12/06/2012 - 18:59

Wondering if anyone has implemented this but run into an issue where calls that are ultmately bound for a CTI routepoint to UCCX get rejected.  I just opened a TAC case around this.  I used this page to build my implmentation plan and everything seemed fine until later in the morning we discovered that DNs inbound from the GWs bound for a CTI RP and UCCX trigger get rejected everytime.

dakeller Thu, 12/06/2012 - 20:30 (reply to JMistrot1)

Jerry,

Unless you change the calling party number to something that UCCX does not accept, the call egressing from the 'route next hop by calling party number'  will look like any other call.  Since I am the author of this doc, I am very interested in seeing what is happening.  I could not find the TAC Case, so can you forward me the SR number and hopefully there will be a trace file for me to look at.  Let's take the troubleshooting off line and I will update this thread when I figure out the issue.

Thanks,

Dan Keller

Technical Marketing Engineer

chryuen Fri, 12/07/2012 - 03:58 (reply to JMistrot1)

Jerry,

Are your CTI RP's and ports in a different partition from your phone DN's?  You may want to double-check the CSS that you have applied to the translation patterns that allow the calls in to make sure they can hit both the CTI RP and the CTI ports themselves.

fergus.w Mon, 12/17/2012 - 16:57

Hi Dan,

I think the CTI issue is summed up well in the "Cisco Unified Attendant Console Troubleshooting Guide v8.6.x". (www.cisco.com/en/US/docs/.../CiscoTSGv8_6_x.pdf).

On page 2-8 it mentions:

"As CUxAC uses TSP and CTI to move calls, the function of CTI Redirect performed on the call forces it to inherit the CSS of the gateway which does not always allow calls to all phones. Modify the gateway CSS to accommodate this and resolve the problem"

My understanding is this means the gateway CSS needs access to the Route Points, CTI Ports and Agent Phones.  That is to say, CTI/TSP connectivity doesn't honour any CSS changes through translation patterns as the redirect uses the original device's CSS.  Certainly this has been my experience since CCM 3.2.

Unfortunately this would then mean any calls to a CTI/TSP connected system could not use the flow to block on CLI as the gateway CSS prohibits access to any other partition than the initial "!" tranlsation pattern, and hence prevents the redirect to the CTI/TSP devices.

It would be ideal if CTI could be reworked to honour changes in CSS through translations, but until that time, I suspect we're limited in how we can apply some of the more interesting dial plan features.

Hopefully I'm mistaken and things work differently to how I think.

Thanks,

Fergus.

dakeller Thu, 12/20/2012 - 06:50 (reply to fergus.w)

Fergus,

You understanding is correct. By default, on a redirect, the CSS of the calling device (GW or Phone) is used to redirect the call.  The CTI application can set the redirect CSS to use, but only the CTI application can do this. You cannot set this behavior at the CUCM level. 

Thanks,

Dan Keller

Technical Marketing Engineer

robburlingame Tue, 04/09/2013 - 07:33

Dan,

I'm with Christopher on this one. We implemented this and "anonymous" and "unavailable" callers get blocked. This is due to the fact that translation patterns only recognize certain numbers and characters. They only recognize the following alphabetic characters: A,B,C,D (capital only)

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmsys/a03rp.html#wp1043633

I realize the above article is dated, but, I can't find anything to the contrary.

Thanks,

Robert

markjpurdy3316 Fri, 04/12/2013 - 11:18

Dan, I've also run into this configuration issue.   It appears because I am filtering on SIP trunks, the <null> translation does not allow "restricted", "anonymous," and unknown strings to pass.   Since SIP does not recognize the various dial plan types as does MGCP,  what options do I have other than some CUBE configuration.   I want to pass these anonymous calls thru.    How would your script work for this instance?  

dakeller Thu, 04/18/2013 - 07:55 (reply to markjpurdy3316)

The original configuration that automatically passed 'restricted' and 'anonymous' calls does not appear to work on all versions.  I am currently working on a way to simplify and ensure no version dependencies.  

So I would appreciate some feedback from the community on how you use this feature and how you would like the issue solved.

1) When blocking incoming calls with no number, specifically calls listed as 'restricted', 'unavailable', 'anonymous' or no numbers at all, will all 5 be treated the same?  Are you planning to block all 3 calls or would you plan to allow 'restricted', but deny the other 3?  Do you want the ability to treat the different types of anonymous callers uniquely?

2) If you plan on passing anonymous callers to your users, what do you expect to see on the display of the called phone?  Do you require differentiation of 'restricted' vs 'anonymous' vs 'unavailable'?  Would it be acceptable to classify all 3 to display the same?  Also, would it be acceptable to make all 3 appear as 'restricted'?

Please provide the feedback to me directly in a private message so I can work on the solution. 

Thanks,

Dan Keller

Technical Marketing Engineer

tm54189873 Thu, 05/30/2013 - 06:19 (reply to dakeller)

Dan,

In response to "the original configuration..does not appear to work on all versions", could you please specify which versions have been tested that Route Next Hop By Calling Party Number has been validated on?

We have an urgent need to implement the block incoming calls based on ANI, using this new TP feature, but also need to pass both 'restricted' and 'anonymous' calls like Christopher, Mark and Stuart have described.  We are running version 8.6.2.20000-2 and hesitate moving forward with this implementation without validation since it will cause an impact by blocking these sourced calls.

In the interim I'll email you directly as requested indicating our preferences on your #1 and 2 inquiries in efforts to engineer a solution for all versions.

Thanks,

Trent

dakeller Thu, 05/30/2013 - 07:36 (reply to tm54189873)

It's been quite some time since I did this script.  I thought I had written it against 8.5, but obviously I had not because it does not work in my retest.  So I might have tested 8.6, but  I cannot commit to that right now. This script does work on 9.x because Cisco added URI dialing capability to the digit analysis which means it could now handle alpha characters along with the 0-9*#ABCD. 

There was an addition to the original script that stripped the anonymous/unavailable/restricted that would allow the call to pass for all versions. 

I am working on newer version of the script so simplify the logic, but given my current workload, I do not see it getting coded, documented, tested and posted until July.

Thanks,

Dan Keller

Technical Marketing Engineer

gsimon@cisco Wed, 07/24/2013 - 11:59 (reply to dakeller)

Hi Dan,

Is the issue with restricted callerID calls not being allowed, specifically for SIP calls or it's happening for PRI as well?

Also is the null pattern required for ISDN or it's just for SIP?

Thanks,

Ginesh

dakeller Wed, 07/24/2013 - 13:20 (reply to gsimon@cisco)

Ginesh,

Yes, the <NULL> pattern is needed if you want to pass a call that does not have a calling party.  This is very true for ISDN, but SIP trunks might be different because they will send 'Restricted' or 'anonymous', which will not match a number, so that is why I have included a script to handle these types of calling number.

Thanks,

Dan Keller

Technical Marketing Engineer

goku-sun Sun, 09/15/2013 - 11:15 (reply to dakeller)

Hi dakeller,

May I know the details of workaround for sending a call without calling ID via null translation. I met the same problem and is urgently seeking solution on this.

Many Thanks,

Goku

dakeller Mon, 09/16/2013 - 07:18 (reply to goku-sun)

Goku,

There is a lot of information missing to be able to answer your question.  What is the protocol into CUCM?  Do you have a Gateway or Trunk?  Are you looking to block NULL caller id's or do you want them to pass?  If you provide the details, I can provide guidance on how to correct the call flow to make this work.

Thanks,

Dan Keller

Technical Marketing Engineer

goku-sun Tue, 09/17/2013 - 11:48 (reply to dakeller)

Hi dakeller,

Thanks for your quick response. Please see the background below:

1) An etraIi PBX is interfaced to a new MGCP GW via QSIG links. With other MGCP GWs connected to 2 different Telcos "A" & "B", all under CUCM 8.6. For voice mails, the Etrali phones will access an ext (say "5000") and it directs the call to the CUC 9.X as no answer call fwd or all call fwd, with corresponding ext defined in the CUC.

2) The translations are used identify the calling ID from PBX and route calls to appropriate CSS's towards T1s of telco "A" and telco, say, 2XXX = DDIs of telco "A"; 6XXX = DDIs of telco "B"

3) All are worknig fine now after CPN is set up for all extensions from the PBX. Except that if a call orginates from PSTN, the call will drop after ringing some time if no answer or via call forward to the voice mail extension. If the call originates from another Etrali ext, voice mail can be left. If the translations are not used(then outgoing call from 6XXX will display as prime # of telco "A"), voice mail can be left from PSTN and extensions.  Is there anything altered after transation is done?

Etrali phones (2XXX, 6XXX) <-> Etrali PBX <->  QSIG links <-> Cisco MGCP VG  <->  CUCM <-> Cisco phones / PSTN (other MGCP GWs to different telcos, 8888-2XXX for telco "A", 9999-6XXX for telco "B")

Config (CUCM 8.6.1)

0) A MGCP VG is installed with QSIG links to interface PBX and CUCM, the partition of QSIG link is "PT_Etrali_incoming".  Another partition as "PT_Etrali_Translation". CSS's with "CSS_Etrali_incoming" and "CSS_Etrali_Translation" are created to include the partitions just mentioned respectively

A) A translation pattern defined as "!" with partition = "PT_Etrali_inoming" for the QSIG link of MGCP VG, CSS is "CSS_Etrali_translation". Option "Route Net Hop by Calling Party Number" is also CHECKED

B) 2nd translation = "2XXX", partition = "PT_Etrai_incoming" and CSS = "CSS_Etrali_Telco_A". This to route  2XXX call to Cisco ext or PSTN via telco "A" (to display his CLI to PSTN instead of incorrect prime# or unknown# )

C) 3rd translation = "6XXX", partition = "PT_Etrai_incoming" and CSS = "CSS_Etrali_Telco_B". This to route  6XXX call to Cisco ext or PSTN via telco "B"  (to display his CLI to PSTN instead of incorrect prime# or unknown# )

Many thanks,

Goku

dakeller Wed, 09/18/2013 - 12:28 (reply to goku-sun)

Goku,

I have read the configuration that you have set up and understand that the issue is calls from the PSTN will drop if the call is CFNA to voice mail.  But one item that is missing is the call flow.  Something like 'call arrives from telcoA, routed to Entrali PBX, CFNA back to CUCM to reach CUC'.  If the flow is like this, then there are 2 potential issues.  The first is that the calling party number is a PSTN number and the Xlate patterns you have for the Entrali trunk don't match to route the call to CUC.  The other choice is that the xlate pattern is matching the external number, but the CSS of the matched xlate does not contain the partition for reaching CUC at 5000.

Thanks,

Dan Keller

Technical Marketing Engineer

Quickdraw2003 Thu, 04/25/2013 - 00:22

We tried this and had the same issue as Mark above. "restricted" and "anonymous" unkown calls do not pass when this is in place.

Has anyone figured out a workaround?

robburlingame Thu, 04/25/2013 - 05:30

TAC has worked with me to try the following on our CUBE (gateway device):

voice class sip-profiles 1

request INVITE sip-header From modify “Anonymous” “999”

!

!

dial-peer voice 1 voip

voice-class sip profiles 1

Note: We've not implemented this in production yet, so, all warnings apply. However, we have modified the headers before and it seems to work as expected.

Robert

dakeller Thu, 08/08/2013 - 10:56 (reply to jjia@intesys-ncl.com)

The call will be recorded in CDR's even if it's rejected through this method.  You can find calls that are rejected based on the rejection type you have set at the xlate pattern.   But I must warn you that there is no special indication that a call was rejected by this configuration.  So if you set the rejected reason code to something like 'Number changed (one not commonly used in CUCM), then you can look at the CDRs to find that cause code to determine which calls were rejected through this configuration. 

Thanks,

Dan Keller

Technical Marketing Engineer

hydera Fri, 08/16/2013 - 09:40

Dan,

We have a user who is complaining that she is getting harassing calls from a particular caller. My questions is, is it possible to setup translation rule only for this user's extension instead of rule based on Calling party for the entire site?  We are running CUCM 9.1.1, I would like to know if I can match a call based on both a "Calling" and a "Called" party and then allow or reject it?

Thanks

Ali

dakeller Fri, 08/16/2013 - 11:39 (reply to hydera)

Ali,

If you look at the method by which the calls are passed to the xlates that will block the call, I use the ! value.  That means a call to any number matches.  If you want to block for a single person, the ingress GW can have an xlate that matches that person's number that will send the call to the block partion, then you can block it.  So even though you cannot block based on both calling and called party in the same operation, you can accomplish what you want to do relatively easily.

Thanks

Dan Keller

Technical Marketing Engineer

wdgarfield1 Sun, 09/08/2013 - 10:30

We are dealing with the Null callerID issue on the gateway router, using a voice translation-rule /^$/ to insert /0000000000/   In this way every call coming into the CUCM has some value appearing in the calling party field, even if it's a string of 10 zeroes. This allows these calls to pass through the callerID blocking without being blocked.

balhoura Mon, 10/07/2013 - 04:05

Hi Dan,

Thanks for the great document.

My customer runs CUCM version 8.5.1.10000-26. I have completed the steps on his system, after that I was able to block a certain caller but at the same time other callers were blocked.

I have recreated the issue in our lab CUCM version 8.6.2.23045-1 and found that the callers are not hitting the ! TP which is assigned to 'Filter_List' partition unless the prefix for the calling party in the incoming calls is configured.

Please find the attached picture:

if the system was configured as shown in the picture all other IP-Phones which are registered to CUCM 2 will not be able to dia 7070 IP-Phone, but if I configure prefix 6 at the calling party for incoming calls and modified the 8080 TP to be 68080 everything works properly (IP-Pone 8080 is blocked and all other IP-Phones are able to call 7070).

Please let me know why other IP-Phones were not hitting the ! TP ? and how should I proceed? CallBlock.png

ealeatherman@ma... Fri, 12/06/2013 - 06:30

Greetings,

I was wondering if the version dependencies/inconsistencies are still present in this feature with regards to restricted or anonymous caller id - particularly with CUCM 8.6(2). I'm doing some planning around implementing this blocking capability but I need to be able to permit these types of calls through. It seems based on comments above that there are still potentially some caveats for this.

Thank you for the excellent document and explanations by the way.

Thanks!

Ed

dakeller Wed, 01/08/2014 - 15:05 (reply to ealeatherman@ma...)

Ed,

When referring to dependencies/inconsistencies, the only interface that I saw was different was the SIP Trunks. PRI and H323 behaved the same on both versions.   So the difference between 8.6(x) and 9.0 was the fact that URI dialing was added to call control in 9.x.  This altered how non-numeric addressed were handled and I believe this change was the cause of the inconsistencies that were observed between versions.  I have tested the blocking based on caller ID over SIP trunks in the 8.6(x) version and the 9.x version and have been able to achieve the desired results in both cases. 

Hope that helps.

Thanks,

Dan Keller

Technical Marketing Engineer

mathewvarghese325 Sun, 01/05/2014 - 08:03

In paralle, to achieve blocking feature for a single user, can we perform access restriction in CSS level of Translation Patterns.

ie. for the ! and null TP's, use CSS to all internal extensions

     for blocking TP, route the pattern and put CSS with all internal extension minus the one phone under question !!!

Could not test this setup, appreciate any responses.

-mathew

dakeller Wed, 01/08/2014 - 15:10 (reply to mathewvarghese325)

Matthew,

To block calls to a specific user, you can specify the xlate pattern as the destination DN of that user, then send those calls to the block partition, all other calls can go straight to the users.  The point of the ! xlate pattern on inbound is to 1) collect all inbound calls to any number 2) set the 'route next hop by calling party number'.  So the application note was written to send all calls to be filtered.  If you want specific users to have anonymous calls blocked, then the xlate pattern at the GW level should include only those users you want to block calls for.

Hopefully that answers your question.  If not, repost and I will reply.

Thanks,

Dan Keller

Technical Marketing Engineer

jeremiah88 Tue, 01/21/2014 - 18:48

Great article Dan!  Thanks for the script too, ultimately your script is the only thing I could get to work with SIP PSTN---SIP CUCM...  I tried using a SIP Profile (TAC even wrote it for me):

voice class sip-profiles 100

request ANY sip-header From modify "Anonymous(.*)" "1234567890\1"

request ANY sip-header From modify "anonymous(.*)" "1234567890\1"

request ANY sip-header Remote-Party-ID modify "Anonymous(.*)" "1234567890\1"

request ANY sip-header Remote-Party-ID modify "anonymous(.*)" "1234567890\1"

But since I had routing based on CPN setup in CUCM (as per instructions in this blog), call still would not get through...Finallly, I applied your script, and it worked!

Many thanks!

ptierce Mon, 04/14/2014 - 12:19 (reply to jeremiah88)

We found that those directives only change the name.... not the incoming number.  We got it to work by modifying the actual number that we found in the debug.  This is what actually got it to work for us.  We change the "anonymous" or "Restricted" to a series of 10 zeroes so we could also block anonymous incoming if we choose to by blocking the "0000000000" in the translations mentioned above.  Verizon and Sprint and TMobile all use one of those words in the SIP header.  Here's what we found actually works:

request ANY sip-header From modify "sip:anonymous(.*)" "sip:0000000000\1"
 request ANY sip-header From modify "sip:Anonymous(.*)" "sip:0000000000\1"
 request ANY sip-header From modify "sip:Restricted(.*)" "sip:0000000000\1"

 

If you do a debug, you'll see the header looks a bit different from what you were probably expecting.  Hope this helps!


 

jgoddard Wed, 01/22/2014 - 11:18

Hi Dan,

I found your document and call flow configuration very straight forward and it works well for us. Inbound calls to DNs that are in PT-Internal route normally as expected.  Some of our DNs however are assigned to the <None> partition. Inbound calls to a DN that is the <None> Partition seem to be blocked or simply do not get completed.

These DNs in the <None> Partition are IPCC extensions.

The CUCM System Guide states that

"Before you configure any partitions or calling search spaces, all directory numbers (DN) reside in a special partition named <None>, and all devices are assigned a calling search space also named <None>. When you create custom partitions and calling search spaces, any calling search space that you create also contains the <None> partition, while the <None> calling search space contains only the <None> partition."

Do you have any thought as to why a call from the outside throught the gateway to a DN in the <None> partition would be unsuccessful with the configured call flow in Figure 1 above?

dakeller Thu, 01/30/2014 - 08:10 (reply to jgoddard)

Jeffery, thanks for the feedback on the document.  After reviewing the information you provided, the only reason I could figure that the calls would be unsuccessful in extending the call to the IPCC extensions in the <none> partition could be caused by the fact that the redirect from CTI (I'm assuming IPCC agent has call delivery from an IVR) uses the CSS of the source device (the ingress GW) and instead of matching the IPCC extension directly, the GW is going through the call blocking logic a second time and failing.  There has been special consideration for IPCC agent extensions that the partitions that hold the IPCC agent extensions be defined in the ingress GW CSS.  Althought I would expect the call to match the IPCC extension in the <none> partition, it sounds like the ! takes precedence and prevents the call from completing.

Thanks,

Dan Keller

Technical Marketing Engineer

nanosynth Thu, 02/13/2014 - 12:49

I applied this procedure to CUCM 8.6.2 with a SIP gateway and it worked just perfect..for blocking the numbers like it shoud. The problem is, now when I dial out from the Call Manager to any outside number or inside extension, the interdigit timeout is invoked. The call out just sits untill timeout then rings out fine. It didn't do this before I applied this procedure. Any thoughts?

dakeller Thu, 02/13/2014 - 15:40 (reply to nanosynth)

This problem will occur when the phones can find the ! translation pattern in their CSS.  Please make sure that the partition that has the ! for inbound calls is not available to phones for outbound calls.  That is why the document recommends creating a new partition specifically for the !.  That way the phone's CSS do not have to change but the inbound gateways (MGCP, SIP, H323) just have to point to the new partition and everything will work just like before, only you can block inbound calls.

Thanks,

Dan Keller

Technical Marketing Engineer

Actions

Login or Register to take actions

This Document

Posted September 7, 2011 at 12:29 PM
Stats:
Comments:55 Avg. Rating:5
Views:34065 Contributors:27
Shares:0

Related Content

Documents Leaderboard