Same here...not a single problem on Central02...I kept thinking I should go back to Sip, but Tim said that Central was in full service and it wasn't necessary. In fact , provisioning keeps me on central.
If nothing changes, I'm fine..
Printable View
Xponder1 and Eagle 1, did you reboot after the outage Friday or did you let the devices come back up on their own?
Can both of you PM me your ticket numbers so I can keep up?
So far, we've had 2 registration tickets today (so I'm hoping they were from the two who posted here).
With 1 of them, it showed the ATA had not been provisioned since the 5th, so in that case you probably didn't get the fixed applied.
With the other provisioning wasn't enabled at all for some reason (we didn't have their MAC in the system), so they didn't get the fix.
I have no problems..If you remember a while back, I thought that central was a temp server and wanted to change back to sip..You said not to bother as central was fully up and running. I mentioned that provisioning is keeping me on central and all is well.
Thanks
I hate to pile up on you guys, but I have been having the same issues and I am assuming it is the same problem. Last night between 6 and 7 pm I received 2 calls on my failover number, so I am assuming the ata had become unregistered. Shortly after 7:15 or so, it started working again. I opened a ticket on this. Now, this afternoon, another call went to my failover, in fact it was from another Voipo number and shortly thereafter it was working again. I have rebooted that AATA 2 or 3 times since yesterday thinking there was some sort of config push I hadn't gotten, but this seems to be an on-going issue. Thankfully, my failover seems to be working fine so I can deal with it, but I'm hoping someone gets a handle on this soon. So far I have turned several people onto Voipo and they have signed up, but I don't dare do this now until this problem gets solved for good. I know you guys are trying hard to get to the bottom of it, so I wait patiently, knowing that you will indeed solve this soon.
RA
Tim, I did open a ticket on last night's issue and got a reply from Justin stating they were looking into it. I didn't open another ticket on this afternoon's issue because it was basically the same thing as last night. The ticket number is [RSQ-524455.
I am about to open another one though regarding voice mail. Even though I have auto-login checked under voice mail options, the system is prompting me for my password. I rebooted, but still the same thing.
RA
Rick,
I'll take a look at that ticket and we'll see what we can do for you to get you situated.
In terms of the auto login, I just made a post about it: http://forums.voipo.com/showthread.php?p=9114#post9114
For what it's worth: Tim, I and Justin (VoipOJustin); worked back and forth on my Grandstream in the beginning in the week when it had all the same problems. No registration, dropping registration, etc... We changed the registration to 1 minute; changed to Central02 server; downgraded the firmware to .15. I have not had one problem sense then. There are 2 MINOR problems, but they are server related and not that important.
1) The grandstream shows BOTH PORTS registered. BOTH PORTS work. I can be on a call on PORT 1; and make another call on the clone in PORT 2. ALL IS GOOD. However; in the Vpanel; ONLY 1 device shows up as registered. Again, this is not really a problem. But I did know that prior; on the sip.voipwelcom.com server, I would see 2 registrations under device in the vpanel. Maybe it's a sip.voipwelcome.com thing; maybe the firmware; I don't know. It's not a big issue.
2) The VoipO servers are having a difficult time CALLING EACH OTHER. I.e. I have my beta line on Jupiter server and my Primary line on Central02 server. If I can FROM juptier to Central02, it rings my failover line. If I call FROM Central02 to the Jupiter, it goes to Voice Mail. This WAS an issue a time back. Maybe it is something that was never really addressed being it's not that common to talk to other voipo numbers; let alone one on a different server. I'm PRETTY SURE that if BOTH are on the same server; e.g. Beta and Primary both on Central02; then they can call each other. When I was using sip.voipwelcome.com on BOTH lines, it was fine. Again; not a problem.
Anyway; just wanted to say that things have been working fine on the grandstream and the current settings. Maybe it's the 1 minute registration. Maybe it's the downgraded firmware to .15. Maybe it's useing the central02 server. Maybe it's a combination. Tim and Justin know they can use my lines to experiment with if needed. Any time day time hours Mon-Fri. And we can work more together any night or on weekends. But current configuration is stable and a good bench mark for any one that needs the info. My BYOD (Beta line on Linksys) never had issues on any of the servers. Even when I moved my primary to it prior to fixing the grandstream issues. Great job Justin and Tim. You guys have a very high work ethic. As does all the voipo employees. Later... Mike.....
Well I sent you my info so please let me know which of the two are me lol :p
Would of replied sooner but as I had to work today. I am off the next couple of days.
Update I just checked and the ATA shows both ports registered but Vpanel only shows one.
Both ports are working. (Reminds me of the "B" test we did). UPDATE logged in with the admin password and it is the B config we tested.
Product Model: HT-502 V1.1B
Software Version: Program-- 1.0.1.21 Bootloader-- 1.0.0.9 Core-- 1.0.0.25 Base-- 1.0.0.76
System Up Time: 19:09:09 up 2:23
PPPoE Link Up: Disabled
NAT: Symmetric NAT
For what its worth, I moved my device back behind my firewall and its a little better. I also noticed that that Ip was getting hammered by three different Ip addresses (Thousands of times per hour).
I set the firewall to only allow the specific ports and Ipaddress specified by support and it seems better.
the offending ip's were:
Name: pbx-vancouver1.mdci.ca
Address: 204.209.14.50
Name: s0106001ee5355afc.ss.shawcable.net
Address: 70.64.23.199
Name: 209-20-73-234.slicehost.net
Address: 209.20.73.234
Just checked at 6.30am and ATA shows I am registered. But vPanel does not show any devices. Incoming going to network down number.
NAT table shows no entries for the adapter. I have a feeling that the adapter is not sending the keep-alive or re-registration request.
Rebooted my adapter and everything is back to normal.
I can't receive inbound calls or make outbound calls. Opened a ticket.
Inbound calls ring, but can't be answered. When it goes to voicemail, it drops the call.
Outbound calls just fast busy.
Scott
Will do.
I have to conference in my wife probably when she gets back.
When she calls out, gets only fast busy. When I call her from work, the phone rings but when she picks up the phone, she gets silence, a click, then a fast busy. I eventually go to voicemail, but me being the caller I never hear her pick up, it just rings until it goes to voicemail.
I had a similar issue as scott2020 yesterday. A reboot solved the issue, but it was the second time it happened. I'll also give customer support a call.
I did have STUN turned on, and my device was still going to central02. Brandon got me re-provisioned to central01 and disabled all STUN and that fixed me up. My STUN was set to some "goes.com" address. I have tried both ways and have had trouble with both, so hopefully this will clear things up.
This morning, I discovered that all inbound calls since about 5:00pm MST (yesterday) were going to failover (voicemail). Had to reboot.
If you are seeing this, there are changes we can apply to your account that will likely resolve it in your specific situation.
We're just not seeing a large drop like before when it was obviously a larger issue. Registration levels look normal.
Now we're only seeing a few cases not hundreds like we did when we were seeing a system issue. A few registrations out of thousands just isn't really that much.
The few cases of this are likely just specific NAT setups that need something specific set and support will try to determine that on a case-by-case basis and apply changes to your account that could help.
For some specific ISPs and network setups, we've determined that the PAP2T is a better option and in some cases may process a replacement if we've seen cases where it's worked better for specific ISPs/setups.
Brandon has a PAP2T was on the way for me (for a different, ongoing ticket).
FWIW, I've had several changes applied to my account over the last 2 weeks to try to fix this, and it's still happening. Hopefully the Linksys will help with both issues.
Yeah it could. Grandstream finally told us that the HT502 is not thoroughly tested (or really designed) to be used behind any kind of complex NAT since they have other products without a built in router that are designed for that. We suspect over time that as more bugs are discover, they'll continue to enhance support for more and more complex scenarios. This would explain the devices giving a "500 Internal Error" in the logs when we see this.
When connected directly to the modem and with most simple NATs, the HT502 continues to work very very well.
We are maintaining a list of network setups/routes that the PAP2T works better on. I suspect it'll resolve your issue.
Before, there was a bigger issue going on for sure given the huge fluctuations we saw. So anyone still experiencing registration issues, contact us.
I had a problem with echos yesterday. Never had that issue before. Only affected the person on the other line. Did not have any audio problems on my end. It happened in the early AM on one call and then again when I called my wife from work last night. Hung up and called back and it was fine. Logged in webmail and submitted a ticket.
Support sent me a message telling me to move my ATA in front of the router. This is after someone else in support told me due to my pppoe connection and AT&T it was better to leave it behind my router.
When I replied and told them I would leave it behind my router because I had not had any echo problems before they never even bothered to reply back. I actually included the email with the ticket where I was told to leave it this way. I reset the ATA and the issue is gone. I do not think it had anything to do with my router.
Then I noticed today that I had a voice mail. Voice mail indicators not flashing and no tone to indicate I had a message. When I had the echo problem yesterday morning the call dropped a few minutes later. I guess she called me back and got voice mail but if I had not logged in vpanel I would have never known it was there. It also did not email it to me as it usually would.
Something fishy going on and its not my router. Anyway the echo issue seems to be gone now and I deleted the voicemail I never got.
I have seen similar symptoms. For me, it's very hit-or-miss as to whether the message waiting indicator and/or stutter tone will work. I've tried it all in terms of how the adapter is set-up: in front of the router, behind the router, in DMZ. No difference. If the mail-gods are smiling on me, I'll have the PAP2T today and report back. It might help you, too...
For what it's worth; I tried calling my house today from my cell phone (Which happens to also be the failover and simultaneous ring number). Normally, if all is working fine, I can get the home phone to ring 3-4 times and then go to voicemail. If the adapter isn't working, I will go straight to my CELL Phone voicemail (Being I'm on it and it's the failover). The voipo line was fine for the last few days. Today; I logged into my adapter (Remotely). Both ports showed "REGISTERED". The vpanel showed 1 device registered. However; when I called it, I went straight to my cell phone voicemail. I.e. The adapter, while saying registered, wouldn't receive a call. I remoted in and rebooted. Waiting a couple of minutes; remoted in; verified register; called it with my cell phone and it would ring like it was suppose to and after 4 rings went to voipo voicemail.
So, maybe voipo made some changes and the adapter doesn't catch up until a reboot. Maybe the registration problem is in effect again. My problem is I have simultaneous ring on the cell phone. So, when I answe a call, I don't know if it's because I answered the cell phone for that or because of failover. I'll try calling the house every night when I get home from work to see if the phones ring in the house. Calling out has worked, because I usually do that at least once a night. So, I'll do some more experimenting. later... mike....
Thanks Mike, I thought I was going crazy or somehow it was me or my equipment. If you had a registration issues then I know I'm not losing my mind !!
Mike....
Interesting..
I don't use the system VM because my wife likes our digital answer machine. No problem as it is as accessible as dialing into the system program...but, I also have failover set to my cell phone and when the adapter is down and I try to call home, before it begins to ring, which it doesn't, a voice with one word I can't understand speaks and immediately goes to a menu selection prompt that I think belongs to Sprint.
Do I remember something in the beta days that Tim mentioned about changing the pattern so if your cell is the failover, or was it simring?, the cell would not ring or it would ring or something. Do you remember any of this?
Burris--
That was for simulring. If you have simulring on with your cell as the destination and call the voipo line from your cell, the cell voicemail would pick up instantly, effectively preventing you from calling home. :eek: If you failover to the cell phone, you'll go right to your cell phone email as well, but it's not like there's another person who could take the call at that point. ;)
Viatalk prevents this from happening. If the call is from a number that is also configured for simulring, it will not do simulring.
My TA wouldn't register all morning to central02. So when I got home from work I switched to sip and it instantly registered. I do notice that when I change to sip I show 2 registrations in vPanel. I can't say that I'm feeling very comfortable about the registration still being there in the morning.
I've been using central01. I wasn't even aware there was a central02.