Re: Grandstream HT502 Update
I appear to be one of 10%. My 502 sits between my Qwest DSL modem and Netgear router. I've had to manually reboot after both of the recent major hits and occasionally before that.
I've gotten to where I check my registration first thing every morning and periodically throughout the day, time permitting. A permanent solution would be appreciated.
Re: Grandstream HT502 Update
Me too. I wish there was a way that you system could email or text me when it looses connectivity to the ata. I always seem to find out it needs a reboot when someone calls my cell telling me the home phone doesn't work.
Re: Grandstream HT502 Update
I have a PAP2T adapter and like it a lot. It's been ultra stable and I'm partial to the Cisco/Linksys quality and reliability, so I have no problem with Voipo's decision to head in that direction. But the PAP2T I recently purchased has only one network port, whereas the Grandstream has two (one LAN, one WAN). By virtue of only having one network port on the PAP2T, most of your clients like me will simply plug it in behind the router, but yet Voipo wants the adapter in front of the router so Voipo tech's can "see" it in the event remote diagnostics are required. Is there a two port version of the PAP2T that Voipo is shipping out? Or is Voipo abandoning the requirement to keep the adapter in front of the router?
Thank you
Re: Grandstream HT502 Update
Tim, thanks for the update. Hoping GS comes with a permanent fix.
I appear to be one of the 10%. Seems like my HT502 also lost registration sometime early this morning and will be like that till i go home and reboot it. If required i can look into my syslog server and find out what time exactly i lost registration.
Just logged in to Vpanel and no device is registered. Outgoing is working fine. Incoming goes to VM.
Re: Grandstream HT502 Update
I am also one of the 10%.
My GS is behind a Linksys router and cable modem and has become unregistered with each of these network glitches as well as several other times. My concern in having it in front of the router was based on my CIO experience- test any new piece of gear carefully. If you have an alternative, don't put it in a critical spot. I understood the potential for manual interaction when placed behind a NAT and was comfortable with it. Without knowing the intimate details of the ATA configuration, there should be several reliable methods to "call home" without too much overhead required by the servers or the ATA.
That being said, I am out of state much of the time and my dear technophobic wife has been saddled with the responsibility of manually resetting the ATA when it becomes disabled. Even though I was able to tell her about the ***999 phone based reset, the reliability concerns are rapidly degrading the WAF of our internet phone initiative.
The PAP2T looks good since it has a proven "call home" feature- especially tested recently. If it does, the WAF will steadily rise.
Thanks for staying on top of this.
Re: Grandstream HT502 Update
Quote:
Originally Posted by
dahotvet
The PAP2T looks good since it has a proven "call home" feature- especially tested recently. If it does, the WAF will steadily rise.
Thanks for staying on top of this.
The PAP2s give us more options as well. For example, we can send a reboot request or cause provisioning to resync without a reboot right in the SIP headers so it doesn't matter if it's behind the router or not.
So as an example, we can add a "reboot" option in vPanel for PAP2 users to send a signal to them right in the headers.
Re: Grandstream HT502 Update
It sounds like you gave all the under dogs (5822, 287, 502) a fighting chance but they all bit you in the a$$
Old reliable wins again !!!!
Re: Grandstream HT502 Update
Tim, if you folks switch over totally to the PAP2, won't that allow you to then use more standard star commands? As I recall, you were forced to use non-standard commands because of the GrandStream.
RA
Re: Grandstream HT502 Update
Quote:
Originally Posted by
VOIPoTim
The PAP2s give us more options as well. For example, we can send a reboot request or cause provisioning to resync without a reboot right in the SIP headers so it doesn't matter if it's behind the router or not.
So as an example, we can add a "reboot" option in vPanel for PAP2 users to send a signal to them right in the headers.
The remote reboot sounds like a real winner to me!