SIP latency

Discussion in 'UK VOIP' started by Theo Markettos, Jul 29, 2013.

  1. Been doing some traceroutes of SIP providers and thought folks might be
    interested...

    Hops Host Loss% Snt Last Avg Best Wrst StDev

    Orlando:
    15. hosted-by.leaseweb.com (voxbeam)0.0% 36 117.1 119.5 115.9 129.5 3.5

    Netherlands:
    13. localphone.com 0.0% 49 29.5 32.2 28.6 53.7 4.7
    17. 77.72.174.128 (Betamax) 0.0% 34 33.1 35.2 31.9 43.8 2.8

    Germany:
    15. sipgate.co.uk 0.0% 35 40.8 36.5 31.5 66.5 6.3

    UK:
    11. voipfone-170.gw.goscomb.net 0.0% 36 14.8 14.4 11.0 26.8 3.3
    (12th hop doesn't reply to traceroute, this could be incomplete)
    12. sip.voip.thw.gradwell.net 0.0% 31 24.5 26.2 22.3 33.3 3.3
    11. a.voiceless.aa.net.uk 0.0% 40 16.1 20.6 15.4 34.0 4.6

    Anycast, geolocate says Mountain View:
    14. any-in-2001.1e100.net 0.0% 35 28.3 26.4 23.2 38.2 2.8
    (Google Voice)

    Setup is Virgin Media cable connection in Cambridge, takes ~14ms and 7 hops
    from my machine to exiting *.virginmedia.com. About 1ms of that is local.

    It's an interesting thought... if you pick the wrong SIP provider you end up
    with 200ms more latency. Though you never know what the routes do beyond
    the provider.

    Theo
     
    Theo Markettos, Jul 29, 2013
    #1
    1. Advertising

  2. On 29/07/13 23:10, Theo Markettos wrote:
    > Been doing some traceroutes of SIP providers and thought folks might be
    > interested...


    These are statistics for ICMP echo, not for SIP, or what you probably
    meant, RTP. ICMP echo is likely to be given low priority for
    transmission, and high priority for being discarded, compared with even
    non-QoSed RTP. (It is unlikely that a mass market ISP would honour QoS
    on SIP or RTP, as it would be too open to abuse for non-VoIP traffic,
    but they are still likely to give ICMP echo lower QoS.)

    If you want to provide statistics for RTP, use the QoS monitoring tools
    in your SIP user agents. This will give information for both directions.
     
    David Woolley, Jul 30, 2013
    #2
    1. Advertising

  3. David Woolley <> wrote:
    > On 29/07/13 23:10, Theo Markettos wrote:
    > > Been doing some traceroutes of SIP providers and thought folks might be
    > > interested...

    >
    > If you want to provide statistics for RTP, use the QoS monitoring tools
    > in your SIP user agents. This will give information for both directions.


    Fair point, though I don't have accounts in those places to be able to set
    up SIP calls. Does anyone post such stats from active calls?

    Theo
     
    Theo Markettos, Jul 30, 2013
    #3
  4. R. Mark Clayton <> wrote:
    > Can you work out the speed of light now?


    Indeed, there's a fairly good relationship. My point is it's not entirely
    obvious for some... eg Betamax (Swiss company trading via Luxembourg routes
    from Netherlands), or Sipgate.co.uk is actually in Germany (but Sipgate.com
    is in the US). Not that Europe really matters, but a transatlantic
    roundtrips starts getting annoying. Particularly if it's on top of the VOIP
    routing - caller/UK-US-callee/UK-US-caller/UK where there are 4x
    transatlantic transits for every echo.

    Theo
     
    Theo Markettos, Jul 30, 2013
    #4
  5. Theo Markettos

    Nick Guest

    On 30/07/2013 23:08, Theo Markettos wrote:
    > R. Mark Clayton <> wrote:
    >> Can you work out the speed of light now?

    >
    > Indeed, there's a fairly good relationship. My point is it's not entirely
    > obvious for some... eg Betamax (Swiss company trading via Luxembourg routes
    > from Netherlands), or Sipgate.co.uk is actually in Germany (but Sipgate.com
    > is in the US). Not that Europe really matters, but a transatlantic
    > roundtrips starts getting annoying. Particularly if it's on top of the VOIP
    > routing - caller/UK-US-callee/UK-US-caller/UK where there are 4x
    > transatlantic transits for every echo.
    >


    The point is obvious but for RTP not SIP. I just checked (with
    wireshark) and sipgate.co.uk is indeed running RTP apparently out of
    Dussledorf (from a uk pots call) .

    If the distance/delay relationship were dominated by the speed of light
    I would expect this to introduce a delay of ~4ms. However I actually
    expect this distance/delay relationship is dominated by electronic stuff
    (maybe boosters/routers/switches).

    Personally I can live with the extra 20ms I see on ping
     
    Nick, Jul 31, 2013
    #5
  6. On 15/08/13 21:11, alexd wrote:
    > David Woolley (for it is he) wrote:
    >
    >> These are statistics for ICMP echo, not for SIP, or what you probably
    >> meant, RTP. ICMP echo is likely to be given low priority for
    >> transmission,

    >
    > Given that this only comes into play where links are congested, I should
    > think it doesn't make a whole lot of difference - if you're trying to run a
    > voice service over a congested link [be you a service provider or an end
    > user] then you're already screwed.
    >

    If a packet network isn't somewhat congested, it isn't being used
    efficiently.
     
    David Woolley, Aug 15, 2013
    #6
  7. Theo Markettos

    Stephen Guest

    On Wed, 31 Jul 2013 11:00:42 +0100, Nick <>
    wrote:

    >On 30/07/2013 23:08, Theo Markettos wrote:
    >> R. Mark Clayton <> wrote:
    >>> Can you work out the speed of light now?

    >>
    >> Indeed, there's a fairly good relationship. My point is it's not entirely
    >> obvious for some... eg Betamax (Swiss company trading via Luxembourg routes
    >> from Netherlands), or Sipgate.co.uk is actually in Germany (but Sipgate.com
    >> is in the US). Not that Europe really matters, but a transatlantic
    >> roundtrips starts getting annoying. Particularly if it's on top of the VOIP
    >> routing - caller/UK-US-callee/UK-US-caller/UK where there are 4x
    >> transatlantic transits for every echo.
    >>

    In practice speed of light approximation we use at work for fibre is ~
    2/3rds of vacuum

    The useful rule of thumb is 1 mSec per 100 Km round trip
    >
    >The point is obvious but for RTP not SIP. I just checked (with
    >wireshark) and sipgate.co.uk is indeed running RTP apparently out of
    >Dussledorf (from a uk pots call) .


    The paths use for IP bear some relationship with distance - but what
    matters is the path used for the fibre and those tend to meander
    >
    >If the distance/delay relationship were dominated by the speed of light
    >I would expect this to introduce a delay of ~4ms. However I actually
    >expect this distance/delay relationship is dominated by electronic stuff
    >(maybe boosters/routers/switches).


    Not usually over continent sized WANs
    - a lot of the traffic rides over lambdas on the fibre, with
    amplification as colours, and only store and forward delays at a
    router
    - since the high end routes will be carried in 10 Gbps+ pipes those
    get fairly small.
    - forwarding latency through a high end router is usually small
    numbers of uSec as well, so the route distance dominates.

    >
    >Personally I can live with the extra 20ms I see on ping
    >
    >

    some of which is probably down to dejitter buffers and software delays
    in the end points......
    --
    Regards

    - replace xyz with ntl
     
    Stephen, Aug 18, 2013
    #7
  8. Theo Markettos

    Nick Guest

    On 18/08/2013 18:15, Stephen wrote:
    > On Wed, 31 Jul 2013 11:00:42 +0100, Nick <>
    > wrote:
    >
    >> On 30/07/2013 23:08, Theo Markettos wrote:
    >>> R. Mark Clayton <> wrote:
    >>>> Can you work out the speed of light now?
    >>>
    >>> Indeed, there's a fairly good relationship. My point is it's not entirely
    >>> obvious for some... eg Betamax (Swiss company trading via Luxembourg routes
    >>> from Netherlands), or Sipgate.co.uk is actually in Germany (but Sipgate.com
    >>> is in the US). Not that Europe really matters, but a transatlantic
    >>> roundtrips starts getting annoying. Particularly if it's on top of the VOIP
    >>> routing - caller/UK-US-callee/UK-US-caller/UK where there are 4x
    >>> transatlantic transits for every echo.
    >>>

    > In practice speed of light approximation we use at work for fibre is ~
    > 2/3rds of vacuum
    >


    Um, yes I had forgotten the refractive index of glass.

    > The useful rule of thumb is 1 mSec per 100 Km round trip
    >>
    >> The point is obvious but for RTP not SIP. I just checked (with
    >> wireshark) and sipgate.co.uk is indeed running RTP apparently out of
    >> Dussledorf (from a uk pots call) .

    >
    > The paths use for IP bear some relationship with distance - but what
    > matters is the path used for the fibre and those tend to meander
    >>
    >> If the distance/delay relationship were dominated by the speed of light
    >> I would expect this to introduce a delay of ~4ms. However I actually
    >> expect this distance/delay relationship is dominated by electronic stuff
    >> (maybe boosters/routers/switches).

    >
    > Not usually over continent sized WANs
    > - a lot of the traffic rides over lambdas on the fibre, with
    > amplification as colours, and only store and forward delays at a
    > router
    > - since the high end routes will be carried in 10 Gbps+ pipes those
    > get fairly small.
    > - forwarding latency through a high end router is usually small
    > numbers of uSec as well, so the route distance dominates.
    >


    Fair enough. So I guess it applies to 6000km to Orlando but not so much
    to the 450km to Düsseldorf.


    >>
    >> Personally I can live with the extra 20ms I see on ping
    >>
    >>

    > some of which is probably down to dejitter buffers and software delays
    > in the end points......
    >


    Wouldn't they be present in all connections. So if my connection is 20
    ms to a local connection and 40ms to Düsseldorf that would already be
    accounted for? Actually I hadn't realised any thing apart from my voip
    software implemented a jitter buffer.
     
    Nick, Aug 18, 2013
    #8
  9. R. Mark Clayton <> wrote:
    > It is supposed to create the path, which once set up should route by the
    > shortest route (lowest number of hops) available dynamically.


    That depends on where the PSTN breakout is. For example:

    UK SIP -> US SIP -> US PSTN -> UK PSTN
    (and the same again for the receive channel)

    won't be able to optimise the path. Occasionally VOIP calls terminating on
    the PSTN get 'international' CLID - I have no idea where they originate
    from, but US might be a possibility.

    Theo
     
    Theo Markettos, Aug 19, 2013
    #9
  10. Theo Markettos

    Stephen Guest

    On Sun, 18 Aug 2013 22:20:09 +0100, Nick <>
    wrote:

    >On 18/08/2013 18:15, Stephen wrote:
    >> On Wed, 31 Jul 2013 11:00:42 +0100, Nick <>
    >> wrote:
    >>
    >>> On 30/07/2013 23:08, Theo Markettos wrote:
    >>>> R. Mark Clayton <> wrote:
    >>>>> Can you work out the speed of light now?
    >>>>
    >>>> Indeed, there's a fairly good relationship. My point is it's not entirely
    >>>> obvious for some... eg Betamax (Swiss company trading via Luxembourg routes
    >>>> from Netherlands), or Sipgate.co.uk is actually in Germany (but Sipgate.com
    >>>> is in the US). Not that Europe really matters, but a transatlantic
    >>>> roundtrips starts getting annoying. Particularly if it's on top of the VOIP
    >>>> routing - caller/UK-US-callee/UK-US-caller/UK where there are 4x
    >>>> transatlantic transits for every echo.
    >>>>

    >> In practice speed of light approximation we use at work for fibre is ~
    >> 2/3rds of vacuum
    >>

    >
    >Um, yes I had forgotten the refractive index of glass.
    >
    >> The useful rule of thumb is 1 mSec per 100 Km round trip
    >>>
    >>> The point is obvious but for RTP not SIP. I just checked (with
    >>> wireshark) and sipgate.co.uk is indeed running RTP apparently out of
    >>> Dussledorf (from a uk pots call) .

    >>
    >> The paths use for IP bear some relationship with distance - but what
    >> matters is the path used for the fibre and those tend to meander
    >>>
    >>> If the distance/delay relationship were dominated by the speed of light
    >>> I would expect this to introduce a delay of ~4ms. However I actually
    >>> expect this distance/delay relationship is dominated by electronic stuff
    >>> (maybe boosters/routers/switches).

    >>
    >> Not usually over continent sized WANs
    >> - a lot of the traffic rides over lambdas on the fibre, with
    >> amplification as colours, and only store and forward delays at a
    >> router
    >> - since the high end routes will be carried in 10 Gbps+ pipes those
    >> get fairly small.
    >> - forwarding latency through a high end router is usually small
    >> numbers of uSec as well, so the route distance dominates.
    >>

    >
    >Fair enough. So I guess it applies to 6000km to Orlando but not so much
    >to the 450km to Düsseldorf.
    >


    Even there.

    remember there is the North Sea in the way - they will be using a
    subsea cable, or fibre thru the Tunnel etc

    A lot of routes go between the "national carrier hotels" once they get
    past the landing stations - some of the subsea bits:
    http://www.submarinecablemap.com/

    so maybe London -> France via Tunnel, -> Paris / Amsterdam ->
    Frankfurt (everything to Germany seems to go via Frankfurt) 1st.....

    >
    >>>
    >>> Personally I can live with the extra 20ms I see on ping
    >>>
    >>>

    >> some of which is probably down to dejitter buffers and software delays
    >> in the end points......
    >>

    >
    >Wouldn't they be present in all connections. So if my connection is 20
    >ms to a local connection and 40ms to Düsseldorf that would already be
    >accounted for? Actually I hadn't realised any thing apart from my voip
    >software implemented a jitter buffer.


    ordinary applications dont.

    Lots of the audio / video stuff at work does since IP and variable
    latency is a new complication for a codec :)
    --
    Regards

    - replace xyz with ntl
     
    Stephen, Aug 21, 2013
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gareth Evans

    Latency on Wireless network.

    Gareth Evans, Apr 20, 2005, in forum: Wireless Networking
    Replies:
    1
    Views:
    5,951
    Peter Bui[MS]
    Apr 21, 2005
  2. Dean

    Cisca 10k latency

    Dean, Nov 17, 2003, in forum: Cisco
    Replies:
    0
    Views:
    634
  3. John Kinsella
    Replies:
    0
    Views:
    488
    John Kinsella
    Nov 22, 2003
  4. Mark Williams
    Replies:
    2
    Views:
    848
    clubfoot
    Apr 25, 2006
  5. Replies:
    2
    Views:
    9,065
    Michael Newbery
    Jun 19, 2006
Loading...

Share This Page