Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Block Incoming number to all users 6

Status
Not open for further replies.

Cambece

Technical User
Nov 9, 2005
5
US
Hello,

I was wondering if there is a way to build an incoming route that would block a number to all of the incoming routes. We have several locations and a total of 600 routes. So short of building individual routes to block the number I was wondering if there is a way I could do this so it applies to all of our routes.

I have tried to leave the incoming number blank and just fill in the caller id and set the destination to a busy short code but that did not work. Any ideas would be appreciated.

Thanks
 
Yes, absolutely.

INCOMING CALL ROUTING. Normally this is used for inbound DID translation, but you can also number-match to treat certain area codes, office codes, specific numbers with different treatment.

You can input the Caller ID and set it specifically to go to something that plays busy signal (perhaps a shortcode with the feature set to CANCEL OR DENY.

Hope this helps...

Kris G.
 
Thank you for the quick reply, instead of leaving the incoming number blank I entered a * and that seems to work.

Thanks again.
 
Nope, tested it out and everything seems to work. Thanks for the concern though.
 
I'm confused. How does a * tell it a specific number? If you're trying to block specific numbers, you need to tell it what numbers you want to block.

Kris G.
 
The * is for all calls when using ananalog lines. Then you use the "incoming caller id" field to block calls with a certain caller id information.

We have a few routes to block a few people that directs the incoming call to a voicemail pro module I named "discon" that is simply a Start Point--->Disconnect

I also have all incoming calls with no caller id go directly to our auto attendant.

We get a LOT less solicitation calls now. :)
 
I had completly forgoten about using * as the incomming number along with the CLI field so I think that is worth a *
 
Would this work on PRI lines in the UK??

Lets say we have 150 DDI's progrmmed to individual users.

Can we block one i/c CLI by adding one route with a * s the i/c DDI and the CLI to be blocked.

When I have needed this before, I have added the CLI to every IC call route so I had each DDI programmed twice. one for CLI block and one for user.

Jamie Green

Fooball is not a matter of life and death-It is far more important!!!!
 
Can we block one i/c CLI by adding one route with a * s the i/c DDI and the CLI to be blocked.

IIRC (and will check) the incoming number (DDI digits) is matched before the CLI is checked so you will need 2 routes per ddi

Take Care

Matt
If at first you don't succeed, skydiving is not for you.
 
That is what I thought.

Thanks anyway

Jamie Green

Fooball is not a matter of life and death-It is far more important!!!!
 
I havnt tested but if it is working for cambeece it should still work in UK

I would recommend giving it a test on a "tame" system.
if you can do that before I get a chance it will be worth another *
 
Here is one for giggles.
route the ICR for the specified CLID to a user that transfers the call to the number you are blocking. Whenever they try to call, they will be transferred externaly to themselves.
OK, maybe more fun than practical.



You do not always get what you pay for, but you never get what you do not pay for.
 
I am searching because I have a similiar situation. An ex of one of the employees is making harrassing inbound calls to random numbers within our DID block and I have been instructed to block these at the switch if possible. So, I created a dummy user and directed via ICR, calls from him to the dummy CallBlock user which unconditionally forwarded them back to one of his own numbers he dials from. If the home number directs to the cell and vice-versa. Actually I created CallBlock1 and CallBlock2 users to do that. Worked great until he figured out he can dial *67 and block his CID, thus negating the ICR rules. Are there any negative possibilities to creating a rule such as this:

ICR: *
Incoming Caller ID:
Destination: CallBlock user port

Would the proper syntax be to leave the Incoming Caller ID blank to match a WITHHELD cid or could you use "" or <NULL>. Or is the whole concept flawed to start with?
 
Check out !, and ? for incoming CLID field in ICR. The help file below lists this information.

I would route the call via ICR to a receptionist. The receptionist should be bale to recognize the voice at some point, and then put the caller on hold indefinitely. This will probably discourage the caller most effeftively to waste his time on hold.
I hope this helps.


Incoming Caller ID:
Enter a number to match the caller's ICLID provided with the call. This field is matched left-to-right. Number options are:

Full telephone number.

Partial telephone number, for example just the area code.

! : Matches calls where the ICLID was withheld.

? : for number unavailable.

Blank for all.

Note: To match on just the Incoming Caller ID, use a * in the Incoming Number field and leave the Incoming Sub Address blank.

Bearer Capability:



You do not always get what you pay for, but you never get what you do not pay for.
 
Thanks, I had applied the block by creating a CallBlock user with the Incoming Caller ID: blank and saw that it took out the unknowns as well as the withheld ICLID's so I had deleted the ICR entry.

Using Incoming Caller ID: ! ...works just as we wanted. The calling has now ceased, but I am thinking of leaving the rule for a while to test whether we might want to just leave it in place for good.
 
you might want to consider routing it to a person that can screen calls that did not send clid unintentionaly, or send to a aa that does not allow transfer to the emloyee in question. so you do not lose callers that for some real gliche did not send clid.

glad i could help, thanks for the reply on the resolution, that helps everyone.

You do not always get what you pay for, but you never get what you do not pay for.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top