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

[Paul Timmins]

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" <nathana at fsr.com 
> <mailto: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 <mailto:nathana at fsr.com>
>
>     _______________________________________________
>     VoiceOps mailing list
>     VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>
>     https://puck.nether.net/mailman/listinfo/voiceops
>     <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/20161205/c5b026d9/attachment.html>