This does not get even to the accuracy of the account records. This issue is family and obviously true.
I was able to narrow it down to mobile carriers using Syniverse to port out from Inteliquent/Onvoy. It seems like Syniverse only request a CSR but never submit an LSR. Does anybody know anything about that? Is there a contact person for Syniverse in this list? Thanks again. On Tue, Mar 5, 2019 at 12:33 PM Mike Ray, MBA, CNE, CTE < m...@astrocompanies.com> wrote: > Our experience has been similar, although the problem can be overcome if > the gaining carrier is sufficiently determined as we are for porting-in > from those difficult carriers. The more resellers involved, the lower the > quality of the losing carrier’s records, for sure. > > > > Our systems are designed so that our wholesale customer is responsible for > adding end user information to our systems either via portal or API, then a > gaining carrier sees that information when a CSR is requested on the > carrier side. The gaining carrier submits an LSR from there, the wholesale > customer is notified automatically, an FOC is issued and NPAC release is > performed. This makes the process quick and simple, while still giving the > wholesale customer time to stop the port if unauthorized. > > > > We have certainly seen wireless carriers tell a subscriber that their > number is non-portable, when the wireless carrier didn’t even pull the > CSR. That’s just lazy on their part, but we’ve also seen sufficiently > determined end users get them to do it with some prodding. > > > > Regards, > > > > Mike > > > > Mike Ray, MBA, CNE, CTE > > Terra Nova Telecom, Inc. > > 11523 Palm Brush Trail #401 > > Lakewood Ranch, FL 34202 > > DIRECT: call or text 941 600-0207 > > *http://www.tntelecom.net <http://www.tntelecom.net>* > > > > > > *From:* VoiceOps <voiceops-boun...@voiceops.org> *On Behalf Of *Ryan > Delgrosso > *Sent:* Tuesday, March 5, 2019 12:00 PM > *To:* voiceops@voiceops.org > *Subject:* Re: [VoiceOps] Growing difficulties porting DIDs out of major > VoIP carriers > > > > 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@voiceops.org > > https://puck.nether.net/mailman/listinfo/voiceops > > _______________________________________________ > 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