Now that the control panel includes the ability to block calls based on STIR/SHAKEN attestation level, it would be very helpful if the actual attestation level for each inbound call appeared in the call logs. Without that information, it’s difficult to understand how calls are being classified or to fine‑tune the blocking settings. I’m interested in what other users think, because having the attestation level visible alongside each call would make this new feature far more practical and easier to adjust.
6 Likes
Following up on my earlier post, I enabled blocking for Attestation C, which should catch the highest‑risk calls. Instead, two long‑established family landlines were blocked, one active since 1959, the other for 25 years. These callers should be fully verified by their providers, yet they were apparently rated C.
Minutes later, I answered a call from an unfamiliar number, assuming it must be safe with C‑level blocking, and it turned out to be spam. So legitimate callers were flagged as C, while a spammer received a higher attestation level.
This shows why the call logs need to display the attestation level for each inbound call. Without that visibility, it’s impossible to understand misclassifications or adjust blocking settings effectively. Seeing the attestation rating next to each call would make this feature far more usable.
1 Like
I was not aware of the ability to block calls to VOIP.MS based on attestation level.
Where would I find this feature?
“CallerID Number Filtering”
Aha. Thank you. . . . . . . . . . . . . .
Agreed, I would like to see attestation level in the logs.
1 Like
I would love to use this feature if it would work. I have two rules. One rule that sends all calls rated c or lower straight to VM, and another that sends all calls with no attestation straight to VM. It seems ALL calls are hitting the rule for calls with no attestation. I have verified this with two cellphones and a google voice number. All of these are verified as having a attestation rating of A. I have had a ticket open with support for over a week with no real movement on the ticket.
There is definitely a bug with the “Absent” option. It is grabbing every call exactly the way you described, even when the calls have Attestation A. I have already confirmed the same behavior on my end, and I currently have a ticket open with support regarding this issue. Until they fix it, the feature will not work as intended.
Thanks a million. Makes me feel better I am not crazy and don’t have something mis-configured. When this gets corrected it should basically get rid of most of the spam calls. Most of the SPAM calls I am getting are obvious number spoofing. Of course they are ALL going to VM right now lol. Suites me fine though. I have the numbers I trust in my address book. Those trusted numbers are routed to my trunk.
I had mine set up the same way to send those calls straight to voicemail, but since that was not working correctly, I changed it to play a short recording that says “press 1 to complete your call.” So far the legitimate callers press 1, and everyone else just hangs up.
Just to give you some more confirmation I’m seeing the same issue. “Absent” routed my cell phone call to voicemail. I tested my cell phone and it gets a A rating on clearlyip’s test
I’m really curious to understand exactly what the underlying problem is with the “Absent” option, because based on what I’m seeing, it has to be one of two things:
-
Attestation A calls are being incorrectly treated as Absent and blocked,
or -
The feature is working correctly, and the real issue is that VoIP.ms isn’t actually receiving any attestation information at all, meaning every inbound call is effectively “Absent” on their side.
Right now, every single call I receive gets caught by the “Absent” rule. That means all my calls are either Attestation A or truly Absent — and if they’re all being routed as Absent, something isn’t lining up.
Until we know which of these two failure points is happening, it’s hard to tell whether the bug is in the filtering logic or in the attestation data VoIP.ms is (or isn’t) getting.
Agreed - sure wish they could get this working. When I first learned about it via their newsletter, I turned it on to dump absent or class C calls. After a few days it dawned on me my phones hadn’t rang at all. When I started doing some testing I found the same as others - all incoming calls are failing the attestation rules. Tried several class A numbers, and they failed the rule - same as others have seen. I opened a ticket in early May and they indicated they were aware of the bug but there was no ETA to get it fixed. It would be a huge help if they could get this working because the bulk of incoming calls for me are SPAM (my DID’s are a couple of legacy landline numbers I wanted to keep). I’m surprised by now it hasn’t been fixed - or at least temporarily remove the feature since it doesn’t work so people don’t end up like I did with all calls blocked. The issue doesn’t seem to be getting much attention to get fixed after this length of time.
I’m in the same boat. I setup a C-or-Lower filter and everything went there even from an old neighbour’s bell landline. Aside from the bug, It highlighted the need for some mechanism or pathway to troubleshoot filters as the OP noted.
For now, since everything seems to be getting caught by the Absent filter, I ended up routing those calls to a short recording that says “press 1 to complete the call.” Most of the people who call me are already in my phone book, so they bypass it entirely. For the ones who do hit the recording, anyone legitimate just presses 1 and the call goes through. So far, everyone who actually needs to reach me has no trouble pressing 1, and the robocallers just hang up.