<br><div><span class="gmail_quote">On 1/9/06, <b class="gmail_sendername">Terry H. Gilsenan</b> <<a href="mailto:thg@interoil.com">thg@interoil.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>I have phones in the US conencted to and Asterisk box in .AU, the ping<br>time averages 230ms, (ADSL at both ends) and the call quality is just fine.<br><br>The problem will be if packets are being dropped, of if one or other of
<br>the end-points is getting saturated. I have Linux/IPTables with ToS and<br>QoS giving voice data the highest priority.<br></blockquote></div><br><br>That is very true when it comes to actual voice quality. But the original poster's users are complaining about latency.
<br><br>If one of the end-points is getting saturated, then that fact should be reflected in the round trip ping times, as the icmp (ping) packets will have to sit in the buffer of the saturated end's router/bridge until its turn comes to get sent down the line. A Linux IPTables machine with ToS and/or QoS at each endpoint (or even just the congested endpoint) can certainly help solve this kind of a problem; in fact I use one myself. But the problem itself is usually detectable by abnormally high ping times from endpoint to endpoint and a sudden jump in traceroute ping times along the route once the saturated interface is reached.
<br><br>If the round trip time across the Internet is 230 ms as in your case, or (100 ms) in the case of my earlier rule of thumb, one-way Internet time would be 115 ms (50 ms) and wouldn't be considered a problem. But, an internet one-way trip time of 115 ms (50 ms) is not normally going to provide a mouth-to-ear voice path time of 115 ms (50 ms), since additional delays will be caused by the jitter buffer if one is in use, as well as by any echo cancellation that may be in use. In my experience, if there is much jitter at all on the Internet path, voice quality will degrade unless a jitter buffer is used. But, the worse the jitter is, the larger the jitter buffer needs to be and the more latency will be introduced by it. So you've essentially got a tradeoff between "voice quality" (
i.e. lack of jitter + lack of packet loss) and latency. <br><br>It does not take much jitter nor all that much latency to cause degradation in the quality and mouth-to-ear delay of VoIP calls. You could easily have a line that would never give you any problems in a web browser or even an ssh session, but that would severely interfere with the quality of a VoIP call. In this case, if you can reduce the Internet latency and/or jitter between your two endpoints, you can improve voice quality of and/or reduce the delay present in your VoIP calls.
<br><br>-Rusty<br><br><br><br>