Two things to check - is it’s Internet connection plugged in an working? Is the phone plugged in and working? I feel compelled to step-in and ask the stupid questions you’d get from a support rep :-) This product has bugs, including what appears to be a memory leak. I’ll bet if you power-cycle the device, it’ll help it along. Mine gets automatically power-cycled every other day at 3:30AM to avoid this issue. I gave up trying to get T-Mobile to fix the underlying issue.
I called 611 and opened an issue that's supposed to be escalated to engineering, who I'm supposed to hear back from in 2 days or so. I referenced this support thread.The automated power-cycle process is still in effect and takes place at 4:15:42 in the morning each day. Support/engineering people - if you'd like me to discontinue this, please let me know. In the mean time, this workaround keeps the service working well enough to prevent my wife from complaining to me. Note that the call volume on this line is pretty low; mostly inbound junk calls. If there was some new software load deployed since I opened this issue that's supposed to address my issue, I can disable the automated restart and let it run for days or a week to see if the issue comes up again. Despite periodic inquires about the status, I've not heard anything and have no reason to experiment unless something has changed.
Any progress towards resolution of this issue? In order to get usable service, I automatically power cycle this device each day at 4:15AM, which seems to be a workaround for the whatever the actual underlying issue is. Good thing I'm not typically using the phone at 4:15 in the morning. Bad news, if if I'm using the phone at 4:15 in the morning, it's probably something important and my automated restart is going to annoy me..As mentioned before, this smells like a memory leak. It has nothing to do with my ISP service. I have a Vonage ATA plugged into the very same ethernet switch and it continues to have good service. I have a constant probe of background traffic (at 8 packets/sec) measuring packet loss and latency and my ISP connectivity is fine. So, hard to piss-and-moan about a $10/month add-on service that I mostly just use to keep a local (previously CenturyLink POTS) number alive for my in-laws to call me on. But I have to believe there are other customers that are using
Have any software or service updates occurred in the last 6 months since I reported this issue? While my strategy of rebooting the device late every night seems to result in more or less "reliable" abilities to make and receive calls, it's not optimal. Doing that automated restart tends to lose pending voicemail notifications, I think, which isn't great.I'd be happy to work with someone on the engineering team with this product to resolve this issue once and for all.
Is there any movement on the resolution of this problem? It's been 5 months since this thread started, and surely I'm not the first to be having this issue.I'm presently power-cycling my LineLink device every day early in the morning to workaround the issue. As a result of this automated daily power-cycle/reboot, I seem to experience reliable service... this leads me to believe that in fact there's some sort of memory or resource leak in the software stack, that over time causes the malfunction.I can power cycle this thing every day since I have a wi-fi controlled switch do it all automatically, but this certainly isn't a great way to treat the as-cheap-as-possible power supply and electronic components in the device. I worry about this because I used to build and sell very similar devices to customers. It would really be great if this was a proper fix in the software so these workaround can be discontinued.Just to poke the bear - I sure hope no LineLink customer has to make a 911
And progress update on this? I have gone to just automatically power cycling the LineLink device at 4:00am every day as a workaround, and that seems rather crude..
Any news on the status of this update, when it might be deployed and any release notes that describe the changes and/or bugs fixed?
Great news. Please follow-up when the new software has been deployed, and I'll watch closely to see how it behaves. Since that testing work is already in progress, I'll just do a periodic power-cycle of my LineLink in the mean time as (hopefully) a workaround.
I am hoping to get this resolved. I'll probably end up inserting a Sonoff Basic Wi-Fi switch on the power supply so that I can more easily power cycle it if necessary. Perhaps nightly at 4:00am when I'm pretty sure no one will be using it. From the way it behaves, it feels like a memory leak or similar in the LineLInk device; alternatively, it could be some event that happens upstream that voids the device registrations. Unfortunately, there's no way to detect the issue until you try to actually put an inbound or outbound call into service, at least that I can tell.When I was at large OTT VoIP operator, our devices would restart themselves upon loss of SIP registration. Some of that was defense against weirdness in the local residential IP network and CPE router screwing up NAT mappings or other craziness that you wouldn't believe. A restart, with new DHCP requests had the effect of working around those issues. It also helped with firmware problems on occasion as well.We had o
@tmo_amanda, thanks for your follow-up. I'd be pleased if you can get my issue in front of an engineer who might be able to work efficiently towards a resolution. I look forward to hearing back with an update. I would agree that trying to open a case via tech support might not be the most productive way forward, as I think there's a more fundamental problem at work that won't get resolved via the usual troubleshooting process.Thanks for your help!
When the device is in the usable state:inbound calls don't ring, and are delivered to voice mailattempted outbound calls do not ring; I get a fast-busy/re-order call progress indication after dialing, which sounds similar to a busy, but has a different cadence. I believe the fast-busy/reorder call progress indication is originated locally by the VoIP adapter, not from a remote media stream.I'm not sure how long that the fast-busy persists; when I hear it, I just go on-hook and abandon the attempt. This happens at call origination time; I've not had it occur during a call that's in-progress. But I don't use that line for very many outbound calls, so I can't really say with certainty if there are any failures during an active call. Just for clarity; when in this failure state, I don't get a locally (or remotely) originated ring-back call progress indication; just the fast-busy/reorder when I attempt to originate an outbound call.So far, power-cycling the TA seems to resolve the issue
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
