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!

[voipinit]

Have you ever tested your actual upload and download speeds? ISP's advertise "up to" speeds which means you will rarely get advertised speed. I am sure your download speed of 760K is fine, but what is your upload rate? If it is a bandwidth issue (and it sounds like it is), you may ask VOIPo to change your default CODEC to one that uses less bandwidth (assuming VOIPo supports that).

[wevowva]

what is your upload rate?
averages 275k. My rates are consistently solid, up and down (love cable ;)) I concede that as bandwidth constricts, it has the potential to choke off the incoming stream, causing breakup in my ear. But I've never had the level of breakup/choppy with the exact same Internet set-up and 3 different providers... they all did fine with 760/280 and never had the breakup I get with VOIPo now while trying to download even a little from the Internet while simultaneously on the phone.

If it is a bandwidth issue (and it sounds like it is), you may ask VOIPo to change your default CODEC to one that uses less bandwidth (assuming VOIPo supports that).
Unless the tech I have spoken to doesn't know the deal, VOIPo only runs a very uncompressed stream, unlike many other providers that squash theirs more. However, I've measured both VOIPo's and Vonage's bandwidth consumption against the whole pipe, and they are almost identical. Anybody have experience trying to run VOIPo on RoadRunner Lite?

[VOIPoTim]

averages 275k. My rates are consistently solid, up and down (love cable ;)) I concede that as bandwidth constricts, it has the potential to choke off the incoming stream, causing breakup in my ear. But I've never had the level of breakup/choppy with the exact same Internet set-up and 3 different providers... they all did fine with 760/280 and never had the breakup I get with VOIPo now while trying to download even a little from the Internet while simultaneously on the phone.

Unless the tech I have spoken to doesn't know the deal, VOIPo only runs a very uncompressed stream, unlike many other providers that squash theirs more. However, I've measured both VOIPo's and Vonage's bandwidth consumption against the whole pipe, and they are almost identical. Anybody have experience trying to run VOIPo on RoadRunner Lite?

That could be the issue then. If it's directly connected, there's really nothing else that could go wrong.

You're right in the assumption that we only use uncompressed codecs which produces the highest quality audio, but isn't good for low bandwidth situations.

Vonage and some other providers use compressed codecs (because it uses less bandwidth for them too which saves them money) which could be why you didn't have an issue.

[stevech]

duped in err

[stevech]

Have you ever tested your actual upload and download speeds? ISP's advertise "up to" speeds which means you will rarely get advertised speed. I am sure your download speed of 760K is fine, but what is your upload rate? If it is a bandwidth issue (and it sounds like it is), you may ask VOIPo to change your default CODEC to one that uses less bandwidth (assuming VOIPo supports that).
Speedtest.net for 2 years shows 20Mbps down and 1Mbps up. No QoS issues.

[stevech]

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.)
Don't think this is an issue. My WAN IP has not changed for a long time. I do have dyndns but that's irrelevant here.

Yes, I can make outgoing calls but VoIPo has elected to forward incoming calls. Last time and this time, power cycling the ATA, then making a call or two incoming cures the problem. The first call incorrectly goes to VoIPo's voice mail on the 1st ring, not the fail-over number. The second incoming call attempt goes on to the ATA and all is well for a some days or weeks, as if some event at the servers causes this - like one out of a thousand re-registrations or heartbeats fail in some way.