The fact that Vonage hasn't disconnected the ATAs makes me feel like
their disconnect workflow hasn't quite worked, and if they have a direct
peering arrangement with AT&T this could be involved in that. They may
try to contact Vonage as well and ask them about it, they certainly have
experienced it somewhere before I'm sure, and might have a workflow for
fixing it.
Of course, opening a ticket with the originating carrier (AT&T)
definitely needs to happen, since they're making the routing decision
they're the ones that can fix it.
-Paul
On 12/05/2016 09:16 AM, Oren Yehezkely wrote:
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
<mailto: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 <mailto:nath...@fsr.com>
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
<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
