Business IP telephony integration service
Zycoo and FreePBX Integration in Dubai, UAE
Connecting two PBX platforms is not only a matter of entering an IP address and creating a trunk. A workable design must account for dial plans, extension ranges, SIP signalling, RTP media, authentication, caller identification, codecs, DTMF, network paths, firewall rules, security controls and the business call flows that users actually need. FourTeck helps organisations assess these dependencies, plan controlled integration and test the result before the new call path becomes part of daily operations.
Integration scope is configuration, access and compatibility dependent. Existing production settings should be reviewed and backed up before approved changes are applied.
Subject to platform configuration
Inbound, outbound and inter-PBX
Backup, testing and rollback
Matched to access and physical scope
What does Zycoo and FreePBX integration mean?
Zycoo and FreePBX integration is the planned interconnection of two separate IP PBX environments so authorised calls can pass between them according to defined business rules. Both environments can use SIP-based trunks and routing, which makes SIP a practical method to assess for inter-PBX connectivity. The service is mainly used when a company wants branch extensions to reach each other, needs a temporary bridge during migration, wants to retain an existing PBX while adding another platform, or must route selected calls between sites. Before work is confirmed, the customer should provide the PBX models or software versions, current extension ranges, desired call flows, network locations, available administrative access, security restrictions and any carrier or gateway details. The final method remains dependent on firmware, FreePBX configuration, network reachability, authentication options and the functions that must operate across the link.
What the integration service may cover
The work starts with the call requirement rather than with a fixed configuration template. FourTeck may review how users currently place and receive calls, which extension ranges belong to each PBX, whether public telephone numbers are terminated on one system or both, and whether calls must cross a LAN, VPN, private WAN or controlled internet path.
Depending on the confirmed scope, assistance may include SIP trunk setup, trunk authentication or trusted-IP design, route configuration, digit manipulation, caller-ID presentation, DTMF handling, codec review, NAT and firewall checks, RTP path validation, voice VLAN considerations, test-call planning, logging, documentation and administrator handover. Advanced features such as presence, shared voicemail, BLF, proprietary call controls, recording or contact-centre functions should not be assumed to pass between platforms simply because basic SIP calling works.
Who may need this service?
The service can suit a business that has inherited two telephone systems after an office move, merger, branch opening, technology refresh or phased migration. It can also help organisations that want users on a Zycoo PBX to dial selected users on a FreePBX system without immediately replacing either platform.
Typical environments include professional offices, warehouses, retail operations, clinics, hospitality sites, schools, property-management teams and multi-branch organisations. The important factor is not the industry label; it is whether the business has a genuine operational need for controlled voice traffic between systems and can provide the access, network path and maintenance window required to assess the change safely.
Common reasons businesses connect the two PBX environments
Branch-to-branch extension dialling
Staff in one location may need to reach colleagues on the other PBX using internal-style numbers rather than placing every call through a public telephone route. This requires non-overlapping numbering and clear route ownership.
Phased migration
A company may be moving users gradually instead of changing every extension at once. Interconnection can keep selected call paths available during the transition, subject to tested routing and an agreed cutover plan.
Shared access to a carrier or gateway
One PBX may host a particular telecom trunk, analogue gateway or legacy interface that the other system must reach. Whether this is appropriate depends on carrier rules, numbering, security and routing design.
Keeping specialised call workflows
A department may remain on one platform because of an existing workflow while another group uses the second PBX. The integration needs to define which calls cross the boundary and which stay local.
Why an unmanaged PBX link can become an operational problem
A call path that works in one direction is not necessarily a finished integration. Poorly planned routing can create unreachable extensions, unexpected number translation, caller-ID problems, loops, inconsistent outbound access or confusion about which platform controls a call. Media may also fail even when SIP signalling appears successful, producing symptoms such as one-way audio or calls that connect without usable sound.
The network layer matters just as much. Firewalls, NAT, VPNs, VLANs, QoS policies and asymmetric routing can influence call establishment and media flow. If administrators change ports or broad firewall rules without understanding the current design, the integration may also increase security exposure. For production systems, access should be authorised, existing settings should be captured, and changes should be limited to the agreed requirement.
From a business perspective, incomplete integration can disrupt reception, sales, customer service, internal escalation and branch communication. FourTeck therefore treats the project as a controlled service change with discovery, configuration, testing and documentation rather than as an isolated trunk entry.
Possible service scope
The exact scope is confirmed after assessment. Not every project needs every activity below, and some items may depend on the telecom provider, firewall administrator, internet provider or another system owner.
PBX versions, extension ranges, trunks, routes, gateways, network interfaces, call flows and recent changes.
Determine the required call direction, dial patterns, trunk method, route ownership, authentication and network path.
Create or adjust approved trunk and routing settings while preserving an agreed rollback path.
Review firewall, NAT, VPN, VLAN, DNS or routing dependencies that may affect signalling and RTP media.
Test representative extension calls, inbound and outbound paths where included, caller ID, DTMF and audio in both directions.
Record the implemented trunk purpose, numbering relationship, important dependencies, test results and next actions.
Service-fit matrix
| Business situation | Relevant assistance | What must be confirmed |
|---|---|---|
| Two offices use different PBXs | Inter-PBX trunk and internal routing assessment | Reachability, extension ranges, route ownership and security policy |
| Users are moving from one system to the other in stages | Temporary coexistence design and migration call paths | Migration sequence, duplicated numbers, rollback and maintenance window |
| Calls connect but audio is missing in one direction | SIP/RTP path review, NAT and firewall investigation | Packet path, ports, network address translation, codecs and endpoint behaviour |
| Dialled digits reach the wrong destination | Dial-plan and route-pattern review | Number format, prefixes, extension overlap and route priority |
| A public telecom service is connected to one PBX | Call-flow and carrier-dependency assessment | Provider rules, permitted caller ID, trunk ownership, failover and emergency-call responsibilities |
Service information for planning the engagement
| Main purpose | Controlled voice connectivity and call routing between Zycoo and FreePBX environments. |
|---|---|
| Typical systems involved | Zycoo IP PBX, FreePBX/Asterisk environment, IP phones, switches, routers, firewall, VPN, SIP trunks, gateways and telecom services where applicable. |
| Assessment method | Remote configuration review, interviews and test calls; on-site checks where physical network or hardware access is required. |
| Remote support suitability | Often suitable when secure administrative access, working connectivity and an authorised test contact are available. |
| On-site support suitability | Useful for PBX appliance checks, cabling, switches, gateways, voice VLANs, console access or faults that cannot be isolated remotely. |
| Customer access required | Authorised administration access, network information and physical-site access when included. Credentials should be shared only through an approved secure method. |
| Testing and validation | Scope dependent. May include two-way extension calls, route tests, caller ID, DTMF, audio, selected inbound/outbound calls and failure-case checks. |
| Security considerations | Authentication, trusted networks, firewall exposure, remote access, source restrictions, administrator access and change approval should be reviewed. |
| Scheduling dependency | Maintenance window, user availability, site access, engineer scheduling and third-party coordination can affect timing. |
| Quotation requirement | Final commercial scope is based on the confirmed environment, work required, service location and approved quotation. |
Remote support or on-site integration: which is appropriate?
Remote work can be effective when the path is already reachable
Many PBX integration tasks are configuration-led. If an authorised administrator can provide secure access to both systems and the relevant network devices, FourTeck may be able to review trunks, routes, logs, registration state and call behaviour without attending the site.
Remote work still depends on a stable internet connection and a customer contact who can assist with endpoint testing. Physical port faults, damaged cabling, failed gateways or inaccessible appliances may stop the remote investigation from reaching a reliable conclusion.
On-site support is useful when the voice system meets physical infrastructure
An on-site visit may be recommended when the integration involves PBX appliances, switch ports, voice VLANs, analogue or digital gateways, local carrier equipment, rack cabling, console access or network faults that cannot be reproduced remotely.
The site scope should identify the location, access rules, available maintenance window and any building or third-party coordination. FourTeck does not assume that every integration requires an on-site visit; the method is selected after the technical and operational dependencies are understood.
How the assessment and discovery process works
Planning and implementing the integration safely
Implementation begins only after the required call flows and dependencies are understood. A production PBX can carry customer calls, reception queues, management extensions, emergency arrangements and business-critical numbers, so changes should be controlled. FourTeck can capture relevant existing settings, define what will be added or modified and agree how the environment will be restored if the result is not acceptable.
The trunk is then configured on each side according to the selected method. FreePBX provides trunk functions specifically for connecting the PBX to other VoIP systems or devices, while Zycoo systems support standard SIP-based connectivity. That technical capability does not remove the need for compatibility checks: the chosen transport, authentication method, address identification, SIP headers, codec list, DTMF mode and media path must suit both ends of the connection.
Routing is built around the business numbering plan. If the Zycoo side uses extensions 2xxx and the FreePBX side uses 4xxx, routes can be designed around those ranges; if both systems already use the same numbers, a different strategy may be required. Prefixes, translations or staged renumbering may be preferable to ambiguous routing. Public telephone routes require separate consideration because carrier rules, caller identification and emergency-calling responsibilities may apply.
Network changes are kept specific to the chosen path. Opening broad firewall access for SIP or RTP without source restrictions is not a substitute for correct design. Where an internet-facing interconnection is unavoidable, security controls, trusted addresses, remote administration and monitoring requirements should be considered. A VPN or SBC may be relevant in some environments, but neither should be inserted automatically without confirming compatibility and operational ownership.
After the approved settings are applied, FourTeck performs the agreed test sequence, reviews logs for unexpected errors and records the final configuration. If a dependency belongs to another provider or administrator, findings can be documented so the correct party can act without repeating the entire discovery process.
Testing, validation and handover
A successful test should represent the actual way the business will use the connection. It is not enough to place one call between two engineer extensions and assume every route is correct. Depending on scope, validation may include calls from Zycoo to FreePBX and from FreePBX to Zycoo, calls from different extension classes, caller-ID presentation, answer and hang-up behaviour, DTMF through IVR prompts, attended or blind transfer where required, codec negotiation, audio in both directions and selected external paths.
Testing also checks for side effects. Existing local extensions, reception routes, voicemail access and public trunks should continue to work according to the agreed design. When a migration is in progress, test users may be placed on both platforms so cross-system behaviour can be observed before larger groups move.
The handover can record trunk names, purpose, route patterns, numbering assumptions, important firewall or network dependencies, known limitations, test outcomes and future-change cautions. Documentation helps another administrator understand why the link exists and reduces the risk that a later PBX, firewall or numbering change breaks it unexpectedly.
Clear dial-plan ownership reduces routing confusion
When two PBXs are connected, both systems need a clear rule for which numbers are local and which numbers belong across the trunk. Overlapping extension ranges are a common planning challenge because each PBX may already treat the same digits as local.
FourTeck can map extension ranges, feature codes, public numbers and prefixes before routes are changed. If renumbering is not practical, translation or prefix rules may be considered, but the choice should remain understandable to users and administrators. The outcome is not simply a working route; it is a numbering relationship that can be maintained after staff moves, branch additions and future migrations.
Media-path testing helps isolate one-way or silent calls
SIP signalling can establish a call while the audio media follows a different path. Firewalls, NAT, address advertisement, VPN routing or codec negotiation can therefore create calls that ring normally but have no audio or only one-way audio.
The investigation separates signalling from RTP media rather than assuming a trunk registration problem. Network information, call traces or logs may be reviewed according to the authorised scope. Where the fault lies outside either PBX, FourTeck can document the affected path for coordination with the firewall, ISP, telecom or network administrator.
Documented coexistence supports a controlled migration
An inter-PBX connection is often temporary. During a phased migration, some users may remain on Zycoo while others move to FreePBX, or the reverse. Without a documented transition plan, the temporary link can become permanent infrastructure that nobody fully owns.
FourTeck can align the integration with migration stages, test groups, cutover windows and rollback considerations. As users move, old routes can be reviewed rather than left indefinitely. This makes the final state easier to support and reduces dependency on temporary translations or duplicated call paths that were intended only for the transition period.
Dependencies, access and compatibility to confirm
The integration depends on more than the brand names. The Zycoo model and firmware can affect available settings, while the FreePBX release, Asterisk version and selected SIP channel configuration influence trunk parameters and routing behaviour. Existing trunks, custom dial plans, modules or security policies may also change what can be implemented safely.
- Administrative access to both systems must be available and authorised.
- The network path between PBXs must be understood, including NAT, firewalls, VPNs and VLANs.
- Extension ranges and feature codes should be checked for overlap.
- SIP transport, authentication, codec and DTMF options must be compatible at both ends.
- Provider-managed trunks, public numbers and gateways may require third-party coordination.
- A maintenance window may be needed if existing production routes are changed.
- Configuration backups or exports should be considered before material changes.
If a required capability cannot be verified, it should be treated as a dependency rather than promised. Contact FourTeck to confirm the service scope against the actual environment.
Risks, limitations and exclusions to understand
Basic SIP connectivity does not guarantee that every feature on one PBX will operate transparently on the other. Vendor-specific BLF behaviour, presence, voicemail integration, recording controls, contact-centre functions, mobile applications or proprietary provisioning may remain local to each platform. These requirements should be identified separately if they are important to the business.
Diagnosis also depends on evidence and access. If one PBX, firewall or network segment is managed by another party and configuration visibility is unavailable, FourTeck may be able to identify the affected boundary without being able to change it. Carrier-side restrictions, telecom-provider routing or managed gateway settings can also require external action.
Unsupported or heavily customised systems can have additional risk. A legacy PBX release may not support the preferred transport or security method, and custom FreePBX dial-plan code can change how normal GUI routes behave. Hardware failure, replacement parts, licenses, carrier fees and unrelated network remediation are not assumed to be included in an integration quotation unless specifically stated.
A successful test confirms the scenarios tested at that time; it does not remove the need for future monitoring, backup and maintenance. Later changes to extension ranges, firewalls, public IP addresses, VPNs, carriers or PBX software can affect the interconnection and should be assessed before implementation.
Business environments and practical use cases
Multi-branch offices
A head office may use FreePBX while a warehouse or branch retains Zycoo. Interconnection can provide controlled internal calling while each site keeps local phones and administration.
Office relocation
During a move, the old site may remain active while the new site is commissioned. A temporary link can support staged user relocation, provided numbering, network and provider dependencies are planned.
Departmental migration
Sales, support or administration may move at different times. The integration can preserve selected interdepartment call paths until the final target platform is ready.
Acquisition or inherited infrastructure
A business may acquire a site with a functioning PBX that does not need immediate replacement. Integration can be assessed as an interim option while long-term standardisation is planned.
Specialist gateway access
One system may connect to an analogue, GSM, E1 or other gateway that the second system needs to reach. Suitability depends on the gateway, licensing, provider rules and routing requirement.
Telephony proof of concept
A limited test group may need to evaluate call interoperability before a larger migration. The scope can define what is being tested and avoid treating a proof of concept as a production design.
Operational, security and maintenance considerations
Voice systems often sit on business networks alongside servers, workstations, cameras and cloud access. The integration should therefore respect the organisation’s network segmentation and change-control practices. Voice VLANs, routing boundaries, switch QoS, firewall rules and VPN policies can influence call quality and reachability. These settings should be assessed in context instead of being changed broadly to make one test call work.
Administrative exposure also matters. PBX management interfaces and SIP services should not be made publicly reachable without a specific security design. Source restrictions, strong authentication, secure remote-access methods, logging and vendor-supported transports may be relevant depending on the environment. Security improvement reduces risk but does not guarantee complete protection, and the correct controls depend on the network architecture and platform capabilities.
After integration, routine maintenance should include awareness of dependencies. If the firewall public IP changes, a VPN is replaced, a PBX is upgraded or extension ranges are reorganised, the trunk may need to be reviewed. Configuration documentation and current backups make those later changes easier to assess.
For call quality, the wider network remains important. Packet loss, latency, jitter, congestion or insufficient QoS can affect audio even when trunk settings are correct. FourTeck can help distinguish PBX configuration issues from network conditions and define whether further network assessment belongs in the same engagement or a separate quotation.
Before you contact FourTeck
Preparing a small amount of accurate information helps define the integration faster and reduces unnecessary changes. You do not need to publish or email passwords in an enquiry; simply confirm that authorised access can be arranged securely after the engagement is agreed.
- Business location and the sites where each PBX is installed.
- Zycoo model, firmware and current role.
- FreePBX version and whether it is physical, virtual or hosted.
- Extension ranges used on both systems.
- The exact call flow you want users to have.
- Any calls that already fail or behave unexpectedly.
- Current SIP trunks, gateways or carrier connections relevant to the project.
- Whether the sites are linked by LAN, VPN, private WAN or internet.
- Firewall or router ownership and who can approve changes.
- Available configuration backups or system exports.
- Recent PBX, network, firewall or provider changes.
- Number of users and departments affected.
- Preferred remote or on-site assistance.
- Allowed maintenance window and critical calling periods.
- Any security or building-access restrictions.
- Expected result and whether the link is temporary or permanent.
Service evaluation and quotation checklist
A quotation should describe the work that is actually required rather than assume every possible telephony task is included. The following points help define the engagement:
- Exact integration objective
- Number of PBXs and sites
- User and extension counts
- Current numbering plan
- Required SIP trunk method
- Firewall or VPN work
- Remote versus on-site scope
- Public carrier routes included or excluded
- Migration or coexistence requirement
- Testing scenarios
- Documentation and handover needs
- Third-party coordination
- Preferred change window
- Known exclusions or legacy constraints
How FourTeck can assist with the project
FourTeck can act as the technical coordination point for the integration. The work can begin with a review of the required call behaviour and the existing PBX and network environment. From there, the team can identify the affected technical layers, highlight dependencies and propose a scope that separates PBX configuration from any network, firewall, gateway or carrier work that must also be considered.
During implementation, FourTeck can configure or adjust approved trunks and routes, coordinate required network changes, organise representative test calls and document the result. When another provider controls part of the path, the team can prepare technical findings so the customer can coordinate that dependency with useful evidence.
The objective is a supportable call path with clear ownership rather than an undocumented workaround. Customers can also review broader FourTeck information on the IT services and support website or learn more about the company through the FourTeck IT Services overview.
Dubai and UAE service coordination
For businesses in Dubai and elsewhere in the UAE, the service can be coordinated remotely or on site depending on the PBX location, access, urgency, network condition and approved scope. Configuration review and test calls may be handled remotely when secure access is available. Physical checks may require a planned visit when appliances, cabling, gateways, switches or local telecom equipment are part of the problem.
Service timing depends on engineer availability, customer access, maintenance windows, site conditions, third-party providers and any required hardware or licensing. A production telephony change should also consider the organisation’s busiest calling periods so testing and rollback can be handled without unnecessary disruption.
Contact FourTeck to confirm the required service method, scheduling options and quotation. The agreed scope should state whether the work includes only PBX integration or also network, firewall, gateway, migration or telecom-provider coordination.
Service coordination across Dubai, Abu Dhabi, Sharjah and Ajman
FourTeck can coordinate Zycoo and FreePBX integration requirements for organisations with voice systems in Dubai, Abu Dhabi, Sharjah and Ajman. A multi-site project may combine remote discovery, planned configuration, on-site inspection and staged testing depending on where each PBX is located and how the sites are connected.
Travel, building access, local contact availability, maintenance windows, equipment availability and third-party telecom or internet dependencies can affect the service plan. The integration scope should therefore be defined around the actual sites and call flows rather than assuming that every location needs the same work. Remote troubleshooting may be sufficient for one site while another requires physical access to a gateway, network cabinet or PBX appliance.
Related FourTeck IT services
Office telephone support
Troubleshooting and support for connected business telephone environments, including network and call-flow dependencies.
Office network support
Assessment of switches, routing, VLANs, cabling and connectivity that can affect IP telephony.
Firewall and VPN coordination
Review of network paths, access rules and secure connectivity where voice traffic crosses network boundaries.
Business IT services
Planning, configuration, migration and support across the wider infrastructure that connects users and communication systems.
Why businesses contact FourTeck for PBX integration work
The value of an integration service is not an unsupported promise about speed; it is having one technical view of the call flow, PBX configuration and network path. A trunk problem may originate in routing, a firewall, NAT, codec negotiation, DTMF behaviour or a provider boundary. Looking at these areas together helps avoid repeatedly changing one PBX when the fault sits elsewhere.
FourTeck can provide a structured initial assessment, remote and on-site coordination, safe change planning, test criteria, documentation and provider coordination. Findings can be explained in business terms so decision-makers understand whether the next action is a PBX configuration change, network remediation, migration step or third-party request.
The final quotation can be based on the confirmed number of systems, sites, required call paths, access method, implementation tasks and testing needs. This keeps the engagement tied to the customer’s actual environment instead of a generic integration package.
Questions businesses ask before connecting Zycoo and FreePBX
Can Zycoo and FreePBX be connected with a SIP trunk?
SIP trunking is a practical integration method to assess because Zycoo IP PBX systems support standard SIP connectivity and FreePBX provides trunk functions for connecting to other VoIP systems or devices. That does not mean one universal template will work for every deployment. The exact settings depend on the Zycoo firmware, the FreePBX/Asterisk configuration, authentication method, IP addressing, transport, codecs, DTMF, routing and security policy. Before configuration, confirm whether the PBXs can reach each other directly, through a VPN, through a private network or by another approved path. The service should also establish which side initiates or registers the trunk and which number ranges each system will route across it.
Do we need to replace either PBX before integration?
Not necessarily. Integration is often requested precisely because a business wants two existing systems to coexist. Replacement may still become relevant if a platform is unsupported, cannot meet the required security or trunk method, has hardware faults or creates an unacceptable operational limitation. The correct decision comes after reviewing the current versions, business requirement and remaining lifecycle. A temporary SIP link can also support a staged migration, but the migration plan should define when temporary routes will be removed so the business does not carry unnecessary complexity indefinitely.
Why can calls ring but have no audio?
Call signalling and audio media do not always use the same path. A SIP exchange can complete while RTP media is blocked, advertised with an unreachable address or routed incorrectly. Symptoms can include silent calls, one-way audio or audio that drops after answer. The next step is to review the network path, NAT, firewall rules, address information, negotiated codecs and logs rather than repeatedly recreating the trunk. If the affected network device belongs to another provider or administrator, FourTeck can document what needs to be checked and coordinate the evidence without assuming control of systems outside the approved scope.
What if both PBXs use the same extension numbers?
Overlapping extension ranges need deliberate planning because each PBX may treat the same number as local. The integration cannot reliably decide that extension 201 belongs on the remote PBX if a local 201 already exists without an additional rule. Options can include temporary prefixes, digit translation, route changes or planned renumbering, depending on user impact and system capability. The chosen method should be documented and tested. If coexistence is temporary, the design should also explain how numbering will be simplified when migration is complete.
Can the integration be completed remotely?
It often can be assessed and configured remotely when both PBXs and relevant network devices are securely reachable, the internet connection is stable, and an authorised customer contact is available for endpoint tests. Remote work is less suitable when the problem involves a failed appliance, cabling, switch ports, gateways, voice VLANs or a network cabinet that requires physical inspection. A hybrid approach is also possible: discovery and configuration can be remote, followed by an on-site visit for physical validation. The final service method depends on access, location, scope and risk.
Will features such as voicemail, presence and BLF work across both systems?
They should not be assumed. Standard SIP trunking primarily addresses call connectivity, while advanced features can rely on platform-specific signalling, subscriptions, applications or proprietary behaviour. A business that requires cross-system BLF, shared voicemail, call recording controls, queue status or mobile-app integration should list those requirements before the scope is confirmed. FourTeck can test what is practical in the actual environment and explain any limitations. If a feature cannot be validated, the safer approach is to keep that function local to its native platform or consider a different architecture.
Should we use a VPN between sites?
A VPN can be useful when two PBXs are located on different private networks, but it is not automatically the correct answer for every environment. Existing site-to-site connectivity, routing, latency, firewall policy, security requirements and operational ownership should be reviewed first. A poorly configured VPN can add another point of failure or route media incorrectly. If the business already has a managed WAN or approved secure inter-site path, that may be preferable. FourTeck can review the telephony requirement with the network design and confirm whether VPN work belongs in the integration scope.
What information is needed for a quotation?
Useful information includes the two platform versions, site locations, number of users, extension ranges, desired call flows, network relationship between sites, any public carrier trunks involved, available admin access, firewall ownership, current problems and the preferred maintenance window. It also helps to say whether the link is permanent or part of a migration. The quotation can then distinguish PBX configuration, network changes, on-site work, testing, documentation and third-party coordination. This avoids assuming that unrelated hardware replacement or provider charges are included.
Can one PBX use the other system’s external telephone trunk?
It may be technically possible to route selected calls through the other PBX, but the design needs more than an internal SIP link. The external provider’s rules, caller-ID requirements, permitted source addresses, emergency-calling responsibilities, number ownership and failover behaviour can affect suitability. The internal PBX must also know how to send digits to the system that owns the carrier trunk and how to handle returned calls. This requirement should be declared early because it can involve third-party coordination and may need separate validation from basic extension-to-extension calling.
What should we test after the change?
The test plan should reflect real operations. At minimum, the organisation should test calls in both directions between representative users. Depending on scope, testing can include different extension ranges, caller ID, DTMF through an IVR, transfer, hold, call duration, codec negotiation, audio in both directions and selected external routes. Existing local calls and critical public paths should also be checked for side effects. Test results should be recorded with any known limitation so later administrators understand what was validated and what remains outside scope.
Frequently asked questions
Does FourTeck configure both sides of the integration?
It can be included when authorised access to both systems is available and the quotation covers both environments. If one side is managed by another provider, FourTeck can document the required parameters and coordinate testing while that provider applies its own changes.
Is a maintenance window required?
A maintenance window is recommended when production trunks, routes, firewalls or numbering rules may change. A limited new trunk can sometimes be created with little user impact, but timing should still be agreed so tests and rollback can be completed without interrupting important calls.
Can FourTeck help with an existing integration that stopped working?
Yes, subject to access and scope. Troubleshooting can review recent changes, trunk state, routes, logs, network reachability, firewall or NAT behaviour and call symptoms. The same symptom can have different causes, so diagnosis should follow evidence rather than assume the PBX is at fault.
Can different codecs prevent calls from working?
Codec mismatch can affect media establishment or audio, depending on how the endpoints negotiate. The codec list on both systems and any carrier or gateway in the path should be reviewed. The correct choice depends on platform support, bandwidth and provider requirements.
What is DTMF and why does it matter?
DTMF is the signalling used when callers press keypad digits for IVR menus, voicemail or other services. Calls may have normal audio while keypad input fails if the two sides use incompatible DTMF handling. Testing should include any business workflow that depends on keypad entry.
Do we need public IP addresses?
Not always. PBXs can communicate across private routed networks or VPNs when designed appropriately. Public addressing may be involved in some hosted or internet-facing scenarios, but the security and NAT design should be reviewed before any service is exposed.
Can the integration support a future PBX migration?
Yes, coexistence is a common reason to interconnect systems. The migration plan should define which users move first, how numbers are routed during the transition, what is tested at each stage and when temporary routes can be retired.
Will the project include firewall configuration?
Only if it is included in the confirmed scope and the customer authorises access. Some businesses have firewalls managed by another provider. In that case, FourTeck can identify required connectivity and coordinate the relevant technical information.
What happens if one PBX is on an unsupported release?
Options may be limited, and an upgrade or replacement assessment may be required before a secure, supportable integration can be confirmed. FourTeck can review the requirement and explain the dependency instead of promising compatibility without evidence.
Is documentation included automatically?
Documentation should be confirmed in the quotation. Useful handover information can include trunk purpose, route patterns, numbering relationship, important network dependencies, test results and known limitations. The level of detail depends on the engagement.
Can FourTeck provide ongoing PBX support after integration?
Ongoing maintenance or support can be discussed separately. Actual inclusions depend on the agreed service plan, covered systems, locations and contract. Integration work by itself should not be interpreted as unlimited support or a guaranteed response arrangement.
How do we request an assessment?
Provide the site locations, PBX versions, desired call flow, extension ranges, current symptoms if any, network relationship and preferred service method. FourTeck can then clarify access and scope before preparing the appropriate quotation.
Plan the integration around your actual call flow
Share the PBX versions, site relationship, extension ranges, required call paths and available maintenance window. FourTeck can review whether the work is suitable for remote configuration, requires on-site assistance, or depends on network and telecom coordination before the final scope is confirmed.