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
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.
On Fri, 7 Feb 2003, Andy Dills wrote:
On Fri, 7 Feb 2003, Drew Weaver wrote:
Howdy, Im having a little difficulty with a 7507, when I do sh run
it just returns a newline and doesn't show me any the running-configuration.
My privelege level is 15, and this worked yesterday. I also
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
Jason,
I believe Global Crossing supports those sites, keep in mind I don't
sell their product, but UUNET should as well.
Regards,
Christopher J. Wolff, VP, CIO
Broadband Laboratories, Inc.
http://www.bblabs.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Hmm, didn't know GC was lit up in Canada.
On Monday, February 10, 2003, at 12:01 PM, Christopher J. Wolff wrote:
Jason,
I believe Global Crossing supports those sites, keep in mind I don't
sell their product, but UUNET should as well.
Regards,
Christopher J. Wolff, VP, CIO
Broadband
On Mon, 10 Feb 2003, Andy Dills wrote:
On Fri, 7 Feb 2003, Andy Dills wrote:
On Fri, 7 Feb 2003, Drew Weaver wrote:
Howdy, Im having a little difficulty with a 7507, when I do sh run
it just returns a newline and doesn't show me any the running-configuration.
My
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
That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised?
As someone who is looking to deploy VoIP in the near future this is of particular
interest.
C.
-Original Message-
From: Bill Woodcock [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 12:48
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
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
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
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
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;
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:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 1:20 PM
To: Charles
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 1:23 PM
To: Charles Youse
Cc: Bill Woodcock; [EMAIL
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
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
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
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
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
(ATT) have deployed it and where it makes sense. It's not about pitting
one customer's
It seems to be working now, thanks to whomever fixed it:
Mon Feb 10 13:24:52 bross@pigeon:~ $ telnet srv34.nanog27.merit.net 25
Trying 192.35.164.34...
Connected to srv34.nanog27.merit.net.
Escape character is '^]'.
220 rat.merit.edu ESMTP Sendmail 8.12.6/8.12.6; Tue, 11 Feb 2003 13:38:50
-0500
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
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
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:[EMAIL PROTECTED]]
Sent:
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
Ok, I've taken all the courses and done some stuff myself.
Here is roughly what to expect.
It IS important to do QoS at the CPE. This ensures that during times of
congestion, voice traffic gets out to the real world in a timely
fashion.
In networks supported by Nanog people, usually they have
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
On Mon, 10 Feb 2003, Ray Burkholder 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
packets won't get dropped since they
--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
Van/Cengiz/Kedar,
Questions that missed the cutoff at the end of your preso:
Most operators have some per-peer inbound policies. Since the
next hop adjacency may move around due to chaning primaries,
where do you configure the policy ? (all routers?)
Also, some of those polices include
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
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
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
The camera facing the slides appears to be out of focuse. If
someone could adjust...
Thanks.
-M
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
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
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
Also note that those sizes are for the
voice part of the payload onlyIt does not take into account any payload/packet
overhead...
We use G.711 quite a bit on our network,
and are traffic flows are right around 80k...
Spencer
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
hopefully we'll be able to switch back to the scan converter if they get
things working...
joelja
On Mon, 10 Feb 2003, Martin Hannigan wrote:
The camera facing the slides appears to be out of focuse. If
someone could adjust...
Thanks.
-M
--
Is there something hoopy up with the streaming? Attempts to connect are
eventually failing, complaing that:
rtsp://198.108.1.36/broadcast/NANOG/encoder/nanog27.rm is not found.
Any fixes at the far end welcome...
--
Paul
Went to Nic.com and got this:
OrgName:RIPE Network Coordination Centre
OrgID: RIPE
Address:Singel 258
Address:1016 AB
City: Amsterdam
StateProv:
PostalCode:
Country:NL
NetRange: 195.0.0.0 - 195.255.255.255
CIDR: 195.0.0.0/8
NetName:RIPE-CBLK3
NetHandle:
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: [EMAIL PROTECTED]
Subject: probable DDOS to 195.238.3.33
I do have the same problem from here. Lots of *buffering* as well.
German
--
Peace cannot be kept by force. It can only be achieved by
understanding. Albert Einstein.
On Mon, 10 Feb 2003, Paul Thornton wrote:
Date: Mon, 10 Feb 2003 20:13:18 + (GMT)
From: Paul Thornton
On Mon, Feb 10, 2003 at 12:05:55PM -0800, Bulger, Tim wrote:
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.
inetnum:
Does anyone have a resource that they believe in when it
refers to how much spam really costs Network operatos?
http://www.nytimes.com/2003/02/09/magazine/09SPAM.html
I'm trying to do some validation. Thanks.
-M
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
Hi I wrote to the noc but this seemed serious enough to mention on the
list. . Seems that Primustel was trying to send me a transit feed ie
full routes over our peer at Paix. I'm assuming that this also happened
to other peers of theirs at Paix so you may wish to check your associated
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
Good point. Later version from the larger video-conferencing Gateway
manufacturers, seem to do a better job (better- not perfect) handling
reordering. So clearly there seems to have been issues with the
applications buffering itself. Out of order packets are considered lost,
so whatever you would
On Mon, Feb 10, 2003 at 12:05:55PM -0800, Bulger, Tim wrote:
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
Deal Enables ISC to Mirror DNS Root Server in Additional U.S. Locations
http://biz.yahoo.com/bw/030210/102340_1.html
You are mistaking utilization for congestion. At the packet level, a link
is congested if it is not immediately available for transmit due to one or
more previous packets still being queued/transmitted. This transient
congestion causes jitter, VoIP's worst enemy.
Certainly, as utilization
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 Message -
From: Leo Bicknell [EMAIL
But in order for RTP to resync the out-of-order packets it must introduce some delay,
no?
And that delay causes issues.
C.
-Original Message-
From: Stephen Sprunk [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 5:21 PM
To: Leo Bicknell
Cc: North American Noise and Off-topic
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
rtsp://198.108.1.36/broadcast/NANOG/encoder/nanog27.rm
file not found. 22:39GMT QoS has been real spotty, from many differing
networks today. multi 10's of seconds gaps in audio or video.
==
Eric Germann
huh? i thought it was in eugene where we were streaming the dead
randy
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
I'm trying to get a idea of what the current going rate is for intercity
(not metro) OC-48. Can anyone give me some pricing information (even
ballpark figures)? Pricing per mile would be helpful.
Thanks,
Brian Cashman
Merit
On Mon, 10 Feb 2003, Martin Hannigan wrote:
Does anyone have a resource that they believe in when it
refers to how much spam really costs Network operatos?
http://www.nytimes.com/2003/02/09/magazine/09SPAM.html
I'm trying to do some validation. Thanks.
-M
Hi Martin,
I
I have been asked by some folks for the link to the lft traceroute I
used this morning in my presentation.
It is available at http://www.mainnerve.com/lft/
--
Rodney Joffe
CenterGate Research Group, LLC.
http://www.centergate.com
Technology so advanced, even we don't understand it!(R)
As a follow-up to the IX Operator Panel today, a Web site
and mailing list have been set up to focus and expand the
interests of regional exchange points.
The REP Forum is intended for anyone who is interested in
discussion and development of regional exchanges. This
includes operators,
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
82 matches
Mail list logo
