Printable View
For testing, I'd really recommend going straight to the modem. If needed, you can set a static IP in the device itself.Quote:
Originally Posted by patoka
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.
Is the Westell setup in bridge mode or is it still acting as a router?
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.
Glad to hear there is progress :)
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.
Quote:
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
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.
Fast busy in VoIP is just a general error.Quote:
Originally Posted by patoka
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.
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.
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