Forum Home
Press F1
Thread ID: 95121	2008-11-25 04:39:00	Which ISP in the Auckland CBD for low jitter - or is the exchange overloaded?	Chilling_Silence (9)	Press F1

Post ID	Timestamp	Content	User
722785	2008-11-25 04:39:00	Hey all, So the business Im working for has just moved floors in the building, and changed ISPs. This is cool, they were with Orcon, now they're with Telstra, full-speed up & down, no probs. Speed tests are great. Problem: Jitter / latency sucks! Pinging from my VPS through the VPN to a client we have in Avondale it looks like this: ~# ping -c 20 Box1 PING Box1 (10.179.0.18) 56(84) bytes of data. 64 bytes from Box1 (10.179.0.18): icmp_seq=1 ttl=64 time=12.3 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=2 ttl=64 time=12.5 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=3 ttl=64 time=11.2 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=4 ttl=64 time=12.2 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=5 ttl=64 time=11.6 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=6 ttl=64 time=12.0 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=7 ttl=64 time=11.8 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=8 ttl=64 time=10.8 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=9 ttl=64 time=12.8 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=10 ttl=64 time=11.6 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=11 ttl=64 time=11.9 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=12 ttl=64 time=12.8 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=13 ttl=64 time=12.7 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=14 ttl=64 time=11.5 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=15 ttl=64 time=10.6 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=16 ttl=64 time=33.0 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=17 ttl=64 time=11.4 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=18 ttl=64 time=11.5 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=19 ttl=64 time=11.8 ms 64 bytes from Box1 (10.179.0.18): icmp_seq=20 ttl=64 time=13.7 ms --- Box1 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 18998ms rtt min/avg/max/mdev = 10.607/13.028/33.050/4.651 ms Sweet right, thats how a connection *should* look! :D Doing it from the VPS to our new Telstra connection in town and we get: ~# ping -c 20 Box2 PING Box2 (10.179.0.38) 56(84) bytes of data. 64 bytes from Box2 (10.179.0.38): icmp_seq=1 ttl=64 time=280 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=2 ttl=64 time=161 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=3 ttl=64 time=285 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=4 ttl=64 time=286 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=5 ttl=64 time=172 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=6 ttl=64 time=46.6 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=7 ttl=64 time=58.7 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=8 ttl=64 time=115 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=9 ttl=64 time=70.0 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=10 ttl=64 time=48.8 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=11 ttl=64 time=51.9 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=12 ttl=64 time=51.0 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=13 ttl=64 time=46.9 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=14 ttl=64 time=62.3 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=15 ttl=64 time=94.4 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=16 ttl=64 time=60.4 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=17 ttl=64 time=45.8 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=18 ttl=64 time=49.2 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=19 ttl=64 time=54.9 ms 64 bytes from Box2 (10.179.0.38): icmp_seq=20 ttl=64 time=48.1 ms --- Box2 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19005ms rtt min/avg/max/mdev = 45.895/104.596/286.829/83.533 ms And that's at a *good* part of the day. Its been WAY worse at points :( Now I've had some comments that the local exchange (Because we're right in the CBD) might be overloaded, especially with all the students getting home from Uni, whatever, plus a ton of businesses... In terms of it being used for general internet, its fine. In terms of it being used for VoIP, it sucks :( So, right now we're going through 20-40GB and the connections costing around $80-120 a month I think? Fibre from what I understand is somewhere 4-5x that, which is a HUGE blow! Pretty much negates most of the benefits of VoIP. Who can recommend some ISPs in town? Do we *need* to go Fibre because the ADSL exchange is overloaded? The VoIP traffic is just across to the other side of the CBD, travelling a few K's at most ... :( Any help would be much appreciated Cheers Chill.	Chilling_Silence (9)
722786	2008-11-25 04:58:00	You could try using the ilbc codec, if your system supports it, as it is very resilient to excessive jitter. Even if you just used it for your trunk it would help.	ughnz (8297)
722787	2008-11-25 05:28:00	True.. Ive compiled iLBC on a few systems, even with Asterisk-1.6 Only thing is that kills our ability to fax.. Then again its not exactly 100% at the moment anyways, so yeah :-/	Chilling_Silence (9)
722788	2008-11-25 05:45:00	Have you checked out CityLink www.citylink.co.nz	Safari (3993)
722789	2008-11-25 07:03:00	CityLink? Fibre? We're in Anzac street ... not on the list, but it is rather dated (2007) so I might call them :)	Chilling_Silence (9)
722790	2008-11-25 07:40:00	True.. Ive compiled iLBC on a few systems, even with Asterisk-1.6 Only thing is that kills our ability to fax.. Then again its not exactly 100% at the moment anyways, so yeah :-/ Have you considered T.38 for the faxing? Asterisk 1.6 will support it pass through.	ughnz (8297)
722791	2008-11-25 09:24:00	Now thats a good question ... Do you know if it works over compressed channels though like iLBC? Currently we've just been using an ATA (with a-law through all trunks) and its been surprisingly well on local faxes. International is a no-go though.	Chilling_Silence (9)
722792	2008-11-25 09:36:00	Hmm... this is a fair bit better - I run the test from home pinging PressF1, and SSH'd into the asterisk box just now, this is definitely how it should be! Home: C:\Documents and Settings\Administrator>ping -n 30 pressf1.co.nz Pinging pressf1.co.nz [210.48.100.45] with 32 bytes of data: Reply from 210.48.100.45: bytes=32 time=35ms TTL=54 Reply from 210.48.100.45: bytes=32 time=46ms TTL=54 Reply from 210.48.100.45: bytes=32 time=37ms TTL=54 Reply from 210.48.100.45: bytes=32 time=38ms TTL=54 Reply from 210.48.100.45: bytes=32 time=39ms TTL=54 Reply from 210.48.100.45: bytes=32 time=39ms TTL=54 Reply from 210.48.100.45: bytes=32 time=38ms TTL=54 Reply from 210.48.100.45: bytes=32 time=36ms TTL=54 Reply from 210.48.100.45: bytes=32 time=43ms TTL=54 Reply from 210.48.100.45: bytes=32 time=39ms TTL=54 Reply from 210.48.100.45: bytes=32 time=45ms TTL=54 Reply from 210.48.100.45: bytes=32 time=37ms TTL=54 Reply from 210.48.100.45: bytes=32 time=37ms TTL=54 Reply from 210.48.100.45: bytes=32 time=39ms TTL=54 Reply from 210.48.100.45: bytes=32 time=39ms TTL=54 Reply from 210.48.100.45: bytes=32 time=46ms TTL=54 Reply from 210.48.100.45: bytes=32 time=42ms TTL=54 Reply from 210.48.100.45: bytes=32 time=42ms TTL=54 Reply from 210.48.100.45: bytes=32 time=37ms TTL=54 Reply from 210.48.100.45: bytes=32 time=36ms TTL=54 Reply from 210.48.100.45: bytes=32 time=38ms TTL=54 Reply from 210.48.100.45: bytes=32 time=40ms TTL=54 Reply from 210.48.100.45: bytes=32 time=45ms TTL=54 Reply from 210.48.100.45: bytes=32 time=45ms TTL=54 Reply from 210.48.100.45: bytes=32 time=38ms TTL=54 Reply from 210.48.100.45: bytes=32 time=40ms TTL=54 Reply from 210.48.100.45: bytes=32 time=35ms TTL=54 Reply from 210.48.100.45: bytes=32 time=40ms TTL=54 Reply from 210.48.100.45: bytes=32 time=35ms TTL=54 Reply from 210.48.100.45: bytes=32 time=39ms TTL=54 Ping statistics for 210.48.100.45: Packets: Sent = 30, Received = 30, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 35ms, Maximum = 46ms, Average = 39ms Work: # ping -c 30 pressf1.co.nz PING pressf1.co.nz (210.48.100.45) 56(84) bytes of data. 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=1 ttl=52 time=42.9 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=2 ttl=52 time=41.5 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=3 ttl=52 time=42.8 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=4 ttl=52 time=43.1 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=5 ttl=52 time=44.4 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=6 ttl=52 time=42.2 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=7 ttl=52 time=45.8 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=8 ttl=52 time=41.4 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=9 ttl=52 time=43.0 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=10 ttl=52 time=47.7 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=11 ttl=52 time=42.9 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=12 ttl=52 time=40.9 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=13 ttl=52 time=43.8 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=14 ttl=52 time=41.4 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=15 ttl=52 time=40.9 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=16 ttl=52 time=42.8 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=17 ttl=52 time=41.1 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=18 ttl=52 time=41.9 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=19 ttl=52 time=41.3 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=20 ttl=52 time=42.8 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=21 ttl=52 time=41.1 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=22 ttl=52 time=43.5 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=23 ttl=52 time=41.6 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=24 ttl=52 time=43.8 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=25 ttl=52 time=46.9 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=26 ttl=52 time=41.0 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=27 ttl=52 time=41.4 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=28 ttl=52 time=43.7 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=29 ttl=52 time=42.3 ms 64 bytes from ip-210-48-100-45.iconz.net.nz (210.48.100.45): icmp_seq=30 ttl=52 time=41.8 ms --- pressf1.co.nz ping statistics --- 30 packets transmitted, 30 received, 0% packet loss, time 29011ms rtt min/avg/max/mdev = 40.907/42.771/47.765/1.698 ms No spikes at all - I ran a test just now for some 15 minutes and its all gravy! :)	Chilling_Silence (9)
722793	2008-11-26 04:46:00	Well Ive learned that because Im using IAX2 for the trunks, that T.38 is out of the question anyway, but thats a small loss. Have figured that I can grab the source for asterisk-1.4.22, compile it on another identical box, grab the one ilbc file and then simply copy it to all my other boxes :D Works well so far I must say, but still not quite perfect ... Any other suggestions? Thanks Chill.	Chilling_Silence (9)
722794	2008-11-26 08:40:00	Well Ive learned that because Im using IAX2 for the trunks, that T.38 is out of the question anyway, but thats a small loss. Have figured that I can grab the source for asterisk-1.4.22, compile it on another identical box, grab the one ilbc file and then simply copy it to all my other boxes :D Works well so far I must say, but still not quite perfect ... Any other suggestions? Thanks Chill. You will find a script in the contrib directory to use for ilbc, very important to use it for asterisk 1.6 I have used T.38 on an IAX trunk before with no problems using SPA2102 devices at both ends of the circut. Remember to disable any re-invites. Have you thought about fine tuning the jitter buffer on the IAX trunk? As for overseas faxing, it will depend on who your ITSP is as they provide the PSTN gateway for the faxing, and your ITSP supports T.38 as very few do. Many ITSPs provide fax <> email gateways which end up being a better solution for faxing. I have used the ilbc codec on alot of high and variable latency connections and it does seem to perform the best, but on realy bad circuts you can notice the drop in audio quality. Sometimes the only hope is to find a better circut.. which it may seem is the better option in your case.	ughnz (8297)
1