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.
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
I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going.
Alec
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 other streaming media applications that put your tcp performance in the toilet.
- jared
g729a, yes.
-Bill
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 the US.
In fact I found, using a software solution that if I dialed into a
local dial-up provider and used VoIP I got better quality than just dialing
direct.
Bill speaks from experience of actually deploying a globally
distributed VoIP system. No Q0S, no dedicated circuits, no large
bandwidth requirements.
JC
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 to corporate networks where
peak hour usage is very near or at available bandwidth the mechanics are different.
However, in our experience VoIP performance is more often hurt by either
broken router code or misconfigured devices in the path (route cache purges,
duplex mismatches, etc.) than actual lack of bandwidth.
If it does not cost you, it�s a good idea to let the VoIP packets first to
a low-bandwidth link but putting serious engineering or money for hardware
is not neccessary. Fancy queueing will give you more consistent performance
when something else uses up the link(s).
Pete
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.
I have run VOIP from Germany without any optimization, customization, QOS,
crossing public Internet, going through a firewall that slows everything and
its dog down, across heavily loaded T1 into my office in LoneGrove,
Oklahoma, and I don't get a delay one, no echo, no problems. Granted, I'm
sustaining a single voice thread here, although it might be useful to point
out that I'm using two different platforms on each side. VOIP can give you
problems, but QOS is usually the least of your worries. I'm more concerned
with the products I'm using and how they handle echo, latency, etc. This is
a market that you test before you buy, and then test some more. If you go
off promo material, you're digging a quick grave, IMHO.
-Jack