Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > UK VOIP > SIP latency

Reply
Thread Tools

SIP latency

 
 
Theo Markettos
Guest
Posts: n/a
 
      07-29-2013
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
 
Reply With Quote
 
 
 
 
David Woolley
Guest
Posts: n/a
 
      07-30-2013
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.
 
Reply With Quote
 
 
 
 
Theo Markettos
Guest
Posts: n/a
 
      07-30-2013
David Woolley <(E-Mail Removed)> 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
 
Reply With Quote
 
Theo Markettos
Guest
Posts: n/a
 
      07-30-2013
R. Mark Clayton <(E-Mail Removed)> 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
 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      07-31-2013
On 30/07/2013 23:08, Theo Markettos wrote:
> R. Mark Clayton <(E-Mail Removed)> 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



 
Reply With Quote
 
David Woolley
Guest
Posts: n/a
 
      08-15-2013
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.
 
Reply With Quote
 
Stephen
Guest
Posts: n/a
 
      08-18-2013
On Wed, 31 Jul 2013 11:00:42 +0100, Nick <(E-Mail Removed)>
wrote:

>On 30/07/2013 23:08, Theo Markettos wrote:
>> R. Mark Clayton <(E-Mail Removed)> 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

http://www.velocityreviews.com/forums/(E-Mail Removed) - replace xyz with ntl
 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      08-18-2013
On 18/08/2013 18:15, Stephen wrote:
> On Wed, 31 Jul 2013 11:00:42 +0100, Nick <(E-Mail Removed)>
> wrote:
>
>> On 30/07/2013 23:08, Theo Markettos wrote:
>>> R. Mark Clayton <(E-Mail Removed)> 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.

 
Reply With Quote
 
Theo Markettos
Guest
Posts: n/a
 
      08-19-2013
R. Mark Clayton <(E-Mail Removed)> 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
 
Reply With Quote
 
Stephen
Guest
Posts: n/a
 
      08-21-2013
On Sun, 18 Aug 2013 22:20:09 +0100, Nick <(E-Mail Removed)>
wrote:

>On 18/08/2013 18:15, Stephen wrote:
>> On Wed, 31 Jul 2013 11:00:42 +0100, Nick <(E-Mail Removed)>
>> wrote:
>>
>>> On 30/07/2013 23:08, Theo Markettos wrote:
>>>> R. Mark Clayton <(E-Mail Removed)> 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

(E-Mail Removed) - replace xyz with ntl
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Latency of copper vs latency of fibre? anon6111@hotmail.com Cisco 2 06-19-2006 01:09 AM
High latency when idle, low latency when passing traffic Mark Williams Cisco 2 04-25-2006 07:19 AM
The best SIP ATA-1000 and SIP ATA-1100 with The lowest price!!! voxquick via HWKB.com VOIP 0 04-03-2006 12:24 PM
Is "allow-connections sip to sip" working? Cisco 0 07-04-2005 06:35 PM
HSS SIP Server Framework used as infrastructure for industry's first fully SIP-controlled video conferencing and collaboration suite Sandeep Bharihoke VOIP 0 09-25-2003 07:47 AM



Advertisments