×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

*
*
*
*

Thanks. We have received your request and will respond promptly.

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

STIR/SHAKEN

thread461-1812409

STIR/SHAKEN

STIR/SHAKEN

(OP)
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.

RE: STIR/SHAKEN

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

RE: STIR/SHAKEN

(OP)
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.

RE: STIR/SHAKEN

(OP)
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.

RE: STIR/SHAKEN

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

RE: STIR/SHAKEN

(OP)
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.

RE: STIR/SHAKEN

@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)

RE: STIR/SHAKEN

(OP)
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.

RE: STIR/SHAKEN

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.

RE: STIR/SHAKEN

(OP)
About a year ago a standard for extending STIR/SHAKEN over TDM was issued by ATIS. Have no clue if anyone is implementing it.

RE: STIR/SHAKEN

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'

RE: STIR/SHAKEN

(OP)
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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login
Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close