[VoiceOps] AT&T / Onvoy / Vonage call routing screwup after LNP

Oren Yehezkely orenyny at gmail.com
Mon Dec 5 09:16:37 EST 2016

Had similar experiences, but with different vendor.
I would try to open a ticket with ATT to fix their routing. I know, it
won't be easy.
I would also try to speak with Vonage. I wouldn't have the customer
disconnect before calls are flowing correctly.
If this doesn't work, and you wait another day or two with no results, I
may try to port the numbers away from convoy.

Interested to know how you solved it...
Good luck.

On Dec 5, 2016 8:06 AM, "Nathan Anderson" <nathana at fsr.com> wrote:

> So here's a weird one: we took over a small business account from Vonage.
> Vonage was using Onvoy for origination, and we elected to keep the TNs with
> Onvoy (through a wholesaler).  So the "port" only consisted of Onvoy
> repointing traffic for those TNs internally away from Vonage and to our
> reseller, with no LRN change.
> The weird bit is that we definitely are seeing some traffic for those
> numbers hitting us, but it's been nearly 72 hours now and some calls are
> still ringing their Vonage ATAs.  I couldn't tell you definitively where
> the delineation is, but I can tell you, for example, that if I call any of
> the TNs from my AT&T cell, those calls still hit Vonage, so I can at least
> reproduce the problem at-will.  This is for a local real-estate office, and
> AT&T is big in our relatively rural market, so even if it turns out that
> AT&T is the only provider that is affected, that is still a huge percentage
> of our end-user's client base.  And the frustrating bit is that traffic is
> now effectively being "forked", which is a huge inconvenience for our
> end-user since they have an old key system with analog trunks and so we
> have to choose between having our IAD hooked up to their KSU or having
> their stack of Vonage ATAs hooked up.  (For now, we have left the Vonage
> ATAs in place, and we are forwarding calls tha
>  t come to us to a single line from the ILEC that this office ended up
> keeping.  I don't know what we would have done if they didn't have that
> line.)
> Onvoy swears up and down that everything is configured correctly on their
> side, and given that we are at least getting *some* calls, I am inclined to
> believe them.  When I give them call examples from my cell phone, they say
> that they don't even see those calls hitting their systems at all.  At this
> point, the running theory is that AT&T must have some kind of direct
> peering with Vonage, and Onvoy isn't in the loop at all on those calls.  If
> that's the case, then perhaps everything magically works itself out once I
> have the end-user call up Vonage and have them close out the account
> completely.  But I'm not sure it is worth the risk of having them take that
> step with things as they are, on the off-chance that I guessed wrong
> (instead of the problem getting fixed, calls from AT&T start going to
> /dev/null).
> Has anybody encountered anything like this before, or heard of national
> wireless carriers doing direct peering with national VoIP providers while
> completely bypassing PSTN switching infrastructure?  Are there any AT&T,
> Onvoy, and/or Vonage reps reading this who can help un-**** this cluster?
> Thanks,
> --
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
> _______________________________________________
> 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/20161205/292508d5/attachment.html>

More information about the VoiceOps mailing list