Spam Scoring

[netpro78]

Is there a way to enable the spam scoring feature on a per domain basis so that you are not paying for queries for domains that do not want the service?

[Vodia PBX]

Yes. It is called "Enable SPAM rejection" when you edit the domain properties.

[netpro78]

I found it, thanks for the pointer, I always forget about all of the settings that are available when editing the domain.  However now that I am testing it for the first time, I am calling in with a known spam number in order to see the different ways that the PBX can reject the call.  TrueCNAM scores 2027537878 at 100.  However with the threshold set at 50 it was not getting rejected.  I tool a look in the logging, and it appears all of the digits were not being submitted to TrueCNAM even though the number showed up properly in the invite, and the call logs.

resp_type=extended&resp_format=json&calling_number=027537878

I am on version 61.0.2 Win64

[Vodia PBX]

Looks like there is a problem with the interpretation of the caller-ID. If you are in the US or Canada, make sure to set the country code in the domain to "1" this helps the PBX to better understand the numbers.

[netpro78]

Thought the development of this product, I cannot think of one one feature that has proven more problematic than the country code.  The problem is the PBX tries to guess how you want to rewrite things.  It has only caused issues, and outages as upgrades have happened since it's behavior had changed so frequently from version to version.  Many years back someone in support recommended that I not use it, and enter everything into the pbx exactly as the carrier expected it.  This solved all of my issues over the years, and occasionally I would test using using the country code again, and it would just reintroduce problems.  Currently I put it back in, and it fixed the spam scoring, however broke outgoing calling since it would send 10 digits instead of 11 (despite rewriting in the dialplan), so I switched the trunk to 11 digits and it broke the ANI since I have a carrier that expects 11 digits of DNIS, but 10 digits of ANI.  So now I am in a tough position that the PBX is rewriting the SPAM ANI despite my best efforts to get it to not manipulate anything

[Vodia PBX]

Well if you set it after everything was already up, it is indeed a problem that it breaks things in many places. Some vendors just hardcode it to "1" (which makes it difficult to sell it outside of the US and Canada) and other hardcode it to ROW (which makes it hard to sell it in US and Canada). When creating a domain the PBX prompts already for the country code, to make the point clear that this is an important setting. We probably need to make this easier in the initial setup, e.g. propose a reasonable default that the admin can override when needed.

[netpro78]

Would it not make more sense to be transparent to the end user, and instead of the PBX rewriting anything, the default would be that noting would be rewritten, and if the user wanted certain things rewritten, they would have the option to write their own regular expression(s) to do so?  This allows an unlimited number of combinations such as trunks to different countries with differently formatted DIDs all in the same domain.

[Vodia PBX]

Internally the PBX stores phone numbers in a global format whenever possible - then when sending the call to a trunk it can be easily presented in the right format. Even in the same country different trunk providers cannot make up their mind on how to present numbers, and likely this will never happen. But for converting user input into canonical numbers the PBX needs to know how to read them, thus the country code. Anyway next version will make a proposal when you create a new domain, and this should make this problem a lot smaller.

[netpro78]

I created a new domain from scratch to eliminate any of the problems you mentioned of changing settings after the fact.  The problem still exists that if you allow the PBX to manipulate the numbers by entering a country code as you suggested, there is no way to have a 11 digit DNIS, and 10 digit ANI on the same trunk.  All of my tests have been domestic, so I would imagine it would be even more problematic if I started testing internationally.  The PBX doing any manipulation of numbers without the full control of the user is going to prove to be problematic.

[Vodia PBX]

We have also added something in the TrueCNAM code itself, because we know it wants the code in the E164 format and there is no point to have everyone jump through hoops to get this working. But so far it is only on the latest and greatest (61.1 builds).

[netpro78]

I just attempted to download the latest 61.1 Win 64 version, and it is still showing a build date of Aug 27, and exhibits the same TrueCNAM  behavior

[Vodia PBX]

Just made another 61.1 Win64 "L&G" version

[netpro78]

It seems to have fixed the issue in my test environment.

[netpro78]

Now that SPAM scoring seems to be working in my test environment, I am testing the various options for the "Handling of suspected SPAM" calls field.

the options of "Reject Call", and "Pretend to be busy" seem to do the exact same thing.  They both say we are sorry, but this extension does not accept anonymous calls.  The problem with this is that they both clue the caller in that some sort of ANI filtering is going on since the caller is probably aware that they are not sending anonymous.  I would suggest that pretend to be busy sends the call directly to Voicemail, and reject the call sends a reorder tone to the caller (500, or 486).  The other two options seem to work as you would expect.

[netpro78]

Are there any plans to address the options above that do the same thing?  TrueCNAM even recommends that one of the options would send the call directly to voicemail.

[Vodia PBX]

The thing is that the call can hit numerous places like ACD, hunt group, extension and other stuff. Each group has some kind of logic what to do with anonymous calls, e.g. send the call though a call screening first when calling extension (which is pretty powerful). We did not want to drop those achievements and thus treated the SPAM scoring as a way to classify a call as "anonymous" and then go from there. If there is anything that we need to change along this way e.g. have an option to send anonymous calls to voicemail well then we can add it in the right place. But IMHO we should have that already?!

[netpro78]

You have it when it hits the huntgroup (you can redirect directly to a mailbox), but a direct dial call to an extension has no way to send a spam call directly to voicemail.

[Vodia PBX]

Well you could select "pretend to be busy" and then set the call forward on busy to the mailbox number (8xxx). But I agree it would be more explicit to have that obvious case right there in the drop down.

[netpro78]

I am glad you pointed that option out.  I was completely confused by "pretend to be busy" playing a recording.  My mindset is that is if a phone is actually busy, and the voicemail is enabled, it would go directly there, and if the mailbox was disabled, it would send a 486 back.  The message confused me since I cannot think of a situation where it would normally play it.  Honestly I think the following 4 Spam options would be the most logical, and cover any need:

-Send to Voicemail

-Send Busy (sends 486, or 500 depending on trunk setting)

-Redirect (and give a field to redirect to)

-Ask for name

[netpro78]

I recently had my first false positive spam score.  I figured I could just add the number to the address book as a whitelisted number, and it should not spam score it.  Unfortunately it still classifies it as spam.  Is there another way to whitelist a number, or could this be added in future versions?

[Vodia PBX]

In principle it would make sense to feed that information back to the SPAM score provider - they will need to update the database on this. Right now the PBX completely relies on that scoring, no matter what is in the address book. It might make sense to look the address book up as well (which is just a quick internal operation), I don't see a reason why a local address book listing should have a lower priority that the lookup from an external score provider.

[netpro78]

I think both are good ideas.  TrueCNAM's API supports learning of false positives.  You would just need to add that to your integration.  I do also believe that the local address book should always take precedence.

[Vodia PBX]

Okay the address book checks will be in the next version. A quick search for the TrueCNAM API did not come up with anything. Also the question is what the best feedback mechanism is - we have a code for blacklisting the last number that we could use; we would also have to add a code for whitelisting a number.