- NANOG - lists.nanog.org

RE: VoIP QOS best practices
by Ray Burkholder 10 Feb '03

10 Feb '03

G.711 gives you the 64kbps quality you get on a channel in a PRI line. No compression is performed. G.729 is a well accepted codec that performs compression, and with ip packet overhead, uses about 16 to 24 kbps (can't remember which). It gives voice quality very close to G.711. G.723 has a noticeable voice quality change, and is in the 6 to 8 kbps range. The optimal is G.729 for quality vs bandwidth issues. There are some other considerations involved but these are the main ones. Ray Burkholder > -----Original Message----- > From: Charles Youse [mailto:cyouse@register.com] > Sent: February 10, 2003 14:42 > To: Alec H. Peterson > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > > Speaking of codecs, what are the primary variables one uses > when choosing a codec? I imagine this is some function of > how much bandwidth you want to use versus how much CPU to > encode the voice stream. > > C. > > -----Original Message----- > From: Alec H. Peterson [mailto:ahp@hilander.com] > Sent: Monday, February 10, 2003 1:40 PM > To: Bill Woodcock; Charles Youse > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock > <woody(a)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(a)hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com >

2 1

RE: VoIP QOS best practices
by Ray Burkholder 10 Feb '03

10 Feb '03

Many boxes are able to reorder packets. If packets arrive too late to be inserted into the conversion stream, they are dropped. One dropped packet in a sequence can usually be 'hidden' or 'faked' by the codec. When more than one packet is missed in sequence, it becomes noticeable to the listener. Ray Burkholder > -----Original Message----- > From: Leo Bicknell [mailto:bicknell@ufp.org] > Sent: February 10, 2003 14:44 > To: nanog(a)nanog.org > Subject: Re: VoIP QOS best practices > > > In a message written on Mon, Feb 10, 2003 at 01:19:08PM > -0500, chaim fried wrote: > > happens). There is no reason to implement QOS on the Core. > Having said > > that, there still seems to be too many issues on the tier 1 networks > > with pacekt reordering as they affect h.261/h.263 traffic. > > > So what's the real problem here? Are the VOIP boxes unable to > handle out of order packets? Do the out of order packets simply > arrive far enough delayed to blow the delay budget? What > percentage of > reordered packets starts to cause issues? > > -- > Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org >

1 0

RE: VoIP QOS best practices
by Ray Burkholder 10 Feb '03

10 Feb '03

There are many companies with branch offices scattered across the country who already have data circuits in place. Why not use those circuits, which in many cases are data T1's, for sharing both voice and data? Long distance rates are so low now-a-days, it is hard to justify voip for that reason alone anymore. But voip on circuits between branch offices allows the capability of uniform dialling plans, user extension between branch offices, traffic management, access to messaging systems, etc, etc. For corporate communcations, when mixed with other technologies, voip is a very powerful tool. And in some contexts, converts in the realm of IP Telephony. Ray Burkholder > -----Original Message----- > From: Jim Cabe [mailto:tex@dcne.net] > Sent: February 10, 2003 15:31 > To: Ray Burkholder > Cc: Charles Youse; Bill Woodcock; nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > Its better to use TDM when trying to share a line anyway. VOIP is only > practical for a mobile work force. > > On Mon, 10 Feb 2003, Ray Burkholder wrote: > > > > > QoS is important on T1 circuits and makes voice higher > priority. Voice > > can even be done on sub T1 circuits with excellent results. In this > > regard, there are some additional packet sizing and fragementation > > issues to worry about in order to make voice packet timing > constant, but > > nothing impossible to over-come. There are commonly > accepted industry > > practices for this. Old hat for many practitioners in the > Voip world. > > > > Ray Burkholder > > > > > > > -----Original Message----- > > > From: Charles Youse [mailto:cyouse@register.com] > > > Sent: February 10, 2003 14:09 > > > To: Bill Woodcock > > > Cc: nanog(a)nanog.org > > > Subject: RE: VoIP QOS best practices > > > > > > > > > > > > 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(a)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 > > > > > > > > > > > > > > >

1 0

RE: VoIP QOS best practices
by Ray Burkholder 10 Feb '03

10 Feb '03

QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher. Ray Burkholder > -----Original Message----- > From: Bill Woodcock [mailto:woody@pch.net] > Sent: February 10, 2003 14:05 > To: Charles Youse > Cc: nanog(a)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 > > >

4 3

RE: VoIP QOS best practices
by Shawn Solomon 10 Feb '03

10 Feb '03

If you are in an environment where the uplink is already saturated, or nearly so, QOS is necessary. But QOS only discards packets in times of contention. So, if you don't have contention, you don't need it. IF you have 300 people and 4meg of data all fighting for that t1, it makes a world of difference. -----Original Message----- From: Bill Woodcock [mailto:woody@pch.net] Sent: Monday, February 10, 2003 1:28 PM To: Charles Youse Cc: nanog(a)nanog.org Subject: RE: VoIP QOS best practices > But I could conceivably have 10+ voice channels over a T-1, I still > don't quite understand how, without prioritizing voice traffic, the > quality won't degrade... Well, of course it all depends how much other traffic you're trying to get through simultaneously. Your T1 will carry ~170 simultaneous voice streams with no conflict, but you have to realize that they'll stomp on your simultaneous TCP data traffic. But you don't need to protect the _voice_... Look, just do it, and you'll see that there aren't any problems in this area. -Bill

1 0

RE: VoIP QOS best practices
by Ray Burkholder 10 Feb '03

10 Feb '03

Depends upon the codec you are using. G.711 uses about 80 kbps in each direction, g.729 takes about 16 to 24 kpbs in each direction. So it is easy to do the math on how much capacity you need, and what your bandwidth budget is when you factor in traffic from other services. If you operate in a cisco world, they have info on their site for traffic engineering your outbound traffic. And if you have good relationship with your upstream provider, they could use the same rules to ensure traffic is regulated into your pipe. Ray Burkholder > -----Original Message----- > From: Charles Youse [mailto:cyouse@register.com] > Sent: February 10, 2003 14:22 > To: Bill Woodcock > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > > But I could conceivably have 10+ voice channels over a T-1, I > still don't quite understand how, without prioritizing voice > traffic, the quality won't degrade... > > C. > > -----Original Message----- > From: Bill Woodcock [mailto:woody@pch.net] > Sent: Monday, February 10, 2003 1:20 PM > To: Charles Youse > Cc: nanog(a)nanog.org > Subject: RE: VoIP QOS best practices > > > > 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 > > >

1 0

Local SMTP server
by Brandon Ross 10 Feb '03

10 Feb '03

Is anyone else having trouble with the local SMTP server here in Phoenix: Mon Feb 10 13:13:57 bross@pigeon:~ $ telnet srv34.nanog27.merit.net 25 Trying 192.35.164.34... telnet: Unable to connect to remote host: No route to host It appears that no SMTP server is running here. That address doesn't appear to respond to ping either, but that may not be important. -- Brandon Ross AIM: BrandonNR VP Operations ICQ: 2269442 Sockeye Networks

1 1

RE: VoIP QOS best practices
by Truman, Michelle, SALES 10 Feb '03

10 Feb '03

Yes, but most companies do not want to upgrade the access link to unneeded levels just to ensure that VOIP never has contention. It is on the access link where QOS matters, ingress and egress. That is where we (AT&T) have deployed it and where it makes sense. It's not about pitting one customer's traffic against another's across the core. The core is over-provisioned for high bandwidth and simplicity. It is pitting one customers applications against their other applications. It is about large packets (1500 byte) vs. small VOIP packets. It is about getting the VOIP out the door while less sensitive applications wait in queue if that is what is required on the access link. It is usually about T1 and below. Michelle Michelle Truman CCIE # 8098 Principal Technical Consultant AT&T Solutions Center mailto:mtruman@att.com VO: 651-998-0949 (NEW NUMBER) w 612-376-5137 -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Monday, February 10, 2003 12:23 PM To: Charles Youse Cc: Bill Woodcock; nanog(a)nanog.org Subject: Re: VoIP QOS best practices On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse <cyouse(a)register.com> said: > That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with "who gets preference when there's a bandwidth shortage". Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement.

1 0

RE: VoIP QOS best practices
by Ray Burkholder 10 Feb '03

10 Feb '03

There are two aspects to QoS that you have direct control over: 1) traffic leaving your network (easy to QoS since you (most of the time) have access to the egress equipment) and 2) traffic arriving on your end-point which is harder to do, but more and more service providers are assisting with QoS on that final ingress link to your network to ensure timely delivery of voice vs your regular traffic. Ray Burkholder > -----Original Message----- > From: Bill Woodcock [mailto:woody@pch.net] > Sent: February 10, 2003 13:58 > To: Stephen J. Wilcox > Cc: nanog(a)nanog.org > Subject: Re: VoIP QOS best practices > > > > > However, its important that the backbone is operating > "properly" ie not > > saturated which I think should be the case for all > network operators, theres a > > requirement tho if the customer has a relatively low > bandwidth tail to the > > network which is shared for different applications, its > probably a good idea to > > make sure the voip packets have higher priority than > non-realtime data... (this > > last comment is a suggestion, I've not actually tested > this in a real > > environment, low b/w lab tests tend to exclude other > traffic flows) > > We've got plenty of the INOC-DBA phones on the ends of > congested satellite > tail-circuits, and don't really have significant trouble. As has been > pointed out, the VoIP traffic may be stomping all over TCP > traffic on the > same links, but it _sounds_ good. :-) > > -Bill > > >

1 0

RE: VoIP QOS best practices
by Charles Youse 10 Feb '03

10 Feb '03

Indeed, but in this case I'm dealing with a private network that doesn't have so much surplus as to guarantee no contention. C. -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Monday, February 10, 2003 1:23 PM To: Charles Youse Cc: Bill Woodcock; nanog(a)nanog.org Subject: Re: VoIP QOS best practices On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse <cyouse(a)register.com> said: > That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with "who gets preference when there's a bandwidth shortage". Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement.

2 1