This article is more than 1 year old

Look, no handsets: How to do telephony without a phone

When IT and voice come together

As I sit at my desk, I have two phones in front of me. One is a cordless Panasonic that talks to a base station via the DECT protocol, and thence to the public phone network via a knackered old piece of copper that broke the other day.

The other is a snazzy mobile number with a picture of a piece of fruit on it and the ability to talk 3G protocols.

Now let's count the number of other ways I have of talking to people. There is the MacBook Pro I am writing this on, which has Skype. There is the Windows laptop next to it on which I am running an eval version of the 3CX IP PBX.

Oh, and the MacBook and the iPhone have the 3CX client so I can test it, not to mention the FaceTime app on the iPhone too.

The iMac in the corner also has Skype. The aforementioned PC has a Citrix connection to my office, with the Microsoft Lync client running; we generally use it for text-based instant messaging-style communication.

If I bothered to get my Android phone out I would find a couple of SIP (Session Initiation Protocol)-based phone clients on that too, as I used it when I went on a Mitel course not long ago.

It is pretty clear, then, that there are plenty of mechanisms for voice communication – many of which extend to video too.

Bridging the gap

How do you converge your corporate IT systems with your telephony service to give yourself a coherent, usable, stable, integrated service where the voice component doesn't require you to pick up a proprietary plastic thing?

The first thing you need to do is deal with the interface between the phone network and the IP network. If you are moving away from a desk phone, you can’t necessarily dump your connectivity to the public phone network because that would preclude you from communicating with people whose kit is not as advanced as yours.

You will need to support both SIP trunks, SIP being the best lowest common denominator for IP trunks, and telco-style trunks. If the in-house phone system supports both, that's great as you can configure it to bridge between the two.

For ancient phone systems that don't support IP telephony you have the choice of either upgrading to a newer unit or using one of the plethora of IP-to-telco converter devices on the market.

In many cases one can buy a full-blown PBX (private branch exchange) for a modest sum, or even go for an open-source option and just pay for a telco line card to go in the server.

You can demote the old PBX to the tasks that only it can handle, such as being the host for proprietary digital phones and analogue fax/modem lines.

Soft option

Moving away from having a phone on the desk means having a softphone application on your PCs, tablets and smartphones. It is not quite that easy, though: you have to think ahead so as not to cut off your future options.

If the goal is simply to implement voice technology while avoiding having a phone, that is easy: just install a SIP-compliant phone application on each device. But it makes much more sense to look at a general approach that gives options for video and the like.

If you have a Microsoft setup, the obvious way to go is Lync. A number of companies I have spoken to lately are seriously considering Lync as the successor to their current phone system when it comes to the end of its useful life.

One can understand why: Lync brings together voice, video, text chat and, with its bigger brother Exchange/Outlook, email.

Completing the integration

The next component to doing telephony without a phone is the underlying directory. I alluded earlier to the idea of bridging between a SIP world and a telco world using gateways and keeping the old phone system to do the stuff that only it could do.

Realistically, though, you need a single underlying directory structure that enables you to tell the system how people's phone numbers and other identities (SIP addresses, email addresses and the like) link together.

If your legacy kit can't connect to your central directory service where this information lives (via LDAP, say), then you really need to think hard. Your best bet is probably to bite the bullet and move to a platform that can handle this type of connectivity.

You want devices to be able to register themselves on your network from anywhere in the world

One last step you need to take is to look at where the users' client applications will be connecting from. If you are putting SIP client apps on your users' smartphones, you want the devices to be able to register themselves on your network from any connection, anywhere in the world.

This means ensuring that you have the right gateways and firewall rules in your edge devices and the necessary mechanisms in place to ensure the devices can register securely but flexibly from anywhere.

You don't want to have to faff about with such things as two-factor authentication on such applications. That is fine for users connecting laptops to the office via a VPN but not for registering a phone each time it is fired up and connects to a Wi-Fi hotspot.

So you will probably want to use on-board certificates or the like on the devices to enable auto-registration.

Nothing to fear

In short, the basics of having a phone without actually having a phone are: implement SIP capability to host the sessions; interface it to the PSTN (via a gateway if you have to); pick a communications server and client that don't preclude the use of features that you don't yet need; think about the edge of your network and how external clients connect inwards; and underpin the lot with a comprehensive directory service.

There is quite a chunk of work to do, but although Rome's telecoms service wasn't built in a day, it wasn't built by rocket scientists either. Don’t be afraid. ®

More about

More about

More about


Send us news

Other stories you might like