Tech

Seamless Inter-Office Calling: Enhancing PBX Connectivity with Inter-Office Trunks

Published on:

August 1, 2013

Traditional PBXs mainly routed calls between PSTN lines and extensions, with trunk-to-trunk calls being rare. Snom ONE followed this model, binding outbound calls to extensions. However, modern businesses with multiple offices and VPN-linked networks require low-latency local call routing. Version 5.1 introduces “inter-office trunks,” allowing calls to be routed directly between PBXs, reducing delays and ensuring local PSTN termination for emergency calls. Calls can now be routed based on dial plans without extension involvement, creating a private telephone network within organizations. This enhances flexibility and efficiency in global enterprise communications.

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.

Latest Articles

View All

Mastering Vodia PBX Installation on Linux: A Complete Guide for System Administrators

Installing Vodia PBX on Linux offers system administrators a powerful, enterprise-grade communication solution with built-in monitoring, automated backups, and disaster recovery features. This guide walks through supported Linux distributions, pre-installation requirements, and step-by-step instructions using a universal install script. With options for service monitoring, backup scheduling, and cloud deployment, it ensures a scalable and secure setup. Post-installation, standard Linux tools manage service status, updates, and logs, making ongoing maintenance simple.

June 26, 2025

Vodia Now Integrates with Microsoft Dynamics 365

Vodia now integrates its industry-leading PBX with Microsoft Dynamics 365, enabling automatic synchronization of call data with the CRM to enhance customer interaction tracking and streamline communications. This integration offers features such as automatic contact creation for unknown numbers, comprehensive call activity logging including direction, duration, and outcomes, and seamless user matching for accurate call attribution. Designed to empower businesses, this connection supports more efficient and scalable communication workflows within the Microsoft ecosystem.

June 24, 2025

Vodia Attends HITEC 2025 Indianapolis

Vodia visited HITEC 2025 in Indianapolis to engage with key hospitality technology partners and explore the latest innovations in the industry. Represented by Sales Engineer Eric Altman, Vodia connected with leaders from Shiji, Agilysis, Maestro, and Oracle. The event offered valuable insights into the evolving hospitality tech stack and affirmed Vodia’s commitment to AI-powered communications. With its recent integration of OpenAI’s Realtime API, Vodia continues to deliver smarter, multilingual guest experiences and more efficient hotel operations.

June 24, 2025