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.
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
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
RE: STIR/SHAKEN
RE: STIR/SHAKEN
LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4 & V6, OpenScape Xpressions V7, OpenScape Contact Center V8, OpenScape Voice V9
RE: STIR/SHAKEN