Calling the Clearly IP attestation check number at 920-666-1392 as well as the testnumber.org attestation check number at 737-727-3232 both return the correct caller ID number I use (the voip.ms account DiD), but the STIR/SHAKEN attestation level reported is B (Partial attestation, Identity known, authorization to use the number: Unknown. In other words “This is my customer. This call originated on my network; however, I did not give them this telephone number”). The call is certified 91715573 Quebec Inc (voip.ms parent company) Service Provider 161K
I called from my voip.ms account using as the caller ID the DiD number I ported into voip.ms, So it is perhaps because the DiD was ported, not originally acquired from voip.ms, but in nay case it is now with voip.ms, so the attestation level should be A (Full attestation, In other words “This is my customer. I gave them this telephone number. This call originated on my network.” .
The fact that the attestation level is B risks the calls from voip.ms being flagged as robocalls or spam calls.
I am curious to know if I am the only one with this issue, or if it is a widespread voip.ms issue. I know that the company I work with has the same problem and has submitted a support ticket, but so far no solution.
If this is a general voip.ms issue, I think it is pretty serious.
Interesting … my work cell phone has a call masking feature where it sends a caller ID number I submitted instead of the real number of the cell phone. (I use it to display my desk phone number instead of my cell phone when making calls.) That number dialed from my cell phone is given an attestation level of “A”. When I call the check number from my actual desk phone (through the local telephone company) I get an attestation level of “B”.
In other words, I am getting a higher attestation level using a carrier that the number is not assigned to than when using the carrier where that number is actively assigned.
It sounds like STIR/SHAKEN needs more work. And I agree, when placing a call through the voip,ms servers using a voip.ms DID I would expect an attestation level “A”.
Thanks for your feedback. My understanding is that if the carrier has verified that you are authorized to use the number as your caller id, they should attest at the A level. The verification could be, as voip.ms or google voice do, via phone call or SMS sending with a confirmation code that must be entered.
So if your cell phone carrier did the verification, attesting at level A is the way it should be. If the did not do a verification, then they are doing it wrong and should attests at B. Your local phone company on the other end seems to be doing it wrong.
I agree with you, STIR/SHAKEN as well as SMS regulations appear to be a total mess, forcing people and companies to spend tons of time and money.
My numbers are US. But it should not matter, because they do attest, but at level B rather then A, which makes the call show up as “unverified” instead of “verified” or “verified Number” on many cell phones, or it might get blocked by some spam/robocall filters (ooma used to have such a thing when I was with them). I believe it will be even more of a problem in the future as call attestation gets more used to filter calls. This is not good.
BTW, I also tried from the main account instead of sub-accounts with the same results.
My voip.ms number, which I have had for 30+ years, have ported at least 5 times through that period, and is US based, reports a level A from your test numbers.
So it’s not a general problem
But a bit concerning is that the 737 number (testnumber.org) says “scout” rates my number as a “possible” robo call risk. I guess because it knows it’s a VoIP number? Or that voip.ms mostly has corporate customers?
My other number, with a simular porting history, but which currently resides with Tello (a T-Mobile reseller) gets an “A” and “unlikely “.
My 3rd number, recently ported to Sonic (an internet provider) and which is VoIP, reports as “A” and “unlikely”.
So that implies it’s probably a voip.ms reputation problem, not a general VoIP concern.
I have an open trouble ticket regarding this exact issue.
My telephone number consistently received Attestation A when I was with my previous VoIP provider, voipo.com. After they went out of business, I ported the number to voip.ms, and since then, it has been assigned Attestation B. Voip.ms has attributed this to the downstream carrier, Bandwidth.com—however, Bandwidth.com was also the downstream carrier when I was with voipo.com, and I still had Attestation A at that time.
What’s puzzling is that the certificate for my calls is now signed by voip.ms, not Bandwidth.com. I understand that in the past, certificates were sometimes signed by the downstream provider, but that’s not the case here. The signing authority is clearly listed as 91715573 Quebec Inc, which is voip.ms’s parent company.
To further illustrate the inconsistency, I tested two free numbers from Textfree and Google Voice, and both returned Attestation A. Yet my paid DID through voip.ms is flagged with Attestation B, and recipients are seeing “Potential SPAM” on their caller ID displays.
Update: voip.ms customer support was able to fix the issue. It took about 3 weeks, and I’m not sure what specifically they had to do to solve it, but they did. So if anyone encounters this issue, I suggest you submit a support ticket and have voip.ms customer support fix it.
I totally agree, they should do something global to fix this for everybody.
I told them in my ticket that I thought this was not just my issue but something that potentially affects a lot of customers, but apparently they did not believed so.
A company I used to work for that just moved (on my suggestion) their phone system to voip.ms had the same issue and it was resolved only via a support ticket.
I submitted a ticket about this and got a response I don’t quite understand:
For outbound calls, we use different providers’ routes. You may place a call using a number from provider A, but the system sends the call through provider B. This will get a B level. If/when the system sends the call from the number of provider A using the provider A route, the call will get a level A.
This makes it sound like the difference between attestation levels A and B is essentially random and meaningless and uncontrollable. But that can’t be right, can it?
I’m definitely using a DID number in my account. I paid the $10 to have the CNAM set to my name. It seems like there should be no problem getting level A? (We know this person, and they’re using an authorized number.)
I think what the response means is that voip.ms (or better 9171-5573 Quebec Inc) does not “signs” the calls, rather it routes the calls to upstream providers that then sign the call. This is how it could have been done during the initial phases of the implementation. It is my understanding that now this is no longer allowed and that calls need to be signed by the service provider independent of how the call is routed. In fact, if you call the Clearly IP attestation check number at 920-666-1392 it will tell you not only the attestation level but also the signer (which for voip.ms will be the legal name of the company: 9171-5573 Quebec Inc). For some more info, have a look at https://commlawgroup.com/2025/fccs-third-party-rule-compliance-deadline-is-september-18-2025/
It seems there is a lot of confusion, even among the customer support personnel, on how all this is supposed to work. I know some know how to fix this issue (they did it for me). I just wish they took care of it automatically for all customers.
If anyone from voip.ms monitors this: I think you have an issue here and you do not realize how badly it could affect you customers and ultimately you. It should be taken care of.
Perhaps I should try to explain it differently according to my understanding of the matter:
yes, voip.ms could be using different upstrem providers delegating them to sign the call. But it is the entity whose certificate is used that is legally responsible to decide the attestation level. If the calls are signed using voip.ms certificate (actually the certificate of 9171-5573 Quebec Inc) then it is voip.ms that decides the attestation level and should enforce whomever actually signs using voip.ms certificate to sign at the attestation level voip.ms decides.
You can delegate someone to sign a document in your name, but if the document bears your signature then you decide what the document contains because you are legally responsible!
So check not only the attestation levels of your calls but also whose certificate was used to sign the attestation level. If it is 9171-5573 Quebec Inc then it was signed by voip.ms and they should take care of the issue. If it was signed by some other provider, but the call was via your voip.ms account then voip.ms should take care of making sure that the call is signed by voip.ms and at the correct attestation level.
ClearyIP’s attestation service reports Level B and the signer is “9171-5573 Quebec,” so it seems Voip.ms is holding all the cards here. The agent said they’d check with a sysadmin to see if there’s anything to be done on their end. (I’m hoping the answer is yes!)
I’m now having trouble getting Voip.ms support to acknowledge that there’s a problem here.
A new support agent is asserting (without evidence) that the attestation level is in fact correct on their end. If I’m seeing a different attestation level from a third party service, that’s invalid. I have asked several times for an approved/recommended way for me to check a call’s attestation level, but they seem to be dodging that question.
They’ve recommended I register with the Free Caller Registry to avoid my calls being blocked or marked as spam. They seem to be unwilling to engage with attestation levels unless I tell them that a call has failed.
By the way, there’s a great tool for showing the full/raw STIR/SHAKEN headers/payload/cert. I can’t link to it here, apparently, but if you search for “ZipDX STIR/SHAKEN Confirmation and Debugging Tool” you should find it. It’s on rraptor-dot-org.
The call will likely not fail (unless Attestation level is C) but it will not show up as verified on most cell phones (e.g., iOS, Samsung, Google). Even voip.ms itself has a feature in beta under account settings/general that states “Show Caller ID Verified [V] BETA” that I think does the same: if selected it will check the attestation level and if it is A it will prefix a [V] to the inbound CallerID to let you know that the CallerID is “verified”. Many, if not most people that have the feature that displays if the CallerID is verified will likely choose not to answer calls failing the verification.
For instance what happened to me was that a friend of mine reported that when I called her on her phone my number appeared on the display without a call verification indicator that she used to get when I was calling before porting the number to voip.ms. She was surprised as she usually does not answer unverified calls, but she recognized my number and answered anyway and then reported the issue to me. So I investigated and saw that the attestation level, which used to be A with the previous carrier, was now B. That did not seem right. So I opened a ticket with voip.ms and after a lot of back and forth they fixed it.
Registering with Free Caller Registry won’t change the caller ID showing up as unverified, but it might prevent blocking if the carrier also check that registry when the attestation level is less then A.
I tried my work number (provided by the local telephone company) and I get a “B” whether that call goes out our SIP circuit (provided by the same company) or a PRI (provided by the same company). Odd that even though that is a 100% physical connection (no Internet - SIP is on a dedicated circuit) they still cannot attest “A” for the calls.
However my wireless provider allows business customers to mask their cell phone numbers … when I call from my wireless phone people see my work caller ID and it sends with an attestation of “A”. I am getting a higher level via a company spoofing the number (legally) than the company that provides the number directly. (That work number is attested “B” when used via voip.ms as a “verified caller ID”.)
I still hope that voip.ms figures out how to attest “A” for all of their subscribers. I am disappointed that tech support no longer seems to be working to fix the problem on an individual basis.
