dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
2748
dmz
join:2006-07-12
canada

dmz to Stewart

Member

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.)
MartinM
VoIP.ms
Premium Member
join:2008-07-21

1 recommendation

MartinM

Premium Member

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
@75.67.107.x

Oceans 11

Anon

Any update as to when Faxing will be available?
MartinM
VoIP.ms
Premium Member
join:2008-07-21

MartinM

Premium Member

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

Thanks
dmz
join:2006-07-12
canada

dmz to MartinM

Member

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!
MartinM
VoIP.ms
Premium Member
join:2008-07-21

MartinM

Premium Member

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
join:2006-07-12
canada

dmz

Member

said by MartinM:

We've high hopes for Australia, should have the results very soon, perhaps even today.

I wait in anticipation. Thanks!
dmz

dmz to MartinM

Member

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

drivel to MartinM

Member

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?
Mango
Use DMZ and you get a kick in the dick.
Premium Member
join:2008-12-25
www.toao.net

Mango

Premium Member

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.
MartinM
VoIP.ms
Premium Member
join:2008-07-21

MartinM to dmz

Premium Member

to dmz
said by dmz:

Any word?

The server will go beta soon.

You can test your ping with melbourne.voip.ms
jheis
join:2008-12-13
Grandview, MO

jheis to mackey

Member

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.
dmz
join:2006-07-12
canada

dmz to MartinM

Member

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

dmz to MartinM

Member

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

dmz to MartinM

Member

to MartinM
US calling now works...
MartinM
VoIP.ms
Premium Member
join:2008-07-21

MartinM

Premium Member

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
join:2006-07-12
canada

dmz

Member

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.
rajulkabir
join:2004-07-14
netherlands

rajulkabir to MartinM

Member

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.
dmz
join:2006-07-12
canada

dmz to MartinM

Member

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.
MartinM
VoIP.ms
Premium Member
join:2008-07-21

MartinM

Premium Member

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
join:2006-07-12
canada

dmz

Member

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
doc
join:2014-08-16

doc to MartinM

Member

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.
dmz
join:2006-07-12
canada

1 edit

dmz

Member

I wondered about that too. However, look at the Softlayer table and compare Melbourne, Sydney, San Jose and Los Angeles.

»lg.softlayer.com

Not 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
join:2014-08-16

doc

Member

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.
foresto
join:2002-04-17
USA

foresto to dmz

Member

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?