Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

STIR/SHAKEN 1

Status
Not open for further replies.
libellis

libellis

Technical User
Joined
Apr 9, 2007
Messages
296
Location
US
I know it’s still early days for STIR/SHAKEN implementation by Carriers, but I was wondering if anyone else has run into this issue:

Small VoIP Carrier has implemented STIR/SHAKEN, but blocks callers with Google Voice issued phone numbers. (NOTE: Subscribers of this Carrier have the option to enable/disable STIR/SHAKEN so the problem can be avoided if the subscriber is willing to live without it.)

The Carrier says that one of the STIR/SHAKEN data headers that Google is sending is wrong (they say it involves the second header, but I have no detail), and so they block these numbers. However, the Google numbers work with other Carriers that they have been tested on, such as Verizon. The Carrier didn’t know why that would be the case, but guessed that - aside from some other Carriers not having yet implemented STIR/SHAKEN (big ones were supposed to have done so by now) - maybe with the incorrect header the other Carriers have simply chosen to assume that the call is legitimate rather than defaulting to block. They weren’t optimistic about Google responding any time soon in an attempt to resolve. That of course begs the question if the Carrier itself is doing something wrong, but no joy in going that route.
 
Sort by date Sort by votes
I'm running into a similar problem. I have AT&T PRI trunks for long distance/inbound toll-free and separate trunks for local/inbound DID. When we call out to a Verizon wireless subscriber in New Mexico, we get a recording "I'm sorry, your call could not be completed. Please check your dialing procedure. This is a recording. 702".
After a whole lot of hassle with AT&T, they told be that Verizon was rejecting the call because the secondary number is incorrect. We are sending a valid caller ID number, but AT&T sends our billing account number as the secondary - which Verizon sees as a non-dialable number and rejects. AT&T can't change the secondary number, as that "service" is no longer available.
Been waiting a week to hear back from Verizon. I can only hope this issue isn't something that started with this one subscriber and will be rolled out nationwide.


LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4 & V6, OpenScape Xpressions V7, OpenScape Contact Center V8, OpenScape Voice V9
 
Upvote 0 Downvote
Sometimes the only way to get meaningful Carrier response is if an issue becomes too widespread for them to ignore. In the situation I described, at least a subscriber is able to log into their account and disable STIR/SHAKEN.
 
Upvote 0 Downvote
Not likely that anyone has been losing sleep waiting for an answer to this post, but just for the record, the problem was caused by a TLS certificate issue, now resolved.
 
Upvote 0 Downvote
Glad you got it resolved. I see a lot more "whack-a-mole" in the future!

LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4 & V6, OpenScape Xpressions V7, OpenScape Contact Center V8, OpenScape Voice V9
 
Upvote 0 Downvote
Another STIR/SHAKEN consequence to note - have experienced this myself. A doctor’s office uses an automated service to call/leave appointment reminder messages for patients. The service spoofs the office caller ID so patients will recognize it. Call gets blocked. Likely there are many doctors/dentists/etc. offices that haven't realized this yet, nor have the services they use implemented solutions.
 
Upvote 0 Downvote
@Libellis
There should be a way at the carrier to verify ownership of a number for shaken/stir. Usually involves getting a pin from the carrier and receiving a phonecall on the line affected and keying it in, "verifying" you own it to use the Caller ID. At least that's what Verizon has done, Twilio has something similar.



Telecom Technician, Healthcare Enterprise
CS1k, Difinity, CUCM, Aura SM, Shortel, Teams, and Twilio (all at the same time)
 
Upvote 0 Downvote
Interesting - just looked at the Twilio offering - thanks for pointing that out. As for STIR/SHAKEN in general, personally I see hardly any reduction in the volume of scam/nuisance calls, but it would have been naive to expect much given the degree of cooperation needed among Carriers (including foreign) for it to work well.
 
Upvote 0 Downvote
LoPath - PRI trunks are TDM technology and have no ability to pass certificate information so STIR/SHAKEN will not work for calls initiated on those unless the carrier attaches certs after the fact, which they are not likely ever to do. STIR/SHAKEN requires all parts of the call path to be SIP and if TDM is introduced anywhere in the path STIR/SHAKEN will not work.
 
Upvote 0 Downvote
About a year ago a standard for extending STIR/SHAKEN over TDM was issued by ATIS. Have no clue if anyone is implementing it.
 
Upvote 0 Downvote
libellis
When you say it was a TLS certificate problem. Was it a carrier certificate or one in the IPO?

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'
 
Upvote 0 Downvote
The Carrier. With that said, I'm lucky they even told me what the issue was. One day the user re-enabled STIR/SHAKEN and found that the problem was resolved. I called the Carrier, but didn't get any more information than "it was a TLS certificate issue". Was that really the case - wouldn't bet the house on it, but wouldn't bet against it either.
 
Upvote 0 Downvote
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top