Connecting PBXs together to form your own private voice network is an established technique. If you’re considering rolling out some Voice over IP, or IP Telephony, you’d better be sure that it can integrate with what the voice guys have been doing for years.

To begin with, PBXs only had trunks to the PSTN to allow them to make calls outside their own switch. These trunks connected to Central Office (CO) Class 5 switches used by carriers to provide end user services and connected together across the country by Class 4 tandem switches.

Then came the ability to connect PBXs together over private leased lines - tie lines. The first of these were the different variations of DC and AC signalling - DC5 (E&M), DC10 and AC15 being the ones you might still hear about today. These are individual 2-wire or 4-wire circuits between PBXs.

DASS - the Digital Access Signalling System - was a BT invention for the UK to allow PSTN services over ISDN. It’s being replaced by something commonly called Q.931, although you’ll still hear about DASS II circuits. In fact, more properly, the service we call Q.931 should be called Euro-ISDN (also known as PRI Euro, or E1 PRI), as it’s actually made up of two parts - Q.931 really covers the connection (if you ever have to debug this on a router you’ll also need to look at Q.921 info, which covers the link layer part of the user to network connection), while the signalling is described by I.421.

This PRI connection expects to see a user (PBX) side and a network (PSTN) side. So if you can configure a PBX to mimic the network side, you can use this type of link to connect PBXs together, as well as using it to link to the PSTN. This is one of the options you’ll have if you want to connect a PBX into an IP telephony environment using a media gateway to do the PRI to IP conversion.

Linking PBXs
The thing is, people wanted the ability, when they started interconnecting PBXs, to make a group of PBXs behave as if everyone was on one large switch. If you make a PSTN call, you don’t expect to get many fancy features (although this is changing nowadays). But in a private system we do expect to be able to transfer calls, put them on hold, camp on till the person you called is free, see the name of the person calling - and we want to have this regardless of whether the person at the other end of the phone is in our office or one hundreds of miles away.

So the connectivity between PBXs had to provide all sorts of extra signalling features to allow this feature transparency. And that had to include cases where different vendor PBXs were in use.

And in the UK, this has historically been achieved using DPNSS. The Digital Private Network Signalling System isn’t a standard but is a co-operation between PBX manufacturers (and BT) to allow inter-PBX signalling over ISDN lines between sites, to allow a group of PBXs to pass selected feature capabilities between them. You get more features if all your PBXs are from the same manufacturer but even if they’re not, you will get a core of features that all manufacturers support.

The trouble is that because DPNSS isn’t a standard, and it’s pretty UK-specific, some of the larger VoIP/IPT manufacturers don’t support it. Cisco, for instance, despite being a huge IPT proponent, has no DPNSS support for its enterprise voice gateways (its PGW2200 does support DPNSS but that has been positioned in the past as a Service Provider gateway). Now, if all you want is a VoIP option, where you keep your existing PBXs and connect them over the IP WAN, that’s not such a big issue. DPNSS uses Common Channel Signalling (i.e. all the signalling carried over one timeslot), so you can set your routers to transparently transport that data from one PBX to the other (T-CCS). They don’t understand it, but they don’t have to - all the clever stuff is done by the PBXs.

But if you want true IP telephony, and need to integrate existing PBXs, DPNSS is difficult to do without. There are alternatives, as we’ve said, Q.931/E1 PRI can do the job and is a standard. However, it doesn’t always support all the features that DPNSS does and you may have to buy a new card (or software) for your PBX to support it.

The other alternative is Q.Sig. This is based on Q.931, but is designed for PBX-to-PBX connectivity and is also a standard. Unfortunately, it’s a European one, so some of the US-based IPT manufacturers have been rather slow at including it at anything more than a very basic level.

Which has led to the development of DPNSS gateways by vendors purely to fill the gap. Companies such as Checkmate, with its Abridge gateways can provide interconnectivity and feature porting from DPNSS, so that you can continue to give your users the features they need. It’s an extra box in the network but if your IPT vendor of choice doesn’t support DPNSS natively, it may be your only choice.

The way of the future is most likely Q.Sig. Some implementations aren’t quite there with feature support yet, but, once the Americans remember that Europe exists, integration with your existing PBX infrastructure will get that much easier.