how to find out one way latency

Home » Asterisk Users » how to find out one way latency
Asterisk Users 11 Comments

Hi All,

How can I find out One way latency from my PBX to my SIP Trunk Provider.
My SIP provider recommends a One way latency of 100ms for good Voice
quality. Ping request to their IP Address gives me a response in approx.
260ms.
Will that be good enough for a SIP Trunk.

Please help. We are trying to sign up with a new SIP Provider.

Thanks,
Najim

11 thoughts on - how to find out one way latency

  • Am 30.11.2011 21:47, schrieb NaJIm:

    Hi Najim,

    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.

  • ‘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.

  • Thank you Ruben.

    Is there anything else that I should be concerned about when looking for a
    SIP provider. ??

    Regards,
    Najim.

    On Thu, Dec 1, 2011 at 2:34 AM, Ruben Rögels

  • Does that mean I can expect lesser delays with my Voice packets ?? That
    would be even better.

    Regards,
    Najim

  • Is there anything else that I should be concerned about, when looking to
    signup for a SIP provider. ??

    Regards,
    Najim

  • 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.

    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.

  • 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.
    ………….

  • 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.

  • Fully agree,

    Actually, you can do better than just a ping, but it takes some time,
    equipment and experience:

    What you can do, is adding an extra box inbetween your voip-client and
    voip-server, and introduce all kinds of “real-life” circumstances.
    I mean artificial delay, loss, resequencing, duplicating packages,
    reduced bandwith. We’ve done it some time ago as an “satelite simulator”
    You can build it aroud any *bsd/linux box with multiple nics.

    The basic idea’s you can find at http://lartc.org/
    If you combine it with the echo function from asterisk, you can decide
    for yourself what it acceptable and what not.

    For one of my projects i push the echo destination as the “default” sip
    connection to their soft phone, as i noticed that people at the other
    side of town regularly have a worse connection then people using umts or
    satelite. Main culprit (in my case) is ill-configured WIFI-setup.
    Latencies of over 10,000 ms and loss of 80% are daily events.
    And people complaining….

    hw