Why a PBX-to-PBX connection can fail even when both systems use SIP

SIP provides a common signalling method, but successful interoperability still depends on how each side is configured and how the network carries signalling and media. A trunk may register successfully while calls fail because the destination number is not accepted by the receiving route. A call may ring while audio fails because the session description advertises an unreachable address. An internal extension may work while external forwarding fails because the receiving system treats the presented caller identity differently. A route can also be correct on one PBX and wrong on the other, producing one-way reachability.

The Asterisk dialplan is particularly important because it determines how incoming channels are placed into contexts and how dialled numbers are matched, transformed, or sent onward. On the Zycoo side, trunk and dial-rule behaviour also determines which numbers are sent to the connected system and which calls are accepted. Version differences, interface terminology, authentication methods, and platform-specific menus can change the implementation details. For that reason, a service engineer should work from the required business flow first and map the configuration to it, rather than copy a generic trunk example without understanding the numbering plan.

The network adds another layer. Firewalls, NAT, access control lists, VLANs, WAN paths, VPNs, and internet connections can all influence whether SIP messages and RTP media reach the correct addresses. Codec policy can affect whether both ends agree on a media format. Provider or gateway dependencies may become relevant if one PBX sends a call to the public network after receiving it from the other. Integration therefore needs a complete path review rather than a single setting change.

Common business triggers for Zycoo and Asterisk integration

Business impact when routing is unclear or unstable

An unreliable PBX connection can create problems that are difficult for users to describe. Staff may report that “internal calls are not working,” while the actual failure affects only one number range. Reception may transfer a customer to a destination that never rings. Callers may see the wrong caller identity, making it harder to return a call. A branch may be able to call headquarters but not receive calls back. Audio may work in one direction only, leading users to hang up and redial over public numbers. These issues increase support effort because employees adopt workarounds that hide the underlying route problem.

Poorly controlled integration can also make future maintenance risky. If nobody knows which PBX owns a number range, which system applies the final outbound route, or whether a call crosses the trunk before reaching the telecom provider, a simple extension change can have unexpected effects. Undocumented number translations may create duplicate routes. Broad wildcard patterns can send calls to the wrong system. In a migration, this uncertainty can delay cutover because administrators cannot confidently identify which users depend on the old platform.

A structured integration service focuses on clarity as well as connectivity. The result should identify the intended path, the systems responsible for each step, the test cases that passed, and any unresolved dependencies. That information gives operations and IT teams a safer basis for later changes.

Possible service scope

The final scope depends on the current environment and approved quotation. A small integration might involve two reachable systems with clean extension ranges and existing backups. A more complex project may include overlapping numbers, multiple sites, telecom provider dependencies, NAT, VPNs, gateways, custom dialplan code, recording requirements, or a planned migration. Depending on what is confirmed, FourTeck assistance may include the following activities:

• Initial consultation to document why the two systems must communicate and which business calls are affected.
• Review of Zycoo platform details, current trunk configuration, extension ranges, dial rules, routes, and available backups.
• Review of the independent Asterisk version, SIP channel configuration, PJSIP resources where used, contexts, dialplan, route logic, and logs.
• SIP trunk or peer planning, including addressing, authentication approach, trusted network requirements, and permitted traffic.
• Number normalisation and dial-pattern design so each system sends the format the other system expects.
• Codec and media-path review for call establishment and two-way audio.
• Firewall, NAT, routing, VPN, DNS, or VLAN checks where they affect signalling or media.
• Controlled configuration changes after backup and customer approval.
• Inbound, outbound, transfer, caller-ID, voicemail, queue, or after-hours test cases where they belong to the agreed call flow.
• Documentation of the integration path, route ownership, important dependencies, and recommended next actions.

Service-fit matrix

Service information for planning and quotation

Remote support versus on-site integration assistance

How the assessment and diagnostic process usually works

Planning the trunk, numbering and route relationship

A successful design begins with number ownership. Each PBX needs a clear rule for deciding whether a dialled number belongs locally, belongs on the remote system, or should leave through a telecom provider. If Zycoo users are 2XXX and Asterisk users are 6XXX, the route can often be simple. If both systems contain overlapping 2XXX extensions, the integration requires another method such as prefixes, number translation, renumbering, or a limited set of reachable destinations. The right choice depends on user habits, migration plans, external numbers, and how long the two systems will coexist.

The SIP relationship must then match the network design. Some environments use authentication, while others identify a trusted peer by address. A PBX behind NAT may need different handling from two systems on a routed private network. If a VPN is involved, the engineer should confirm which addresses are advertised in SIP and where RTP media should travel. Asterisk PJSIP configuration can separate endpoint, authentication, address-of-record, identification, and transport concepts, so the implementation should reflect the actual trunk model rather than force every setting into one generic template.

Route order also matters. A broad pattern on one PBX may accidentally capture numbers intended for the provider. Asterisk contexts can serve as security and routing boundaries, so calls arriving from the Zycoo system should enter only the dialplan logic intended for that connection. The same principle applies on the Zycoo side: the remote trunk should receive only approved number ranges and should not create a route loop back to Asterisk.

Call quality and media-path validation

A call that rings successfully has proved only the signalling path. Users also need stable two-way audio. SIP negotiates the call, while RTP commonly carries the media stream, and those packets may follow different firewall or routing behaviour. One-way audio often indicates that one side cannot reach the media address advertised by the other system, but the exact cause still needs evidence. NAT, multiple network interfaces, VPN routes, firewall policies, asymmetric routing, or incorrect external and local network definitions can all contribute.

Codec negotiation is another consideration. Both systems need at least one compatible codec for the intended path, and downstream provider or gateway requirements may narrow the acceptable set. More codecs are not always better; a clear policy can reduce unexpected transcoding or negotiation behaviour. If calls traverse an Asterisk application, recording service, conference function, or external trunk, processing requirements may change.

Validation should represent the real business flow. Tests may include extension-to-extension calls in both directions, hold and resume, transfer between systems, DTMF where an IVR is involved, calls with typical duration, and external routes if they are explicitly part of the scope. Network quality should be considered when the systems are separated by a WAN, VPN, or internet path. A successful test at one moment does not guarantee future network performance, so ongoing monitoring or quality-of-service work may be recommended when the underlying connection is variable.

Security and access controls for PBX integration

Connecting two telephone systems creates a new trust relationship. The goal is to permit the traffic required for business calls without exposing unnecessary management interfaces or dialplan capabilities. Access should be limited to authorised systems and networks wherever the platforms support that design. Internet-facing SIP, management portals, VPNs, and remote administration should be reviewed in the context of the organisation’s firewall policy and provider requirements.

Asterisk contexts are particularly useful because they can restrict what an incoming channel is allowed to dial. A trunk arriving from another PBX should not automatically receive unrestricted access to every internal feature or outbound destination. The permitted extensions, applications, and onward routes should match the approved business use. On the Zycoo side, trunk permissions and dial rules should follow the same least-necessary principle. Where credentials are used, they should be strong, controlled, and stored through an approved process rather than published in documentation intended for general circulation.

Configuration backups, administrator ownership, and change records also contribute to operational security. If a future incident occurs, the support team needs to know who changed the route, which addresses are trusted, and how to return to the previous configuration. Security improvement reduces risk but cannot guarantee that a voice environment will never be attacked or misused. Platform updates, firewall management, provider controls, logging, and broader network security remain separate responsibilities that may require ongoing maintenance.

Testing, validation and handover

Testing should be defined before the change so everyone agrees what “working” means. For a basic inter-PBX link, the acceptance list may require a user on Zycoo to call a defined Asterisk extension range and a user on Asterisk to call back. For a migration project, the list can be wider: reception transfer, department hunt groups, voicemail paths, external calling, caller identification, after-hours behaviour, DTMF to an IVR, and selected emergency or priority routes where appropriate to the customer’s environment and telecom obligations.

The engineer should compare expected and actual results rather than rely on a single successful call. A call trace or log can show which route matched, what digits were sent, which endpoint handled the call, and why a rejected call failed. Where media problems exist, signalling success and RTP reachability should be assessed separately. Failed cases should be recorded with enough information to distinguish a PBX configuration issue from a provider, firewall, network, or endpoint dependency.

Handover may include a simple diagram or written route summary, extension-range ownership, trunk names, relevant network addresses, backup location, important provider dependencies, maintenance notes, and a record of the test cases completed. The level of documentation depends on the approved scope. A clear handover is particularly valuable for phased migration because future engineers can see which users still depend on the old system and which routes can eventually be retired.

Capability focus: faster fault isolation through route visibility

The most useful outcome of a well-documented integration is not a promise that faults will never happen. It is the ability to narrow them down more quickly. When the support team knows which extension range belongs to each PBX, which trunk carries the call, which context receives it in Asterisk, and what number format crosses the connection, a failed call can be investigated methodically. The engineer can ask whether the call left the source PBX, reached the destination PBX, matched the expected route, rang the endpoint, and exchanged media.

This structure matters because user descriptions are often broad. “Branch calls are down” might mean one dial pattern was changed. “Asterisk cannot call Zycoo” might be limited to a new department range. “No audio” may mean signalling is correct but media is blocked. Clear route visibility prevents unrelated settings from being changed simply because they are nearby in the administration interface.

The benefit is especially important in environments with several providers or administrators. FourTeck can help produce a practical record that shows where internal responsibilities end and where carrier, firewall, ISP, application, or vendor action may be required. Diagnosis still depends on available access and evidence, but a documented path reduces avoidable guesswork and supports more controlled escalation.

Capability focus: safer coexistence during migration

Many businesses cannot replace a telephone platform for every user at the same moment. Departments may move in batches, a carrier cutover may occur on a different date, or an old gateway may need to remain until a new connection is approved. Integration can support coexistence, but only if the temporary architecture is treated as a real production design rather than an improvised bridge.

A coexistence plan should identify which system owns each active user, which inbound numbers terminate where, how users call across the boundary, where voicemail lives, whether call forwarding can cross systems, and what happens when a user is moved from one PBX to the other. If external calls are centralised on one platform, route permissions and caller-ID presentation need careful review. If each system maintains its own provider connection, the migration team must prevent duplicated or conflicting rules.

Rollback should also be considered. If a migration batch is unsuccessful, the team should know which routes and user assignments must be restored. Backups of the relevant configurations and a change record are more useful than trying to remember settings under pressure. FourTeck can help structure the interconnection around migration stages, test the agreed workflows, and document what remains on each system. The duration and complexity of coexistence remain scope dependent, particularly where legacy devices, custom dialplans, recordings, gateways, or third-party integrations are involved.

Capability focus: maintainable call routing instead of hidden workarounds

Telephone systems often accumulate exceptions. A temporary prefix becomes permanent, one extension forwards through an external number because the internal route never worked, or a custom Asterisk pattern handles a department that nobody remembers. These workarounds may keep calls moving in the short term, but they make later troubleshooting and migration harder. Integration work is an opportunity to identify which behaviours are intentional and which are historical fixes.

Maintainability starts with simple questions: What number does the user dial? Which PBX should make the routing decision? Does the receiving system expect the full number or only the extension? Is the caller identity preserved or rewritten? What happens if the destination does not exist? Could the call match a public outbound route by mistake? Are there overlapping patterns? Answering these questions produces a route design that administrators can explain later.

Not every environment can be simplified immediately. A legacy application may require a specific number format, or a provider may impose routing rules that the customer cannot change. In those cases, the exception should be documented along with its reason. FourTeck can help distinguish required complexity from accidental complexity and provide recommendations for future clean-up. Any larger redesign, renumbering, or provider migration should be separately planned and approved.

Dependencies, access and customer inputs

Integration cannot be scoped accurately from the two product names alone. FourTeck may need details about the exact Zycoo platform or appliance, software or firmware version, independent Asterisk version, current SIP channel configuration, network addresses, extension ranges, trunk names, telecom providers, gateways, firewall platform, and how the business expects calls to behave. If the systems are in different locations, the connection between those sites also becomes part of the assessment.

Administrative access should be authorised by the customer. Credentials should not be posted in a public support form or visible page; they should be shared only through an approved secure method after identity and permission are confirmed. Where possible, the customer should identify who owns each system and who can approve changes to provider or firewall settings. If a third-party vendor manages Asterisk or Zycoo, coordination may be required before FourTeck can change or even inspect certain elements.

Backups matter because PBX changes can affect active call flows. The team should know whether current configuration backups exist, how they can be restored, and whether a maintenance window is required. A backup is not a guarantee of instant recovery; restoration may depend on platform version, hardware, licences, and the completeness of the saved configuration. The final integration scope is therefore access dependent, environment dependent, and sometimes vendor or provider dependent.

Risk, limitation and exclusion guidance

Business environments where the integration may be useful

Professional offices may use a Zycoo PBX for day-to-day extensions while an Asterisk system supports a specialised application or a new department. Retail or showroom groups may have branches acquired at different times and need controlled inter-site calling before standardising the estate. Warehouses and logistics operations may keep existing analogue gateways or paging-related workflows while moving office users to another system. Clinics, training centres, property-management teams, hospitality locations, and multi-branch businesses may also have mixed telephony environments created by expansion, relocation, mergers, or previous vendor decisions.

The operational context determines the design. A reception-heavy office needs transfer and caller-ID testing. A warehouse may depend on cordless or analogue endpoints connected through gateways. A multi-branch business may be more sensitive to WAN and VPN quality. A migration project may care most about coexistence and rollback. An application environment may need specific DTMF, codec, or dialplan behaviour. These requirements should be collected before the trunk is built because the “right” integration is the one that supports the actual call journey.

FourTeck can assist with the technical assessment, but customer stakeholders should explain which call flows are business critical. The person who understands reception behaviour or department routing may provide information that is not visible in the PBX configuration alone. Combining technical evidence with operational knowledge produces a more useful service plan.

Operational, security and maintenance considerations after integration

An inter-PBX connection should become part of normal change management. When new extension ranges are added, administrators should confirm whether the other system needs a corresponding route. When a firewall or VPN changes, the voice path should be included in the impact review. When either PBX is upgraded, trunk behaviour, codec support, certificates where used, authentication, and custom dialplan logic should be checked as part of the maintenance plan.

Logs and backups should be retained according to the customer’s operational and security practices. A clear contact list is also helpful: who manages Zycoo, who manages the Asterisk server, who controls the firewall, which provider owns external SIP services, and who can approve changes? In a fault, this prevents support time being lost while ownership is discovered. If the integration is temporary for migration, the documentation should include the condition for retirement so old routes do not remain active indefinitely.

Security reviews should consider management access, trusted peers, firewall exposure, unnecessary routes, administrator accounts, and whether the connected system can reach more destinations than intended. Maintenance should not be limited to the PBX interface; network switches, voice VLANs, routing, WAN links, UPS power, gateways, and provider services may also influence call availability. FourTeck can discuss preventive support or a broader IT maintenance approach where the customer wants recurring review beyond the initial integration project.

Before you contact FourTeck

Preparing a small amount of accurate information can make the first assessment more useful. You do not need to publish passwords or send sensitive credentials with the initial enquiry. Instead, prepare the facts that describe the environment and the business objective:

• Business location and whether the two PBXs are at the same site or different sites.
• Exact Zycoo model, platform family, and software or firmware version if known.
• Independent Asterisk version and whether PJSIP or another SIP channel configuration is in use.
• Current extension ranges on both systems.
• The call flow you want, described from the user’s point of view.
• Which call direction currently works and which direction fails, if troubleshooting.
• Sample dialled numbers and approximate time of recent failed test calls.
• Recent PBX, firewall, provider, VPN, or network changes.
• Network relationship between the systems, including VPN or public internet where relevant.
• Firewall or router platform and who is authorised to change it.
• SIP provider or telecom carrier details if external calls are included.
• Availability of current configuration backups.
• Administrator access availability without sending credentials in the initial message.
• A contact person who can place and receive test calls.
• Preferred remote or on-site support method.
• Any required maintenance window, building access rule, or operational restriction.

Service evaluation checklist for the quotation

How FourTeck can assist with the integration

FourTeck can help translate a business call requirement into a technical integration scope. The process can begin with an explanation of the current problem or planned change: for example, “users on the Zycoo PBX need to reach 6XXX extensions on Asterisk,” or “we are moving one department to Asterisk and need both groups to communicate during the transition.” From that requirement, the engineer can identify which configurations, network paths, and third parties need to be reviewed.

Assistance may include examining the Zycoo trunk and dial-rule environment, reviewing the Asterisk SIP and dialplan configuration, mapping extension ranges, checking reachability, testing call signalling and audio, reviewing firewall or NAT conditions, applying approved routing changes, and coordinating test calls with the customer’s users. If the issue belongs to a carrier or managed network, FourTeck can help organise the technical evidence so the customer has a clearer basis for escalation.

The quotation can separate initial assessment, configuration, on-site activity, network remediation, documentation, migration support, and any follow-on maintenance where appropriate. This helps avoid assumptions that every related telephony task is automatically included. Businesses can review broader technology support through the FourTeck IT Services website, explore the business IT service portfolio, read about FourTeck’s service approach, or use the contact page to request an assessment.

Dubai and UAE service coordination

For businesses in Dubai and across the UAE, the appropriate support method depends on the type of integration problem. A route, trunk, dialplan, or log issue may be suitable for remote assessment when secure administration access and a working network path are available. An on-site visit may be recommended when the job involves physical gateways, cabling, switches, voice VLANs, firewall appliances, local handset testing, or equipment that cannot be reached remotely. The service plan should identify which tasks can be completed remotely and which require physical access before scheduling is confirmed.

Installation, configuration, migration, and maintenance activities should be clearly included in the quotation. Timing depends on engineer availability, customer access, maintenance-window approval, site conditions, third-party provider action, and any required hardware or licensing. Where a telecom provider must activate, change, or troubleshoot a service, the project may depend on that provider’s schedule and technical policies. FourTeck can coordinate within the approved scope but cannot guarantee a third party’s completion time or outcome.

Customers should also consider site access and operational restrictions. Data centres, managed buildings, warehouses, clinics, and corporate offices may require visitor approval, escort arrangements, change tickets, or after-hours access. Sharing these requirements during quotation planning helps align technical work with the customer’s business environment.

Coverage coordination across Dubai, Abu Dhabi, Sharjah and Ajman

FourTeck can coordinate telephony integration support for customers with sites in Dubai, Abu Dhabi, Sharjah and Ajman according to the confirmed scope. A multi-site project may combine remote configuration review with planned on-site work at one or more locations. For example, an engineer may review the Asterisk dialplan and Zycoo trunk settings remotely, while a local visit is scheduled where a gateway, firewall, switch, voice VLAN, or handset group needs physical testing.

The service plan should account for travel, building access, equipment availability, maintenance windows, local contacts, and the network relationship between sites. If one PBX is hosted or located in a data centre, that facility’s access procedure may also affect scheduling. If the systems communicate through an ISP circuit, VPN, or managed firewall, third-party change approval can become part of the timeline.

A combined approach helps avoid repeated work. The same route map, extension ownership record, and test plan can be used across the project, while site-specific differences are recorded separately. The exact coverage, attendance method, and schedule should be confirmed with FourTeck before work begins rather than assumed from the city alone.

Related FourTeck IT service areas

Why businesses contact FourTeck for mixed telephony environments

Mixed PBX environments often cross boundaries between telephony, networking, security, internet connectivity, and provider services. A call problem may start at an IP phone, pass through a switch and voice VLAN, reach the Zycoo PBX, cross a SIP trunk, enter an Asterisk context, and then depend on another route or carrier. Looking at only one administration screen can miss the actual dependency. FourTeck approaches the issue as a connected technical path and can help identify which layer needs attention.

Businesses also need clear decisions rather than unexplained configuration changes. The assessment should describe what is currently happening, what the desired route should be, which change is proposed, what could be affected, how the result will be tested, and what remains dependent on another provider or system. This approach is useful for IT managers and office administrators who need to approve work without becoming PBX programmers themselves.

Documentation and handover are another practical reason to involve a service provider. A working integration that exists only in one engineer’s memory becomes a support risk. Recording extension ranges, trunk purpose, route ownership, provider dependencies, and test outcomes gives future administrators a better starting point. FourTeck can include that documentation in the agreed scope and can discuss follow-on support if the customer wants help maintaining the environment after the initial change.

Can Zycoo and Asterisk be connected with a SIP trunk?

A SIP trunk or SIP peer relationship is a common technical approach for connecting separate PBX systems, and Zycoo documentation confirms that its IP PBX platform supports standard SIP while Asterisk provides SIP channel and dialplan functionality for trunking and call routing. The exact configuration still depends on the Zycoo model or platform, Asterisk version, network relationship, authentication method, firewall policy, codec requirements, and desired numbering plan.

Before choosing the method, define whether both systems are on the same routed network, connected by VPN, or separated over the public internet. Also confirm whether the link is intended only for internal extension calls or whether one PBX will send calls onward to an external carrier. That distinction affects security and routing decisions. Where possible, limit the trunk to the destinations required by the business rather than creating unrestricted access between platforms.

If an existing trunk is already present but unreliable, preserve the current configuration before replacing it. Logs from failed calls can reveal whether the problem is registration, endpoint identification, route matching, dialled digit format, codec negotiation, or media reachability. FourTeck can review these factors and propose changes based on evidence rather than rebuilding the connection without a diagnostic baseline.

Can the integration be checked remotely?

Yes, many configuration and routing issues can be assessed remotely when both PBXs are reachable through an authorised method and a customer representative can assist with test calls. Remote review may cover Zycoo trunk status, dial rules, Asterisk PJSIP or SIP configuration, dialplan contexts, extension patterns, logs, network addressing, firewall policies, codec settings, and recent changes. It can be especially effective when calls fail predictably and the systems provide enough logging to compare the expected route with the actual result.

Remote support becomes less effective when the suspected problem is physical. An unstable switch port, damaged cable, gateway power issue, incorrect patching, intermittent WAN handoff, or equipment with no remote management may require someone on site. In larger offices, local testing can also be valuable when the behaviour differs between departments or VLANs.

When requesting remote assessment, prepare the approximate time of recent failed calls, source and destination numbers, screenshots or error messages where available, and a contact who can repeat the test. Do not send administrator passwords in the initial public enquiry. Confirm a secure access method after the support scope and authorisation are established.

What if calls work only from Zycoo to Asterisk, but not back?

One-way reachability usually means the two call directions are not equivalent somewhere in the route, but it does not identify one specific cause. The failing side may be sending a different number format, using a route pattern that does not match, entering the wrong Asterisk context, failing peer identification or authentication, being blocked by an access control rule, or trying to send the call through a provider route instead of the inter-PBX trunk. The receiving system may also lack a route back to the source extension range.

The diagnostic process should compare a successful call and a failed call. What digits are sent? Which trunk is selected? Does the destination PBX see the incoming SIP request? Which context or inbound route receives it? Does the destination extension exist in that routing scope? If the call reaches the destination PBX and is rejected, the local log often narrows the issue. If it never arrives, the source configuration or network path deserves more attention.

Avoid widening all routes or disabling security controls simply to make the call pass. A narrow, documented correction is preferable because it protects other call flows. FourTeck can help isolate the failing stage and apply the approved change while keeping the permitted number ranges clear.

What if calls connect but there is no audio or only one-way audio?

When the phones ring and the call answers, SIP signalling has progressed far enough to establish a session. Audio problems then point attention toward the media path, although codec and signalling details can still be relevant. The engineer may review the addresses exchanged during call setup, RTP port handling, NAT rules, local and external network definitions, firewall policy, VPN routing, and whether either PBX advertises an address the other cannot reach.

The problem can be direction specific. Audio from Asterisk to Zycoo may work while return audio fails, which suggests that one side’s media packets are not reaching the other. Comparing packet direction, interface counters, and call traces can help. If the systems are separated by the internet, a session border controller, managed firewall, or provider device may also influence the media path. If transcoding is required, codec support and server capacity may become relevant.

An on-site visit is not always necessary, but it may help when the issue depends on physical network equipment or a managed device that cannot be inspected remotely. The final recommendation should be based on observed traffic and configuration rather than assuming that every one-way audio problem is caused by the same NAT setting.

Can existing extension numbers stay the same?

Often they can, especially when the two systems use distinct ranges, but this is configuration dependent. If Zycoo uses one range and Asterisk uses another, each PBX can usually route the remote range across the integration without changing the user’s familiar number. If the systems have overlapping extensions, however, the same digits cannot automatically mean two different destinations within one routing context. A decision is needed about prefixes, translation, renumbering, or limiting which overlapping numbers are reachable.

Migration projects should also consider direct inward dial numbers, reception routes, voicemail, queues, and speed-dial habits. Keeping an extension number is only one part of continuity. A user moved to Asterisk may still depend on a public number terminating on Zycoo, which means the inbound route must forward the call across the interconnection until the carrier migration is complete. Conversely, outbound caller identity may need to remain associated with the existing provider connection.

Before promising that all numbers can remain unchanged, map the current numbering plan and identify conflicts. FourTeck can help produce that map and explain the practical options. Any renumbering should be coordinated with users, directories, printed material, applications, and external contacts where relevant.

Is this better than replacing one PBX immediately?

Integration and replacement solve different problems. Connecting the two systems can be useful when coexistence has a clear business purpose: a staged migration, a branch transition, a specialised application, or a temporary dependency that cannot yet move. It allows the organisation to change in smaller steps. However, maintaining two PBXs also creates more routing, security, backup, documentation, and support responsibility than operating one standardised platform.

The decision should therefore consider lifecycle, supportability, feature requirements, administration skills, user count, provider compatibility, migration risk, and the expected duration of coexistence. If both systems are current, well documented, and serve distinct purposes, a longer-term integration may be reasonable. If one system is obsolete, unreliable, or poorly supported, a complicated interconnection might only postpone a necessary migration. In that case, the integration should have a defined retirement plan.

FourTeck can assess the current environment and help compare the effort required for integration with the effort required for migration. The result is not automatically “keep both” or “replace one.” The appropriate path depends on the customer’s business objectives, budget, maintenance expectations, application dependencies, and tolerance for change.

What information affects the final service scope?

The number of systems is only one factor. Scope grows when the environment includes several sites, overlapping extension ranges, multiple SIP providers, analogue or GSM gateways, custom Asterisk dialplan applications, call recording, queues, remote users, VPNs, firewalls controlled by third parties, or strict maintenance windows. A simple internal trunk can be very different from a migration project where public numbers and reception workflows must be preserved throughout the change.

Access is equally important. If administrators can provide current backups, diagrams, IP addressing, and authorised login access, the engineer can spend more time testing the actual route. If the environment is undocumented, the first stage may need to be discovery. If another vendor owns the Asterisk server or telecom carrier configuration, FourTeck may need to coordinate rather than change those elements directly. The quotation should make these boundaries clear.

Testing requirements also affect scope. A business with two internal extension ranges may need a short validation list. A contact centre, clinic, hotel, or multi-branch office may require many scenarios involving reception, queues, transfers, after-hours behaviour, caller ID, DTMF, or external routes. Define those acceptance cases before work begins so the project is measured against the real business requirement.

What should be tested after configuration changes?

Testing should cover the routes that justified the integration. At minimum, verify representative calls from Zycoo to Asterisk and from Asterisk to Zycoo. Use more than one destination if different dial patterns are involved. Confirm the displayed caller identity, answer the call, and check two-way audio. If the business needs transfers across the boundary, test attended and blind transfer as appropriate. If a menu or application depends on keypad input, verify DTMF. If external provider calls are part of the scope, test only the approved outbound and inbound scenarios.

Negative testing is also useful. A number that should remain local should not unexpectedly cross the trunk. A destination that is not authorised should not become reachable simply because a broad route was created. If a route has a fallback, confirm what happens when the remote PBX is unavailable. In a migration, test a user who has moved and one who has not, because their paths may differ.

Results should be recorded with date, source, destination, expected behaviour, and observed result. If a test fails because of a provider or third-party network, document that dependency rather than marking the whole integration as complete. This produces a clearer handover and gives the customer a practical list of remaining actions.

How should businesses prepare for a staged migration?

Start with an inventory of users, extensions, direct numbers, departments, phones, gateways, queues, voicemail, recordings, reception rules, and provider connections. Mark which items will move in each stage and which must stay on the existing PBX. Then map the dependencies between them. A user may move to Asterisk while the public number still terminates on Zycoo, or a department may move while its queue remains on the old platform. The inter-PBX route must support those temporary relationships.

Choose a pilot group where the business can test normal workflows without exposing every user to the change at once. Define rollback before the pilot starts. Keep configuration backups, record the original routes, and know how to return the pilot users to their previous path if a critical issue appears. Inform reception and support teams because they often notice call-flow changes first.

After each migration stage, update the route map. Temporary patterns should not accumulate without ownership. Once a number range or provider route is fully moved, confirm whether the old interconnection rule can be removed. FourTeck can support discovery, route planning, testing, documentation, and post-change troubleshooting within the agreed migration scope. Migration duration and downtime depend on the environment and should not be assumed before assessment.

Frequently asked questions