My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. C. -----Original Message----- From: Bill Woodcock [mailto:woody@pch.net] Sent: Monday, February 10, 2003 1:05 PM To: Charles Youse Cc: nanog@nanog.org Subject: RE: VoIP QOS best practices > That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? > As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
> My main concern is that some of the sites that will be tied with > VoIP have only T-1 data connectivity, and I don't want a surge in > traffic to degrade the voice quality, or cause disconnections or > what-have-you. People are more accustomed to data networks going > down; voice networks going down will make people shout. It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. -Bill
--On Monday, February 10, 2003 10:19 -0800 Bill Woodcock <woody@pch.net> wrote:
It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary.
I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
You're specifically talking about the g728a codec? I typically have been using g711ulaw which is a 64k vs the g728a codec that is 8k. Aside from that, Bill is quite correct here. There's little need for QoS other than at the edge of ones network to insure that your circuit is not full of other streaming media applications that put your tcp performance in the toilet. - jared On Monday, February 10, 2003, at 01:19 PM, Bill Woodcock wrote:
My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout.
It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary.
-Bill
On Mon, 10 Feb 2003, Jared Mauch wrote: > I typically have been using g711ulaw which is a 64k vs the g728a codec > that is 8k. g729a, yes. -Bill
I'm a user of one of those INOC-DBA phones. I have two one at the office, one at home. When I travel long distance I drag the one at home with me. Beat the **** out of using traditional phones between Europe and west coast USA, beat the **** hell out of traditional phones between China and the US. In fact I found, using a software solution that if I dialed into a local dial-up provider and used VoIP I got better quality than just dialing direct. Bill speaks from experience of actually deploying a globally distributed VoIP system. No Q0S, no dedicated circuits, no large bandwidth requirements. JC
It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary.
The correct answer here is that "it depends". Most multimegabit connections are underutilized enough not to introduce significant jitter to change VoIP behaviour, however specially when going to corporate networks where peak hour usage is very near or at available bandwidth the mechanics are different. However, in our experience VoIP performance is more often hurt by either broken router code or misconfigured devices in the path (route cache purges, duplex mismatches, etc.) than actual lack of bandwidth. If it does not cost you, it´s a good idea to let the VoIP packets first to a low-bandwidth link but putting serious engineering or money for hardware is not neccessary. Fancy queueing will give you more consistent performance when something else uses up the link(s). Pete
From: "Charles Youse"
My main concern is that some of the sites that will be tied with VoIP have
only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout.
I have run VOIP from Germany without any optimization, customization, QOS, crossing public Internet, going through a firewall that slows everything and its dog down, across heavily loaded T1 into my office in LoneGrove, Oklahoma, and I don't get a delay one, no echo, no problems. Granted, I'm sustaining a single voice thread here, although it might be useful to point out that I'm using two different platforms on each side. VOIP can give you problems, but QOS is usually the least of your worries. I'm more concerned with the products I'm using and how they handle echo, latency, etc. This is a market that you test before you buy, and then test some more. If you go off promo material, you're digging a quick grave, IMHO. -Jack
participants (7)
-
Alec H. Peterson -
Bill Woodcock -
Charles Youse -
Jack Bates -
Jared Mauch -
John L Crain -
Petri Helenius