|
to Stewart
Re: [Voip.ms] new beta servers...said by Stewart:What is your device? How connected to the Internet? ISP? Bria on iPhone, and a consumer all-in-one (Fritz!Box 7390) that is essentially a SIP phone/DECT base. (wife-acceptance-factor at play) Recently switched ISP to TPG (www.tpg.com.au) because they ran fibre to my building. VDSL to the basement. 100/40 connection. Previously was on a different ISP (www.internode.on.net) who had better routing, but was ADSL2 syncing at 16/1.8. I'm not a heavy phone user, and any issues I've had have only cropped up very occasionally. This is more of an academic discussion, than a troubleshooting discussion. said by Stewart:but I would assume that VoIP.ms uses the same upstream providers for a given destination, regardless of which server you are on. How and where do they connect to that upstream provider? Would it just be regular internet routing to that upstream provider? Would they have multiple points of interconnection? It's all very opaque once you hit the voip.ms server. I like the idea of sanjose.voip.ms (hosted by Softlayer) because my ISP has local peering with them. I'm assuming Softlayer has good trans-pacific transit. But who knows. (They also have datacenters in Melbourne and Sydney ... hint hint voip.ms.) |
|
MartinMVoIP.ms Premium Member join:2008-07-21
1 recommendation |
MartinM
Premium Member
2015-Jan-6 1:43 pm
said by dmz:How and where do they connect to that upstream provider? We've many proxy servers distributed along the same POPs locations we use in USA and Canada. We really have some kind of a spider network. Example: Let's say, London has a better Latency/peering from London -> Los Angeles SIP proxy (Not POP, dedicated Proxy) -> Canadian Carrier, instead of London -> Carrier, that's the route this POP will use for that particular carrier. Peering plays a role. However, it doesn't represent a single point of failure, as backup routes are configured to go directly to carriers, if a proxy was to fail. It's all configured to minimize latency and jitter. When we can find routes with direct peering, we proxy, sometimes can chop off up to 100 ms with some carriers with our London server (And soon to come Paris and Amsterdam) this way. said by dmz: (They also have datacenters in Melbourne and Sydney ... hint hint voip.ms.) We've test servers deployed in Melbourne and Singapore. We're conducting latency tests to make sure they meet our quality requirements. We tried to launch Singapore 3 years ago and had to cancel the project but now the peering is much better. I'll be able to let you know in a few days if we deploy Melbourne. edit: bunch of typos Regards, |
|
|
|
Oceans 11
Anon
2015-Jan-6 1:53 pm
Any update as to when Faxing will be available? |
|
MartinMVoIP.ms Premium Member join:2008-07-21 |
MartinM
Premium Member
2015-Jan-6 1:55 pm
said by Oceans 11 :Any update as to when Faxing will be available? Let's try to not hijack.. » [Voip.ms] VOIP.MS fax beta maybe by Dec. 25Thanks |
|
|
to MartinM
said by MartinM:We've many proxy servers distributed along the same POPs locations we use in USA and Canada. We really have some kind of a spider network. That's interesting. Nice to peek under the hood. said by MartinM:I'll be able to let you know in a few days if we deploy Melbourne. You're going to get my hopes up! |
|
MartinMVoIP.ms Premium Member join:2008-07-21 |
MartinM
Premium Member
2015-Jan-6 2:06 pm
said by dmz:You're going to get my hopes up! Singapore is still a no-go. Proof that we've been trying to deploy in Asia for almost 5 years now: (13:40:27|root@singapore1:~)# uptime 13:40:33 up 1728 days, 18:51, 0 users, load average: 0.05, 0.03, 0.00 Latency is still too high, jitter is fine. That's not with Softlayer though, we might do a test with Soft Layer soon. We've high hopes for Australia, should have the results very soon, perhaps even today. |
|
|
dmz
Member
2015-Jan-6 2:30 pm
said by MartinM:We've high hopes for Australia, should have the results very soon, perhaps even today. I wait in anticipation. Thanks! |
|
dmz |
to MartinM
said by MartinM:We've high hopes for Australia, should have the results very soon, perhaps even today. Any word? |
|
drivel join:2013-07-12 Santa Clara, CA |
to MartinM
said by MartinM:We've high hopes for Australia, should have the results very soon, perhaps even today. If a voip.ms customer using a local server in Australia calls another voip.ms customer using a local server in San Jose will the bits travel between the servers over the internet or over PSTN? |
|
MangoUse DMZ and you get a kick in the dick. Premium Member join:2008-12-25 www.toao.net |
Mango
Premium Member
2015-Jan-12 11:54 pm
If the two customers use North America DIDs, internal extensions, SIP URIs, or Virtual SIP numbers, the audio will travel over the internet.
Last I heard, calls to international DIDs are routed via the PSTN, even if the DID is owned by a VoIP.ms customer. |
|
MartinMVoIP.ms Premium Member join:2008-07-21 |
to dmz
The server will go beta soon. You can test your ping with melbourne.voip.ms |
|
jheis join:2008-12-13 Grandview, MO |
to mackey
mackey - thanks for the script. I executed it from Kansas City with Time Warner standard cable service and produced the following results:
atlanta 0% packet loss, time 5007ms rtt min/avg/max/mdev = 39.775/42.569/45.484/2.043 ms atlanta2 0% packet loss, time 5005ms rtt min/avg/max/mdev = 53.347/55.122/57.402/1.536 ms chicago 0% packet loss, time 5005ms rtt min/avg/max/mdev = 46.290/48.225/49.952/1.349 ms chicago2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 46.327/48.177/51.483/1.772 ms chicago3 0% packet loss, time 5008ms rtt min/avg/max/mdev = 45.671/47.707/49.549/1.302 ms chicago4 0% packet loss, time 5007ms rtt min/avg/max/mdev = 46.249/50.114/59.846/4.516 ms dallas 0% packet loss, time 5006ms rtt min/avg/max/mdev = 22.448/24.739/26.517/1.645 ms denver 0% packet loss, time 5007ms rtt min/avg/max/mdev = 53.334/55.069/56.920/1.287 ms denver2 0% packet loss, time 5007ms rtt min/avg/max/mdev = 36.884/38.559/40.911/1.409 ms houston 0% packet loss, time 5006ms rtt min/avg/max/mdev = 29.186/31.444/33.192/1.390 ms houstonnew1 0% packet loss, time 5006ms rtt min/avg/max/mdev = 27.514/29.120/30.720/1.196 ms houstonnew2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 27.122/29.421/31.138/1.357 ms losangeles 0% packet loss, time 5006ms rtt min/avg/max/mdev = 58.897/64.568/76.648/5.778 ms losangeles2 0% packet loss, time 5008ms rtt min/avg/max/mdev = 60.827/62.641/63.977/1.301 ms newyork 0% packet loss, time 5006ms rtt min/avg/max/mdev = 64.390/67.015/69.686/1.676 ms newyork2 0% packet loss, time 5007ms rtt min/avg/max/mdev = 64.920/67.463/70.397/1.762 ms newyork3 0% packet loss, time 5006ms rtt min/avg/max/mdev = 63.982/66.315/68.720/1.635 ms newyork4 0% packet loss, time 5005ms rtt min/avg/max/mdev = 64.329/67.423/71.419/2.152 ms sanjose 0% packet loss, time 5005ms rtt min/avg/max/mdev = 67.308/68.874/71.060/1.426 ms sanjose2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 67.018/69.263/71.239/1.481 ms seattle 0% packet loss, time 5006ms rtt min/avg/max/mdev = 75.258/77.798/79.995/1.763 ms seattle2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 75.267/77.747/79.165/1.437 ms seattle3 0% packet loss, time 5007ms rtt min/avg/max/mdev = 75.282/77.400/79.582/1.569 ms tampa 0% packet loss, time 5006ms rtt min/avg/max/mdev = 55.160/57.977/61.219/2.083 ms tampanew1 0% packet loss, time 5008ms rtt min/avg/max/mdev = 55.331/57.658/60.871/1.835 ms tampanew2 0% packet loss, time 5005ms rtt min/avg/max/mdev = 55.225/57.721/59.720/1.725 ms washington 0% packet loss, time 5002ms rtt min/avg/max/mdev = 52.982/57.642/67.785/4.725 ms washington2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 54.508/57.156/58.778/1.364 ms montreal 0% packet loss, time 5007ms rtt min/avg/max/mdev = 67.444/69.676/71.151/1.303 ms montreal2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 68.331/70.397/73.874/1.772 ms montreal3 0% packet loss, time 5006ms rtt min/avg/max/mdev = 67.163/70.412/72.952/2.083 ms montreal4 0% packet loss, time 5006ms rtt min/avg/max/mdev = 66.695/69.035/71.858/1.782 ms toronto 0% packet loss, time 5008ms rtt min/avg/max/mdev = 71.955/73.778/75.850/1.410 ms toronto2 0% packet loss, time 5007ms rtt min/avg/max/mdev = 70.828/74.163/81.903/3.689 ms toronto3 0% packet loss, time 5006ms rtt min/avg/max/mdev = 71.729/73.967/75.298/1.288 ms toronto4 0% packet loss, time 5005ms rtt min/avg/max/mdev = 70.721/72.911/74.979/1.362 ms vancouver 0% packet loss, time 5007ms rtt min/avg/max/mdev = 119.666/122.267/123.926/1.426 ms vancouver2 0% packet loss, time 5006ms rtt min/avg/max/mdev = 120.281/123.333/127.757/2.492 ms london 0% packet loss, time 14150ms rtt min/avg/max/mdev = 133.981/136.608/138.165/1.599 ms
Dallas appears to be the best option for me and is what I currently use. |
|
|
to MartinM
Awesome news... ================================================================
VoIP Server IP Address Latency Jitter Loss
================================================================
melbourne.voip.ms 168.1.73.84 13.053 0.293 0.0% ( 1)
losangeles.voip.ms 96.44.149.186 193.008 0.400 0.0% ( 2)
sanjose2.voip.ms 23.246.247.147 195.387 0.318 0.0% ( 3)
sanjose.voip.ms 23.246.247.146 196.882 0.392 0.0% ( 4)
losangeles2.voip.ms 96.44.149.202 197.299 0.314 0.0% ( 5)
seattle.voip.ms 50.23.160.50 213.919 0.185 0.0% ( 6)
seattle2.voip.ms 50.23.160.51 214.060 0.482 0.0% ( 7)
seattle3.voip.ms 50.23.160.52 215.520 0.362 0.0% ( 8)
vancouver2.voip.ms 162.213.157.117 228.138 0.562 0.0% ( 9)
vancouver.voip.ms 162.213.157.82 246.977 0.310 0.0% (10)
toronto3.voip.ms 184.75.215.146 300.203 0.263 0.0% (11)
montreal2.voip.ms 67.205.74.187 311.559 0.284 0.0% (12)
london.voip.ms 5.77.36.136 373.871 0.374 0.0% (13)
================================================================
|
|
dmz |
to MartinM
said by MartinM:The server will go beta soon.
You can test your ping with melbourne.voip.ms So I can register to the server, and make calls to Canada. (US calls didn't work when I tried.) Just made a 90 minute call to Canada with no problems whatsoever. Thanks again!! |
|
dmz |
to MartinM
US calling now works... |
|
MartinMVoIP.ms Premium Member join:2008-07-21 |
MartinM
Premium Member
2015-Jan-21 2:08 pm
said by dmz:US calling now works... Melbourne is up for closed beta customers. Everything should be working now, the server has been listed as "Experimental", because we need to make sure it will meet our quality standard and can't yet assure that we'll release it. If you want to help us test the quality, we would be glad to provide a credit as a courtesy. Regards |
|
|
dmz
Member
2015-Jan-21 3:07 pm
said by MartinM:If you want to help us test the quality Anything specific? Or just anecdotally... I've been using it for a little while now to make outgoing calls (some to PSTN, some to other voip.ms accounts on different servers). So far, so good. As an aside, the SMW3 cable has been broken between Australia (Perth) and Singapore a couple of times in the last few months. Has really messed up the latency to SE-Asia from here. Not sure if it's had any side-impacts as ISPs juggle their routing. |
|
|
to MartinM
said by MartinM:Singapore is still a no-go.
Latency is still too high, jitter is fine. That's not with Softlayer though, we might do a test with Soft Layer soon. I'd try other data centers in Singapore. I used voip.ms for years from Malaysia (across the bridge from Singapore, but generally with inferior connectivity) and had ~200ms pings to losangeles.voip.ms. Not perfect, but enough to make it very usable. |
|
|
to MartinM
said by MartinM:Everything should be working now, the server has been listed as "Experimental", because we need to make sure it will meet our quality standard and can't yet assure that we'll release it.
If you want to help us test the quality... I've been using it to call toll-free numbers, other voip.ms customers and regular PSTN numbers. Everything is working great so far. |
|
MartinMVoIP.ms Premium Member join:2008-07-21 |
MartinM
Premium Member
2015-Feb-13 3:57 pm
said by dmz:I've been using it to call toll-free numbers, other voip.ms customers and regular PSTN numbers. Everything is working great so far. Feedback appreciated DMZ. So far so good and no complaints. We don't like the latency we're seing but there's no jitter, seems stable. We've proxied a few of our carriers to a west coast server to lower latency as well. |
|
|
dmz
Member
2015-Feb-13 11:45 pm
said by MartinM:We don't like the latency we're seing but there's no jitter, seems stable. What kind of latency are you seeing from your end? Most international fibre connects through Sydney. The hop to Melbourne tacks on another 15ms or so. I don't know how much better you could do than Telstra (incumbent telco). Using their (very limited) looking glass: Trace to losangeles.voip.ms 1 gigabitethernet3-3.exi1.melbourne.telstra.net (203.50.77.49) 0.243 ms 0.266 ms 0.243 ms
2 bundle-ether3-100.exi-core1.melbourne.telstra.net (203.50.80.1) 2.613 ms 1.542 ms 1.992 ms
3 bundle-ether12.chw-core10.sydney.telstra.net (203.50.11.124) 15.484 ms 16.160 ms 16.732 ms
4 Bundle-ether17.oxf-gw2.sydney.telstra.net (203.50.13.70) 15.109 ms 15.408 ms 16.108 ms
5 bundle-ether1.sydo-core01.sydney.reach.com (203.50.13.38) 17.982 ms 19.408 ms 15.983 ms
6 202.84.223.42 (202.84.223.42) 16.859 ms
7 202.84.140.202 (202.84.140.202) 158.769 ms
8 202.40.149.142 (202.40.149.142) 158.406 ms
Trace to sanjose.voip.ms 1 gigabitethernet3-3.exi1.melbourne.telstra.net (203.50.77.49) 0.604 ms 0.267 ms 0.240 ms
2 bundle-ether3-100.exi-core1.melbourne.telstra.net (203.50.80.1) 1.491 ms 1.415 ms 2.115 ms
3 bundle-ether12.chw-core10.sydney.telstra.net (203.50.11.124) 15.735 ms 16.157 ms 16.734 ms
4 Bundle-ether17.oxf-gw2.sydney.telstra.net (203.50.13.70) 16.482 ms 15.409 ms 16.109 ms
5 bundle-ether1.sydo-core01.sydney.reach.com (203.50.13.38) 16.982 ms 19.407 ms 15.984 ms
6 202.84.140.54 (202.84.140.54) 168.271 ms
7 202.40.149.126 (202.40.149.126) 161.765 ms
Trace to melbourne.voip.ms 1 gigabitethernet3-3.exi2.melbourne.telstra.net (203.50.77.53) 0.288 ms 0.221 ms 0.245 ms
2 bundle-ether3-100.win-core1.melbourne.telstra.net (203.50.80.129) 2.369 ms 1.611 ms 2.368 ms
3 bundle-ether1.win-edge902.melbourne.telstra.net (203.50.11.110) 0.995 ms 0.987 ms 0.744 ms
4 sof1522605.lnk.telstra.net (139.130.197.158) 0.496 ms 0.488 ms 0.495 ms
5 ae6.dar02.mel01.networklayer.com (50.97.19.79) 1.870 ms 0.985 ms 0.996 ms
6 po1.fcr01b.mel01.networklayer.com (168.1.118.135) 1.369 ms 1.360 ms
7 168.1.73.84-static.reverse.softlayer.com (168.1.73.84) 1.110 ms 0.986 ms 0.995 ms
Another ISP that has good international connectivity is iiNet. They have a much more functional looking glass (and maps of their network). See: » looking-glass.iinet.net.au |
|
|
to MartinM
said by MartinM:We don't like the latency we're seing but there's no jitter, seems stable. If you care about latency (and obviously you do!) then why did you pick Melbourne? A quick look at » www.submarinecablemap.com/ will show you there's only one place to do latency-sensitive services in Australia, and that's Sydney - there's zero international cables landing in Melbourne. |
|
1 edit |
dmz
Member
2015-Feb-14 7:41 am
I wondered about that too. However, look at the Softlayer table and compare Melbourne, Sydney, San Jose and Los Angeles. » lg.softlayer.comNot sure why that is. Also not sure which cables and what routing Softlayer uses. Honestly, it looks like the Sydney and Melbourne numbers are reversed. |
|
|
doc
Member
2015-Feb-14 5:48 pm
said by dmz:I wondered about that too. However, look at the Softlayer table and compare Melbourne, Sydney, San Jose and Los Angeles. Traceroute shows that they are routing their Sydney traffic via Melbourne. At an IP level it then lands in the US, but from a lower level it almost certainly routes back via Sydney to get there. |
|
|
to dmz
I see the San Jose servers are now on the list, but not on the map. I don't remember receiving an announcement about them going live. Are they considered production servers yet? Is there any reason not to use them? |
|