Sounds like a possible ENUM routing issue if it's bypassing the PSTN. Was
Vonage notified of the port away by Onvoy?
Regards,
Andrew Paolucci
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
Subject: Re: [VoiceOps] AT&T / Onvoy / Vonage call routing screwup after LNP
Local Time: 5 December 2016 9:16 AM
UTC Time: 5 December 2016 14:16
From: oren...@gmail.com
To: voiceops@voiceops.org <VoiceOps@voiceops.org>
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" <nath...@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
nath...@fsr.com
_______________________________________________
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
