[VoiceOps] Growing difficulties porting DIDs out of major VoIP carriers

[Ryan Delgrosso]

I believe this has more to do with shoddy record keeping than anything. 
Most voip carriers will port their own numbers around multiple times 
(using scale as leverage to get better deals playing carriers off each 
other). When they do that its not uncommon for them to use the same info 
(like their office address) versus the actual customer info, or their 
address parser code to translate between carrier A's system and carrier 
B's system mangles something, or there has been some M&A activity and 
the merged databases have bad info.

In the end the new recorded address is not predictable by the customer 
and is easily and frequently rejected.

I am moving through a project right now to move numbers between carriers 
and have found my losing carrier has done exactly this.

With the state of record keeping and lack of appreciable standards I'm 
shocked that the LNP system works at all.

On 3/5/2019 8:41 AM, Oren Yehezkely wrote:
> Hello,
>
> I am hoping that someone may be able to shed some light as to the 
> difficulties mobile carriers have to port DIDs away from major VoIP 
> carriers such as Bandwidth and Onvoy.
>
> The problem does not seem to be on the VoIP providers. In most of the 
> cases, they do not even receive an LSR. The mobile carriers seem to be 
> asking for a CSR multiple times but never submit an LSR, then they 
> tell the EU that the port request has failed.
>
> In another case, when the DID is with Bandwidth, the ATT system tells 
> the customer that the number is with LOCKED with Google Voice and 
> cannot be ported. I wonder who builds these faulty systems for these 
> corporations?
>
> Any advice is appreciated.
>
> Oren
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20190305/77496f20/attachment.html>