The traditional PBX had primarily one function: Distribute calls from the PSTN lines to extensions and vice versa. Calls from trunks to trunks were a rare exception, for example in the case when an extension was redirecting a call to an outside number.

The snom ONE PBX was designed pretty much the same way. There was a clear distinction between extensions and trunks. Every outbound call was bound to an extension. This is still the adequate architecture for most deployments and meets the customer expectations when it comes to enterprise communications.

However what is different in today’s enterprise communication is that companies tend to open local offices, while still maintaining the notion of a “LAN”, at least a network for working together in the organization. In many cases this is done by creating VPN links between the different LAN. We have even seen companies with very large global networks running their own network in the 10.x.x.x address space, with thousands and thousands of employees and network nodes. It works well. I am not sure what exactly a private cloud is, but I guess it comes close.

What is so special about the PBX service in such a network is that the network delay matters. Other services like web services, CRM, accounting and so on can live with delays in the hundreds milliseconds. But enterprise communications requires that the delay stays in the tens milliseconds. When making local calls, employees as well as outside parties expect a short delay. This can only be achieved by using a local PBX and a local PSTN termination, often by using a PSTN gateway. Also for emergency services, a local breakout usually solves the problem: You don’t want to end up talking to the fire department of San Francisco when you have problems in the Sidney office.

On the other hand, when you are in Sidney and you want to call someone up in San Francisco, it does make sense that your call is terminated in San Francisco. If the San Francisco already has a local PSTN breakout, why not using it for making calls in the area? Even more obvious, if you want to call someone from Sidney in the San Francisco office, why using a PSTN line for that?

In the old model, achieving that with snom ONE was difficult. In the new version 5.1, we have added the notion of the “inter-office trunk”. This is how it works:

• When a call comes in on an inter-office trunk, the PBX retrieves the destination number from the Request-URI of the INVITE message. If a domain is set, it converts the number into a global format (starting with +).
• If the destination is a local account, the call will be sent to that local account. This is the same behavior like regular trunk calls.
• Otherwise, the PBX will try to route the call using the dial plan that was specified in the trunk setup. Typically, this will cause another trunk to be used to send the call to the local number. This creates a trunk-to-trunk call without the involvement of an extension.

The setting “Destination for incoming calls” is not in effect when the trunk is in inter-office-mode. The routing is done by using the dial plan unless a local account is the destination for the call.

On the PBX that sends the call, you need to have dial plan entries that route the call to the right PBX. For example, if you have a PBX that should terminate all calls in the NANPA region (essentially USA, Canada), you can use the dial plan pattern 001* if the PBX is located in ROW region with the country code set.

Using a mesh of inter-office trunks, you can build your own little telephone network inside your organization. Instead of private cloud, this could be called private telephone network.