Have the customer sue Thinq, if they feel it is worth it.

Or ask Thinq to pay the customer some amount.

Otherwise move on, learn never to trust your carriers, constantly monitor
and validate them, and hope you'll avoid a similar issue in the future.

Beckman

On Mon, 20 Mar 2023, Carlos Alvarez via VoiceOps wrote:

To get everyone updated, we were just told that nothing will be done, and
our customer is just out of luck on what they have already spent
publicizing the incorrectly assigned number.  I have no idea yet if/how
they will try to pass this cost to us, or if/when lawyers will get
involved.  Mistakes happen of course, but in this chain of events, who is
liable for actual costs due to some amount of negligence?


On Mar 14, 2023 at 9:48:09 PM, Todd Wolf <tw...@wolftechgroup.com> wrote:


Bill copy and signed resporg documents...should show a clear path of
ownership. If your docs supersede the one after the fact and you didn't
release the number or lose it due to non payment with notice etc..



-----Original Message-----
From: VoiceOps <voiceops-boun...@voiceops.org> On Behalf Of Peter Beckman
via VoiceOps
Sent: Tuesday, March 14, 2023 9:30 PM
To: Carlos Alvarez <caalva...@gmail.com>
Cc: VoiceOps <voiceops@voiceops.org>
Subject: Re: [VoiceOps] TF number ported out/re-assigned without
authorization

On Tue, 14 Mar 2023, Carlos Alvarez via VoiceOps wrote:

On Mar 14, 2023 at 2:03:17 PM, Peter Beckman <beck...@angryox.com> wrote:




We've also put numbers into production that our carrier provided,

only to find out they should not have been in their inventory at all.




I’ve learned this lesson, hence the test calls.  But this is a new one

on me; how often should we have to test all of our numbers??


 Should you HAVE to? Never. How often do you NEED to, so you can avoid
 situations like this? Once every 2 weeks in my estimation, unfortunately.

 I tried to find an affordable way to ensure that the ILEC/CLEC/Resporg of
 one of our numbers had not changed, but I couldn't find one. I also found
 that if the number moved internally, e.g. one Bandwidth customer to
 another, I'd never detect it. Test Calls and SMS messages seemed to be the
 most deterministic indicator.

 I will commend and recommend Alcazar Networks for offering a very
 reliable, though about 24 hours out of date, LNP/LRN API at affordable
 rates. USD$0.00025 per extended query, or a flat rate for higher usage.

 https://www.alcazarnetworks.com/data_services_lnp_lrn.php

 Anyone know of a RespOrg API that would tell us information about a TF
 number?

That’s uglier than a Pontiac Aztek.


 But reliably detects carrier failures.

I just hope thinQ can handle this.  Looking at our call records vs

their TF number history, it’s clear when it was ours, then taken, then

given out again.  I believe someone else on the list suggested that

previous ownership is superior to current ownership?  If it comes down

to that, anyone know the process to enforce it?


 The challenge here is what is ownership?

 Really, nobody owns a phone number. NANPA leases it to carriers, and
 carriers lease it to companies or individuals. It is up to the carrier to
 lease it to only one entity. Thinq failed to do so. IMHO Thinq should be
 working their butts off to fix this for you.

 I do not know of an FCC rule that would help you scare Thinq into doing
 the right thing and fixing this.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beck...@angryox.com
https://www.angryox.com/
---------------------------------------------------------------------------



---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beck...@angryox.com                                https://www.angryox.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

Reply via email to