Really Scary Telecoms Stuff? Nah – telephony's just an app

That's pure insanity

I mean with a hosted solution you will have a lot more parties to shift the blame... and also a _lot_ more things to go wrong. Remember VoIP requires pristine connections with low latency, low yitter and next to no packet loss.

Typically you are much better off with a small PBX, for example a "Starface" or something else based on Asterisk. There are certain vendors like Mitel or 3CX which tend to offer you solutions that are just plain broken.

Telco stuff isn't scary if you are prepared to learn a bit and not choose the worst solutions. Unfortunately there are people who refuse to learn things and reliably choose a solution in the lower 90%. Unfortunately many of those believe they know how to install/run some PBX.

Reliability

..single ISDN links because failures were generally in the PBX, not the line

Really?!? I've been in the telecoms/IT world for 20+ years, and the BT ISDN lines have always been the most unreliable part of a phone system.

If you wanted all the features without the box or the hassle, spread over multiple sites, then why didn't you go withvBT Feature net (5000?). They were doing it from at least 20 years ago.

I think people overstate the reliability of the old POTS networks. The exchanges and switches rarely went wrong but the plant isn't all that reliable. If someone digs up a cable somewhere in the local network or cuts an overhead line, your service is gone.

How often is an enterprise grade IP connection going into fail?

If you're a serious site, surely you would have multiple redundant links to different networks so that you could at least maintain your core services in case of disaster ?

Asterix!

My business(s) run a simple asterix install, hand configured. I had no clue when I started, to having full system configured in a couple of weeks.

If you have < 300 people, and write the macro's carefully, you really can manage this in text-file, for free. I actually host it on a google cloud virtual linux server for good measure.

There's actually another very real danger if you host your PBX outside of your network

If you have a local PBX on your LAN, it doesn't matter how secure your internal credentials are, unless you're very stupid, nobody will be able to pose as an internal phone.

How if you have a cloud PBX all you need is your credentials to pose as an internal phone... and if you use an app, that means that you store your credentials on a highly insecure device.

This is a real danger as calling someone involves money. Perhaps not when you call someone locally, but there are providers like wpremiums.com which offer your premium rate numbers all over the world. Just get one of those numbers and call them over your snitched PBX login.

Even run your own PBX as a hosted solution!

Just to add something else into the mix...

I work for a small MSP with a slant towards MS products. Over the last 3 years or so there has been an explosion in requests for Lync / Skype for Business across the industry as a whole.

Most of the time, we've installed SfB as a single VM (standard edition) using SIP trunks (although sometimes we needed to stay with ISDN so needed a SBC to get that plumbed in), or for larger clients that need HA and even DR for telephony, we've deployed the full enterprise edition of SfB (so 12 VM's for no spof's / HA, and then the same again in another site for the DR element).

Customers love it, with the biggest challenge being the culture shift. I disagree about the need for DDI's. A lot of modern, SIP focused PBX's these days have phone numbers as a simple abstraction layer to the user's actual SIP address. Nobody in our office has a DDI (other than me, for testing naturally!). Everyone call out, and each department has it's own response group (e.g. hunt group) that people can call in for. We also have a IVR where you can pick your department.

Users expect:

- A dial tone

- A ring-ring noise when a call is holding in a hunt group

- Phone numbers for each phone

- That physical handsets are where the number lives

The above are all perfectly reasonable, as that's how traditional PBX's operate. But in the world of SIP, and in particular SfB (but most other modern PBX's) things work a little different:

- There is no dial tone

- When holding in a hunt group, you get music or whatever audio file the PBX admin has specified

- Phone numbers aren't a real thing. They are simply a way to map a number to the real SIP address that's really used

- SIP addresses (e.g. phone numbers) are mapped to a user, not to a device

That last one is a real cultural shift for end users, and one of the hardest parts of a deployment. User centric services is where IT has been heading for years, but telephony has traditionally been somewhat behind the times. Getting users to understand that when dialling a number (SIP address!) the phone system is attempting to reach YOU - the end user - NOT the device. Which is why your handset, mobile app and softphone can all be ringing at the same time. The person calling you is after YOU - the fleshy bit - they caller isn't trying to call a particular endpoint.

Anyway - back on topic...

A satellite office for one of our larger clients based in Zurich has about 15 users and needed a new phone system. Building SfB wasn't financially viable, nor was buying a traditional PBX. We therefore put them onto a hosted SfB platform by a company called AlwaysOn. They sent out some awful SNOM handsets and once they had internet access they were working. The reliability and support was truly terrible. After 9 months the client demanded something else as they rely on telephony and this "cloud" solution sucked massively.

Technically, I couldn't see any reason why it wouldn't work - it's just that the supplier sucked massively, rather than the wrong technology.

So, I built out a new SfB Enterprise Edition (e.g. no spof HA) platform in our Cambridge datacentres on a shiny new AD domain dedicated to this client. Sent out some decent Polycom phones and a load of Jabra headsets for softphones and 12 months later the client is still loving it. The connection is over the internet from Zurich without QoS or MPLS, with all traffic over the edge servers.

Essentially it's a dedicated, private hosted SfB.

The client was so happy with it in their satellite office, the head office in Cambridge wanted to move to it as part of a large office move, giving the platform a total of 280 users.

As we as the environmental (2 x datacentres, UPS + diesel gen, access control, N+1 AC etc.), physical (Hyper-V cluster, HP SAN's) and application (SfB enterprise edition / clustered) layers all having security, reliability, performance and capacity all baked in as part of the architecture, as the author rightly points out there's no point having all of this but no SIP trunks. Our SIP trunk provider (PureIP if anyone is interested - they're amazing!) has given us two SBC destinations to point our calls to, with each SBC in a different datacentre running as an active/active pair. The same applies for inbound calls - either SBC can send the calls to either of our meditation servers. So should a whole datacentre fail with our telco then there is zero interruption of service.

With all of this, we've essentially created our own dedicated hosted SfB platform for one of our largest clients.

I'm aware that SfB can operate as a multi-tenanted configuration, although I haven't tried it. Our client is delighted with the system they have with reliability and also feature set (visual voicemail, IM and presence, conferencing, whiteboards and screen sharing, file transfer, telephony (inc, delegate, IVR's, hunt groups, private line, 2nd line etc.) voice access to their mailbox, enterprise chat rooms etc.), but as it's hosted by us there is no real capital cost involved. Our main cost is licensing, which is 3 x SfB server licences that we brought via SPLA (so about £240).

I put a similar system in on premise for another large client, but also wanted DR (so the above x 2) which cost around £90k. Compared to the hosted option I have to say it looks like the writing is on the wall for on premise PBX systems.

With Office365 including SfB Online - and MS now offering Cloud PBX / PSTN Calling (MS provided SIP trunks), combined with the insanely expensive capex needed for on premise, I really can't see many companies opting for on premise in 5 - 10 years time.

Hence being rather proud of the work we did to get this private hosted system in place. If nothing else it clearly demonstrates that it can be done with good results, and I think the market very much has an appetite for it.

Sorry of the long and rambling post. After reading this article as well as the ISDN to SIP article I got all passionate again about the SfB projects I've done in the last 2 years and simply wanted to talk codshit about it!

TL;DR

The market wants hosted. If you're a IT service provider / MSP then it may well be worthwhile looking into YOU creating a multitenant IP PBX system yourself and selling it directly to your clients.