News:

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

Main Menu

ObI202: UserDefinedDigitMaps with ?: works but still receive anonymous calls.

Started by Vegetus, April 30, 2016, 08:06:57 AM

Previous topic - Next topic

Vegetus

Hi there.

I have a User Defined DigitMaps in place on my ObI202 box:

(?:|00xx.|010xx.|011xx.|02xx.|030xx.|049xx.|051xx.|055xx.|071x.|0733xx.|0744xx.|0753xx.|081xx.|092xx.|095xx.|096xx.|098xx.|3405xx.|388xx.|3902xx.|3906xx.|3900.|3933xx.)

If I call from my cellphone:

#31#VoIPnumber

(#31# is a standard GSM code for outbound anonymous calls) my VoIP (no GV) home number, the call is rejected due of the User Defined DigitMaps and the ?: code inside it.
It happens time to time I continue to receive very few anonymous calls.
I logged in locally to my ObI202 box just to see the call history and that is what appears:

--> From 'Anonymous ' SP1(anonymous)

Now, I would like to know, what are the differences from ?: code and the SP(x) based AnonymousCallBlockEnable feature? Why the ?: code works when I call anonymously from my cellphone and I still receive anonymous calls despite of the ?: code?

Many Thanks to everyone will help!

ianobi

First the part that I'm sure about:
The "?:" rule is testing CallerID. If the CallerID is blank, then it will reject the call. In this case:
From 'Anonymous ' SP1(anonymous) - From 'CName' SP1(CallerID)
CallerID = anonymous, which is not blank.

To test for that situation and for upper and lower case your User Defined Digitmap would start:
(?:|anon@.:|Anon@.:|


Second the part I'm not so sure about:
I believe that AnonymousCallBlockEnable feature is looking at CName, which telcos/SIP providers etc send as "Anonymous" if the caller has requested privacy. The last sentence from the Admin Guide in this quote seems relevant:

QuoteSIP Privacy
The OBi device observes inbound caller privacy and decodes the caller's name and number from SIP INVITE requests by checking the FROM, P-Asserted-Identity (PAID for short), and Remote-Party-ID (RPID for short) message headers. All these headers may carry the caller's name and number information. If PAID is present, the device takes the name and number from it. Otherwise, it takes name and number from RPID if it is present, or from the FROM header otherwise. RPID, if present, will include the privacy setting desired by the caller.

The privacy setting may indicate one of the following options:
- off = no privacy requested; the OBi will show name and number.
- full = full privacy requested; the OBi will hide both name and number.
- name = name privacy requested; the OBi will show the number but hide the name.
- uri = uri privacy requested; the OBi will show the name but hide the number.
Regardless, if PAID exists or not, the device always takes the privacy setting from the RPID if it is present in the INVITE request. Note that if the resulting caller name is "Anonymous" (case-insensitive), the device treats it as if the caller is requesting full privacy.

Very roughly speaking - the "?:" is looking for a blank CallerID to reject the call and the AnonymousCallBlockEnable is looking for the CName "Anonymous" to reject the call.

Better explanations would be very welcome   :)




Vegetus

Thank you ianobi for explain to me the differences.

ianobi

If you are using your User Defined Digit Map in your InboundCallRoutes, then I would suggest splitting it into two User Defined Digit Maps. For example (Mbad) - calls to reject, (Mgood) - calls to accept:

Voice Services > SPx Service > X_InboundCallRoute:
{(Mbad):},{(Mgood):ph}

(Mbad) would be something like:
(?|anon@.|Anon@.)

(Mgood) would contain CallerID formats that you wish to accept.

Search for "scanners" for more information on this subject.




Vegetus

Time to learn never end.

I subscribed for a two years ObiExtras account, just to avoid spam calls from telemarkets. Next step for ObIHai ObIExtras folks/Engineers  should be (in my humble opinion) to let build "White List". In other words, only that know numbers can reach our ObIHai boxes. Despite in Italy we have a way to op-out, that system doesn't work at all. Telemarketers for example are forbidden to place anonymous calls. Will you trust someone who is going against law? I, not for sure!

Now, it is possible that other ObI202 users stumble upon this thread, maybe they will to stop spam calls, therefore I would like to show them what I did.

I have 4 User Defined Digit Map:

Label: Telemarketers
(?:|00xx.|010xx.|011xx.|02xx.|030xx.|049xx.|051xx.|055xx.|071x.|0733xx.|0744xx.|0753xx.|081xx.|092xx.|095xx.|096xx.|098xx.|3405xx.|388xx.|3902xx.|3906xx.|3900.|3933xx.)

Label: Telemarketers2
User Defined Digit Map3
(06142x.|0619x.|06211xx.|067842x.|06807x.|0689xx.|06945xx.|0735x.)

Label: Telemarketers3
User Defined Digit Map4
(2xx.|4xx.|5xx.|6xx.|7xx.|8xx.|9xx.)

Label: Telemarketers4
User Defined Digit Map5
(anon@.:|Anon@.:)

Then in Voice Service, under SP1, I have:

X_InboundCallRoute
{(Mtelemarketers):},{(MTelemarketers2):},{(MTelemarketers3):},{(MTelemarketers4):},{ph,ph2}

The better OS or firewalls provide "All close services" and the user opens only the services/ports he/she needs. That is the better choice to implement security but as you can see it's hard to do that in VoIP system.

The worse is CallerID spoofing and belive me, Telemarketers too discovered VoIP nowadays and my 4 User Defined Digit Maps try to narrow as possible the range of unwanted CallerIDs range.

Anyway, there is a Thread about CallerID spoofing here:

http://www.obitalk.com/forum/index.php?topic=9511.msg63129#msg63129

Best regards to all of you, VoIP addicted!

ianobi

You certainly seem to be determined to defeat the telemarketers!

A small point - the ":" after ? , anon@. and Anon@. is not required. The final ":" after each (Mtelemarketers) digitmap is all that is required to reject those calls.

Keep up the good fight against the telemarketers   :)