Did Sonic voice maintenance knock out my ATA?

[dherr]

Last night there was work done on the voice network:

Update: Sonic.net MOTD: Non-Intrusive Voice Network Maintenance

This morning I noticed that the 4th light on my ATA was dark. I power cycled it and it came back just fine. This is the first time that it has dropped out without there being a known reason, over 3 months of having the VOIP service.

I made sure to put the ATA where I could see it, so that I would notice issues like this but I had gotten to the point of trusting it.

Anyone else notice the same?

[goetsch]

Same here: no fourth light, "not registered" message when taking the phone off-hook, everything comes back after pulling the plug and restarting. That means that unbeknownst to me, I've been without telephone service for something like eight hours. As much as I detested AT&T when I was one of their customers, I can't think of a single time that ever happened with them. Yes, I know that the underlying technology is different between POTS and VOIP, but that really should just be a black box to me: It's the phone, and I just expect it to work.

The biggest problem I've had with the whole cut over from legacy DSL/POTS to all-in-one FTTN has been communication from Sonic as to what's going on. I felt left out of the loop by the lack of information during the setup process, and having my phone service disappear without notice--contrary to the "no service impact is expected from this" statement in the MOTD notice--doesn't give me that warm, fuzzy feeling I expect from Sonic.

At very least, I would have appreciated an update to the Status message; even better would be an email telling me to reboot the ATA. With VOIP service, we're "all in" with Sonic as our telephone provider; it's time y'all take us seriously as well, and not just as something that feels like a side project.

[Guest]

Same here: no fourth light, "not registered" message when taking the phone off-hook, everything comes back after pulling the plug and restarting.

Same thing on my end. I did set up Accession on our cell/tablets/my PC and have calls ring all devices.

I agree, Sonic needs to do better on communication as FTTN rollouts increase. Something tells me they're learning the product as well.

[dherr]

My hope is that Sonic can find a setting on this ATA that will allow it to reconnect without needing a reboot. I know that it *does* do this in some situations but I have found that rebooting the router can cause the ATA to need a reboot or an rj45 unplug/plug to get it to light up that 4th light.

In some of my tests I have gone as far as about 30 minutes after a router reboot, and that is really 30 minutes after full host connectivity for my computer. I then give up and power cycle the ATA. This means that some sorts of network outages will cause the ATA to simply give up on attempts to reconnect. It seems that if it is not registered then it should just keep retrying over and over without more than a minute wait between tries.

In summation: Hey Tim, we know you are busy but please find some time to look at this!

[rmragsdale]

I just noticed that my 4th light on the ATA was dark at about 4:45pm today. Not sure how long it had been like that. When I picked up the line, it said something about not being registered. I power cycled the ATA and it started working correctly a few minutes later. I presume it had been disconnected for an extended period and I wonder why it couldn't reestablish the connection by itself? It would be nice if the firmware would handle these situations a little better.

[toast0]

Thanks, just saw this and my ATA was in the same place

[Guest]

Thanks, just saw this and my ATA was in the same place :(

Happened again today (Saturday).

[timjackson]

We've got a ticket open with Grandstream about this. The ATAs did not attempt to re-establish a TCP connection after the initial session was lost which is a bit of an issue.

We may end up trying to move back to UDP over port 443 instead of TCP and see how reliable that ends up being. We initially had issues with some RGs blocking UDP/443 or UDP/80 traffic or attempting to treat it like SIP traffic and their ALGs acting horribly, but I think we've worked around that via other means, and moving back to UDP would resolve these issues, and hopefully not cause other issues.

[dherr]

Since I started the thread I should jump in with a big "Thank you!!!". I did assume you were on the case but it is nice to read the confirmation of that.

I would also be happy to help with any beta testing of the UDP setting.

[bobrk]

Ah, this explains why we had a report that our phone "wasn't taking calls."

You guys have to be more careful with this stuff.