I can’t imagine why the new user of the number would want all those misdirected calls, it’ll probably cost them a pretty penny. What a mess for everyone.
> On Mar 23, 2023, at 00:57, Peter Beckman via VoiceOps <[email protected]> > wrote: > > 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 <[email protected]> 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 <[email protected]> On Behalf Of Peter Beckman >>> via VoiceOps >>> Sent: Tuesday, March 14, 2023 9:30 PM >>> To: Carlos Alvarez <[email protected]> >>> Cc: VoiceOps <[email protected]> >>> 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 <[email protected]> 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 >>> [email protected] >>> https://www.angryox.com/ >>> --------------------------------------------------------------------------- >>> >> > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > [email protected] https://www.angryox.com/ > ---------------------------------------------------------------------------_______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
