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?
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.
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?
Is there a reason you're not using the "Oleg method" as ianobi mentioned?
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.
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.
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.
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.
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?
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}
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.
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 :)
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.
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)
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 :)
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.
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.
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 ;)
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.
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.
@ InetUser - I upgrade my agreement to 100% regarding your comment regarding labels.
Empirical testing always beats making assumptions :)
This is probably a good place to park this information on how call routes work, just for clarification. I hope it's of use. :)
For each Trunk (SP, LI, PP, BT etc), configure routing rules for incoming calls in the following format:
rule or {rule},{rule},...., where:(http://www.obitalk.com/forum/index.php?action=dlattach;topic=8381.0;attach=657;image)
• Rules and peerings are tested from left to right
• The first matched rule will be selected and used to route the call
• Every rule must be placed inside a pair of { } curly brackets
• Digitmaps always inside round brackets (Mabc)
• If there is only 1 rule, then { } is optional.
• {0255556666:SP2} is the same as {(0255556666):SP2} - since 0255556666 is just a constant, the parentheses are optional - however:
• If the rule includes things like xxxx and so forth that is a part of digitmap syntax, the round brackets are required, like this: {(025xx.):SP2} or {(xxx|123|(MMMM)):}
Neat table. Much clearer than the Admin Guide.
Also, nice to see postings from Obihai staff :)
It's a table from this document (Page 7):
http://www.obihai.com/docs/OBi-VoIP-Device-Attach-Legacy-IP-Phone-Workbook-v1-0.pdf (http://www.obihai.com/docs/OBi-VoIP-Device-Attach-Legacy-IP-Phone-Workbook-v1-0.pdf)
I created that document a few months ago as a follow on to this digit maps tutorial that I created for our Australian users on the Whirlpool forum:
http://www.obihai.com/docs/OBi-VoIP-Device-Australian-Localisation-Workbook-v1-1.pdf (http://www.obihai.com/docs/OBi-VoIP-Device-Australian-Localisation-Workbook-v1-1.pdf)
Skimming through both documents, there are some errors than can be fixed and tidied, but I could also rewrite both documents in a more generic manner and combine them into an "Introduction to digit maps and call routing" - would that be of benefit?
- Mark.
I believe an "Introduction to digit maps and call routing" would be a great benefit to OBi users. All of the information does exist, but it is spread around all over the place in various documents and postings on this forum. To have a good basic guide in one place where new (and not so new) users could be directed would be useful.
Let's wait a day or two and see if other forum posters agree.
I not only agree but strongly encourage Mark to write such a guide.
I've been away for awhile and have just seen the replies here.
I will try enclosing the digit map reference in parenthesis and see what happens.
Thanks for all of the hand holding.
Ok, success in blocking all of the 'bad guys' I have in my 'Ban' list.
Now, another question:
Right now, it appears that the banned numbers don't ring my phone, but do go to voicemail.
For some numbers, that is fine, but for others, I don't even want to give them a shot a voicemail.
Is there a way to specify or configure that somehow?
Setup a 2nd ban list then add the following rule to the inbound route:
{(Mban2):sp2(lenny@sip.itslenny.com)}
SP2 must be defined as SIP.
See: http://www.itslenny.com/
Lenny will answer the call, so it won't go to VM.
Quote from: azrobert on August 28, 2014, 01:46:52 PM
Setup a 2nd ban list then add the following rule to the inbound route:
{(Mban2):sp2(lenny@sip.itslenny.com)}
SP2 must be defined as SIP.
See: http://www.itslenny.com/
Lenny will answer the call, so it won't go to VM.
Well, that's pretty funny, but it might not be the best remedy.
Best would probably be the ability to forward to a 'not in service' message and hang up.
How would one do something like that?
I send these calls to Callcentric's Fax to Email service.
Get a CC free Freedom account.
In call treatments route all inbound calls to CC's Fax to Email service.
Send the calls to sp2(17771234567@in.callcentric.com)
17771234567 is your CC account number.
If the caller is smart enough they can send you an ad via fax.
I've been doing this for years and I never received a fax.
OR
Here are some Bell System Recorded Announcements:
http://www.beatriceco.com/bti/porticus/bell/recordedannouncements.html
The one you want is BlankNumber-.wav
Play the above several times and use any recording software to record it.
Use the recording as a greeting for an email service.
GoogleVoice allows a custom greeting.
Send the calls to the email service.
Maybe someone else will suggest a better method for using the recording.
You can set up a Tropo script to play the recording from my last post directly from the Web site. Tropo is a free service when used for development. I've had my free account for years.
Here is the script to play the disconnect recording:
<?php
answer();
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
reject();
?>
It plays a Sit tone then the "Disconnected" message twice and hangs up.
If anyone wants to try this get a free Tropo account here:
https://www.tropo.com/register
Create an App with a name like "Ban"
Then create a file/script for the App with the above code and name it "Ban.php"
The script is written in PHP, so the file suffix must be php.
I have trouble creating/modifying Tropo scripts using Internet Explorer, so I use Chrome.
If you have trouble creating an App, I can walk you thru it.
After the App is created they give you a SIP URI to access it.
It will be like this:
9990012345@sip.tropo.com
Edit:
I changed the "Hangup" to "Reject".
Edit2:
I found a better quality recording and changed the script.
Quote from: azrobert on August 31, 2014, 09:52:51 AM
You can set up a Tropo script to play the recording from my last post directly from the Web site. Tropo is a free service when used for development. I've had my free account for years.
Here is the script to play the disconnect recording:
<?php
answer();
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
reject();
?>
It plays a Sit tone then the "Disconnected" message twice and hangs up.
If anyone wants to try this get a free Tropo account here:
https://www.tropo.com/register
Create an App with a name like "Ban"
Then create a file/script for the App with the above code and name it "Ban.php"
The script is written in PHP, so the file suffix must be php.
I have trouble creating/modifying Tropo scripts using Internet Explorer, so I use Chrome.
If you have trouble creating an App, I can walk you thru it.
After the App is created they give you a SIP URI to access it.
It will be like this:
9990012345@sip.tropo.com
Edit:
I changed the "Hangup" to "Reject".
Edit2:
I found a better quality recording and changed the script.
I'm familiar with Tropo and this should work well.
However, for some reason I'm currently getting server errors anytime I try to do something with Tropo.
I'll have to try at another time.
Quote from: azrobert on August 31, 2014, 09:52:51 AM
You can set up a Tropo script to play the recording from my last post directly from the Web site. Tropo is a free service when used for development. I've had my free account for years.
Here is the script to play the disconnect recording:
<?php
answer();
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
reject();
?>
It plays a Sit tone then the "Disconnected" message twice and hangs up.
If anyone wants to try this get a free Tropo account here:
https://www.tropo.com/register
Create an App with a name like "Ban"
Then create a file/script for the App with the above code and name it "Ban.php"
The script is written in PHP, so the file suffix must be php.
I have trouble creating/modifying Tropo scripts using Internet Explorer, so I use Chrome.
If you have trouble creating an App, I can walk you thru it.
After the App is created they give you a SIP URI to access it.
It will be like this:
9990012345@sip.tropo.com
Edit:
I changed the "Hangup" to "Reject".
Edit2:
I found a better quality recording and changed the script.
Finally go Tropo to accept my script, but it doesn't seem to work on the Tropo end.
I know it makes it to Tropo because I can see the logging information there.
All I hear is a brief ring, and then basically silence.
I'm having trouble using Internet Explorer with Tropo. In the past my Tropo scripts weren't getting updated with IE. I have an older computer running Vista with Chrome installed. Chrome worked perfectly with Tropo.
For this script I had a Tropo App I don't use, so I thought I would modify it instead of creating a new App. I used IE and it seemed to update, but when I looked at it again it wasn't updated. If someone told me this I would think he was wacko. I never had a problem like this with IE.
Are you using Internet Explorer?
Anyway, I created another App from scratch using the following script:
<?php
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
hangup();
?>
First, the previous script worked for me. It took a few seconds before the message was played after it answered the call. I removed the optional Answer command. It didn't make a difference. I removed the blank lines and changed the last command back to Hangup.
I created a Speed Dial to test it like this:
sp2(9991425987@sip.tropo.com)
If you want to test, the above is the actual number for my App. I feel uncomfortable leaving this App public, so I will be deleting it in a few days.
Edit:
First, I am far from a Tropo expert. The script doesn't force the call to end. When I test it with a Speed Dial the call stays in session until I hang up. That is why I changed the last command to Reject, but I got the same result.
Edit2:
I just noticed a error with the previous script. I inserted a blank as the 1st character of the script when I did the cut and paste. I don't know if this would cause a problem.
Edit3:
The App stopped answering. I think Tropo is having problems.
Edit4:
The App is working again without any changes.
Using IE going thru MY FILES (Instead of MY APPS) to update the script worked.
Quote from: azrobert on September 02, 2014, 08:26:43 PM
I'm having trouble using Internet Explorer with Tropo. In the past my Tropo scripts weren't getting updated with IE. I have an older computer running Vista with Chrome installed. Chrome worked perfectly with Tropo.
For this script I had a Tropo App I don't use, so I thought I would modify it instead of creating a new App. I used IE and it seemed to update, but when I looked at it again it wasn't updated. If someone told me this I would think he was wacko. I never had a problem like this with IE.
Are you using Internet Explorer?
Anyway, I created another App from scratch using the following script:
<?php
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
say("http://www.thisisarecording.com/z/z/206-201-0000X.mp3");
hangup();
?>
First, the previous script worked for me. It took a few seconds before the message was played after it answered the call. I removed the optional Answer command. It didn't make a difference. I removed the blank lines and changed the last command back to Hangup.
I created a Speed Dial to test it like this:
sp2(9991425987@sip.tropo.com)
If you want to test, the above is the actual number for my App. I feel uncomfortable leaving this App public, so I will be deleting it in a few days.
Edit:
First, I am far from a Tropo expert. The script doesn't force the call to end. When I test it with a Speed Dial the call stays in session until I hang up. That is why I changed the last command to Reject, but I got the same result.
Edit2:
I just noticed a error with the previous script. I inserted a blank as the 1st character of the script when I did the cut and paste. I don't know if this would cause a problem.
Edit3:
The App stopped answering. I think Tropo is having problems.
Edit4:
The App is working again without any changes.
Using IE going thru MY FILES (Instead of MY APPS) to update the script worked.
I did all my editing with Chrome.
I am trying to use your Tropo App, but get the same results as mine: short ring and then nothing except some very faint pulsating static.
I'm changing the the X_InboundCallRoute for my SP2 voice service to include the following rule:
{(MHangup):sp2(9991425987@sip.tropo.com)}, ...
Not sure if the problem has something to do with transferring a call on sp2 to sp2 again.
The call does make it to Tropo, but I can't hear the result for some reason.
I did all my testing with a Speed Dial.
I just now changed the X_InboundCallRoute for a GV account to the following and it worked.
{sp2(9991425987@sip.tropo.com)}
Can you run your App from a browser?
Log into Tropo.
Click on your App.
There are 2 places you can call the App.
On the top right or bottom of the page.
You will get a pop-up keypad.
Click on the phone symbol on the bottom left.
You might get a 2nd pop-up.
Click on the circle next to Allow.
Quote from: azrobert on September 03, 2014, 06:55:45 PM
I did all my testing with a Speed Dial.
I just now changed the X_InboundCallRoute for a GV account to the following and it worked.
{sp2(9991425987@sip.tropo.com)}
Can you run your App from a browser?
Log into Tropo.
Click on your App.
There are 2 places you can call the App.
On the top right or bottom of the page.
You will get a pop-up keypad.
Click on the phone symbol on the bottom left.
You might get a 2nd pop-up.
Click on the circle next to Allow.
There isn't a phone number associated with my app, but I don't think it is my app because I get the same results with your app. It must be something else, probably on the Obi side of things.
You don't have to dial a number.
Click on "Call my App from browser".
Then click on the Phone symbol.
You don't dial a number.
Quote from: azrobert on September 03, 2014, 07:22:26 PM
You don't have to dial a number.
Click on "Call my App from browser".
Then click on the Phone symbol.
You don't dial a number.
OK, I get the same results as with forwarding the Obi calls.
The call answers, then silence, then hangs up.
It must be something with your network, but I have no idea what it would be.
Can someone else try my Tropo App?
Setup a Speed Dial like this:
spn(9991425987@sip.tropo.com)
Where spn is the SP number of a SIP trunk.
Thanks
Quote from: azrobert on September 03, 2014, 07:47:40 PM
Can someone else try my Tropo App?
Works fine for me. Two consecutive "number disconnected" messages and then a hangup.