Has anyone been able to make a decent comparison of functionality between the DP1-style Remote IP phones and the newer 48-button Remote IP phones, when using over a DSL connection?
I know that the DSL connection is what's shooting us in the foot, to begin with. I know that there is no QOS or TOS when going thru the internet cloud. I also know that in the few instances where we've had point-to-point between the sites, they work almost flawlessly.
It just seems strange that, even on a same-backbone, same-provider network (same CLEC provider on both ends, same channel bank/internet connection via T1 on both ends, same 768k on both ends), that we would still be hearing about a quality that's worse than a cell phone, and at times not usable.
My next step is to go thru the process of sniffing the network to see the packets coming and going, to see if I can tell whether something is not getting from point A to point B as efficiently as it could be.
Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.
I have had pretty good luck setting up the Netgear 8 port VPN router with QOS. As far as I know they are the only ones that make a small VPN router with QOS. I normally make the connection back to the main office through a VPN tunnel and run the QOS for the phone. It's not perfect but it works well 98% of the time.
If your not having fun, go find something else to do.
That's good to know. But doesn't that only give you QOS within the tunnel? It seems to me that the tunnel itself is stil subject to latency and other such delays that QOS would help improve. Doesn't the QOS inside the tunnel only help give the VOIP packets priority among the other packets within the tunnel?
That's good to know, though, about the Netgear VPN router. Does it allow you to setup the QOS based on MAC address?
We are ESI linked in the same fashion BigD mentioned and works well. The only time we have an issue is when its high tide and the entire circuit goes down (AT&T and port of SF problem).
We are going to try and do a satellite next since all the copper on this pier ic under water.
5 years, I think your correct as far as QOS goes and once you get out on the internet, its anyones guess. P2P is the best way to go.
Doesn't the VPN just end up adding overhead, thereby taking away more bandwidth? Or does the protection of the VPN end up being a greater advantage that outweighs the added overhead that you get from the VPN?
I've always gone around the VPN, when possible, to try to reduce overhead on the VOIP packets. I know it doesn't reduce the overall overhead, since the tunnel is up, regardless. But the actual overhead it adds to the VOIP packets seems like it should make a difference.
I wouldn't run the ESI-link/ remote phones through the Tunnel. The encryption of the tunnel is only going to add more latency. I've built a few Asterisk box's as testing tools. Running them through the tunnel caused more problems than good.
Plus, I asked David O'Brian last week in Plano what he thought about running remote phones over the tunnel. He said the same thing, the latency is going to cause more problems.
In most of the cases where I had remote phones that the customer complained about really poor sound quality etc, it was due to bandwidth constriction at their location rather than latency/jitter issues caused by the internet "cloud". I found that reserving some of the bandwidth for the ip phones on whatever router they were using cleared up the problem if they wouldn't buy new hardware for me to setup QOS. You might assign a permanent amount of bandwidth to one phone at their location just as a test to see if that phone works while the other's suffer. Use it as an example and tell em how QOS would clear the problem up maybe.
