Remote Setup of SMBs

[midev]

Hi!

We are getting started with setting up SMB type customers on the private cloud.

The typical customer has between 8-20 phones and is not tech savvy. Some have an IT person they can consult and many do not.

And from experience, it seems that 80% of the installations (which we do remotely) go well simpy with "plug and play" while 20% can surprises that can end up become quite frustrating.

Our guess is that poor network setups or hardware is the culprit.

I am sure this is not a new problem, and so I am curious from veterans of this type of market and remote installations, how have you overcome this challenge as a cloud voip provider doing remote installs?

One the one hand a full network map would of course make sense, yet is simply isn't practical due to the customers lack of knowledge.

Any insights would be greatly appreciated!

P.S. For example, is there any "magic bullet" router or setup that if included would solve the majority of these expected problems?

[Karl Stallknecht]

I know this isn't the answer you are looking to hear, but this is why we decided to only focus on our local market where we can physically access the customer's location. We refuse to sell outside of our area unless it's a single phone for a remote home-based employee, or it's a satellite office for a company whose HEADQUARTERS is here in this area. Even then, the scenarios can be a nightmare.

 

We actually recently had an install for a customer who has a small satellite office on the opposite side of the country from us/their HQ. The phones simply would not register when connected to their firewall, but would if they connected them directly to the ISP's router. We assumed that our IPs just needed to be whitelisted and we gave them our IPs for their I.T. to add, but we were told that they would not do that and we needed to. We explained that we don't manage their network so that's not our responsibility and they would need to pay us hourly to troubleshoot their firewall, but they just kept pointing the finger at us saying our phones were messed up.

 

We then told them we would ship a free firewall to them that would work well, and that they needed to connect it to a secondary static IP from their ISP and have a cabling contractor install additional drops, and they refused to do this. We ended up just caving and spending several hours modifying firewall rules and adding exceptions until we were able to get the phones online, but that was not our responsibility in the first place. It was much harder to do remotely since if you get locked out you're screwed, so you have to be way more careful and conservative with what you change.

 

Long story short, this is exactly why we don't mess with this stuff. It becomes a complete nightmare to deal with 😞 

[Rick Guyton]

A lot of what @Karl Stallknecht is saying is very true. At the end of the day you need three things. A good LAN, solid connectivity and sufficient bandwidth.

 

A Good LAN:

Well, this is 50% of the battle TBH. At the end of the day if the LAN sucks, so will the phones. Grab a VLAN if you can get it. (remarkably hard with many IT people for some reason) But, more than anything you need good IT. If you are targeting SMBs that means finding local IT folks or doing the IT for them. (I think Karl does his customer's IT) Good IT folks will usually be comfrotable with Cisco (not Meraki, but Cisco IOS), mikrotik, palo alto or juniper equipment. All they REALLY need to know is basics like jitter, packet loss, latency, and VLANing. But, most people who are proficient in this stuff aren't using netgear.

 

Solid Connectivity:

We use PingPlotter extensivly for this. I like to run continuous pings to a couple of the phones, the router, cable modem (192.168.100.1 typically), ISP gateway, 1.0.0.1, 8.8.8.8 and 4.2.2.2. This will give you a VERY accurate picture of jitter, PL, latency OVER TIME. And, tell you where it's starting. For instance if you are getting packet loss to the phones, there's LAN issues. To the router, LAN issues or bad router. To the modem bad modem. To the GW, bad circuit. GW ok, but others bad, peering issues with ISP. I'll roll this in advance if I'm able and get these issues resolved before deploying if I can.

 

Bandwidth:

Nope, 1.5Mbps ADSL isn't going to cut it... There's two ways to handle this. Either have them buy way more than they'll ever use (most people do this) or setup bandwidth management. I use Mikrotik routers personally wherever I can to do the latter.

 

So, to your question on how to prevent these issues, figure out a way to cover the above bases. Top of the list should be partnering with good IT folks.

To your question about how does everyone else do it? Well... Most go Karl's route and do the IT too. Or they don't mess with it. They sell to everyone and take the 80%. The 20% will get tech support that basically just points the finger at IT (I mean, they aren't wrong really). The vast majority or SMBs, especially with the rise of cloud services, don't even have any IT support AT ALL so they will deal with the occasional bad quality or move on to a land line provider. The remainder will blame their IT folks until they figure it out or do the same.

Edited December 21, 2019 by Rick Guyton (see edit history)

[Karl Stallknecht]

Great post, @Rick Guyton!

 

And +1 for PingPlotter. Very very helpful and allows us to show clients proof that the network is at fault!

[esoare]

18 hours ago, Karl Stallknecht said:

I know this isn't the answer you are looking to hear, but this is why we decided to only focus on our local market where we can physically access the customer's location. We refuse to sell outside of our area unless it's a single phone for a remote home-based employee, or it's a satellite office for a company whose HEADQUARTERS is here in this area. Even then, the scenarios can be a nightmare.

 

We actually recently had an install for a customer who has a small satellite office on the opposite side of the country from us/their HQ. The phones simply would not register when connected to their firewall, but would if they connected them directly to the ISP's router. We assumed that our IPs just needed to be whitelisted and we gave them our IPs for their I.T. to add, but we were told that they would not do that and we needed to. We explained that we don't manage their network so that's not our responsibility and they would need to pay us hourly to troubleshoot their firewall, but they just kept pointing the finger at us saying our phones were messed up.

 

We then told them we would ship a free firewall to them that would work well, and that they needed to connect it to a secondary static IP from their ISP and have a cabling contractor install additional drops, and they refused to do this. We ended up just caving and spending several hours modifying firewall rules and adding exceptions until we were able to get the phones online, but that was not our responsibility in the first place. It was much harder to do remotely since if you get locked out you're screwed, so you have to be way more careful and conservative with what you change.

 

Long story short, this is exactly why we don't mess with this stuff. It becomes a complete nightmare to deal with 😞 

Next time @Karl Stallknecht (I know there won't be one though!  ) send over a computer/box that has your remote access software + Ping plotter. Have them plug it in to their network. And then you can access the firewall programming through there. + See if connectivity to your IP's works without having to much problems. 

Also you could Angry IP scan their network, and then ARP -a to get the MAC address + IP addresses of the phones (assuming the OUI MAC you know)

Then script a login/reboot of the phones. 

This post was REAL EASY to type, I'm sure it would still be a headache to actually do though!!  (do they call that Sunday night quarterbacking?) 

esoare

[Rick Guyton]

44 minutes ago, esoare said:

Next time @Karl Stallknecht (I know there won't be one though!  ) send over a computer/box that has your remote access software + Ping plotter. Have them plug it in to their network. And then you can access the firewall programming through there. + See if connectivity to your IP's works without having to much problems. 

Also you could Angry IP scan their network, and then ARP -a to get the MAC address + IP addresses of the phones (assuming the OUI MAC you know)

Then script a login/reboot of the phones. 

This post was REAL EASY to type, I'm sure it would still be a headache to actually do though!!  (do they call that Sunday night quarterbacking?) 

esoare

Few things, FYI Macs and local IPs for phone are available in the debugging app. No need to broadcast scan and ARP. I use this all the time to access phone WebUI while remoting into a client PC. BTW simple-help.com is a great cost effective self hosted remote access service. Also, provisioner can reboot phones easily.

 

The real issue with shipping routers is you have to be 100% right or you are screwed. Also, sometimes you need to setup PPPoE bridging to avoid double NAT. It’s a mess, if you are going to offer a router you need someone onsite.

 

[esoare]

8 minutes ago, Rick Guyton said:

Few things, FYI Macs and local IPs for phone are available in the debugging app. No need to broadcast scan and ARP. I use this all the time to access phone WebUI while remoting into a client PC. BTW simple-help.com is a great cost effective self hosted remote access service. Also, provisioner can reboot phones easily.

 

 The real issue with shipping routers is you have to be 100% right or you are screwed. Also, sometimes you need to setup PPPoE bridging to avoid double NAT. It’s a mess, if you are going to offer a router you need someone onsite.

  

True on Debugging app/provisiones, but the phones wouldn't register on the platform. 

Thanks for the simple-help.com site. That looks very interesting! 

esoare

[midev]

Thanks for the input

I know it is a loaded and challenging question. 

We haven't been using ping plotter so will start using this now.