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

[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.