<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
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.<br>
<br>
-Paul<br>
<br>
On 12/05/2016 09:16 AM, Oren Yehezkely wrote:<br>
</div>
<blockquote
cite="mid:CAL+WrhLWxZ1qqKZjDSifLChzjYCSjmZKkfcxdwqRXh2UAgVF2A@mail.gmail.com"
type="cite">
<div dir="auto"><span
style="font-family:sans-serif;font-size:13.696px">Had similar
experiences, but with different vendor.</span>
<div dir="auto"
style="font-family:sans-serif;font-size:13.696px">I would try
to open a ticket with ATT to fix their routing. I know, it
won't be easy.</div>
<div dir="auto"
style="font-family:sans-serif;font-size:13.696px">I would also
try to speak with Vonage. I wouldn't have the customer
disconnect before calls are flowing correctly.</div>
<div dir="auto"
style="font-family:sans-serif;font-size:13.696px">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.</div>
<div dir="auto"
style="font-family:sans-serif;font-size:13.696px"><br>
</div>
<div dir="auto"
style="font-family:sans-serif;font-size:13.696px">Interested
to know how you solved it...<br>
</div>
<div dir="auto"
style="font-family:sans-serif;font-size:13.696px">Good luck.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Dec 5, 2016 8:06 AM, "Nathan
Anderson" <<a moz-do-not-send="true"
href="mailto:nathana@fsr.com">nathana@fsr.com</a>> wrote:<br
type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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<br>
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.)<br>
<br>
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).<br>
<br>
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?<br>
<br>
Thanks,<br>
<br>
--<br>
Nathan Anderson<br>
First Step Internet, LLC<br>
<a moz-do-not-send="true" href="mailto:nathana@fsr.com">nathana@fsr.com</a><br>
<br>
______________________________<wbr>_________________<br>
VoiceOps mailing list<br>
<a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>