cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1303
Views
15
Helpful
8
Replies

jitter problem

hugoeic
Level 1
Level 1

I'm getting a jitter of 15ms!

link 128kbps(clock rate), 1 stream Chariot 118(tunnel overhead)*50pps*8kbps=47.2kbps, and MGEN 60kbps

IPv6-MGEN---f0/1-|Router1-s0/0----tunnel GRE----s0/0--Router2-------fastE

IPv4-chariot---f0/0-|

class-map match-all skinny

match dscp cs3 af31

match protocol ipv6

class-map match-all voz

match dscp ef

match protocol ipv6

class-map match-all def

match protocol ipv6

!

!

policy-map pri80

class voz

priority 500

class skinny

bandwidth 10

class def

police 85000

int ser0/0

sevice-policy pri80

thanks

Hugo

8 Replies 8

Patrick Laidlaw
Level 4
Level 4

Hugo,

15ms of jitter is completly tolerable if your noticing serialization delays you might look into using mlppp across the links inorder to interleave your packets.

Patrick

what is the maximum jitter?

thanks

Hugo

Hello,

the ITU recommendations (G.114) are:

- one-way-delay below 150 ms

- jitter below 30 ms

This is no hard limit (like with 151 ms delay it´s unusable) but a statement about user acceptance of voice quality. You might get away with 200 ms delay as well.

Technically there is a dejitter buffer, which stores data before sending it as voice through the handset with VoIP. The question is on one hand: how large is the dejitter buffer? You should stay within this limit to avoid voice degradation.

There are however also systems, which dynamically adjust the dejitter buffer. Then in any case it should be below 150 ms - (sum of other delays).

Delays - to name a few - are caused for VoIP by: packetization, serialization, processing, transportation.

So in the end you need to calculate a "delay budget" to figure out what the possibilities are in your environment.

Hope this helps! Please rate all posts.

Regards, Martin

A second comment on your jitter: Did you configure Link Fragmentation and Interleaving (LFI) on your link. This is the technical approach to solve the jitter problem on low speed links. Have a look at f.e. "Reducing Latency and Jitter for Real-Time Traffic Using Multilink PPP Roadmap" at

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008044677d.html

for an explanation of the problem and the prposed solution. It will allow you to predict (and "configure") the jitter caused by your serial link.

Hope this helps! Please rate all posts.

Regards, Martin

hi

what is the maximum jitter for VoIP recommended...

thanks

Hugo

Hugo

I would recommend anything in a Campus Lan environment under 5ms over WAN links is a different thing depending on what your use to. I deal with a lot of satellite links so I expect to see quite a bit more two way latency than most people 600ms on average. But when dealing with terestrial links anything under 30 is tolerable.

Patrick

I would like to know if the delay on my network is acceptable for VOIP. How can I test the delay? By PING (what is the byte size) or other method?

Thanks.

Doug

Hi Doug,

There are a couple of things to note first:

- generally ping packets are treated as low-priority so try and use two end-points that are reasonably free of congestion before using ping

- if the network is prioritising voice packets based on DSCP EF, set the appropriate DSCP value on your ping packets

If you do the above, you can use pings to get a rough idea of the latency. The size of the packet you use should match the size of your VoIP packets. This depends on the codec used. For example, with G.711, your packets could be;

160 (voice payload)

+ 12 (RTP)

+ 8 (UDP)

+ 20 (IP)

= 200 Bytes.

Alternatively, with G.729, you have:

20 (voice payload)

+ 12 (RTP)

+ 8 (UDP)

+ 20 (IP)

= 60 Bytes.

Once you account for the above, you can certainly use pings. Divide the total round-trip time by 2 to give you an approximate one-way latency.

Pls rate the post if it helps.

Paresh

The size could be lower again if you are using compressed RTP headers.