<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I would bet you get about the same result with the two
providers.....all else being equal. <br>
mdev (mean deviation) is a simple way to measure jitter, and you
have to put in context with the min/avg/max numbers. If I had 7ms
of deviation and average times of 4ms, that would be an issue
because you would be likely to get packets out of order. But 7ms
compared to 286ms probably means nothing.<br>
<br>
Your biggest problem with both providers is delay, but if you can
tolerate the delay you have now, then you can probably tolerate the
delay with the other provider.<br>
<br>
Also note that although packet loss is 0%, some packets are still
dropped in both cases. One dropped packet means a small amount of
audio is lost (depends on codec, but often 20ms). If those handful
of dropped packets are scattered evenly then you wouldn't notice it,
but it's common for them to occur in a cluster. If the 13 packets
dropped in the first example all happened at once you would have
lost 260ms of audio....and you would certainly hear that. You may
be able to tell by watching the periods appear on the screen when
you run the ping command. Each period is a dropped packet....if
they accumulate in a burst then something is happening that you
would hear on the phone.<br>
<br>
<blockquote
cite="mid:CAH=k-+t9E_9cA3v0--+ZSVU8yvD1EvvpymwycZL7dYfKoxG6yw@mail.gmail.com"
type="cite">WOW.. That is the most complicated Ping I have ever
seen.. :) <br>
<br>
This is the result I got. <br>
<br>
# ping -f -i .02 -s 180 -Q 0xb8 xx.xx.xx.xx<br>
<i>PING xx.xx.xx.xx (xx.xx.xx.xx) 180(208) bytes of data.<br>
.............<br>
--- xx.xx.xx.xx ping statistics ---<br>
15338 packets transmitted, 15325 received, 0% packet loss, time
352748ms<br>
rtt min/avg/max/mdev = 276.499/286.185/310.118/7.248 ms, pipe
15, ipg/ewma 22.999/284.882 ms<br>
</i><br>
<br>
The same test with my Present SIP Provider gave me the result
below. <br>
<br>
<i>10926 packets transmitted, 10913 received, 0% packet loss, time
244048ms<br>
rtt min/avg/max/mdev = 289.514/292.668/316.350/2.336 ms, pipe
15, ipg/ewma 22.338/292.941 ms<br>
</i><br>
<br>
I suppose the value of mdev is much higher in the first case but
0% packet loss in both the cases. <br>
Does this mean that the voice quality is going to be real bad?? <br>
<br>
Thanks,<br>
Najim<br>
<br>
<div class="gmail_quote">
On Thu, Dec 1, 2011 at 6:33 AM, Adam Moffett <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:adamlists@plexicomm.net">adamlists@plexicomm.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
a ping is the time a packet needs for travelling to a
destination and<br>
back to you. So the one way latency you are refering to,
should be half<br>
the time your ping took.<br>
<br>
In your case this will be 130ms, I would say this is
still reasonable.<br>
</blockquote>
</blockquote>
</div>
I am probably splitting hairs, but that's not always true
because there's no guarantee that the reply traveled the same
path as the echo request. If you dig into BGP issues you'll
see sometimes that traffic one direction takes a different
route than traffic the other direction. I don't know of any
simple and accurate way to learn the "one way" latency so I'm
surprised they specified anything other than round trip time.
<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
'Ping time' is not an accurate predictor of SIP quality.<br>
<br>
A 'ping' is an ICMP Echo/reply packet and some routers
consider them less important than 'data' packets and
service them on an 'as resources permit' basis. <br>
</blockquote>
</div>
That's possibly maybe true if someone's router or connection
is overloaded and they are trying to make up for it with CoS
policies while they save up for an upgrade. Otherwise it's an
apology for a crappy network. That's the brutally honest
truth.<br>
<br>
You can make a pretty good prediction with ping.<br>
"sudo ping -f -i .02 -s 180 -Q 0xb8 [ip]" gives a tolerable
simulation of voip traffic. let it run for awhile, then press
ctrl+c and see how many packets were dropped and also check
the mdev number. If mdev is low and packet loss is almost
nothing then you can expect decent voice quality. It may not
be a 100% perfect test, but I'll bet you a vast majority of
the time I can do that test and tell you whether it's going to
suck.<br>
<br>
latency by itself with low jitter and no packet loss just
means delay. It's a matter of opinion and circumstance how
tolerable delay is, but I think your 230ms ping is at the
upper edge of what most people can live with. Much more than
that and you'll be tempted to say 'over' at the end of
sentence.
<div class="HOEnZb">
<div class="h5"><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a
moz-do-not-send="true" href="http://www.api-digital.com"
target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar
every Thurs:<br>
<a moz-do-not-send="true"
href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a moz-do-not-send="true"
href="http://lists.digium.com/mailman/listinfo/asterisk-users"
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
New to Asterisk? Join us for a live introductory webinar every Thurs:
<a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a></pre>
</blockquote>
<br>
</body>
</html>