12 hours without service

[patoka]

Been a voipo customer for a week now, until last night I was very satisfied.

Tried to order pizza about 8pm, got only fast busy after calling.
Sent an email to tech support.
8am Saturday, ticket is still open and still can't call out.

Still, 12 hours is better than the 5 days it took AT+T to fix my line in December.

[usa2k]

I expect you've done the standard mundane things,


power down, then restart all your devices beginning with the Cable or DSL modem?
try another number?
try the phone on the second phone port?

Which ATA are you using?

Likely your post in any forum here will get someone, even though officially there is no technical support on the weekends.


Available 9AM-7PM CST Monday-Friday

[VOIPoTim]

There are no outages, so you need to work with support to resolve this.

While our official support hours at Mon-Fri 9AM-7PM, we do have limited staff available in our office on weekends so you will get a ticket response.

[patoka]

RT31P2? (large Linksys, eyes do not get better with age...) pots port 2 same as 1.

reboot no change

inbound calls OK, outbound gives fast busy, but rings number called, nothing but dead air on called phone.

[usa2k]

So its directly connected to the Modem and is working fine for the attached PCs.


What kind of modem is it?
Odd that it worked for the better part of a week

Or maybe the VOIPo Tech has been talking to you by now?
When VOIPoTim says something is going to happen, it usually does.

I'm just a lowly user here, so my ideas do not represent VOIPo.

[patoka]

system diagram

Westell DSL modem --- hub --- Mikrotik router --- 8 port switch --- Linksys ATA.

I made 2 calls just a few minutes ago, both went through, then a fast busy, then a call with some distorted audio.

Tech support said to power cycle the modem for a config change, did that, nothing by busy signals again, but called phone rings.

[usa2k]

If its a RT31P2 or even a PAP2T, why not run directly off the hub?
It does not sound like the ATA is needed to serve as a router.

I assume the DSL modem is doing DHCP and that is why a hub serves a purpose?
Or is it a just point to monitor data traffic?

EDIT: not familiar with MikroTik Routers (http://www.mikrotik.com/software.html)but their site is interesting!

[VOIPoTim]

system diagram

Westell DSL modem --- hub --- Mikrotik router --- 8 port switch --- Linksys ATA.


That sounds like the issue. If you take the hub out of the mix, it will likely solve the issue.

Try connecting the device directly to your modem and reboot everything. Then see if it solves your issue.

A switch would be fine, but hubs and VoIP do not mix sometimes from our experience.

[usa2k]

Try connecting the device directly to your modem and reboot everything. Then see if it solves your issue.

That is the best proof. Some routers can be problematic too.
If it works direct, try the hub, if that works, maybe it can stay there?
If it acts up again, retest directly.

I used a hub for a while without issues on WideOpenWest Cable (WOW!). That worked fine back then. The modem issued a maximum of three dynamic real world IP addresses, and did not do firewalling or NAT. Ultimately I feel a switch is a bit better than using a hub. It certainly routes traffic more efficiently. Obviously we only have a small picture of the various devices being used on your network to understand why things are as they are.

VOIPo is a residential product. Home networks are sure becoming more complex every year! Mine is no exception. That will surely mean support issues that are not a direct result of anything VOIPo is doing.

[patoka]

I have static IPs, I use the hub in order to monitor traffic between the ISP and my network, switches with port mirroring didn't exist or were way out of my price range when I set up my network.

If I hook the ATA to the modem it won't DHCP and get an address.

I will take the hub out and see what happens, monitoring is not something I use on a daily basis.

I could run wireshark in my current mode if tech support would like to see the traffic during a call.

** this just in -- still fast busy on dial out with no hub, incoming calls work but not the same audio quality I had before.

[VOIPoTim]

I have static IPs, I use the hub in order to monitor traffic between the ISP and my network, switches with port mirroring didn't exist or were way out of my price range when I set up my network.

If I hook the ATA to the modem it won't DHCP and get an address.

I will take the hub out and see what happens, monitoring is not something I use on a daily basis.

I could run wireshark in my current mode if tech support would like to see the traffic during a call.

For testing, I'd really recommend going straight to the modem. If needed, you can set a static IP in the device itself.

The reason is that it also takes the router out of the equation for troubleshooting purposes since some routers can be problematic unless port forwarding is setup, etc.

Then if you don' see the issue with it connected directly to the modem, you'll be able to work backwards to find the problem.

[chpalmer]

Is the Westell setup in bridge mode or is it still acting as a router?

[patoka]

I can make calls now, I guess the ATA doesn't return pings.

I'm going to try a switch between the modem and the routers, I have a backup unit running VRRP that takes over if the main router fails, so they both need to see the modem as they have unique public IPs.

[usa2k]

Glad to hear there is progress :)

[patoka]

Back to fast busy again on outbound calls.
I did get one call in, the next 4 failed, the one completed, then more busies.

Fast busy signals use to mean a trunk busy problem out of the CO, which would indicate the call is making the pstn and that nothing on my end network or user wise is the problem.

Trace routes to 67.111.81.6 and 174.37.45.134 are under 12 hops, ping times are 550-700 ms. My router's packet sniffer shows no dropped packets to either address.


I have used Magicjack for over a year now with almost no problems.

[chpalmer]

550-700 ms


theres your trouble... i see isp issue.

do a ping test ortwo and paste em here...


dslreports.com

4.2.2.1
4.2.2.3
olypen.com

[usa2k]

Make sure when you report, that you include the Call reference ID.
Just click on one of the numbers in Call History and copy it.

One of mine looks like this:
Call Reference ID: b801ef57-45e8dffc@71.55.195.87

They can get a bit of info from it, as long as they make it to call history.

[VOIPoTim]

Back to fast busy again on outbound calls.
I did get one call in, the next 4 failed, the one completed, then more busies.

Fast busy signals use to mean a trunk busy problem out of the CO, which would indicate the call is making the pstn and that nothing on my end network or user wise is the problem.

Trace routes to 67.111.81.6 and 174.37.45.134 are under 12 hops, ping times are 550-700 ms. My router's packet sniffer shows no dropped packets to either address.


I have used Magicjack for over a year now with almost no problems.

Fast busy in VoIP is just a general error.

Have you setup the appropriate port forwarding on your router that's laid out in the troubleshooting guide?

Port Ranges 5060-5080 an 35000-65000 should be forwarded to the device if its behind a router/NAT.

All VoIP networks are designed differently and if port forwarding is not needed for one service, it may be for another depending on how their network is structured.

With VOIPo, we don't handle audio streams so usually when a fast busy comes in, it's usuaully because the phone call connected but then when the audio stream starts and comes from an IP address that the router is not familiar with since it didn't initiate the connection, the router is blocking it. By forwarding all the ports we use, all traffic directed to those ports will go straight to the ATA and this problem will go away. Most routers let it through but some of the more advanced ones block it unless the forwarding is setup.

In terms of ping times, that seems extremely high. Are you sure it's 500-700ms? VoIP is generally not reliable above 100ms. If it's really 500-700ms consistently, I don't think our service is going to work well for you. If you can't get it resolved with support, you can always take advantage of our guarantee and get a full refund as long as you cancel within 30 days and return our equipment.

[VOIPoTim]

Also since this is a support/troubleshooting thread and not a straight review, I am moving it to the Residential VoIP discussion forum. The reviews section is only for reviews about the service and the Residential VoIP forum is more appropriate.

[patoka]

The ping times were accurate, I noticed the excessive delay, that's why I posted as much info as possible. Now voipo is working, as you can see from these times the speed has increased dramatically.

I did not think to capture the trace route data earlier to see if one router was causing the problem, will continue to monitor this during the next few days.

Reply from 4.2.2.3: bytes=32 time=14ms TTL=59
Reply from 4.2.2.3: bytes=32 time=14ms TTL=59
Reply from 4.2.2.3: bytes=32 time=13ms TTL=59
Reply from 4.2.2.3: bytes=32 time=13ms TTL=59

Reply from 67.111.81.6: bytes=32 time=17ms TTL=52
Reply from 67.111.81.6: bytes=32 time=17ms TTL=52
Reply from 67.111.81.6: bytes=32 time=17ms TTL=52
Reply from 67.111.81.6: bytes=32 time=19ms TTL=52

[VOIPoTim]

The ping times were accurate, I noticed the excessive delay, that's why I posted as much info as possible. Now voipo is working, as you can see from these times the speed has increased dramatically.

I did not think to capture the trace route data earlier to see if one router was causing the problem, will continue to monitor this during the next few days.

Reply from 4.2.2.3: bytes=32 time=14ms TTL=59
Reply from 4.2.2.3: bytes=32 time=14ms TTL=59
Reply from 4.2.2.3: bytes=32 time=13ms TTL=59
Reply from 4.2.2.3: bytes=32 time=13ms TTL=59

Reply from 67.111.81.6: bytes=32 time=17ms TTL=52
Reply from 67.111.81.6: bytes=32 time=17ms TTL=52
Reply from 67.111.81.6: bytes=32 time=17ms TTL=52
Reply from 67.111.81.6: bytes=32 time=19ms TTL=52

That looks a lot better. It sounds like something was definitely causing the delay. We see that kind of thing a lot with newer advanced routers which analyze/rewrite all the traffic that goes through them.

Hopefully it's resolved for you.

[patoka]

Think I found the problem, Carbonite.

My ping time went from the times in my earlier post to 500+ ms again, noticed heavy outbound traffic in the router and disabled Carbonite for 10 min, ping times dropped immediately.

I'm going to work on QOS and prioritizing traffic in the morning to see if either choking Carbonite back or giving the Voipo ports higher priority works best.

Might be worth adding Carbonite / Mozy to your troubleshooting list.