Home page logo
/

nanog logo nanog mailing list archives

RE: VoIP QOS best practices
From: "chaim fried" <cfried () wireone com>
Date: Mon, 10 Feb 2003 13:19:08 -0500




-----Original Message-----
From: owner-nanog () merit edu [mailto:owner-nanog () merit edu] On 
Behalf Of Stephen J. Wilcox
Sent: Monday, February 10, 2003 12:56 PM
To: Bill Woodcock
Cc: nanog () nanog org
Subject: Re: VoIP QOS best practices



On Mon, 10 Feb 2003, Bill Woodcock wrote:


    > > Looking for some links to case studies or other 
documentation which
    > > describe implementing VoIP between sites which do 
not have point to
    > > point links.  From what I understand, you can't 
enforce end-to-end QoS
    > > on a public network, nor over tunnels.  I'm 
wondering if my basic
    > > understanding of this is flawed and in the case 
that it's not, how is
    > > this dealt with if the ISPs of said sites don't 
have any QoS 
policies?

QoS is completely unnecessary for VoIP.  Doesn't appear to 
make a bit 
of difference.  Any relationship between the two is just FUD from 
people who've never used VoIP.

My conclusion too when I looked at this a couple years back. 

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)

I have tested this in lab settings for video over IP (t1 with multiple
384k calls and data) , and came to that same conclusion. While it works
on the tail and needs to be implemented bi-directionally (which never
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. 


Steve



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]