Why two working PBXs can still fail when connected

A 3CX system and a FreePBX system may each work correctly on their own and still experience problems when calls cross between them. Integration introduces a boundary where signalling, media, numbering and security assumptions have to agree.

Common project triggers and the business impact behind them

Most organisations do not integrate 3CX and FreePBX simply to prove that two systems can call each other. There is usually a business reason such as migration, branch consolidation, an acquisition, a temporary coexistence period, protection of an established call flow, or a need to reduce disruption while users move gradually. Understanding that reason changes the technical design.

Service-fit matrix for 3CX and FreePBX environments

Buyer-focused service information

Remote support versus on-site integration work

Assessment and discovery: what should be understood before configuration?

Reliable PBX integration begins with a current-state map. A surprising number of telephony problems are caused by undocumented assumptions: an old outbound prefix still active on one system, a number range that overlaps a new department, a firewall rule that points to a retired address, a provider that sends DIDs in a different format, or a call queue that depends on a feature not available across the PBX boundary. FourTeck’s assessment focuses on the business outcome and the technical path needed to achieve it.

1. Define the business reason for integration. Confirm whether the project supports internal extension calling, staged migration, central reception, DID handoff, branch communication, shared PSTN access, legacy application retention or another defined requirement. If the purpose is unclear, the integration can grow into unnecessary complexity.
2. Identify the platform versions and deployment model. 3CX version and hosting model matter, as do the FreePBX and Asterisk versions, enabled modules and current SIP driver. Modern FreePBX environments favour PJSIP, while older installations may contain legacy chan_sip definitions that need special migration planning rather than simple copying.
3. Map extension and DID ranges. Every internal extension range, public number, queue, IVR and service code that may cross the interconnection should be documented. Overlap between extension ranges can require prefixes or a revised numbering plan.
4. Trace existing trunks. Determine which PBX currently terminates each carrier trunk, which numbers are delivered there, how authentication works, and whether the carrier expects a particular source IP, caller-ID format, transport or contact information. A PBX-to-PBX interconnection should not inadvertently break carrier routing.
5. Review network topology. Record whether systems are on the same LAN, separate VLANs, separate sites, private cloud networks or public networks. Identify NAT devices, firewalls, VPNs, SBCs and any double-NAT condition. Voice media and signalling may follow different paths.
6. Confirm security and ownership. Decide who is authorised to change each PBX and firewall. Credentials should not be posted in public requests and should only be shared through an approved secure method after identity and authority are confirmed.
7. Collect representative call flows. The assessment should include examples such as 3CX extension to FreePBX extension, FreePBX user to 3CX queue, incoming DID to a remote IVR, transfer back across the trunk, and outbound caller-ID requirements. Testing only one basic call is not enough when production flows are more complex.
8. Plan backup and rollback. Current configuration exports or backups should be available where supported. The change plan should identify what can be restored or disabled if the new route creates an unexpected problem.

How the integration design is selected

There is no single safe template for every 3CX and FreePBX environment. The design depends on the current platform capabilities, support boundaries, network exposure, call-flow requirements and whether the connection is temporary or long term. A direct SIP peer may be technically possible in some environments, but the fact that two systems speak SIP does not guarantee that every function will interoperate or that the configuration is supported by each vendor.

On the FreePBX side, trunks are specifically used to connect the FreePBX/Asterisk system to another VoIP system or device. That makes the trunk module a natural place to examine the FreePBX half of an inter-PBX design, together with inbound and outbound routes. The exact FreePBX configuration must still match the chosen authentication model, source identification, context, codec set, network addressing and routing rules.

Where the systems are separated by the public internet, security and media handling become central. Publicly exposing a PBX simply because a SIP port exists is not a sufficient design. Access-control lists, firewall policy, source identification, transport selection, credential protection and ongoing patching should be considered. Where an SBC or site-to-site network design is already approved, it may provide a cleaner security boundary, but the additional device also becomes part of the support and failure path.

Numbering and routing: the part users notice first

Users experience a PBX integration through dialling. If the numbering plan is confusing, technically successful SIP signalling will not make the project feel successful. A good route design should allow staff to understand how to reach colleagues, queues and external numbers without guessing which PBX owns the destination.

The first question is whether extension ranges overlap. If 3CX has extensions 100 through 199 and FreePBX also has extensions in the same range, neither system can know from the digits alone whether a call to 120 is local or remote. Options may include adding a prefix for cross-system calls, renumbering one group, using longer extension ranges, or defining selective patterns. The choice depends on user impact, existing applications and migration plans.

Outbound routes require equally careful ownership. A business may want all PSTN calls to remain on the existing FreePBX carrier during migration while 3CX users reach that carrier through the interconnection. Another business may want each PBX to use its own carrier. A third may want only specific destinations to cross for cost or resilience reasons. The route order, prefix handling and failover behaviour should be documented so that a broader rule does not unintentionally capture calls intended for another trunk.

Inbound routing needs a DID map that states which number terminates where and which destination should answer. If a DID arrives at FreePBX but the receiving user now works on 3CX, FreePBX may forward the call across the interconnection. If a queue or IVR is involved, the team should also decide where time conditions, holidays, voicemail and overflow logic live. Duplicating the same logic on both PBXs can create inconsistent behaviour during later changes.

Caller ID is another routing dependency. A cross-PBX call may need to preserve the original external number, present the internal extension, or use an approved main business number when it exits to the public network. Each direction should be tested because the originating PBX, interconnection and carrier can interpret identity headers differently. Provider rules and local telecom requirements must also be respected.

Capability 1: more reliable fault isolation across the SIP boundary

One of the most valuable outcomes of a structured integration is not simply that calls work; it is that future faults are easier to isolate. When the call path is documented, an administrator can distinguish a 3CX issue from a FreePBX issue, a firewall problem from a carrier problem, and a signalling failure from a media failure.

For example, if a 3CX user dials a FreePBX extension and the call immediately fails, the investigation can compare the dialled digits, 3CX outbound route decision, SIP destination, receiving FreePBX trunk identification and inbound context. If the call rings but has no audio, attention shifts toward SDP, RTP addressing, firewall/NAT policy and codec negotiation. If audio works but keypad input fails in an IVR, DTMF handling becomes a more likely technical area. This layered method avoids changing unrelated settings simply because the symptom is inconvenient.

FourTeck can help build a test matrix that lists representative calls in both directions and records expected outcomes. That matrix can include extension-to-extension, extension-to-queue, inbound DID handoff, outbound PSTN calls where authorised, attended transfer, blind transfer, hold/resume, DTMF interaction and caller-ID presentation. Not every project requires every test, but the tests should reflect the real business workflows rather than a single engineering call.

Logs should be collected during controlled failures when possible. A SIP response code, rejected source, unmatched route or codec offer can provide evidence that is more useful than repeated configuration changes. Where the issue appears to sit with a carrier, cloud host or platform vendor, FourTeck can help package the relevant technical information for escalation instead of asking the customer to explain the entire environment from memory.

Capability 2: controlled media, codec and DTMF behaviour

SIP creates and controls a call, but the spoken audio normally travels as a separate media stream. This is why a phone can ring normally even when one party cannot hear the other. During 3CX and FreePBX integration, the engineer needs to understand both signalling and media paths, especially when systems are at different sites or behind NAT.

Codec selection should be deliberate. Both sides need at least one compatible codec for the intended call path, and carrier legs may introduce another negotiation point. Using many codecs without understanding the order can make troubleshooting harder. Using only one codec can also be unsuitable if a required external trunk or endpoint does not support it. The practical choice depends on bandwidth, endpoint support, provider requirements and whether transcoding is expected.

DTMF is the way keypad digits are conveyed during a call. It matters when a caller chooses menu options, enters an extension, interacts with a voicemail system or uses an application that listens for digits. A call that sounds perfect can still fail operationally if the two systems do not agree on DTMF handling. Testing should therefore include at least one real menu or digit-sensitive workflow when such functions matter to the business.

Media security may also be relevant. TLS for signalling and SRTP for media are supported in certain 3CX trunk scenarios, but compatibility varies and should not be assumed across an arbitrary inter-PBX connection. FreePBX security capabilities likewise depend on its configuration, certificates, modules and Asterisk version. If encrypted transport is a requirement, it should be treated as a design item with explicit compatibility tests rather than enabled casually during a production window.

Network quality remains important even after the systems are correctly configured. Voice is sensitive to latency variation, packet loss and congestion. Where traffic crosses WAN links or shared office networks, network assessment may include VLAN design, QoS policy, bandwidth utilisation and firewall processing. These controls reduce avoidable problems but do not guarantee call quality if the underlying internet or carrier service is unstable.

Capability 3: a safer path from coexistence to consolidation

Many 3CX and FreePBX integrations are temporary by design. A company may be migrating users, moving offices, replacing an old carrier or consolidating after an acquisition. In those cases, the integration should support the transition without becoming a permanent undocumented dependency.

A staged plan can divide users into migration groups. Before each stage, the team confirms which extensions and DIDs move, what routes must change, which queues or IVRs remain on the old system, and how users should dial across the boundary. The change is then tested, documented and observed before the next group is moved. This approach can reduce the size of each change window and make rollback more manageable if a compatibility issue appears.

FreePBX version and SIP technology deserve particular attention in older environments. Modern FreePBX development has moved toward PJSIP, and legacy chan_sip configurations are deprecated. A migration project should therefore avoid building a new long-term dependency around a legacy SIP driver simply because it exists today. Where old trunks or extensions still use chan_sip, FourTeck can review whether they need conversion, replacement or temporary support as part of the wider transition.

Consolidation also requires ownership decisions. Which PBX will remain the authoritative source for business hours, queues, voicemail, emergency routing, public numbers and user administration? Which system can be retired after the final stage? Which logs and backups must be retained? A technically functional link without these decisions can leave the business managing two systems indefinitely. The better outcome is a documented target state with milestones, rollback points and clear completion criteria.

Implementation journey from approved design to working call paths

Testing, validation and handover

Testing should be planned before configuration, not added at the end. The project team should know what a successful call looks like for each critical workflow, who can make test calls, which external numbers may be used, and how the results will be recorded. This prevents a project being declared complete because two test extensions could call each other while business-critical features remained unchecked.

A typical validation sequence starts with a simple internal call in each direction. The engineer confirms ringback, answer, two-way audio and caller identification. Next, the test expands to the routes that matter to the business: a transferred call, an IVR digit, a queue destination, an inbound public number or an outbound route where the approved scope includes it. If the integration is part of migration, testing should include at least one representative user from each migration group.

Failure testing is equally important where the business depends on the connection. The team may need to confirm what happens when the remote PBX does not answer, when a route is unavailable, or when the WAN path is interrupted. The objective is not to manufacture a guarantee of availability; it is to know whether calls fail clearly, retry another route, reach voicemail or require manual intervention. The appropriate behaviour depends on business requirements and available infrastructure.

Handover documentation can include a call-flow summary, extension-range map, trunk purpose, route ownership, firewall dependencies, test results, outstanding limitations and the contact path for third-party issues. Credentials should not be stored in general-purpose documentation unless the customer has an approved secure credential-management process. The document should help an authorised administrator understand the design without exposing sensitive information.

Dependencies, access and customer responsibilities

Security and network considerations for PBX interconnection

Connecting two PBXs changes the security boundary. A route that did not exist before can introduce new sources of SIP traffic, new administrative dependencies and new paths to public trunks. The security design should therefore be reviewed alongside the call-flow design.

At a minimum, the team should understand which IP addresses or FQDNs are expected to communicate, how the systems identify one another, whether authentication is required, which transport is being used, and which firewall rules are necessary. Broadly opening SIP and RTP traffic to the internet is not a substitute for a controlled peer relationship. Where a firewall or SBC can restrict traffic to defined sources and destinations, those controls should match the approved architecture.

NAT deserves special attention. A PBX may advertise an internal address even though the remote side must send media to a public address, or a firewall may rewrite ports in a way that breaks return traffic. On-premise 3CX deployments have explicit firewall requirements, and the platform provides a firewall checker for relevant installations. FreePBX also relies on correct local and external address configuration. The exact rules should be based on the deployed versions and topology, not copied from an unrelated site.

SIP ALG is another network feature that can interfere with VoIP by rewriting SIP messages unexpectedly. If troubleshooting suggests that a router or firewall is altering signalling, the network configuration should be reviewed carefully. Changes to security devices should be authorised and documented because disabling or bypassing controls without understanding the wider environment can create new risk.

Encrypted signalling and media may be appropriate where supported, but certificate, transport and interoperability requirements should be checked first. Security should also include software maintenance, unique credentials, controlled administrator roles, logging, backup and removal of obsolete rules after a migration completes. A temporary coexistence route should not remain exposed indefinitely just because the final migration succeeded.

Risks, limitations and exclusions to understand before proceeding

Business environments where this integration can be useful

Different industries tend to have different reasons for running two telephone platforms. The integration should follow the operational context rather than use a generic rule set for every customer.

Operational and maintenance considerations after integration

An interconnection creates an ongoing dependency between two systems. Once it is placed into production, routine platform changes should consider the effect on the peer. A 3CX update, FreePBX upgrade, firewall replacement, public-IP change, certificate renewal, carrier migration or route change can alter behaviour even if the original configuration was stable.

For that reason, the handover should identify which components are safe to change independently and which require cross-platform validation. If the integration uses IP-based source identification, a public-IP change may affect trust. If it uses FQDNs or certificates, DNS and certificate lifecycle become important. If it relies on an SBC, that device needs its own updates, backups and monitoring. If FreePBX contains custom dialplan, the business should know who maintains it and how changes are tested.

Periodic review can also identify obsolete routes. During a staged migration, the number of calls crossing between systems should decrease as users and DIDs move. Once a route is no longer needed, removing it can simplify troubleshooting and reduce security exposure. Old test trunks and broad temporary patterns should not remain active simply because they are not causing visible problems.

Call quality trends should be considered separately from configuration correctness. If users experience intermittent jitter or drops, the team may need network data, WAN utilisation, provider evidence or packet captures rather than repeated PBX changes. FourTeck can help separate persistent configuration faults from variable network or carrier conditions and recommend the next diagnostic step based on available evidence.

Before You Contact FourTeck

Providing a concise technical picture at the start helps FourTeck determine whether the first action should be a remote review, an on-site assessment, a configuration session or a broader telephony migration discussion.

Integration scope checklist for quotation

The quotation should describe the actual work rather than use a generic “PBX integration” label. The following points help define what is and is not included.

How FourTeck can assist with 3CX and FreePBX integration

FourTeck approaches the project as a connected IT and telephony task. That means the work can include the PBX configuration itself as well as the network, firewall and operational dependencies that determine whether calls are usable. The first objective is to clarify the reported requirement: which callers need to reach which destinations, what must remain unchanged, what can be migrated, and what failure risk the business can accept during the change.

From there, FourTeck can review the two PBX environments, identify overlapping extension ranges, examine existing trunks and routes, confirm the network path, and determine what information is missing. Where a direct SIP design appears suitable, the configuration can be planned around current platform capabilities and support limits. Where a direct design is unsuitable, FourTeck can discuss alternatives such as an SBC, gateway, provider-supported routing change or a different migration sequence.

During implementation, changes can be introduced in controlled stages with defined tests. If a call fails, FourTeck can review both sides of the path rather than assuming the originating system is at fault. The same approach applies to one-way audio, DTMF failure, caller-ID problems and route conflicts. When a third party owns part of the path, FourTeck can help identify the evidence needed for escalation and coordinate the technical conversation.

After testing, the handover can document what was changed, what still depends on third parties, what the business should monitor and what follow-up work is recommended. For customers planning a longer migration, the same documentation can become the foundation for the next stage instead of treating every new group of users as a separate troubleshooting event.

To understand FourTeck’s wider approach to connected business technology, visit FourTeck IT Services UAE, review the IT services overview, learn more about FourTeck, or use the technical support contact page to discuss the required scope.

Dubai and UAE service coordination

FourTeck can coordinate 3CX and FreePBX integration work for businesses in Dubai and across the UAE. The service method depends on how the PBXs are hosted, where the affected users are located, whether the network can be accessed remotely, and whether physical equipment needs inspection. A hosted 3CX instance and remotely accessible FreePBX server may be assessed largely online, while a site with local gateways, complex firewalling or undocumented voice networks may benefit from an on-site visit.

For Dubai projects, the initial discussion should identify whether the requirement is urgent troubleshooting or planned integration. Urgent faults may need evidence collection first so changes are not made blindly under pressure. Planned work may be easier to schedule around a maintenance window with test users and rollback preparation. The same principle applies across other UAE locations: the correct delivery model is based on the environment and business risk, not simply on distance.

Installation, configuration, migration and maintenance tasks should be clearly included in the approved quotation. If replacement hardware, third-party licences, carrier changes or new connectivity are needed, those items should be identified separately. Timing can depend on engineer availability, customer access, building restrictions, vendor responses, required parts, maintenance windows and the final work scope.

Combined coverage for Dubai, Abu Dhabi, Sharjah and Ajman

Businesses with users or offices in Dubai, Abu Dhabi, Sharjah and Ajman may need a mixture of remote troubleshooting and planned on-site support. A 3CX and FreePBX integration can span those locations in different ways: one PBX may be hosted centrally, another may sit in a branch, users may connect from multiple offices, and SIP carriers or internet services may differ by site. The service plan should therefore identify each location’s role in the call path rather than assume one identical network design.

Remote work may include configuration review, log analysis, route mapping and controlled call testing with local users. On-site visits may be appropriate where physical firewalls, switches, gateways, phones or cabling need inspection, or when network documentation is incomplete. Travel, building access, site conditions, local contact availability, equipment availability and third-party scheduling can affect the plan. Contact FourTeck to confirm which activities are required at each site and which can be handled remotely.

Related FourTeck IT services

Why businesses contact FourTeck for PBX integration work

Cross-platform telephony problems rarely belong to one device. A failed call can involve a PBX rule, a SIP header, a codec, a firewall, NAT, a WAN connection, a carrier policy or a user endpoint. Businesses contact FourTeck when they need those dependencies considered together rather than receiving isolated advice from separate vendors.

The service begins by translating the business requirement into testable call flows. That creates a more useful scope than a broad request to “connect the systems.” FourTeck can then help determine which technical layer is responsible for each part of the path, what access is required, what changes are safe to make, and what evidence should be preserved if another provider needs to become involved.

Documentation is part of that practical approach. When the integration is complete, an authorised administrator should be able to understand why the route exists, which numbers use it, what network access it depends on and what should happen during the next migration stage. Clear handover reduces the chance that an old temporary route becomes a mystery dependency later.

FourTeck also helps customers define a quotation based on the real environment. A simple single-site interconnection with documented routing is different from a multi-site migration involving legacy FreePBX configuration, public trunks, custom call flows and firewall changes. The scope should reflect those differences instead of promising a fixed outcome before assessment.

Frequently asked questions about 3CX and FreePBX integration