So you’ve got your VoIP servers, you understand the basics of ENUM and you will be registering your numbers, but one question remains:

How do I add support for ENUM into my enterprise VoIP system so we can start to get free calls?

well here is a guide to help understand how it all fits together

Scenario 1 - the basic setup

This is the classic enterprise VoIP deployment that you will have been sold by Cisco, Avaya or any other enterprise telephony provider:

As you can see:

• we have a clearly delineated border;
• the VoIP server and all the internal phones sit inside the border;
• PSTN connectivity is through a specialist border device (like a Cisco 28xx router or a Session Border Controller (SBC)), which is the single point of entry;
• the internal phone uses SIP or possibly SCCP or another proprietary protocol internally;
• the border device deals with signalling protocol translation and media transcoding;
• calls in either direction use the same paths (signified by the double headed arrows).

Scenario 2 - Receiving incoming VoIP calls

Taking this one step at a time let’s just look at receiving VoIP calls. I’m going to assume your border device does that:

What this diagram shows is:

1. The external VoIP caller does an ENUM lookup to find your public SIP servers (the border device).  Strictly they might not have used ENUM for this, they might have dialled an alphanumeric SIP address or found your details some other way, but let’s assume ENUM for now.
2. The VoIP phone uses SIP to talk to the border device.
3. The border device proxies this SIP to the PBX.
4. The PBX proxies the SIP to the internal phone and the connection is made.
5. The media stream then comes from the external VoIP phone to the border device, which then
6. terminates and reconnects the media stream to the internal phone.

At no point does the external VoIP phone see any internal infrastructure or talk to it directly.

Scenario 3 - Ideal bi-directional VoIP calls

Ideally we want outgoing calls to mirror the process for incoming calls:

This preserves the single point of entry, the proxying of protocols, media transcoding and so on. Don’t forget, whilst the diagram shows SIP internally, it will might well be a different protocol entirely.

However for this to work the border device needs to be able to do an ENUM lookup and act on that.  Unfortunately this is a rarity at present, though the investment in the UK Central Numbering Database should change that.  Some attempts have been made, for example Cisco sell an add-on called CUBE  (which you need just to do the basic incoming VoIP of scenario 2) that claims to do ENUM, but it is pre-standard version and so not a lot of use.

Scenario 4 - a drop-in ENUM box for outgoing VoIP

To get around the lack of support for ENUM for making outgoing VoIP calls, we drop in an ENUM box:

This shows:

1. The internal phone talks SIP to the PBX;
2. the PBX proxies that to the ENUM box;
3. the ENUM box does the ENUM lookup (which might succeed, fail, or timeout);
4. the ENUM box then tells the border device where to send the call to, either the original destination asked for by the phone (that will then use PSTN) or the new VoIP destination discovered from the ENUM lookup;
5. the border device contacts the external VoIP phone and the connection is established (if this connection fails then it falls back to PSTN);
6. the internal phone sends its media to the border device;
7. which then terminates and resends the media on to the external VoIP phone.

Where the border device does not support ENUM this is easily the neatest way forward.  You have one new device that only contacts the outside world by DNS and the border device still acts as the single point of entry for signalling and media.

Scenario 5 - Border device does not do VoIP

Things could be worse though, maybe your border device does not support VoIP at all and so you need an entirely new box to do all of that:

The ENUM box is more than just an ENUM box, it is also a border device in itself.  The call flow is pretty straightfoward:

1. The internal phone contacts the PBX by SIP;
2. the PBX proxies that SIP to the ENUM box;
3. the ENUM box does an ENUM lookup (if it fails it passes the call back to the PSTN border device);
4. assuming the lookup is a success the ENUM box contacts the external VoIP phone on SIP and the connection is established (if that fails then it send the call back to the PSTN border device);
5. the internal phone sends the media to the ENUM box;
6. which then terminates and resends the media to the external VoIP phone.

So the border is still preserved but you now have a whole new VoIP infrastructure in there.  Of course many people would then be tempted to throw out the rubbish border device that does not do VoIP and get the ENUM box to also do the PSTN connectivity.  Asterisk anyone?

Scenario 6 - all very messy

Let’s suppose your border device still doesn’t do VoIP but you don’t want or can’t have the ENUM box do all of that and want to keep it as just a lightweight SIP proxy. In that case you have no choice but to expose your internal phones:

The call flow is again pretty simple but with a horrible ending:

1. The internal phone contacts the PBX by SIP;
2. the PBX proxies that SIP to the ENUM box;
3. the ENUM box does an ENUM lookup (if it fails it passes the call back to the PSTN border device);
4. assuming the lookup is a success the ENUM box contacts the external VoIP phone on SIP and the connection is established (if that fails then it send the call back to the PSTN border device);
5. the internal phone sends the media directly to the external phone, exposing itself in the process!

And finally …

Support for ENUM amongst enterprise telephony vendors is woefully inadequate, yet history clearly shows that the Internet has left graveyards full of companies that tried to resist it. If your vendor is one of those dinosaurs then hopefully this article will help you bypass their ignorance to take control of your own telephony.