February 2003 - Test - lists.nanog.org

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

10 Feb '03

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

3 2

RE: probable DDOS to 195.238.3.33
by Bulger, Tim 10 Feb '03

10 Feb '03

Thanks to those who replied with how to find the owner of that IP address. ;) I was more curious about the cause of the traffic. Thanks, Tim -----Original Message----- From: Bulger, Tim Sent: Monday, February 10, 2003 12:06 PM To: nanog(a)merit.edu Subject: probable DDOS to 195.238.3.33 We're seeing packets with spoofed source addresses destined to 195.238.3.33 getting dropped on firewalls at several locations going outbound. Googling has turned up nothing relating to that destination IP address. Is anyone else seeing this? Anyone know what it is? Thanks, Tim

1 0

Webcast
by Martin Hannigan 10 Feb '03

10 Feb '03

The camera facing the slides appears to be out of focuse. If someone could adjust... Thanks. -M

3 2

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