Re: [VoiceOps] PSA - Hosting SHAKEN cert behind Cloudflare

[Karl Douthit via VoiceOps]

For Cloudflare we had to set a Page Rule on the cert page / site : Browser
Integrity Check: Off

On Sat, Jul 15, 2023 at 6:54 PM Jared Geiger via VoiceOps <
voiceops@voiceops.org> wrote:

> We were notified that some validators were unable to pull our cert which
> is hosted behind Cloudflare.
>
> I believe the fix is to create a WAF rule to match when the  User Agent
> contains "Java/1.8.0" and then choose the Skip action.
>
> Please share if anyone has any better tips for WAF rules for this scenario.
>
> I was seeing Bandwidth, TransUnion, and Level3 getting blocked.
>
> TransUnion gave me the heads up and mentioned they saw it with other
> carriers lately also.
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Rate Center Geodata

[Karl Douthit via VoiceOps]

Haven't looked in awhile, but telcodata.us has a bit of that information.

On Mon, Mar 20, 2023 at 9:36 AM Calvin E. via VoiceOps <
voiceops@voiceops.org> wrote:

> Is there an authoritative source for rate center latitude and longitude?
>
> Is there a free source for this data?
>
> I'm aware that BIRRDS/LERG has the Switch CLLI coordinates, but I don't
> know if the rate center virtual coordinates are also there. NANPA said,
> "NANPA doesn’t have this information. We suggest you check with a vendor
> who creates rate center maps, but we can’t recommend one."
>
> Is rate center data centralized, or invented by carriers and 3rd parties?
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Issues to T-Mobile

[Karl Douthit via VoiceOps]

Welcome to the wide world of random call blocking.

We've been seeing the same issue for some time now due to the magic of
"analytics".  Emergency notification calls (school closures, weather
events, shootings) are especially great when getting blocked due to random
systems deciding that they don't like the call patterns or the ANI.

You are possibly running into where some of your ANIs have been flagged for
no reason at all and that your cert or signed level isn't even being looked
at before getting rejected.

Of course when your customer tries making the same call on their cell phone
(or a different carrier) it works just fine so you're left looking like you
don't know what you are doing.

Best you can do is open tickets and complain.  You can also look at trying
to fill out the FCR but I haven't seen that help too much.

On Wed, Jan 11, 2023 at 7:08 AM Dovid Bender via VoiceOps <
voiceops@voiceops.org> wrote:

> Hi All,
>
> We are a small ITSP and every so often we have issues with calls that go
> to T-Mobile. We sign all our calls with our cert. Lately we have been
> getting 404's, 608's etc through 382, Telnyx and SIPRoutes. Bandwidth has
> been worse than the rest as they don't outright reject calls but they send
> a 100 trying and leave us hanging for 30 seconds. Peerless and one other
> carrier are completing the calls. Anyone know what makes T-Moble special
> that so many carriers will just 404 calls to their network?
>
> TIA.
>
> Dovid
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Bandwidth - Monday Outage

[Karl Douthit]

Because they aren't att, vz, sprint or t-mobile, as well as being a voip
company and thus not a 'real' phone company.  Not a household name.

Give it a few more days and it will pop up on a few web networks but the
only mention you'll see otherwise is how you can't trust voip companies to
stay up.

On Mon, Sep 27, 2021, 5:32 PM Mark Wiles via VoiceOps 
wrote:

> I have been asking myself that question all day… how is this not somehow
> covered on the news somewhere?
>
>
>
>
>
>
>
> *From:* VoiceOps  *On Behalf Of *Carlos
> Alvarez
> *Sent:* Monday, September 27, 2021 8:04 PM
> *To:* Voiceops.org 
> *Subject:* Re: [VoiceOps] Bandwidth - Monday Outage
>
>
>
> I never watch news, but I would have expected my news cycle addict friends
> to be asking me by now.  Hmm.  There have to be some three letter agencies
> fully involved, too.
>
>
>
>
>
>
>
> On Mon, Sep 27, 2021 at 4:57 PM Pete Eisengrein 
> wrote:
>
> Bandwidth is a $2.5B publicly traded company... how is this not national
> news?
>
>
>
> On Mon, Sep 27, 2021 at 5:44 PM Ryan Delgrosso 
> wrote:
>
> Would it? Or would SIP/TLS supplant that?
>
> The VZ VPN requirement was a bad solution to a paranoid delusion that
> really didnt solve anything.
>
> As were all being dragged kicking and screaming into TLS based peering for
> the sake of SHAKEN/STIR why not fully embrace what it provides?
>
> On 9/27/2021 2:35 PM, Aryn Nakaoka 808.356.2901 wrote:
>
> If its SIP based, Verizon standard to run a VPN would become a norm.
>
>
>
>
>
>
>
>
> Aryn Nakaoka
> anaka...@trinet-hi.com
> Direct: 808.356.2901
>
> 518 Holokahana Lane
>
> Honolulu, Hi 96817
>
>
>
> AlohaTone Mobile: https://youtu.be/PdUyuf0hTYY
>
>
>
> A Better Solution https://www.trinet-hi.com/abettersolution.pdf
>
> 
>
> Aloha Tone PBX  https://www.youtube.com/watch?v=96YWPY9wCeU
>
>
>
> CONFIDENTIALITY NOTICE:  The information contained in this email and any
> attachments may be privileged, confidential and protected from disclosure.
> Any disclosure, distribution or copying of this email or any attachments by
> persons or entities other than the intended recipient is prohibited. If you
> have received this email in error, please notify the sender immediately by
> replying to the message and deleting this email and any attachments from
> your system. Thank you for your cooperation.
>
>
>
>
>
> On Mon, Sep 27, 2021 at 11:27 AM Ryan Delgrosso 
> wrote:
>
> Do we know this is a SIP/RTP targeted volumetric attack and those arent
> just collateral damage in a more plebian attack aimed ad portals/apis or
> routers?
>
> I can understand them being tight lipped but some transparency helps the
> situation.
>
> I wonder if DHS is involved yet?
>
> On 9/27/2021 1:48 PM, Jay Hennigan via VoiceOps wrote:
> > On 9/27/21 13:30, Darren via VoiceOps wrote:
> >> I know it’s hard to be patient but I can’t imagine they’re NOT all
> >> hands on deck.
> >>
> >> The reality is probably that the DDoS attack is now so big, they
> >> can’t handle it on their own, so they’re scrambling to contract out
> >> with another provider who can handle it. That would explain why the
> >> BGP routes they advertise have shifted. These DDoS products typically
> >> take weeks to setup, so they’re likely having to scramble. I’ll be
> >> surprised if this does NOT continue tomorrow (unfortunately).
> >
> > From my understanding this is not your typical volumetric DDoS but
> > something specific to SIP or VoIP and thus the typical scrubbing
> > services aren't going to be effective against the voice side of things.
> >
> > Obviously they are keeping things close to the vest in order not to
> > give too much information to the bad guys but I agree that it may take
> > some time to resolve.
> >
> >> *From: *VoiceOps  on behalf of Carlos
> >> Alvarez 
> >> *Date: *Monday, September 27, 2021 at 1:23 PM
> >
> >> Generic SIP client here, and the ongoing "continue to investigate"
> >> notices are infuriatingly like "we have no damn clue what we're
> >> doing."  Try explaining to customers why it's not "our fault*" and
> >> that there's no way to estimate a repair time.
> >
> > I think the ongoing "continue to investigate" messages are fine.
> > They're obviously dealing with a major incident and trying their best
> > to keep their customers informed. This IMHO beats silence.
> >
> >> *Our fault for choosing them I guess, but not something we can fix in
> >> minutes.
> >
> > The same thing could and has affected others. Voip.ms
> 
> has been dealing
> > with a similar attack for at least a week. We've had excellent service
> > from Bandwidth for 

Re: [VoiceOps] thinQ is making hay while Bandwidth is down

[Karl Douthit]

Mobile carriers will do an internal short term forwarding while LRN changes
get pushed or will use their existing agreements for porting and push for
an LRN change live.  If you have access to NPAC LRN updates you can make
your changes but that does not guarantee that others see them ASAP, so
usually it is a bit of both.

On Mon, Sep 27, 2021, 3:12 PM Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

>
> > On Sep 27, 2021, at 6:04 PM, Aryn Nakaoka 808.356.2901 <
> anaka...@trinet-hi.com> wrote:
> >
> > How do cell phone companies port instantly? I can walk into Verizon and
> they can port my Tmobile number to them. Or are they all sharing a back
> end?
>
> It’s got to be something like that. Whatever it is, VoIP ITSPs don’t have
> it through their intermediated supply chain of ULCs.
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STIR/SHAKEN concerns

[Karl Douthit]

I'm just enjoying (not really) sending calls to VZ/ATT mobile numbers and
getting the response back from both that the SIP calls are going into their
TDM network so, oops, token gone.

On Fri, Aug 20, 2021 at 10:51 AM Mike Johnston  wrote:

> > 2. If your network is partially TDM and partially VOIP, have you
> experienced any issues with either of them? What are your future concerns
> since STIR/SHAKEN does not work with TDM?
>
> We have a mix of TDM and SIP.  We are continuing to work towards an all
> SIP network.  However, our aging management is still stuck in the legacy
> mindset where TDM made us money (subsidies).  There are other reasons as
> well, such as simply a resistance to change, lack of knowing how
> something works can lead to a fear of it, etc.  I am hoping and praying
> that STIR/SHAKEN _NEVER_ works with TDM, so it forces our hand to an all
> SIP environment.
>
> We have both SIP and TDM trunking with Inteliquent for toll sort of
> stuff.  All of our EAS trunks with neighboring telcos is still TDM only.
>
> > 10. I tried to keep my list simple but I would love to hear your
> thoughts on anything I missed.
>
> For whatever reason, some telcos are simply marking everything as "A".
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>


-- 

Karl Douthit

10572 Calle Lee  #123

Los Alamitos Ca. 90720

(562) 257-3590 (Desk)

(562) 824-0757 <%28562%29%20827-0757> (Mobile)

*www.piratel.com <http://www.piratel.com/>*
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TransNexus STIR/SHAKEN Stats

[Karl Douthit]

When we started signing calls back in December it was a no brainer to use a
CDN for cert cache / hosting.

Geo location and best path for lookups vs a ton of PDD.

On Thu, Jul 8, 2021 at 11:24 AM Jared Geiger  wrote:

> TransNexus made a blog post
> https://transnexus.com/blog/2021/shaken-stats-june/ which shows the
> percentage of calls that had Passport headers in June.
>
> Inteliquent, Lumen/Centurylink, Frontier, Windstream, Intrado, Peerless
> seem to be missing from the list unless they are under the SaaS providers.
>
> I'm glad that many carriers are putting certs behind a CDN. The ones that
> aren't seem split between being hosted on AWS and self hosted. Validation
> will add to PDD, so CDNs will hopefully make it less of an issue.
>
> ~Jared
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>


-- 

Karl Douthit

10572 Calle Lee  #123

Los Alamitos Ca. 90720

(562) 257-3590 (Desk)

(562) 824-0757 <%28562%29%20827-0757> (Mobile)

*www.piratel.com <http://www.piratel.com/>*
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Fake Voicemail Anti-Robocall Tactics

[Karl Douthit]

Stir will only help if carriers actually pass or allow tokens.  Still
waiting on several tier 1 carriers to take them.

On Tue, Feb 16, 2021 at 9:35 AM Glen Gerhard  wrote:

> Hopefully Stir/Shaken will make this a moot point. Calvin, are you saying
> that a 608 is the recommended response for a call that is being rejected
> due to S/S attestation or CVT reasons?
>
> ~Glen
>
> On 2/16/2021 8:19 AM, Calvin Ellison wrote:
>
> Today we received a notice from one of our underlying carriers that
> included the following statement:
>
> * If a customer spoofs an ANI that they do not own, the clec's can forward
>> to call to a voiceless Voicemail which appears to be FAS.
>>
>
> Is there any legal device that actually supports this practice? I'm
> looking for a specific statute, FCC rule, precedent in a judicial ruling,
> or the like.
>
> The FCC has ruled that the SIP 608 response code is to be used for
> signaling when a call is rejected. I doubt the FCC or FTC has ruled that
> terminating carriers are permitted to cause loss of trust and revenue
> between upstream intermediate and originating carriers.
>
>
> Regards,
>
> *Calvin Ellison*
> Systems Architect
> calvin.elli...@voxox.com
> +1 (213) 285-0555
>
> ---
> *voxox.com <http://www.voxox.com/> *
> 5825 Oberlin Drive, Suite 5
> San Diego, CA 92121
> [image: Voxox]
>
> ___
> VoiceOps mailing 
> listVoiceOps@voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops
>
>
> --
> Glen gerhardg...@cognexus.net
> 858.324.4536
>
> Cognexus, LLC
> 7891 Avenida Kirjah
> San Diego, CA 92037
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>


-- 

Karl Douthit

10572 Calle Lee  #123

Los Alamitos Ca. 90720

(562) 257-3590 (Desk)

(562) 824-0757 <%28562%29%20827-0757> (Mobile)

*www.piratel.com <http://www.piratel.com/>*
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Fake Voicemail Anti-Robocall Tactics

[Karl Douthit]

It's all fun and games until someone's parent doesn't get their daily
reminder phone call to take their medication due to the call getting routed
to nothing (this has been happening to one of our customers).


On Tue, Feb 16, 2021 at 8:45 AM Carlos Alvarez  wrote:

> But the ridiculous side of this is that there are valid reasons to "spoof"
> numbers.  We have two customers who need to do it all the time, and it's
> legal, as well as demanded by their customers.
>
>
> On Tue, Feb 16, 2021 at 9:37 AM  wrote:
>
>> Legal or not it’s genius. Humans will notice right away and it’ll cost
>> for the robocallers.
>>
>> Sent from my iPhone
>>
>> On Feb 16, 2021, at 11:23 AM, Calvin Ellison 
>> wrote:
>>
>> 
>> Today we received a notice from one of our underlying carriers that
>> included the following statement:
>>
>> * If a customer spoofs an ANI that they do not own, the clec's can
>>> forward to call to a voiceless Voicemail which appears to be FAS.
>>>
>>
>> Is there any legal device that actually supports this practice? I'm
>> looking for a specific statute, FCC rule, precedent in a judicial ruling,
>> or the like.
>>
>> The FCC has ruled that the SIP 608 response code is to be used for
>> signaling when a call is rejected. I doubt the FCC or FTC has ruled that
>> terminating carriers are permitted to cause loss of trust and revenue
>> between upstream intermediate and originating carriers.
>>
>>
>> Regards,
>>
>> *Calvin Ellison*
>> Systems Architect
>> calvin.elli...@voxox.com
>> +1 (213) 285-0555
>>
>> ---
>> *voxox.com <http://www.voxox.com/> *
>> 5825 Oberlin Drive, Suite 5
>> San Diego, CA 92121
>> [image: Voxox]
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> _______
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>


-- 

Karl Douthit

10572 Calle Lee  #123

Los Alamitos Ca. 90720

(562) 257-3590 (Desk)

(562) 824-0757 <%28562%29%20827-0757> (Mobile)

*www.piratel.com <http://www.piratel.com/>*
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Confusing Spoofing Customers

[Karl Douthit]

Sounds like you have either:

A)  The group making the calls are trying to get live people, and when they
leave a message they are leaving a "real" call back number in an attempt to
play at being legitimate, even if that number does not go back to them.

or

B)  The group making the calls were giving a random / bad / incorrect
number to use.

Either way, I'd request a traceback from your inbound trunks that the call
came in on and see if the process can work its way back to the originator
of the call.  You can also file a complaint with the FCC but that will take
longer to get processed.  Or do both.

In the meantime if this is becoming an issue, you could perhaps put a rule
for your customer that "unknown" gets routed into an IVR or voicemail
bucket for validation later on.

On Fri, Nov 6, 2020 at 8:30 AM Christopher Aloi  wrote:

> Hey All,
>
> We have observed multiple reports of our business customer telephone
> numbers being used by a bad actor leaving messages for consumers.  The
> consumers receiving the call do not have a direct relationship with us.
> The bad actor presents “unknown” as the caller-id and leaves a harsh
> message asking for personal information and demanding a call back (illegal
> sounding collector call).  The number the bad actor leaves to be called
> back (in a verbal message) is owned by one of our business customers.  So,
> the response to the “bad” call goes back to the legit company.  The
> consumer calls our business customer back and explains the message, the
> business customer has no record of an outbound call to the consumer and is
> perplexed by the call.
>
> We have a few customers impacted by this and in every instance we have no
> record of the outbound (bad actor) call leaving our network.  I can’t
> figure out the scam here, they aren’t pumping traffic and the call goes
> back to the legit business, leaving no opportunity for the bad actor to
> engage with the consumer.  Anyone have any thoughts?
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>


-- 

Karl Douthit

10572 Calle Lee  #123

Los Alamitos Ca. 90720

(562) 257-3590 (Desk)

(562) 824-0757 <%28562%29%20827-0757> (Mobile)

*www.piratel.com <http://www.piratel.com/>*
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops