> 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
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
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
con
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
> aw
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; voi
>
> 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 p
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
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 in
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.
I
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
cknell" <[EMAIL 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
ation 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 y
ectified with proper 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
>
> 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 goi
> 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
AIL PROTECTED]>
Sent 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 practi
es noticeable
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:0
me. 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:[EMAIL PR
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
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 reorderi
D]]
> Sent: 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 band
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
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 oth
> 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
--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 oth
volumes not 5 minute averages!) to affect the jitter you 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:
a world 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
ear about it).
Ray Burkholder
> -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 -
Youse [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, with
: 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 i
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 o
--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 g
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
> 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.
Wh
137
-Original 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]>
her.
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 seem to make a l
> 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 y
]
> 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
> 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
ck; [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 a lot of sense - is it that QoS doesn't work
as advertised?
Qos is designed for dealing with "who gets preference
o: Charles 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 disconnection
> 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;
> -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,
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 t
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 ow
> 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..
V
down 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
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
>
2003 12:48 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
> 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 lo
> > 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 ci
> 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 applicatio
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
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, n
> > 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
Broadband 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 ar
]] 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
is
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
is that company A has a satellite office in Boston, one in Sydney and
one in Tokyo while their head office is in Toronto. Not a very wide
range of provide
Jason,
My strategy would be to use the same carrier at point A and point B and
purchase some kind of high-priority MPLS switching config between the
two. I believe Global Crossing offers something like this where they
differentiate between the proletarian traffic and the uber-business
traffic.
60 matches
Mail list logo
