Simplest QoS for VoIP

Hi,
I have two PBXs in two different sites, exchanging communication by VoIP
across a network link.
I'd like to setup some QoS for phone traffic (good idea, isn't? ) but I'm
not a "guru" of QoS.
Some preliminary suggestion? Good reading?
A simple setup?
Do I need to setup QoS only between routers or along the whole chain of
devices?

Thanks in advance
Mimmus

P.S. Sorry for my bad english

 

Mimmus,

While I've never dealt with Qos for voice over IP, I've worked with it for video over IP purposes
quite a bit..

The first thing I would to id examine all of the links that the VoIP traverses (ethernet ports on
routers/switches, serial ports on T1, etc.) and see how high the utilization tends to be..

QoS is going to do you the most good on links that tend to get physically saturated.. I would
concentrate on those links first and foremost..

QoS can do a little good in situations where the links are not getting physically saturated, but
often times it's not much of a noticable difference in those cases...

Low Latency Queueing (LLQ) works pretty good for us.. We use it to set a specific priority queue for
a set amount of video BW, and those packets will get preferential treatment when being transmitted
out an interface up to that certain BW..

Weighted Randon Early Detection (WRED) is another good QoS method that especially works good on
saturated links.. I like to think of it is a sniper with a gun, killing the lower priority packets
one at a time before they have a chance to fill your queue and cause problems for your higher
priority packets..

But again, I can't stress enough to check those utilizations and focus on links that might tend to
get physically saturated first..

Good luck!

Mike

: Hi,
: I have two PBXs in two different sites, exchanging communication by VoIP
: across a network link.
: I'd like to setup some QoS for phone traffic (good idea, isn't? ) but I'm
: not a "guru" of QoS.
: Some preliminary suggestion? Good reading?
: A simple setup?
: Do I need to setup QoS only between routers or along the whole chain of
: devices?

: Thanks in advance
: Mimmus

: P.S. Sorry for my bad english

 

Links seem not to be saturated often but VoIP calls are not so good.
I choose an empirical approach.
I set up simple Flow-Based WFQ (Weighted Fair Queue) to grant volume traffic
streams-which comprise the majority of traffic-receive increased service,
transmitting the same number of bytes as high-volume streams.
Then I set up also LFI (Link Fragmentation and Interleaving). Interactive
traffic (Telnet, Voice over IP, and the like) is susceptible to increased
latency and jitter when the network processes large packets (for example,
LAN-to-LAN FTP transfers traversing a WAN link), especially as they are
queued on slower links. The Cisco IOS LFI feature reduces delay and jitter
on slower-speed links by breaking up large datagrams and interleaving
low-delay traffic packets with the resulting smaller packets.

Thanks
DV

 

Hmm, you might want to start looking at how clean your links are, making sure there are no errors
and such. Specifically, check the router-->switch ethernet links for output errors. If you see any
output errors climbing, hard code the speed and duplex on both sides of the dirty link.. I've seen
where having AUTO set on one or both sides caused congestion alerts w/ video calls and very bad
video quality. Hard coding the speed AND duplex on BOTH sides cleared the video problems right up..

Also, make sure you don't have any L3 load balancing across two parallel links in the mix.. That's
another enemy for video, because packets can arrive out of order if one packet goes across one link
and one packet goes across the other... I'm sure voice would be just as supceptable as video to
problems from this, but again, I don't claim to have voice experience (just video)! ;-)

: Links seem not to be saturated often but VoIP calls are not so good.
: I choose an empirical approach.
: I set up simple Flow-Based WFQ (Weighted Fair Queue) to grant volume traffic
: streams-which comprise the majority of traffic-receive increased service,
: transmitting the same number of bytes as high-volume streams.
: Then I set up also LFI (Link Fragmentation and Interleaving). Interactive
: traffic (Telnet, Voice over IP, and the like) is susceptible to increased
: latency and jitter when the network processes large packets (for example,
: LAN-to-LAN FTP transfers traversing a WAN link), especially as they are
: queued on slower links. The Cisco IOS LFI feature reduces delay and jitter
: on slower-speed links by breaking up large datagrams and interleaving
: low-delay traffic packets with the resulting smaller packets.

: Thanks
: DV

 

Good suggestion for indagating furtherly!
I have a 2x2Mbps multilink PPP link and it is surely bad for VoIP but I
cannot do nothing: the other chance is a 4x2Mbps ATM/IMA link.

Have a good day
MImmus

 

Hmm, Mppp generally doesn't hurt video as long as it's one bundle w/ 1 IP at each
end, and I assume it is.. CEF per-packet load sharing, a popular alternative for
MPPP, is bad news though..

The ATM links could be your culpret. The bottom line is that if your routing
protocol is seeing the links as two seperate IP paths and load balancing between
them, that's when the problems show up..

: Good suggestion for indagating furtherly!
: I have a 2x2Mbps multilink PPP link and it is surely bad for VoIP but I
: cannot do nothing: the other chance is a 4x2Mbps ATM/IMA link.

: Have a good day
: MImmus

 

Ah, OK. Then Mppp is good, I don't use CEF in this case.

Thank you for anything
Mimmus