BYOD Users: Testing Michigan Datacenter

Hey Guys,


We're doing some casual testing of a few new datacenters that we are considering adding into the mix so that there is an alternative option outside of our primary datacenter available for you guys to use if you prefer it for some reason.


Right now, we're testing a facility in Michigan. If you'd like to try it out, you can connect to sip7.voipwelcome.com instead of sip.voipwelcome.com. All BYOD users can register to it (and all reseller/resold accounts).


Please let me know what your connectivity is like to this facility and if you feel it's a better or worse connection for you. Traceroutes would be very helpful with feedback.


Our Dallas datacenter is owned by IBM now and is rock solid with excellent connectivity for most people, but one big difference with it and some of the others we're evaluating is that it has a lot of direct ISP peering in its routing so if a user is using a major ISP like Cox or Comcast the traffic is likely being routed directly to it. Other facilities we're looking at adding as an alternative don't have as much peering so they may have better routing for customers not on major ISPs or for certain geographical areas.


Current Facility: Softlayer - http://www.softlayer.com/about/network/carriers

sip.voipwelcome.com


Possible Addition/Alternative: Liquidweb - http://www.liquidweb.com/datacenter/network.html
sip7.voipwelcome.com


Again, this is just something we're testing. We are extremely happy with our current facility but have a few datacenters we're considering adding to the mix and this one in Michigan is currently our top choice so we'd like to get some testing. We have one reseller that seems to have a poor connection to our Dallas facility for some reason so we're re-exploring adding some diversity to the SIP server mix.


If anyone wants to test, please let me know how your connection (and post traceroutes if possible to compare). We'd like to get as much "real-world" data as possible.

Thanks!

I get 17 hops to sip. and 15 hops to sip7.

I have attached a screenshot of both trace routes.

Sorry- missed the requests for tracerts... :)

Code:

---



1  10.28.0.1 (10.28.0.1)  8.173 ms  12.951 ms  7.981 ms 
2  static-24-113-126-57.wavecable.com (24.113.126.57)  8.178 ms  11.664 ms  4.985 ms 
3  wave-gw.ae0.sea-bdr1.noanet.net (64.146.252.253)  6.987 ms  4.977 ms  5.885 ms 
4  ae0-124.sea23.ip4.tinet.net (216.221.158.97)  26.355 ms  8.772 ms  4.587 ms
5  as3356.sea21.ip4.tinet.net (199.229.231.186)  15.371 ms  25.644 ms  10.279 ms 
6  ae-32-52.ebr2.Seattle1.Level3.net (4.69.147.182)  58.007 ms  55.899 ms  56.144 ms
7  ae-2-2.ebr2.Denver1.Level3.net (4.69.132.54)  56.766 ms  56.788 ms  57.805 ms 
8  ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62)  56.507 ms  60.393 ms  60.003 ms 
9  ae-102-3502.edge2.Chicago2.Level3.net (4.69.158.5)  59.302 ms   
    ae-101-3501.edge2.Chicago2.Level3.net (4.69.158.1)  56.298 ms   
    ae-104-3504.edge2.Chicago2.Level3.net (4.69.158.13)  55.602 ms
10  CWIE-LLC.edge2.Chicago2.Level3.net (4.59.29.82)  66.380 ms  66.483 ms  66.393 ms
11  lw-core4-te91.rtr.liquidweb.com (209.59.157.206)  70.288 ms  73.669 ms  69.387 ms
12  lw-dc3-dist15.rtr.liquidweb.com (69.167.128.201)  71.687 ms  107.121 ms  74.780 ms
13  72.52.231.45 (72.52.231.45)  71.485 ms  81.453 ms  71.487 ms

---

It appears to me from my firewall logs that sip7 is also handling the audio traffic... True in all cases or just some? Just trying to tighten my firewall rules up here.

Moved to a new home office this morning—I now have Comcast and had CenturyLink prior—and I have been having issues registering so I figured I’d come over to the forums to see if there were other similar reports. Not seeing any and not being certain if my new Internet connection is to blame, I came across this thread and figured I’d give sip7 a try—and I have had zero registration issues since using it. While audio latency seems to be a bit more pronounced than sip.voipwelcome.com, my registration with sip7 appears to be solid.

>tracert sip.voipwelcome.com

Tracing route to sip.voipwelcome.com [67.228.182.2]
over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 10.0.0.1
2 34 ms 30 ms 29 ms 50.155.214.1
3 29 ms 13 ms 15 ms te-7-4-ur02.englewood.co.denver.comcast.net [162.151.15.101]
4 13 ms 18 ms 18 ms te-0-0-0-4-ar02.aurora.co.denver.comcast.net [68.86.103.45]
5 19 ms 46 ms 15 ms he-3-10-0-0-cr01.denver.co.ibone.comcast.net [68.86.92.25]
6 18 ms 17 ms 16 ms xe-0-0-0.bbr01.cf01.den01.networklayer.com [75.149.228.102]
7 34 ms 29 ms 28 ms ae12.bbr02.eq01.dal03.networklayer.com [173.192.18.138]
8 29 ms 28 ms 32 ms ae1.dar02.sr01.dal01.networklayer.com [173.192.18.213]
9 282 ms 38 ms 32 ms po2.fcr04.sr05.dal01.networklayer.com [66.228.118.218]
10 30 ms 44 ms 62 ms 67.228.182.2-static.reverse.softlayer.com [67.228.182.2]

Trace complete.

>tracert sip7.voipwelcome.com

Tracing route to sip7.voipwelcome.com [72.52.231.45]
over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 10.0.0.1
2 190 ms 28 ms 29 ms 50.155.214.1
3 18 ms 46 ms 13 ms te-7-4-ur02.englewood.co.denver.comcast.net [162.151.15.101]
4 19 ms 15 ms 16 ms te-0-2-0-6-ar02.aurora.co.denver.comcast.net [68.86.179.189]
5 87 ms 15 ms 18 ms he-3-10-0-0-cr01.denver.co.ibone.comcast.net [68.86.92.25]
6 340 ms 39 ms 39 ms he-5-11-0-0-cr01.350ecermak.il.ibone.comcast.net [68.86.86.185]
7 97 ms 37 ms 131 ms be-16-pe03.350ecermak.il.ibone.comcast.net [68.86.82.218]
8 108 ms 40 ms 37 ms 66.208.216.86
9 45 ms 44 ms 44 ms lw-dc2-core6-te9-2.rtr.liquidweb.com [209.59.157.226]
10 47 ms 63 ms 49 ms lw-dc3-dist15.rtr.liquidweb.com [69.167.128.205]
11 43 ms 44 ms 45 ms 72.52.231.45

Trace complete.

I can confirm what Bink experienced. I had to move multiple accounts in several different cities over to SIP7.

Slightly higher ping times and more hops, but much more reliable connections.

All of my locations using Comcast in particular had to be moved to SIP7.

Your mileage may vary, but SIP7 seems more stable.

I agree. sip.voipwelcome.com has been acting real flakey over the past couple of weeks (calls going to failover when registered, etc.). The reliability of this SIP server at Dallas compared to sip-central01 is definitely noticeable.

Lots of strange things happening of late...and it reminds me of the same issues experienced in this thread:
http://forums.voipo.com/showthread.p...oipwelcome.com

I had my father (located in Texas) who is on BYOD switch over to sip7 and the problems have simply went away.....

Quote:

---

Originally Posted by tritch

I agree. sip.voipwelcome.com has been acting real flakey over the past couple of weeks (calls going to failover when registered, etc.). The reliability of this SIP server at Dallas compared to sip-central01 is definitely noticeable.

Lots of strange things happening of late...and it reminds me of the same issues experienced in this thread:
http://forums.voipo.com/showthread.p...oipwelcome.com

I had my father (located in Texas) who is on BYOD switch over to sip7 and the problems have simply went away.....

---

We haven't noticed anything out of the ordinary, but I know some users have reported sip7 works better for them. If we find anything we'll address it, but so far it just seems like some people have better connectivity to sip7 and some better to sip.

Tim - would love to see a new server on the West Coast, used to use sip-west01 before it was taken down. Any plans to setup one on the left coast?

Quote:

---

Originally Posted by racerdude

Tim - would love to see a new server on the West Coast, used to use sip-west01 before it was taken down. Any plans to setup one on the left coast?

---

I agree with racer... would love to see North, South, East and West. That should provide options to get around quirky local ISP issues, and provide good performance to more users.

Tim - any update on this?

Quote:

---

Originally Posted by racerdude

Tim - any update on this?

---

The MI testing server has still been in place for BYOD/resellers (SIP7).

We've been exploring a few options for deploying some more servers for resellers/BYOD users to choose from. Honestly there there's not much difference in them unless someone just happens to have a bad route. We've hesitated on publicly doing this because then people get very set on being put on specific servers thinking they need to be on closest one or a small difference in ping times will make a difference vs looking at the alternative as an option if they have a significantly better connection to it.

We're still debating a little and looking at options, but we're considering either deploying a public/permanent node in a different centralized datacenter (like the Michigan one) or just adding additional servers on the east and west coasts with Softlayer (our primary datacenter in Dallas).

How about one in the northwest like Seattle where all the big guys are.

Thanks Tim for the update. Hopefully you will be able to install some more servers around the country that will help us minimize latency on our calls. I have tried the Michigan server and noticed it added 5 extra hops (18 total) over the Texas server (13 total) and a small but detectable latency in my calls so I rarely use it. Just as a comparison, the Los Angeles voip.ms server is 11 hops and the ping is about 25ms better for me than the Texas server which is a noticeable difference.

It would be nice for BYOD/Resellers to have more options on the servers, perhaps having something in CA, WA and FL would cover more bases for you. Of course if you only do one I would vote for CA and I would be more than happy to test it out for you! :p

To me it isn't only about geographic location, but about network/backbone path.

Example: I've run into a lot of issues with Comcast customers experiencing connectivity issues with the main Texas server.

When I move these customers to the Michigan server, the issues go away, even though MI has more hops and a bit more latency. I even have some Comcast customers in Texas that have better results connecting to Michigan.

This could be due to its different geographic location resulting in a different path through the internet. Or it could be simply because MI has different backbone providers than the TX data center. I don't know enough about either data center to be sure. But the results suggest there's something very different between the two.

Here's a really interesting article written by an admin at Level 3 that relates to this topic... Observations of an Internet Middleman

So to me, it seems that thoughtful selection of alternate data centers that use different backbone providers might help as much, if not more, than just different geographic locations on the same backbone.

Just keep in mind that the amount of hops or latency to these SIP servers at the data centers should have no effect on the audio of the call (or quality of the call). Unless Voipo has changed the way they handle audio (RTP stream), these SIP servers are just handling the setup/signaling of the call not the audio stream itself. Voipo’s upstream/terminating carriers are handling the audio stream, unless Voipo has specifically flagged your account to proxy the audio.

See Tim’s last 2 responses in this thread a few years ago:
http://www.dslreports.com/forum/r242...Washington-DC-

If this is still the case, your ISP network backbone/routing would be most important between the terminating carriers and your location, not so much to the SIP servers at the data centers. I’m talking about the audio quality of the calls. The amount of hops/latency would come into big play here.

The main concern to the SIP servers is just to have good connectivity (no extreme latency), so as not to have any call setup/signaling problems during the call. In this respect, the backbone/routing just needs to be dependable and reliable more so than bandwidth….

I believe that post you linked to is outdated, Voipo does proxy audio now on all calls. In the case of sip7 the audio proxy shows as 72.52.231.45 (Liquidweb Michigan) and in the case of sip and sip-central01 it shows 67.228.190.147 (Softlayer Dallas). So this does have an effect in the call quality, at least for me.

Quote:

---

Originally Posted by racerdude

I believe that post you linked to is outdated, Voipo does proxy audio now on all calls. In the case of sip7 the audio proxy shows as 72.52.231.45 (Liquidweb Michigan) and in the case of sip and sip-central01 it shows 67.228.190.147 (Softlayer Dallas). So this does have an effect in the call quality, at least for me.

---

Thanks, I stand corrected. I wasn't aware they made changes and proxy the audio now....good to know.

I suppose they made the change to mitigate firewall issues at the customer's router. In the past, they suggested forwarding a wide range of ports on the router to prevent blocked, one-way audio issues due to the audio coming from a different IP (terminating carrier) than the SIP server...

Quote:

---

Originally Posted by tritch

Thanks, I stand corrected. I wasn't aware they made changes and proxy the audio now....good to know.

I suppose they made the change to mitigate firewall issues at the customer's router. In the past, they suggested forwarding a wide range of ports on the router to prevent blocked, one-way audio issues due to the audio coming from a different IP (terminating carrier) than the SIP server...

---

at risk of getting off topic... I believe that this change has rendered the "force media proxy" setting in the control panel to be meaningless. can anyone confirm that?

Would you guess then that those of us who have major port forwarding enabled for many years now, can disable the port forwarding?.

Quote:

---

Originally Posted by burris

Would you guess then that those of us who have major port forwarding enabled for many years now, can disable the port forwarding?.

---

I used to have dozens of port forwarding rules setup on my router for each of the RTP audio providers, it was a real pain especially when I found a new one (one way audio) and had to go add the port forward rule and redial or have them call me back. I finally just gave up and port forwarded all UDP traffic on my RTP ports to my SPA2102 and haven't had any issues since. I did change the RTP port range from the standard ones to a different range and also the SIP port numbers on my SPA2102 just to avoid any issues with random calls from hackers that I've read about on other message boards.

But to answer your question - if you do require port forwarding on the RTP ports you can try just setting it to the ones I posted above for outgoing calls and for incoming calls I am seeing 174.36.46.53 (verify that these are the same ones for you). This should work until they change to proxies and you get one way audio..... Or just forward everything like I ended up doing and if you get strange calls then change the RTP ports to a different range.

Thanks for your reply..

Many years ago Brandon advised me to port fwd 5004-65000-Since then I have never had a problem.
I think this is safer than DMZ and it doesn't affect any of my other devices or network.

Maybe Tim will offer an opinion at some point..

thanks again..

It's actually not necessary to port forward that entire range to your ATA, it would work but is overkill. If you need port forwarding at all due to one way audio (not everyone needs to do this), normally you would just port forward the RTP port range defined on your ATA. On my SPA2102 the default range is 16384 to 16482, you would setup a UDP port forward rule to your local ATA IP. In my case I changed this range to something different that didn't conflict with any other programs I use (i.e, 17000 to 17098) and forwarded just that range. If you forward 5004-65000 then it could interfere with other programs that might also need port forwarding, for example Plex Server which uses port 32400.

It is slightly better than using the DMZ which would forward everything to your ATA, but if you want to limit which traffic goes to the ATA it is better to just use the RTP port range. In my case I didn't have to port forward the SIP ports, but if you do that would normally be 5060 (and 5061 if you have 2 lines).

Of course if everything is working fine and you don't get any random calls on your ATA then you could leave everything alone and not worry about it. :)

Thanks again....

For my 502 I have (in my edge firewall) my firewall rules set to allow destination ports 5004-5059 from 174.36.46.0/25 any port to my 502 with no port forwarding. When I make or receive calls this is the network that the GS 502 connects to for RTP.

For my RT31P2, PAP2 and RTP300 same but destination ports 16382 - 16484.

These are for sip-central01.voipwelcome.com the non BYOD server.

For sip7 (byod server) I see the same SIP server IP connecting for RTP. So it seems that they only proxy audio for the BYOD servers just to clarify.

I also allow from 67.228.190.148 for RTP to 16382-16484 at the house here where I have 3 Linksys devices. I do not recall but this may have been for the PBX. Doing a test from the PBX phone get RTP traffic from the PBX sip server however...

Is anyone else having issues with sip7 today? I'm unable to register to this server but can register successfully to sip and sip-central01.

Yes, starting Saturday 01/03/2015, we've been having issues with several accounts that were using SIP7.

We switched them to the SIP address, problem solved. But this kind of stuff really erodes confidence in the voipo network.

Still ongoing issues with sip7 today... 01/05/2015

Seems that inbound calls ring once then die, or customer answers and gets no audio.

Hello,

Please retest at this time and advise if any further issues persists, thank you.

Just did a quick inbound and outbound test call on sip7 and it appears to be working now. What turned out to be the issue?

Quote:

---

Originally Posted by racerdude

Just did a quick inbound and outbound test call on sip7 and it appears to be working now. What turned out to be the issue?

---

This server was being attacked by a very aggressive "scanner" from fraud attempts. Since it's not in our core datacenter and isn't widely used we don't have all our usual extension monitoring on it (only more simplistic server monitoring) and didn't catch it quickly enough since technically it was still up and connections were still working, they just had no audio. We're adding it to our more extensive monitoring since more of you are using it than expected.

Sorry for the inconvenience.

Quote:

---

Originally Posted by VOIPoTim

This server was being attacked by a very aggressive "scanner" from fraud attempts. Since it's not in our core datacenter and isn't widely used we don't have all our usual extension monitoring on it (only more simplistic server monitoring) and didn't catch it quickly enough since technically it was still up and connections were still working, they just had no audio. We're adding it to our more extensive monitoring since more of you are using it than expected.

Sorry for the inconvenience.

---

Excellent! Glad to hear sip7 will get the full monitoring. Thanks, Tim. :)

Thanks Tim for the update and glad you'll be able to catch any new attacks with the monitoring. For me, sip7 seems to work better lately than both sip and sip-central01 even though it's farther away with more hops. Maybe this is because you are using the same server for audio, you posted something about that earlier that the other 2 servers use a different server for audio so are there plans to change those to the same config as sip7?

Quote:

---

Originally Posted by racerdude

Thanks Tim for the update and glad you'll be able to catch any new attacks with the monitoring. For me, sip7 seems to work better lately than both sip and sip-central01 even though it's farther away with more hops. Maybe this is because you are using the same server for audio, you posted something about that earlier that the other 2 servers use a different server for audio so are there plans to change those to the same config as sip7?

---

Yeah that's something we've been exploring. We have the ability to flag your account to use whatever server you're connected to for audio directly if you'd like to help test the theory on any of the other servers. Just let me know. We're still looking into the concept more in general.

Great - I'll send you an email with my acct info so I can test that out on the other servers.

http://business.wavebroadband.com/en...ces/locations/ :) Figured Id share in case you guys were looking around still.. Not that Im seeing any issues or anything though. been working great.