Something stuck? No Vpanel or inbound calls

[Xponder1]

Back to the matter at hand, my local sip port on FXS1 is 5079 and local RTP port is 5004. FXS2 local sip port is 5062 and local RTP port is 5012. Yours the same?

Sounds good. Thanks Tim for the update.

Ya mine is the same on both.

[Vumes]

Ah well, thanks for the tips. I will revert back for now and hopefully it stays registered for now. I'm patient, so no biggie.

[Xponder1]

Ah well, thanks for the tips. I will revert back for now and hopefully it stays registered for now. I'm patient, so no biggie.

I bet they fix it for you in the morning after a huge cup of coffee.

[Vumes]

Buenas noches everyone.

[Vumes]

Tim, I tried to revert back by adding provision.dev.voipo.com to the Config Server Path and I hit update, then reboot, and it did not revert. It did stay, but did not go back to sip so I am trying it manually. Just thought you should know. This can wait till morning, so no worries.

[Vumes]

Update::: Don't know if this is normal, but I reverted back, and everything works as it should, but I just looked up and the lights on Line 1 and Line 2 are both blinking together. It's been going on now for about 10 minutes. I made a call and received a call and it works fine, but the lights are blinking.... Anything related to this ongoing problem?

[burris]

Morning Update..

Good Morning, VOIPo....Bet you all had a rough night.

This is a summary of my experience..

I have the 502 and it sits behind a wireless router. Never a problem until the one time it unregistered. Upon reboot, it was ok. I did try my SPA-2102 to see what happens, but although it worked on all functions, it did drop registration from time to time. Haven't tried it on Central02.

Last night I went with the test bed settings. Turned right up and I left it overnight. Still fine this morning.

The only settings I changed were those specified..the rest were as they were after the clone provisioning update a few weeks ago.

What I have now is....

STUN=disabled
Central02 on Sip and OB Proxy
Phone no. in port 1 both in sip user and authenticate
Phone no. +B in port 2 both in sip user and authenticate
Port 1 DNS mode=SRV
Port 2 DNS mode=NAPTR/SRV
Port 1=unreg on reboot=yes
Port 2=unreg on reboot=no

These settings, with the exception of the server selection and +B on line 2 phone number were all the same as it had and was working since inception.

I will leave it on Central02 until you indicate I should switch back to sip.

Thanks to all of you for some really hard work troubleshooting and support all through the night..

[KenH]

Good morning,

Here's the situation at 7:45 AM EST:

HT502 CPL shows both ports registered.

vPanel: You do not currently have any devices registered to our servers!

FXS1:
Outbound: call completed OK
Inbound: Failover

FXS2:
Outbound: call completed OK
Inbound: Failover

Edit:
Power-cycled the HT502 and vPanel shows one registration. Incoming call on both ports working.

Edit:
Unregister on reboot:
FXS1: Yes
FXS2: No

Edit 09:43 EST:
vPanel now showing three devices, all with identical data (port numbers, expiration time, etc.)

Ken

[burris]

The previous thread reminded me to take a look in the VPanel, even though everything is working well..

Tim mentioned that the +B line would not show up in the VPanel, however this is what I see at the moment...I'm still on Central02..

305xxxxxx sip:305xxxxxx@192.168.1.6:5079 2009-01-29 14:01:39 Grandstream HT-502 V1.1B 1.0.1.21
305xxxxxx sip:305xxxxxx@192.168.1.6:5079 2009-01-29 14:01:39 Grandstream HT-502 V1.1B 1.0.1.21

edit: I just did notice that the call history stopped recording at about 6:03 pm last night. I would guess that this was due to the server change.
Certainly not anything important for the moment.

[fisamo]

Update::: Don't know if this is normal, but I reverted back, and everything works as it should, but I just looked up and the lights on Line 1 and Line 2 are both blinking together. It's been going on now for about 10 minutes. I made a call and received a call and it works fine, but the lights are blinking.... Anything related to this ongoing problem?

Is that what the device does during a f/w update? (Even if so, not sure why it would have gone on for so long...)