News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Blocking Calls from 'Unknown'

Started by Uncle_Wiggley, July 28, 2014, 08:29:24 PM

Previous topic - Next topic

Uncle_Wiggley

I've been getting calls from 'Unknown' that I thought should have been blocked by this X_InboundCallRoute:

{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|anon@@.):}, {ph}

What am I missing?

ianobi

The rules in the X_InboundCallRoute look for a precise match with whatever appears in "Peer Number" in your Call History. In this case it may be the upper case "U" which is not matching the "un@@." rule. You could add "Un@@.":

{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|Un@@.|un@@.|anon@@.):},{ph}

A better rule is:

{(?|@|@@|@@@|@@@@|@@@@@|@@@@@@|@@@@@@@|anon@@.):},{ph}

@ matches any alphanumeric character. Therefore "@@@@@" would match "test1", "TEST1" etc. "@@@@@@@" would match "Unknown", "unknown", "UNKNOWN" etc. This assumes that you do not have legitimate seven character CallerIDs that you wish to accept calls from.

The best defence against the SIP scanners in most situations is to use the "Oleg method". A search in this forum will show examples.


Uncle_Wiggley

So I'm still getting these calls coming through and I'm not sure why.

Here is the call log entry: From 'Unavailable' SP2(4069982212)

And here is the Incoming Call Route: {(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.):}, {ph}

Why is this call getting through?


Taoman

Is there a reason you're not using the "Oleg method" as ianobi mentioned?

azrobert

There are 2 types of annoying calls. The first is scanner calls. These calls come over the internet using your public IP address and usually the standard port numbers 506x. You are blocking them based on a non-standard CallerID. The Oleg method allows only calls from your provider, therefore it blocks these scanner calls. Another method is to change the OBi port number (X_UserAgentPort) to a non-standard number.

The second type is telemarketing calls. These calls come thru your provider when they call your DID and cannot be blocked using the above techniques. 

You said:
QuoteHere is the call log entry: From 'Unavailable' SP2(4069982212)

I think "Unavailable" is the Caller Name and "4069982212" is the CallerID. This looks like a telemarketing call and you cannot block calls based on Caller Name. I don't answer calls I think are telemarketing. If they call 2 or 3 times without leaving a message I will add their CallerID to a blocking list. Some providers like Callcentric have a feature that blocks these calls.

Uncle_Wiggley

Quote from: Taoman on August 01, 2014, 07:01:27 PM
Is there a reason you're not using the "Oleg method" as ianobi mentioned?

Yes, I tried it and it doesn't work for me. I assume that my provider, Future-Nine, doesn't support that.

Uncle_Wiggley

Quote from: azrobert on August 01, 2014, 10:22:31 PM
There are 2 types of annoying calls. The first is scanner calls. These calls come over the internet using your public IP address and usually the standard port numbers 506x. You are blocking them based on a non-standard CallerID. The Oleg method allows only calls from your provider, therefore it blocks these scanner calls. Another method is to change the OBi port number (X_UserAgentPort) to a non-standard number.

The second type is telemarketing calls. These calls come thru your provider when they call your DID and cannot be blocked using the above techniques. 

You said:
QuoteHere is the call log entry: From 'Unavailable' SP2(4069982212)

I think "Unavailable" is the Caller Name and "4069982212" is the CallerID. This looks like a telemarketing call and you cannot block calls based on Caller Name. I don't answer calls I think are telemarketing. If they call 2 or 3 times without leaving a message I will add their CallerID to a blocking list. Some providers like Callcentric have a feature that blocks these calls.


I have changed the port number to a non-standard one.

I didn't know that you couldn't block based on Caller Name so now it makes sense. I wonder why that isn't a supported feature as it seems it would be very useful.

Dandy

Here are the instructions:

Anonymous Call Block

Anonymous Call Block allows you to block calls from incoming callers when there is no identifying caller ID name or number.� Incoming calls will be presented with a busy signal.� To use Anonymous Call Block, from the phone attached to the OBi, dial *77.� To cancel Anonymous Call Block, from the phone attached to the OBi, dial *87.

Uncle_Wiggley

Having trouble trying to block CIDs via User Defined Digit Map

X_InboundCallRoute:

{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.|MTelemarketers):}, {ph}

User Defined Digit Map2:

Label: Telemarketers
DigitMap: (1234567890|0987654321)

If I call 1234567890, it rings the phone (ph), but should not.

What's wrong?

ianobi

The problem is the label "Telemarketers" contains reserved characters. In a digit map you can use any combination of 0-9,*,#,+,-,A-Z,a-z, except m, M, s, S, x, X which have special meaning in the digit map syntax.

You can overcome this by enclosing the reserved characters in single apostrophes, but much easier to use a label with no reserved characters. How about:

Label: ban
DigitMap: (1234567890|0987654321)

X_InboundCallRoute:
{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.|Mban):},{ph}


Uncle_Wiggley

Quote from: ianobi on August 09, 2014, 05:57:44 AM
The problem is the label "Telemarketers" contains reserved characters. In a digit map you can use any combination of 0-9,*,#,+,-,A-Z,a-z, except m, M, s, S, x, X which have special meaning in the digit map syntax.

You can overcome this by enclosing the reserved characters in single apostrophes, but much easier to use a label with no reserved characters. How about:

Label: ban
DigitMap: (1234567890|0987654321)

X_InboundCallRoute:
{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.|Mban):},{ph}



That was the problem!

Thanks for the help.

ipse

Quote from: ianobi on August 09, 2014, 05:57:44 AM
The problem is the label "Telemarketers" contains reserved characters. In a digit map you can use any combination of 0-9,*,#,+,-,A-Z,a-z, except m, M, s, S, x, X which have special meaning in the digit map syntax.

Dammit....I had this label configured for a year now and always wondered why it doesn't work...had to put all kind of conditions and block in my Anveo IVR. I guess I should have RTFM.

Thank you ianobi...another life saver from you :)
Of all the things I lost, I miss my mind the most. - Mark Twain

Uncle_Wiggley

So changing the label name works in general, but I still have a call listed in my 'Ban' list that gets through.

In the Obi Call History, I see: From 'Unavailable' SP2(1234567890)

In my User Defined Digit Map2 I have:

Label: Ban
DigitMap: (x.1234567890|x.0987654321)

In my X_InboundCallRoute:
{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.|MBan):},{ph}

But I still get ring throughs on ph from 1234567890.

How is that happening?

If I put my cell phone number in the Ban list and then call from my cell phone, I get sent to VM as expected.

azrobert

Try this:
{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.|(MBan)):},{ph}

MBan not enclosed in parentheses did not work for me.

Your Ban list will work, but IMHO this is better:
(1?1234567890|1?0987654321)

ianobi

I could be sliding from hero to zero rapidly here   :-[

There's a mistake in my Reply #9. MBan is a digit map and needs to be enclosed in its own parentheses even though it's already in another digit map. It should be:

{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|Un@@.|anon@@.|Anon@@.|(MBan)):},{ph}

I'm surprised it worked at all. It's all about punctuation ...

Was just posting the above when saw azrobert's post   :)

ipse

Quote from: ianobi on August 09, 2014, 05:57:44 AM
The problem is the label "Telemarketers" contains reserved characters. In a digit map you can use any combination of 0-9,*,#,+,-,A-Z,a-z, except m, M, s, S, x, X which have special meaning in the digit map syntax.

Hate to harp on this, but the default label "ste" contains a reserved character...is it working because it's a system default (maybe hardcoded and not parsed)?
I am embarrassed to find problems with my digitmaps after 1 year....I admit to using some suggestions from this forum that might not have come from the gurus.
Of all the things I lost, I miss my mind the most. - Mark Twain

InetUser

Quote from: ipse on August 18, 2014, 11:31:52 AM
Quote from: ianobi on August 09, 2014, 05:57:44 AM
The problem is the label "Telemarketers" contains reserved characters. In a digit map you can use any combination of 0-9,*,#,+,-,A-Z,a-z, except m, M, s, S, x, X which have special meaning in the digit map syntax.
Hate to harp on this, but the default label "ste" contains a reserved character...is it working because it's a system default (maybe hardcoded and not parsed)?
Labels do NOT have reserved characters (m, M, s, S, x, X).  "ste" is NOT a system default label (it's a user defined label for Seven/Ten/Eleven) and works because labels do NOT have reserved characters.

ianobi

I apologise for the confusion. The original problem in Reply #8 was most likely caused by the label "MTelemarketers" not being enclosed in its own parentheses.

@ InetUser - I agree 99% with your comment regarding labels. The exception would be to avoid the upper case "M" in an actual label as anything following the "M" may be parsed as the label. We use many digit map labels with a lower case "s" in - Msp1, Msp2 etc. which does show that in most cases a label can contain a reserved character.

@ ipse -
QuoteI am embarrassed to find problems with my digitmaps after 1 year
I have designed hundreds of digitmaps. When I look back at them there's nearly always improvements that can be made and sometimes there are actual mistakes which don't always show up right away. I'll carry on coding mistakes and all - I can rely on the good folks here in the forum to check my work and point out any errors   ;)



ipse

#18
Quote from: ianobi on August 19, 2014, 01:29:28 AM
I have designed hundreds of digitmaps. When I look back at them there's nearly always improvements that can be made and sometimes there are actual mistakes which don't always show up right away. I'll carry on coding mistakes and all - I can rely on the good folks here in the forum to check my work and point out any errors   ;)
I find this a VERY friendly forum...and this makes for the complete lack of Obihai reps chiming in to solve actual problems. Definitely it was a criteria in buying a second Obi and recommending it to all my friends and co-workers.

Still...I have no excuse for going for the easy "copy/paste" solution sometimes :)
Thanks InetUser.
Of all the things I lost, I miss my mind the most. - Mark Twain

InetUser

Quote from: ianobi on August 19, 2014, 01:29:28 AM
@ InetUser - I agree 99% with your comment regarding labels. The exception would be to avoid the upper case "M" in an actual label as anything following the "M" may be parsed as the label. We use many digit map labels with a lower case "s" in - Msp1, Msp2 etc. which does show that in most cases a label can contain a reserved character.
There's no problem using uppercase 'M's in a label name.  For example, a label name of "MMM" works perfectly, referenced by "(MMMM)".  There's no ambiguity since the parser looks for "(M" to trigger a label reference and treats everything (2-16 characters) between there and a ')' as a label name.

Try it.