DSL & VoIP Testing Software/Hardware

[Logicwrath]

How do you decide if a client's Internet is going to work well with a hosted VoIP solution?  I have seen online tests that check for packet loss and jitter etc..  Is there software I can purchase or download that documents Internet quality over a period of time?  Specifically, can I set something up to run for a week or two and have some piece of mind that their Internet is reliable enough to run VoIP for x users/lines?

How do you feel about setting up hosted VoIP on a DSL connection?  I assume this is going to be case by case.  Some clients might have reliable DSL as they are a short distance from the ISP's CO.  I have seen cases where old phone circuits flood when it rains and issues intermittently show up etc..

Are there other considerations to make when deciding if hosted VoIP is right for a client?

[Michael D]

Here is a similar thread https://helpcenter.2600hz.com/2600hz/...

[Michael D]

Also, I use http://www.pingtest.net on a firefox browser via wired ethernet connection . If you get less than a B grade with Packet loss, Ping time, or Jitter. Chances are the connection is going to be problematic with VoIP

Also, try this test http://www.ringcentral.com/support/ca...

hth

MD

[Logicwrath]

Hello,
I am not able to view that thread.  Is it possible to get access to it?

"Sorry! You don't have access to the content you requested. If you think you should have access, please contact the administrator of the community."

[Rick Guyton]

We are actually trying something new on this. We are going to try runing continuous pings to local IPs, Local GW Ip, DOCSIS modem (where applicable), WAN GW ip and Google/L3 DNS servers. We are going to run this for a few days to a week in the hopes that we will get a really good snapshot of the quality of the connection. We are using an Icinga server on Linode to record and present the data and rasperry Pis to collect the data on the client's side. I'll let you all know how it goes...

EDIT: Oh yea, ADSL sucks, just don't do it. Even if it's ok now, it's going to die a horrible death. Fiber backed/Ethernet switched DSL is ok. Cable connections are our go to. If you can get fiber to your door OMG awesome.

[Rick Guyton]

You probably don't have access to the reseller section of this forum. If you are reseller ping someone at 2600 and they'll give you access. Don't worry, you're not missing much on that thread. It basically says that there's no silver bullet answer to this question and that speed test.net is about as good as you can get

[Karl Stallknecht]

DSL works fine AS LONG AS it's dedicated to the VoIP. For example, several of our customers have Comcast which is notoriously horrible for VoIP. What we do for them is get a secondary internet connection (a DSL line) and connect ONLY their phones to that DSL line. DSL is usually really reliable (at least Verizon DSL in the D.C. area is) but the issue becomes if you connect computers to it too then when they try to download or upload files it sucks up all of the bandwidth which causes call quality issues. Obviously you can implement QoS but in order to do it correctly you need expensive equipment plus then the customer has a horribly slow computer connection. So again, it's easier just to separate the network and have the data network on Comcast/cable and the "voice" network on the Verizon DSL line. That combination makes customers super happy usually, it just involves extra wiring in some situations if they only have one drop per desk/office.

[Logicwrath]

We are implementing QoS on most installations.  We use Mikrotik firewalls, and setup packet marking and Queue Trees.

I will need to figure out how to identify the type of DSL connection someone has so I can factor that in.

It would be nice if there was software we could purchase that would run extension to extension calls periodically and test voice quality latency etc..

I really like your idea for the Pi and Icinga.  I think that is a good idea.  Sounds like it would require some effort to setup.

[Logicwrath]

Karl, it sounds like you might be doing more work than you need too.  You could easily get $50 mikrotik firewall and setup QoS.  Additionally, you could still do dual wan, and set the gateway on the phones to use something different than the PCs and continue to use the same wiring.

[Michael D]

Hey, what Mikrotik router and firwall models have you used?

[Karl Stallknecht]

Right, but then the customers are still using a horribly slow DSL connection to download/upload files on their computers.

As for using the same wiring, it can still be problematic and as a general rule of thumb it's best to physically separate if possible.

[Logicwrath]

Full disclosure, I am huge Mikrotik fan.  We generally use the hEX for smaller installs where the Internet speed is less than about 65 megabit.  Otherwise, I would look at the RB3011 for closer to 200-250 megabit and the CCR1009 for larger connections.

At home I run a CCR1009 because I have a 300 megabit connection that bursts higher.

These are configured with mangle rules for packet marking and queue trees priority 1-8 for both upload and download.

http://prntscr.com/b2u05s

I currently run about 45 mangle rules to mark packets but this will increase over time as we update our golden configuration.

[Michael D]

THanks

[Rick Guyton]

Yea, it does on the front end. But at this point, I have an image that I can put onto an SD card, pop into a Pi and then it all manages itself...

[Logicwrath]

Perhaps something like PingPlotter Pro would be a good fit for what I am trying to do.  We could install it on a server or workstation and let it run for 2-5 days.  Configure it to test all 3 proxies etc.

https://www.pingplotter.com/pro.html

Something open source would be preferred.  WinMTR would work, but it does not check jitter.

[Karl Stallknecht]

The problem here is that you can run any kind of test for a week straight and it can look great, and then suddenly the customer can have horrible problems. One of the local ISPs here, Cox, works really well most of the time but still has blips every month or so where calling quality will be terrible for a period of hours or days.

The Internet is always changing and there are millions of things that can affect Internet quality at someone's location...it's not like a cell phone signal where if you are stationary it will remain the same quality (under normal circumstances).

Sorry to sound so negative, I just wouldn't advise wasting huge amounts of your time to come up with fancy tests, because chances are you'll just happen to run the test at a time when nothing is wrong thinking the Internet is perfect, and then you'll regret it after installation.

[Rick Guyton]

Yea, I mean any connection can go south on you. Even fiber connections go down. But, the idea is to make sure you aren't walking into a service line with problems. Here in AZ, we'll see temps over 110 mid-day and it'll drop down under 80 at night. That causes massive moment just in the copper itself. A great connection at noon might spit and sputter near closing time. I've gotten a bunch of clients by setting up continuous pings and watching the results in real time. I tell people that I'll resolve these type of problems on the front end as long as they agree to sign up with us if we can make the numbers work out. Sometimes they have a bad switch, sometimes the WAN GW needs to be replaced or have some QOS setup on it, or I need to call up the ISP and give them hell to fix their end. The Icinga instance and Pis are just to automate this process really.

[Vernon Keenan]

We have hit this particular nail with a sledghammer, and we go with Cisco-Meraki security gateways. It clears up most voice quality issues caused by LAN-side congestion, and the cloud controller lets us see what's going on with just a couple of mouse clicks from anywhere.

Meraki can cause sales issues to ask customers to buy such expensive gear, but we feel so strongly about it that we'd rather not have that customer if they won't spend $1100 on a gateway to support five or more phones.

Also, with the MX64 and higher you get Dual-WAN, and we often recommend dedicated WISP or DSL lines just for the Voice to go with their Comcast cable Internet. For smaller sites, we've used the Z1 effectively, for about $600 cost.

It is my understanding that the QoS queueing algorithms in the Meraki are superior for VoIP, especially when compared to the algorithms in SonicWALL or PFsense. Finally, it doesn't hurt that Meraki gives a 40% margin on most sales.

Vern

[Rick Guyton]

Geez Vern, I want more clients like yours. :) Merakis are nice. No doubt there. 

[Michael D]

I'm curious, when the term "QOS" is mentioned in this thread.
Are we talking about the ability for a router to perform some traffic shaping? Other than that, what else can be done? if you mark packets on the egress towards someone like Comcast, they are not given any priority once they leave your router. (unless this is something beyond basic business broadband circuit)

[Rick Guyton]

He he he, yea... that's a deep well. QOS in general is just a way of tagging a packet of data with it's priority. What happens after that is up to whatever network devices look at it. Even some LAN switches might look at the packet and prioritize it over general data. This usually isn't necessary, but in some high local load situations it could be nice. Wireless APs might look at it. But it's mostly routers that watch it. Many people just stick the QOS tag on there and hope for the best with their ISP. Cox is pretty good about respecting that in my market and CenturyLink seems to aswell. But, others like integra seem to chuckle at the thought.

So, we do some bandwidth management aswell. Mikrotik, DD-WRT and Sonicwall folks do this a lot. I'm pretty sure Meraki does too, but in the background, hidden away. :) Basically, instead of relying on your ISP to treat your packets right, you intentionally pinch down how much data you allow through your router. So, if you have a 50/10 connection from your ISP, you might only "allow" 45/9 through your router. Now you are the bottleneck so you control who goes through first and last. There's a lot of ways to accomplish this HTB is my personal favorite. Others will scoff at me for this, that's ok. There's pros and cons all over the place...

[Nicholas]

I am big user of the Mikrotik devices as well and agree with the choices.  hEX for the smaller places or even a hEX lite. It all depends on the peak throughput you expect and the number of rules/filters you apply to the data passing through and if you are going to do any secure VPNs.  Right now I am using a hAP because I was just about to deploy some and wanted to do some test but was using a RB2011.  If you have a large customer a CCR might good but either way don't make the mistake of using the router as a switch as well which some people do.  Separate those because the way the filtering works puts load on the CPU.

Something else to look at for testing and monitoring.
http://myspeed.visualware.com/index.php

I have used it while working with/for various cloud providers. It doesn't ride the same OOKLA sites like speedtest or pingtest but rather will focus on the path the VoIP traffic takes.  Of course if you really want true end to end stats and an in depth assessment both, sides have to have the software. 

[Rick Guyton]

Ok, I know there was a lot of controversy on this. But we finally got out monitoring tool up and running. This particular client is having sporadic issues where their latency jumps to 2000+ms Next time it happens, I should be able to tell where the chink in the armor is...  http://i.imgur.com/a66Hg0f.png

[Travis Hawkins]

Looks nice Rick. What are you using?

[Rick Guyton]

Thanks!! We are using Icinga2+Graphina on linode for server. Raspberry Pi 3s + Raspbian Lite + Icinga2 Client + These nifty cases http://amzn.to/1sRU1R5 for the endpoint data collection.