On Mon, 10 Feb 2003, Aditya wrote:
FWIW, I purchased a Cisco ATA-186 and then a 7960 on eBay (after
trying out MS Messenger and finding it lacking) and they just work. I
also have used the same units to get a PSTN phone number routed over
IP using www.iconnecthere.com -- and you can make it
On Mon, 10 Feb 2003, Aditya wrote:
FWIW, I purchased a Cisco ATA-186 and then a 7960 on eBay (after
trying out MS Messenger and finding it lacking) and they just work. I
also have used the same units to get a PSTN phone number routed over
IP using www.iconnecthere.com -- and you can make
Indeed. I've unfortunately had many instances where a company runs 5+ VoIP
calls -- in addition to data traffic -- over a 64k circuit with the line
staying at 95-100% capacity 24x7. It's not easy, but it's doable.
We're not running VoIP, but we did run an OC3 at 100% 24x7 for 6 months and,
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
: Monday, February 10, 2003 9:47 AM
To: [EMAIL PROTECTED]
Subject: VoIP QOS best practices
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
Laboratories, Inc.
http://www.bblabs.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Lixfeld
Sent: Monday, February 10, 2003 9:47 AM
To: [EMAIL PROTECTED]
Subject: VoIP QOS best practices
Looking for some links to case studies or other
]] On Behalf Of
Jason Lixfeld
Sent: Monday, February 10, 2003 9:58 AM
To: Christopher J. Wolff
Cc: [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
Providing your sites are local to the same ISP, that would be fine.
Worst case scenario and probably a more likely scenario in most cases
Laboratories, Inc.
http://www.bblabs.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Lixfeld
Sent: Monday, February 10, 2003 9:58 AM
To: Christopher J. Wolff
Cc: [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
Providing your sites are local
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
On Monday, February 10, 2003, at 12:47 PM, 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,
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
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,
Any relationship between the two is just FUD from people
who've never used VoIP.
Indeed, people like me :)
No, no, I didn't mean you, you were just asking the question. I meant the
folks who don't want end-users doing their own VoIP because it means lost
revenue on
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
PM
To: [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
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 Mon, 10 Feb 2003, Bill Woodcock wrote:
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
will make people shout.
C.
-Original Message-
From: Bill Woodcock [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 1:05 PM
To: Charles Youse
Cc: [EMAIL PROTECTED]
Subject: RE: VoIP QOS best practices
That doesn't seem to make a lot of sense - is it that QoS doesn't work
of course if your using satellite your already accepting the delay from
propogation and delay from buffering from this kind of jitter which is fine, but
may not be acceptable for say a commercial voip service in a local area which
ought to be comparable to pstn quality..
VoIP
On Monday, February 10, 2003, at 12:59 PM, Bill Woodcock wrote:
Any relationship between the two is just FUD from people
who've never used VoIP.
Indeed, people like me :)
No, no, I didn't mean you, you were just asking the question. I meant
the
folks who don't want end-users doing their
On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED] 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
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Stephen J. Wilcox
Sent: Monday, February 10, 2003 12:56 PM
To: Bill Woodcock
Cc: [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
On Mon, 10 Feb 2003, 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;
Youse
Cc: [EMAIL PROTECTED]
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
PROTECTED]
Subject: Re: VoIP QOS best practices
On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED]
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
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
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:[EMAIL PROTECTED]]
Sent: February 10, 2003 13:58
To: Stephen J. Wilcox
Cc: [EMAIL PROTECTED]
Subject: Re: VoIP QOS
Indeed, but in this case I'm dealing with a private network that doesn't
have so much surplus as to guarantee no contention.
You don't need a guarantee of no contention, you just have to be able to
live with your web browser being slow if there isn't enough bandwidth to
support both
-Original Message-
From: Bill Woodcock [mailto:[EMAIL PROTECTED]]
Sent: February 10, 2003 14:05
To: Charles Youse
Cc: [EMAIL PROTECTED]
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
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 12:23 PM
To: Charles Youse
Cc: Bill Woodcock; [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED]
said:
That doesn't seem to make
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.
Why
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.
I've got a
--On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED]
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
]
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
: Monday, February 10, 2003 1:40 PM
To: Bill Woodcock; Charles Youse
Cc: [EMAIL PROTECTED]
Subject: RE: VoIP QOS best practices
--On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED]
wrote:
It works fine on 64k connections, okay on many 9600bps connections. T1 is
way more than
[mailto:[EMAIL PROTECTED]]
Sent: February 10, 2003 14:22
To: Bill Woodcock
Cc: [EMAIL PROTECTED]
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
-Original Message-
From: Charles Youse [mailto:[EMAIL PROTECTED]]
Sent: February 10, 2003 14:03
To: Bill Woodcock; [EMAIL PROTECTED]
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?
As someone who is looking
of difference.
-Original Message-
From: Bill Woodcock [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 1:28 PM
To: Charles Youse
Cc: [EMAIL PROTECTED]
Subject: RE: VoIP QOS best practices
But I could conceivably have 10+ voice channels over a T-1, I
still
don't quite
need to
implement priorities at this point.
Steve
Ray Burkholder
-Original Message-
From: Bill Woodcock [mailto:[EMAIL PROTECTED]]
Sent: February 10, 2003 14:05
To: Charles Youse
Cc: [EMAIL PROTECTED]
Subject: RE: VoIP QOS best practices
That doesn't
--On Monday, February 10, 2003 13:41 -0500 Charles Youse
[EMAIL PROTECTED] wrote:
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.
The
On Mon, 10 Feb 2003 10:27:39 -0800 (PST), Bill Woodcock [EMAIL PROTECTED] said:
Look, just do it, and you'll see that there aren't any problems in
this area.
For those looking to just do it, it's not very complicated or
expensive to try -- and the quality is very, very good esp. if you
have
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
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
: February 10, 2003 14:42
To: Alec H. Peterson
Cc: [EMAIL PROTECTED]
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
On Mon, 10 Feb 2003, Leo Bicknell wrote:
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
On Mon, Feb 10, 2003 at 10:34:14AM -0800, Bill Woodcock wrote:
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
tool. And in some contexts, converts in the realm of IP
Telephony.
Ray Burkholder
-Original Message-
From: Jim Cabe [mailto:[EMAIL PROTECTED]]
Sent: February 10, 2003 15:31
To: Ray Burkholder
Cc: Charles Youse; Bill Woodcock; [EMAIL PROTECTED]
Subject: RE: VoIP QOS best practices
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
to the listener.
Ray Burkholder
-Original Message-
From: Leo Bicknell [mailto:[EMAIL PROTECTED]]
Sent: February 10, 2003 14:44
To: [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
In a message written on Mon, Feb 10, 2003 at 01:19:08PM
-0500, chaim fried wrote:
happens
by: [EMAIL PROTECTED]
02/10/2003 02:21 PM
To:
Charles Youse [EMAIL PROTECTED],
Alec H. Peterson [EMAIL PROTECTED]
cc:
[EMAIL PROTECTED]
Subject:
RE: VoIP QOS best practices
G.711 gives you the 64kbps quality you get on a channel in a PRI line.
No compression
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.
Yeah, if you're operating in the modern world, your tradeoffs are audio
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
buffering. However,
again we don't want anybody reordering our packets.
-Original Message-
From: Leo Bicknell [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 11:44 AM
To: [EMAIL PROTECTED]
Subject: Re: VoIP QOS best practices
In a message written on Mon, Feb 10, 2003 at 01:19
rises so will congestion; however, it is quite
common to have transient congestion while overall utilization is minimal.
S
- Original Message -
From: Shawn Solomon [EMAIL PROTECTED]
Sent: Monday, 10 February, 2003 12:54
Subject: RE: VoIP QOS best practices
If you are in an environment
PROTECTED]
Sent: Monday, 10 February, 2003 12:43
Subject: Re: VoIP QOS best practices
- --OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried
Gripes
Subject: Re: VoIP QOS best practices
Reordering per se doesn't affect VoIP at all since RTP has an inherent
resync mechanism.
Reordering is also unlikely, since each packet is sent 20ms or more apart;
I'm not aware of any network devices that reorder on that scale.
S
- Original
Thus spake Bill Woodcock [EMAIL PROTECTED]
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.
To paraphrase Randy, I encourage all of my competitors to think like this.
Iff you
Thus spake Ray Burkholder [EMAIL PROTECTED]
QoS is important on T1 circuits and makes voice higher priority.
QOS is a much broader subject than just giving voice priority treatment.
Voice can even be done on sub T1 circuits with excellent results.
Indeed. I've unfortunately had many
Thus spake [EMAIL PROTECTED]
On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED]
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
Reordering per se doesn't affect VoIP at all since RTP has an inherent
resync mechanism.
Most VoIP implementations don´t care about storing out-of-order packets
because they think that 20ms or 30ms late packets should be thrown
away in any case.
Reordering is also unlikely, since each
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
On Tue, 11 Feb 2003, Petri Helenius wrote:
Reordering per se doesn't affect VoIP at all since RTP has an inherent
resync mechanism.
Most VoIP implementations don´t care about storing out-of-order packets
because they think that 20ms or 30ms late packets should be thrown
away in any
The issue is when
traffic crosses ISP boundaries, because many times these links are
clogged. It used to be you had to stay away from MAEWEST and such
because of big packet drops and delays (big no-no's for voice). Things
are getting better in this regard because of a larger number of cross
62 matches
Mail list logo
