I would bet you get about the same result with the two providers.....all
else being equal.
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.
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.
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.
WOW.. That is the most complicated Ping I have ever seen.. :)
This is the result I got.
# ping -f -i .02 -s 180 -Q 0xb8 xx.xx.xx.xx
/PING xx.xx.xx.xx (xx.xx.xx.xx) 180(208) bytes of data.
.............
--- xx.xx.xx.xx ping statistics ---
15338 packets transmitted, 15325 received, 0% packet loss, time 352748ms
rtt min/avg/max/mdev = 276.499/286.185/310.118/7.248 ms, pipe 15,
ipg/ewma 22.999/284.882 ms
/
The same test with my Present SIP Provider gave me the result below.
/10926 packets transmitted, 10913 received, 0% packet loss, time 244048ms
rtt min/avg/max/mdev = 289.514/292.668/316.350/2.336 ms, pipe 15,
ipg/ewma 22.338/292.941 ms
/
I suppose the value of mdev is much higher in the first case but 0%
packet loss in both the cases.
Does this mean that the voice quality is going to be real bad??
Thanks,
Najim
On Thu, Dec 1, 2011 at 6:33 AM, Adam Moffett <adamli...@plexicomm.net
<mailto:adamli...@plexicomm.net>> wrote:
a ping is the time a packet needs for travelling to a
destination and
back to you. So the one way latency you are refering to,
should be half
the time your ping took.
In your case this will be 130ms, I would say this is still
reasonable.
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.
'Ping time' is not an accurate predictor of SIP quality.
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.
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.
You can make a pretty good prediction with ping.
"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.
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.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
