Anyone know: My incoming calls go to my fail-over number

[stevech]

Anyone know: My incoming calls go to my fail-over number.
Outgoing calls OK.
I've made no changes to feature settings.
Cannot find a feature setting that would cause this.
Ticket filed - waiting on response.

[VOIPoTim]

Have you tried a reboot? More than likely rebooting your router and the ATA will fix.

Sounds like the router just isn't letting the traffic through (likely an IP address change with your ISP).

In general with most routers, a reboot is needed periodically for VoIP.

[stevech]

refer to LNJ-408013

problem in this and the prior ticket seems to be that the ATA isn't able to re-register after expiration of a power-up registration. Outbound calls work, but some days/weeks later, incoming go to fail over, outgoing still work, and VoIPo's servers don't alert the customer nor VoIPo of the fault.
That's my supposition, considering the last two tickets.

[VOIPoTim]

refer to LNJ-408013

problem in this and the prior ticket seems to be that the ATA isn't able to re-register after expiration of a power-up registration. Outbound calls work, but some days/weeks later, incoming go to fail over, outgoing still work, and VoIPo's servers don't alert the customer nor VoIPo of the fault.
That's my supposition, considering the last two tickets.

The devices re-register every few minutes, but sometimes if an ISP renews the IP or something along those lines the router will "close" the NAT pinhole basically preventing two way communication where our packets don't get to it.

That's why sometimes a reboot is needed.

Not ideal, but it's just the nature of NAT since if we can't get through to the device, we can't make it do anything.

With most routers port forwarding fixes this since all traffic on those ports get right through, but it depends a lot on the router.

[stevech]

The devices re-register every few minutes, but sometimes if an ISP renews the IP or something along those lines the router will "close" the NAT pinhole basically preventing two way communication where our packets don't get to it.

That's why sometimes a reboot is needed.

Not ideal, but it's just the nature of NAT since if we can't get through to the device, we can't make it do anything.

Thanks, but that's irrelevant. my router's public IP is unchanged for months. Still is.

With most routers port forwarding fixes this since all traffic on those ports get right through, but it depends a lot on the router.

Thanks, but that's irrelevant to this case too. Port forwarding off/on makes no difference. It has been on for a long time.

The fundamental problem here is that VoIPo pays no attention to ATAs that have inexplicably stopped re-registering. Takes no staff time to have server email customer a warning for the first n days. Or a robo-dial to the customer's number since it rolls to the failover.

Because the outgoing calls are OK, the customer (e.g., me) assumes all is OK.

[voipinit]

It could be from your ISP renewing your lease. It makes no difference if the public IP changed or is the same. The lease periodically gets renewed.
I am a little confused, if you are losing registration, you should not be able to make outbound calls as well as receive inbound. If it is registered and making outbound calls is OK and you are sure of your router port forwarding settings, I would first start by disabling (if set) any type of custom ring settings (distinctive ring, simul ring etc.)

[stevech]

why would renewing the lease on the WAN side IP address, where the address does not change, affect VoIPo? I don't see the logic.

Thanks for the suggestions, but I do have outgoing calls OK, incoming roll to the failover. Power-cycle the ATA (not the router) at VoIPo's suggestion, the problem goes away TEMPORARILY.

I don't have any custom settings like distinctive ringing, simultaneous ring.

VOIPo MUST alert CUSTOMERS by email, voice mail, robo-call to the failover number or by SOME MEANS, so the customer can know that incoming calls have been pushed to the failover number. I say this because it is THEIR EQUIPMENT (service) that elects to do so, and since outgoing calls are OK, the customer doesn't know.

[wevowva]

Steve, what is your isp bandwidth? VOIPo 2nd level support keeps telling me that 760k RR is not wide enough for their service, and blame bandwidth for incoming calls failing over (In my case, it is not all incoming numbers, seems to be certain ones, and heals without resetting the modem). I've never had incoming call problems with 3 other VOIP services and 3 other types of modems: Time Warner Digital, Vonage and Lingo. All running on exactly the same roadrunner lite service. I also never had problems dialing out (dead after dialing or fast busy and no connect) except with VOIPo.

[VOIPoTim]

Steve, what is your isp bandwidth? VOIPo 2nd level support keeps telling me that 760k RR is not wide enough for their service, and blame bandwidth for incoming calls failing over (In my case, it is not all incoming numbers, seems to be certain ones, and heals without resetting the modem). I've never had incoming call problems with 3 other VOIP services and 3 other types of modems: Time Warner Digital, Vonage and Lingo. All running on exactly the same roadrunner lite service. I also never had problems dialing out (dead after dialing or fast busy and no connect) except with VOIPo.

Do you have ports 5004-65000 UDP forwarded to the adapter in your router? Doing that will almost always solve dead air issues because it's just a situation where the audio streams can't get through to you. They use random ports so that's why it would be sporadic.

[wevowva]

...Do you have ports 5004-65000 UDP forwarded to the adapter in your router?

My Grandstream VOIP modem is upstream of everything including my router, i.e. connected first to Road Runner modem. I still get dropped dial-out and have bad choppiness on inbound stream like I never had with other providers.

I suspect the Grandstream modem has issues, and can't assemble bits as accurately/fast as my other modems did. Any suggestions, because I really want to stay with VOIPo!