TF number ported out/re-assigned without authorization
This is a huge problem, so while I?m waiting for thinQ to tell me what they can do, I thought I?d check with my other resources. They gave us a small block of TF numbers some time back, and we assigned them to one customer. We tested them in March of 2022. One of them was not put into use as it was for a pre-planned project this year; the customer needed to physically publish the number on posters, via letters, and by email. Now it?s time to start the project, and we find out that the number has been given to Telnyx. We were told by thinQ that it was part of a bad inventory load, but that can?t be possible since it did work. And we also have working numbers from the same batch (for now?that?s worrisome too). Currently the number goes to a fax tone, and we don?t know who owns it. I have not tried sending a fax. I?m not sure how I?d start that conversation. This seems like a massive failing on thinQ?s part. The end user is a regional government authority that has spread the number far and wide. In fact if you google the number, you get the government agency?s info. What can we force them to do? The project was to go live on Monday.
Do you have a <30 day invoice with the number on it? I would try to NASC it... it may set off a pissing match between you and the current user, but if you can show that you had it first... you may win it. [image: Star Telecom - Cloud Communications and Customer Experience Solutions] <http://www.startelecom.ca> <https://www.linkedin.com/company/star-telecom-www-startelecom-ca-/> <https://www.facebook.com/startelecomcanada> <https://twitter.com/startelecom?lang=en> <https://www.youtube.com/channel/UC7Us9bsIx2_ua1-LSQ3FGhw> *Ivan Kovacevic* www.startelecom.ca On Tue, Mar 14, 2023 at 12:45?PM Carlos Alvarez via VoiceOps < voiceops at voiceops.org> wrote:
This is a huge problem, so while I?m waiting for thinQ to tell me what they can do, I thought I?d check with my other resources. They gave us a small block of TF numbers some time back, and we assigned them to one customer. We tested them in March of 2022. One of them was not put into use as it was for a pre-planned project this year; the customer needed to physically publish the number on posters, via letters, and by email. Now it?s time to start the project, and we find out that the number has been given to Telnyx. We were told by thinQ that it was part of a bad inventory load, but that can?t be possible since it did work. And we also have working numbers from the same batch (for now?that?s worrisome too).
Currently the number goes to a fax tone, and we don?t know who owns it. I have not tried sending a fax. I?m not sure how I?d start that conversation.
This seems like a massive failing on thinQ?s part. The end user is a regional government authority that has spread the number far and wide. In fact if you google the number, you get the government agency?s info. What can we force them to do? The project was to go live on Monday.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.
We don?t list DIDs on our invoices when customers have a large number (and they have close to 1k). We do have CDRs showing that we test called it last year, and thinQ has confirmed that a mistake caused it to be taken back by their resporg. So I think ownership evidence is solid. I don?t know what you mean by NASC it, that?s probably access we do not have, as an ultra-small ITSP. We just go through thinQ and Bandwidth for all number management and porting. They are trying to get it released back from Telnyx. If that is refused, we?re going to be headed into a storm, I think. On Mar 14, 2023 at 9:54:48 AM, Ivan Kovacevic <ivan.kovacevic at startelecom.ca> wrote:
Do you have a <30 day invoice with the number on it?
I would try to NASC it... it may set off a pissing match between you and the current user, but if you can show that you had it first... you may win it.
[image: Star Telecom - Cloud Communications and Customer Experience Solutions] <http://www.startelecom.ca>
<https://www.linkedin.com/company/star-telecom-www-startelecom-ca-/> <https://www.facebook.com/startelecomcanada> <https://twitter.com/startelecom?lang=en> <https://www.youtube.com/channel/UC7Us9bsIx2_ua1-LSQ3FGhw>
*Ivan Kovacevic*
www.startelecom.ca
On Tue, Mar 14, 2023 at 12:45?PM Carlos Alvarez via VoiceOps < voiceops at voiceops.org> wrote:
This is a huge problem, so while I?m waiting for thinQ to tell me what they can do, I thought I?d check with my other resources. They gave us a small block of TF numbers some time back, and we assigned them to one customer. We tested them in March of 2022. One of them was not put into use as it was for a pre-planned project this year; the customer needed to physically publish the number on posters, via letters, and by email. Now it?s time to start the project, and we find out that the number has been given to Telnyx. We were told by thinQ that it was part of a bad inventory load, but that can?t be possible since it did work. And we also have working numbers from the same batch (for now?that?s worrisome too).
Currently the number goes to a fax tone, and we don?t know who owns it. I have not tried sending a fax. I?m not sure how I?d start that conversation.
This seems like a massive failing on thinQ?s part. The end user is a regional government authority that has spread the number far and wide. In fact if you google the number, you get the government agency?s info. What can we force them to do? The project was to go live on Monday.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.
NASC is a name for a process where your RespOrg takes ownership of the TFN without the cooperation of the losing carrier. So you can expect it to be bumpier than the usual give and take. If you are not your own RespOrg - then thinQ is likely not going to cooperate - since it would create liability. Although arguably - they are already liable. [image: Star Telecom - Cloud Communications and Customer Experience Solutions] <http://www.startelecom.ca> <https://www.linkedin.com/company/star-telecom-www-startelecom-ca-/> <https://www.facebook.com/startelecomcanada> <https://twitter.com/startelecom?lang=en> <https://www.youtube.com/channel/UC7Us9bsIx2_ua1-LSQ3FGhw> *Ivan Kovacevic* www.startelecom.ca On Tue, Mar 14, 2023 at 1:40?PM Carlos Alvarez via VoiceOps < voiceops at voiceops.org> wrote:
We don?t list DIDs on our invoices when customers have a large number (and they have close to 1k). We do have CDRs showing that we test called it last year, and thinQ has confirmed that a mistake caused it to be taken back by their resporg. So I think ownership evidence is solid.
I don?t know what you mean by NASC it, that?s probably access we do not have, as an ultra-small ITSP. We just go through thinQ and Bandwidth for all number management and porting.
They are trying to get it released back from Telnyx. If that is refused, we?re going to be headed into a storm, I think.
On Mar 14, 2023 at 9:54:48 AM, Ivan Kovacevic < ivan.kovacevic at startelecom.ca> wrote:
Do you have a <30 day invoice with the number on it?
I would try to NASC it... it may set off a pissing match between you and the current user, but if you can show that you had it first... you may win it.
[image: Star Telecom - Cloud Communications and Customer Experience Solutions] <http://www.startelecom.ca>
<https://www.linkedin.com/company/star-telecom-www-startelecom-ca-/> <https://www.facebook.com/startelecomcanada> <https://twitter.com/startelecom?lang=en> <https://www.youtube.com/channel/UC7Us9bsIx2_ua1-LSQ3FGhw>
*Ivan Kovacevic*
www.startelecom.ca
On Tue, Mar 14, 2023 at 12:45?PM Carlos Alvarez via VoiceOps < voiceops at voiceops.org> wrote:
This is a huge problem, so while I?m waiting for thinQ to tell me what they can do, I thought I?d check with my other resources. They gave us a small block of TF numbers some time back, and we assigned them to one customer. We tested them in March of 2022. One of them was not put into use as it was for a pre-planned project this year; the customer needed to physically publish the number on posters, via letters, and by email. Now it?s time to start the project, and we find out that the number has been given to Telnyx. We were told by thinQ that it was part of a bad inventory load, but that can?t be possible since it did work. And we also have working numbers from the same batch (for now?that?s worrisome too).
Currently the number goes to a fax tone, and we don?t know who owns it. I have not tried sending a fax. I?m not sure how I?d start that conversation.
This seems like a massive failing on thinQ?s part. The end user is a regional government authority that has spread the number far and wide. In fact if you google the number, you get the government agency?s info. What can we force them to do? The project was to go live on Monday.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message.
You're not alone. We've had numbers ported out without authorization or even the correct information before, and we get billed for it for months until someone notices. 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. We went as far as sending test calls or SMS messages to each number in our inventory about once every 2 weeks, and generate a report of numbers that have failed the test (we didn't receive the inbound call or text). This has helped us detect issues earlier, but not prevent them. We have implemented Port Out Webhooks with Bandwidth and that has prevented several incorrect Port Outs. Mistakes happen, but Thinq seems to have royally messed up here. There is no requirement for carriers to regularly validate that they are still the CLEC/ILEC/RespOrg carrier of record for a number, and honestly there is no proactive notification sometimes either, so they simply might not know. But most carriers assume that if it is in their system, it is probably still there and theirs. This just isn't the case in a small number of situations, and these situations really suck. Beckman On Tue, 14 Mar 2023, Carlos Alvarez via VoiceOps wrote:
This is a huge problem, so while I?m waiting for thinQ to tell me what they can do, I thought I?d check with my other resources. They gave us a small block of TF numbers some time back, and we assigned them to one customer. We tested them in March of 2022. One of them was not put into use as it was for a pre-planned project this year; the customer needed to physically publish the number on posters, via letters, and by email. Now it?s time to start the project, and we find out that the number has been given to Telnyx. We were told by thinQ that it was part of a bad inventory load, but that can?t be possible since it did work. And we also have working numbers from the same batch (for now?that?s worrisome too).
Currently the number goes to a fax tone, and we don?t know who owns it. I have not tried sending a fax. I?m not sure how I?d start that conversation.
This seems like a massive failing on thinQ?s part. The end user is a regional government authority that has spread the number far and wide. In fact if you google the number, you get the government agency?s info. What can we force them to do? The project was to go live on Monday.
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
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?? We went as far as sending test calls or SMS messages to each number in our
inventory about once every 2 weeks, and generate a report of numbers that have failed the test (we didn't receive the inbound call or text). This has helped us detect issues earlier, but not prevent them.
That?s uglier than a Pontiac Aztek. 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?
I'm fighting one now for a local number. The number was with BW and used rarely. It disappeared from our account and no one was aware for 12 months. It's now with T-Mobile and we've been told to basically piss off. That nothing will happen.. On Tue, Mar 14, 2023 at 5:11?PM Carlos Alvarez via VoiceOps < voiceops at voiceops.org> 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??
We went as far as sending test calls or SMS messages to each number in our
inventory about once every 2 weeks, and generate a report of numbers that have failed the test (we didn't receive the inbound call or text). This has helped us detect issues earlier, but not prevent them.
That?s uglier than a Pontiac Aztek.
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?
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- David Wessell Owner t: 828.575.0030 ext 101 e: david at ringfree.com | w: ringfree.com <http://www.ringfree.com/>
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/ ---------------------------------------------------------------------------
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/ ---------------------------------------------------------------------------
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/ ---------------------------------------------------------------------------
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/ ---------------------------------------------------------------------------
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
I?m not a lawyer nor a legal strategist, but I see few downsides in going to war for it. At the very least, the matter will go to the general counsel and maybe get some actual attention. ? Alex
On Mar 23, 2023, at 2:47 AM, Paul Timmins via VoiceOps <voiceops at voiceops.org> wrote:
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
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
I agree, but unfortunately our customer has chosen to not fight it. Since this would likely involve them, I have to respect that. -- Sent from my iPad
On Mar 23, 2023, at 6:25 AM, Alex Balashov via VoiceOps <voiceops at voiceops.org> wrote:
?I?m not a lawyer nor a legal strategist, but I see few downsides in going to war for it. At the very least, the matter will go to the general counsel and maybe get some actual attention.
? Alex
On Mar 23, 2023, at 2:47 AM, Paul Timmins via VoiceOps <voiceops at voiceops.org> wrote:
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
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (7)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
caalvarez＠gmail.com -
david＠ringfree.com -
ivan.kovacevic＠startelecom.ca -
paul＠timmins.net -
twolf＠wolftechgroup.com