[VoiceOps] TF number ported out/re-assigned without authorization

[Paul Timmins]

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 <voiceops at voiceops.org> 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 <twolf at 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-bounces at voiceops.org> On Behalf Of Peter Beckman
>>> via VoiceOps
>>> Sent: Tuesday, March 14, 2023 9:30 PM
>>> To: Carlos Alvarez <caalvarez at gmail.com>
>>> Cc: VoiceOps <voiceops at 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 <beckman at 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
>>> beckman at angryox.com
>>> https://www.angryox.com/
>>> ---------------------------------------------------------------------------
>>> 
>> 
> 
> ---------------------------------------------------------------------------
> Peter Beckman                                                  Internet Guy
> beckman at angryox.com                                https://www.angryox.com/
> ---------------------------------------------------------------------------_______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops