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

[Oren Yehezkely]

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 <
mike at 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-bounces at voiceops.org> *On Behalf Of *Ryan
> Delgrosso
> *Sent:* Tuesday, March 5, 2019 12:00 PM
> *To:* voiceops at 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 at voiceops.org
>
> https://puck.nether.net/mailman/listinfo/voiceops
>
> _______________________________________________
> 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/20190306/5347a208/attachment.html>