Did Sonic voice maintenance knock out my ATA?

[Neil]

I also had that problem last week. Just for everyone's information, if you hear that "Device not registering" message when you pick up a phone, you can punch ***999 on the keypad (three asterisks, then three 9's) and the device will reboot. You don't have to physically pull the plug.

That being said, I agree with the others, and I'll go a step further. Voice telephony is a critical utility when E-911 is tied to it. You really don't want to discover that your ATA's not functioning and needs a reboot/power cycle when you're in a panic to reach 911 because someone's having an emergency, especially if it's you and you're "tech support" for your household.

[wresnick]

I'm relatively new to VOIP and to FTTN for that matter, and this is one of many problems I had. I left town not long after Sonic finally got VOIP working for me, which took three weeks after FTTN install (but that's another story) so when I got back I had no history of reliability to begin with. All I knew was that the fourth light was out, and might have been out for days. Given this thread, it was most likely the case. I power cycled the ATA, and the problem recurred the next day. Things have been working ever since, but the issue I have is that I called Sonic that day after it recurred and they were supposed to get back to me. I'm still waiting to hear back from them on a separate issue and that's not happening either.

Everything from the time of the FTTN install until now has been a series of calls resulting in misinformation, contradicting information, and unresolved problems. Should I be giving up on Sonic support and trying to rely on the forum for now on? Even at that I still have an issue that I couldn't solve relying on forum posts.

Even if Sonic had told me that others had had the problem at that time and it has cleared up, at least I would have known what I might be able to expect. It's been working for 10 days now, which is the longest ever given my limited experience. But without hearing back, I have no clue whether I can rely on this.

[timjackson]

This was an un-intended side effect of moving to TCP/443 for all of the traffic. We had originally launched all of this on UDP/80 and UDP/443, but some of the AT&T RGs had some issues with this forcing us to move to TCP/443 in a bit of a hurry.

After doing that, we did a maintenance that *shouldn't* have caused any issues, but it did reset the TCP sessions on all of the ATAs. It would normally be expected that once the ATAs get their TCP session reset, they would re-establish, but they did not. Evidently this was caused by some default value in the Grandstream configuration that seems unrelated, but after changing the default to off it's resolved this issue and shouldn't happen again going forward.

The RG interop issues have been something of a nightmare to work around as there are multiple different ones, and each one seems to treat the traffic a little differently. As for now, we think we've got everything (except for that weird DNS issue someone posted about yesterday) knocked out and things should be settling down.

[dherr]

Heh, great fun! Thanks for the update and don't forget to keep an eye out for fresh issues with AT&T firmware updates. I just got the "10" update to the 5031 and it seems *good* for my VOIP. I now get an "A" grade for the bufferbloat test.

Big note for other FTTN customers....

Make sure to setup the Sonic voicemail option even if you are using your own answering device. Set the Sonic vmail to answer some seconds *after* your own machine would answer. It is also nice to have the email notification enabled. In normal working situations the Sonic vmail will not activate. If the ATA is offline then people will roll over to Sonic vmail and they can leave a message that gets emailed to you, which alerts you to the problem. You can even create a special message to let people know that you might be having power/internet/phone issue.

[wresnick]

It is also nice to have the email notification enabled. In normal working situations the Sonic vmail will not activate. If the ATA is offline then people will roll over to Sonic vmail and they can leave a message that gets emailed to you, which alerts you to the problem. You can even create a special message to let people know that you might be having power/internet/phone issue.

Having the Accession Communicator software let me get phone calls even when the ATA was down and what tipped me off was that my cell phone rang and the home phone didn't. Otherwise I would not have had a clue. That software is far from perfect but in this case it was great.

[Guest]

This was an un-intended side effect of moving to TCP/443 for all of the traffic. We had originally launched all of this on UDP/80 and UDP/443, but some of the AT&T RGs had some issues with this forcing us to move to TCP/443 in a bit of a hurry.

After doing that, we did a maintenance that *shouldn't* have caused any issues, but it did reset the TCP sessions on all of the ATAs. It would normally be expected that once the ATAs get their TCP session reset, they would re-establish, but they did not. Evidently this was caused by some default value in the Grandstream configuration that seems unrelated, but after changing the default to off it's resolved this issue and shouldn't happen again going forward.

The RG interop issues have been something of a nightmare to work around as there are multiple different ones, and each one seems to treat the traffic a little differently. As for now, we think we've got everything (except for that weird DNS issue someone posted about yesterday) knocked out and things should be settling down.

In lieu of Dane's comment about Sonic's call center phone capacity, here is a data point for the ATA issues many have experienced over the past several months.

The ATA has been relatively stable after your comment about changing the transport layer to UDP, but last week the AT&T gateway rebooted for some reason and the Grandstream did not reconnect. Modem stats looked good before. The only difference was the web server's SSL certificate's common name changed from gateway.pace.com to attlocal.net. This event occurred between Aug 14 02:44:49 PDT and Aug 14 02:49:56 PDT.

[Guest]

The ATA has been relatively stable after your comment about changing the transport layer to UDP, but last week the AT&T gateway rebooted for some reason and the Grandstream did not reconnect.

It happened again yesterday when the modem had sync issues (but it didn't reboot). Please fix this issue with the Grandstream. I can't recommend Fusion FTTN to people who are not technically inclined and rely on POTS.